Rethink Requirements Gathering with the Power of Three

Collaborative requirements gathering for a more agile, human-centered future — breaking down barriers between business analysts, designers, and architects.

One of the agile principles underlying the Agile Manifesto is that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” This principle, as with other agile principles, applies to more than just software development and can also be used in making processes and management more efficient.

The application of this principle is what allowed the process of requirements gathering to evolve in such a way that enables the discovery and definition phase of a project to not just be more agile but also more human-centered.

Old School Requirements Gathering: the Linear Flow

Until recently, when someone asked if we had the requirements documented, they typically meant the business requirements. If there was any further breakdown, it would be between functional and non-functional requirements.

The process of gathering requirements followed a linear flow. First, we gathered what were called user requirements, though stakeholder requirements was a more accurate label. After analyzing the stakeholder requirements and gaining alignment and consensus, we organized them into business requirements. We then handed those business requirements over to designers to put together the UI/UX designs and to technical architects to assemble the technical requirements and diagram the architecture.

That all sounds straightforward and fairly simple until you start thinking about the potential issues. What if an architect decided a business requirement is impossible to implement? What happens if a designer points out that a business requirement results in a poor user experience? In such cases, we had to go back to the stakeholders, reevaluate the requirements, and essentially repeat the entire process. Due to the time and effort invested, this approach often resembles a waterfall strategy that requires significant revisions.

Ultimately, the problem with this approach is that designers and architects need to be more involved in the process.

New School Requirements Gathering: Bringing It All Together

To address the issues associated with the linear method, we turn to Scrum and Enterprise Design Thinking. These frameworks share common principles: continuous and rapid iteration to facilitate constant learning and improvement, as well as a strong emphasis on collaboration.

Instead of relying solely on the work of business analysts in a linear flow, we foster collaboration among designers, architects, and business analysts. This approach ensures that the knowledge and insights from one group are immediately shared with the other two. The end result? Each group receives immediate feedback on the feasibility of the requirements and their potential to result in a satisfactory solution for the client.

Let’s take a look at a simple example to illustrate the importance of this collaborative effort. Imagine a scenario where a client has an old product that no longer meets customer needs, so they want a replacement product built from scratch. In response, the definition team gets to work. Business analysts, designers, and architects come together to gain a better understanding of the client’s request and initiate their research. The research process may involve immersion sessions and interviews, among many other methods, but ultimately provides a more comprehensive perspective on the project, considering the viewpoints of multiple stakeholders and users.

Throughout this phase, the definition team collaborates to ensure a shared understanding of all types of requirements. In the end, the full definition team can present to the client a holistic approach to solving their problem, effectively balancing user needs, desired business outcomes, and technical feasibility.

The Power of Three

With something as fundamental as requirements gathering, breaking down barriers between business analysts, designers, and architects results in the following:

• Better collaboration and communication between the three practices
• Useful insights from different perspectives
• Mutual support where one practice can help fill in a gap identified by another practice
• Ability to react more quickly to changing requirements and understandings of requirements
• Reduced long-term rework

And that is the impact of the Power of Three, where team members blend strategic insights and thoughtful design with brilliant engineering. But the Power of Three isn’t just something that sounds nice. It’s a working, practical strategy we use to bring together different perspectives and thought processes into a single and exciting solution that maximizes business value for our clients.

Original post here.

Authored by David Tomov-Strock:

As a Senior Business Analyst II, David understands our clients’ wants and needs and translates them into requirements that engineers use to build a product. His work requires him to think like a product owner and an engineer. In addition to his client responsibilities, David also serves as a mentor and trainer to help other BAs improve their skills. He’s helped many fellow BAs strengthen their skills and achieve “aha” moments when complex concepts suddenly clicked. Success for David comes when he reaches the point in a project where he knows exactly how a product owner will respond to a question from an engineer.

With an undergraduate in biology and advanced degrees in gastronomy and computer science, David’s career has meandered down several different paths to get to where he is today. He’s worked in higher education in student employment, academic advising, program administration, and financial aid. He’s even earned certificates in culinary arts and cheese studies. It was his work in financial aid where he began to gain his technical and BA skills. He moved from the U.S. to Bulgaria and worked in a small software development firm where he had to wear many hats like PM, BA, QA, and occasionally front-end developer. After realizing he was most interested in BA work, he joined the MentorMate BA team.

David lives in a remote village in Bulgaria, which has helped him explore his interests in the outdoors. He has five dogs and ten chickens and spends plenty of time tending to his vegetable garden and hiking through the mountain forests in search of wild berries and mushrooms. During the winter months, David enjoys spending time indoors cooking and reading.