Requirements Capture

Properly capturing requirements is one of the keys to the success of the project. Below are most important issues to look at when gathering requirements:

1. There are 3 levels of requirements:
   a. Business Requirements - high-level objectives of the project
   b. User Requirements - functionality available to the user, captured in Use Cases
   c. Functional Requirements - detailed description of functionality that the software must provide. This and other non-functional requirements are recorded in Software Requirements Specification (SRS).
    
2. Involve the end-user or customers as much as possible during the requirements capture stage. Identify various user groups and one representative individual from each group for inputs regarding their specific requirements. They could also review prototypes and the SRS to ensure completeness and effectiveness.
    
3. Ensure that the requirements are quantifiable and measurable. Areas that are unclear may require more detailed analysis or even the development of a prototype. Developing Test cases early also help reveal any gaps in the requirements capture. Verify the completeness of the requirements by formally inspecting the documents generated.
    
4. Prioritize Requirements by their relative importance. This will help weed out high cost-low value functionality. It will also help in making informed and critical decisions when faced with time/ resource and functionality tradeoffs. Identify and remove any functionality which will not be used or which do not help meet any of the business objectives.
    
5. Ensure that the project scope is clearly defined in the Vision and Scope document. Expect some amount of requirements growth and buffer for it, since rarely is the project deadline changed, additional resources provided or any existing functionality deleted to compensate for it. Effectively using requirement gathering methods and base lining the requirements specifications also helps avoid scope creep. All parties involved must realize that future additions will add to the cost.
    
6. Establish and enforce a clear and realistic process for change management. Prioritize the proposed requirement changes against the requirements yet to be implemented. Ensure that each change and its impact are sufficiently analyzed to avoid unforeseen complexities and slipping project schedule and deadlines. Analyze associated costs and benefits and all the associated tasks and resource impacts. Also, be disciplined about following suitable version control policies to ensure that all the project participants are working on the latest requirements.
    
7. Finally, while it is important to have a complete set of requirements to start design and development, it is also important not to get bogged down at this stage. After a set of requirements has been fully identified, development can begin on this while unclear requirements continue to get analyzed and clearly defined. The iterative model or phased approach is better than the waterfall model in these cases.

More about our services...