Endorse Maximize your ROI, minimize your project risk Consulting
The Fine Art of Gathering and Documenting Requirements We’ve all done this many times and know it is about as much fun as a stick in the eye but it has to get done. So can we make it a fun activity? Maybe. For sure though, we can make some changes to the process so it isn’t as painful. In fact, it is also possible to make quantum leaps in the effectiveness of requirements with very little effort.
The following paragraphs will explain how you can help your project by gathering more complete business and technical requirements, ensuring that gaps in the design do not exist, and test coverage is significantly improved.
Quality Assurance You may be wondering why mention Quality Assurance (QA) upfront. Well simply put, if you expect to produce a quality product, quality needs to be built into the product at the very beginning. What we are looking for here from the QA perspective is to ensure that Requirements Traceability can be easily accomplished. The objective for Requirements Traceability is to pick any requirement from the business, technical or test case document and be able to quickly identify the corresponding requirement all of the associated documents.
To get a better understanding of what is meant by requirements traceability, let’s take a look at Figure 1 below. We see 2 business requirements generated 4 technical requirements; each technical requirement spawned 4 test cases.
Figure 1 – Example of Requirements Traceability
This graphic simplifies the relationship between the business requirements, technical requirements and test cases. How you maintain the actual relationship in real practice is not as simple. One approach that can be used to tie the different documents together is to derive a numbering system that can be inherited by the subsequent documents as a reference as shown in Figure 2.
Figure 2 – Requirements Traceability Outline
• Business Requirement 1
• Technical Requirement 1 (refers to Business Requirement 1)
• Test Suite 1 (refers to Technical Requirement 1)
Test Scenario 1.1 (refers to Technical Requirements 1.1)
Test Case 1.1.1 Test Case 1.1.2 Test Case 1.1.3 Test Case 1.1.4
Test Scenario 1.2 (refers back to Technical Requirements 1.2)
Test Case 1.2.1 Test Case 1.2.2 Test Case 1.2.3 Test Case 1.2.4
By coming up with a logical structuring of the business document, the task of reconciling business and technical requirements becomes much simpler and more effective. You can also almost guarantee yourself full test coverage if your test case development follows the same methodology. The take away here is to note the importance to structuring the business requirements at the start of the project which will drive the outline structure for the subsequent documents.
Business Requirements So what is the best way to capture business requirements? Lock your users in a room and grill them for 8 hours, send out a survey, or maybe just make them up yourself. These approaches have all been used to varying degrees of effectiveness, but whichever method you use, your requirements will still go through several iterations of brainstorming and review before they are complete.
Using the example from Figure 1, assume the first business requirement states “Track Customer Purchases”. That sounds straight forward enough but there is no mention of what to do when an invalid condition is encountered or a purchase is cancelled. Granted that this is a weak example, but my point is when the business requirements have ambiguity or omissions, this may not become apparent until the technical requirements are being developed. Even worse, these issues may not surface until design and development.
To flush out these hidden details, you will need to gather the requirements from your users in bite size chunks based on what their tolerance level is for time and their attention span. This will be an iterative process because you too will have work to do from gathering the business requirements. As the requirement sessions progress, you should build a mock up of the application based on what you have to date. This will become your platform for discussion explaining how you view what the customer is asking for. This will help your customer make the leap from concept to reality now that they have something concrete to relate their ideas to.
Your platform mock up does not have to be a working model at this point. A simple slide presentation or static web pages will suffice. Don’t be surprised if your business requirements change drastically at this point because your customers may view what they were asking for in a whole different light now. Before you call the business requirements a wrap, have a walk through of the document to ensure all the content is still required and that no ambiguity exists.
A tip for who should be part of the audience when gathering your business requirements besides your users is representation from development and test. You may not need/want them initially, but you certainly want them involved once you get to the mock up phase. I can’t say enough about how important early buy in is for the project to succeed.
Technical Requirements Now that you have a robust set of business requirements it is time to begin developing the technical requirements. Your technical requirements document should maintain the same structure as the business requirements wherever possible. If you need to deviate, ensure there is traceability back to the business requirements.
Once you have the technical requirements to the point where the system flow is well defined, a working prototype should be developed. The prototype does not need to do more than convey the screen logic flow and basic functionality. The intent of presenting the prototype is to ensure the technical requirements accurately reflect the business requirements. The prototype will also benefit everyone on the development side of the house to gain an understanding of what is to be built. You most likely will be peppered with some tough questions from the crowd but this is good constructive criticism. If you follow this advice, fewer issues are likely to surface during the design phase.
Test Case Document Testing is one of my personal favorites although it does not get the respect it deserves. Testing to me is truly an art where the number of test cases generated is limited by the imagination of the tester. Not having a good method of documenting the test cases further limits the effectiveness.
If we follow the same outline methodology as in the business and technical requirements, tracking requirement test coverage becomes a non-issue. This structuring of the test cases will also allow for easier selection of test case scenarios and a more manageable method of organizing the test cases if they are to be automated.
Summary If you implement any or all of the suggested approach above, you are certain to improve upon your existing process. The requirements gathering techniques described here are a proven method for building a solid foundation for your application. Since no one can guarantee a 100% fool proof method, I would put this one up as one of the contenders to come close.
Ken Pohl is the president and founder of Endorse Consulting which specializes in minimizing the risk to a project’s ROI by mitigating potential problems before they arise. His many years of developing and implementing data warehousing, business intelligence and CRM systems has provided a wealth of knowledge as proven techniques. These techniques translate into real world not from a book “best practices”.
