Once requirements are gathered, many of us believe the worst is over, but that is not true! Tracking the status of each and every requirement throughout the development phase often takes more time and effort than gathering, approving and prioritizing the requirements all put together.
This article shows you in seven simple steps how to develop, document, track and test business requirements throughout a release. Business requirements can be difficult to manage, but by following these steps, you can be confident that all business requirements will be part of the final release.
1. A blank sheet of paper
How do you begin the process of collecting requirements for an upcoming release? Let’s start at the very beginning where all you have is a blank sheet of paper. What is the first thing you can do to identify business requirements?
A good way to start developing requirements is to think about what is not working with the existing software. For example, the existing application has a free flow text box where product information is entered, making it impossible to collect standardized
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
data results. Users are
entering the wrong information, as well as using highly creative words to describe the same product
information. You need a simple pull-down menu with standardized product information. This is your
first business requirement and your page is no longer blank. Continue to add to the page other
changes or requirements you would like. At this stage, do not evaluate the quality of the items on
the list as you will do that later in the process.
2. Requirements vs. wish list
The list you created above will really be more of a wish list than a true requirements document. This is because you have not yet had business and development discuss and agree what items are realistic for upcoming releases, given the resources, time, and money available for the release. Once business and development have reviewed and discussed the list, you can develop a Business Requirements Document (BRD) that has solid, achievable requirements in it.
3. Prioritization process
The BRD documents the requests for enhancements (RFE), but it does not prioritize the RFEs or bug fixes. A good plan at this stage is to have development spend time scoping each RFE. Development will come back to business with how much time each requirement will take to complete, plus the duration and cost. With this knowledge in hand, development can guide business into creating a release package that has the most important requirements in it, taking into consideration the scope, time and cost of each requirement. You now have the requirements for the next release, plus a list of great RFEs for future releases.
You are in a very strong position for a successful release, but there is still more to do to make sure these requirements do not get lost or missed during the development cycle.
4. Specifications
The BRD is used by development to create two specifications: functional and technical. Joel on Software defines these two specs as:
A functional specification describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on.
A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.
Both of these documents need to be approved by business before any coding is started. It is understandable that business may not understand the technical specification, but an overview of the specifications is still needed before business signs off on these documents as these will show how each requirement from the BRD will be included in the release.
5. Timeline and Milestones
After business approves the specifications, development creates the timeline with the various milestones for the release. Again, the timeline and milestones will continue to show how the requirements will be implemented in the release. Business needs to ensure that all requirements are again located in these documents prior to signing off.
6. Development Phase
Finally! Development gets to do what it is best at. Develop code! The BRD, specifications, timelines, and milestones are all approved. Development knows exactly what needs to be done and is confident that all requirements will be included in the release.
However, the only way business will know that all the requirements are being included in the code is to have regular meetings with development where screen shots and features are reviewed. The milestone document is a good guideline for how often these review meetings need to take place. Any deviation from the approved documentation can be quickly corrected with these reviews, a critical step to a successful release.
7. User-Acceptance Testing
Due to the strong documentation and regular review meetings, there will be minimal surprises during user-acceptance testing. All requirements will be part of the test plan and test cases, allowing business to test and accept the requirements that were agreed to at the very beginning of this process. In addition, the test plan will allow business to go off of the controlled test cases to see if the new requirements break other parts of the software.
Back to the beginning
By following these seven steps, you can develop, document, track and test the requirements throughout a development phase to ensure that all of them become part of the final release. Although these steps take time and energy, without them, requirements can easily get lost during a release cycle, something no one wants to happen.
This was first published in March 2011
Join the conversationComment
Share
Comments
Results
Contribute to the conversation