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.
This article 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.
You may be wondering why I mention quality assurance (QA) upfront. 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. We see two business requirements generated four technical requirements; each technical requirement spawned four 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
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.
So what is the best way to capture business requirements? Lock your users in a room and grill them for eight 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 straightforward 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 that 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 their timeframe and their attention span. This will be an iterative process because you will also have work to do from gathering the business requirements. As the requirement sessions progress, you should build a mockup 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 mockup 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 to include in the audience when gathering your business requirements (besides your users): development and testing. You may not need or want them initially, but you certainly want them involved once you get to the mockup phase. I can't say enough about how important early buy-in is for the project to succeed.
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 is truly an art, in which the number of test cases generated is limited only 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 nonissue. 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.
If you implement any or all of this suggested approach, 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% foolproof method, I would put this up as one of the contenders to come close.
For more information on related topics visit the following related portals...
Business Intelligence (BI),
Ken Pohl is the president and founder of Endorse Consulting (www.EndorseConsulting.com) 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. You can reach Pohl at KenP@EndorseConsulting.com