We are often asked by Business Analysts, “How do I know when requirements are complete?” I was intrigued with one such person’s attempt to answer this question for his Master’s thesis using a Requirements Completeness Model (see Figure 1, Alexander, 1990). Alexander elegantly represents in his quadrant model what we already know, that business analysis is not easy stuff. To get complete, correct, unambiguous, verifiable, necessary, feasible and prioritized, “excellent” requirements (Wiegars, 1999), the Business Analyst is compelled to possess curiosity, talent, business analysis knowledge, and skills.
In his diagram, Alexander describes Block A to be the requirements that we know and we know they trace to the scope, objectives, and purpose of the project. We have understood and documented these requirements. There are three remaining blocks of requirements for which we need to do more work. The goal for a complete requirements package is that requirements all eventually move to Block A.
Block B represents requirements that we know, but we have not really thought about, verbalized, or documented. Think of the organizations that outsource to external development teams. Think of your own projects. How many times have your solution teams missed the obvious because you did not explicitly tell them about those requirements? It happens all the time. Of course once documented they can move to Block A.
Block C represents requirements we know that we need, but we do not quite understand them. Therefore we must identify outstanding questions and perform more investigation to fully describe what we don’t understand. Once they are uncovered, understood, and documented, they move to Block A.
Lastly Block D represents those requirements that we do not know and that we do not know that we do not know. So, how do we find them? The savvy Business Analyst, by continued investigation and using the appropriate techniques with subject matter experts can gather and elicit the missing requirements. Techniques such as reviewing existing documentation, using facilitated requirements sessions, conducting interviews, surveys, focus groups, and job observations can be selected. Using different modeling techniques also allows the Business Analyst to see the different dimensions of the requirements and discover those hidden but critical requirements. The Business Analyst needs knowledge and skills in varied analysis techniques such as data modeling, process decomposition modeling, process mapping, work flow analysis, use case modeling, prototyping, or simulation techniques. The experienced Business Analyst, when employing the right tools with the right audience in the appropriate venue can uncover, document, and move Block D, represented requirements, to Block A, known requirements, and finally requirements are complete!
Alexander, L, Selection Criteria for Alternative Software Life-Cycle Process Models, Software Engineering M.S. Thesis, Fairfax, VA: George Mason University, 1990.
Thayer, Richard and Dorfman, Merlin, Software Requirements Engineering – 2nd Edition, IIEE Computer Society Press, Los Alamitos, CA, 1997.
Wiegers, Karl E., Software Requirements, Microsoft Press, Redmond, Washington, 1999
- Being part of the solution - May 1, 2012
- What’s the difference between ordinary and extraordinary… - March 14, 2011
- Lots of resources to learn about agile - May 10, 2010
- Agile and the BA – Part 1 - March 23, 2010
- Is It Really Tyranny of Best Practices? - February 20, 2010
- BAs are Bridge-Builders Instead of Bridges - January 25, 2010
- James Bond and Business Analysis - January 18, 2010
- Should the BA scribe at a team meeting? - August 4, 2009
- Why do we need detailed business requirements? - July 28, 2009
- Updated CBAP® Handbook now available for download - July 14, 2009