Requirement Definition Template

Tags

business requirements definition analysi...

Description

This is the template used to document and classify the various high-level requirments identified during interviews with the clients. Those templates were then merged into a Business Requirements document for Management.

You must be logged in to download this document

be first to review

Requirement: Reference ID Definition Importance Justification Activities Involved Data Information/Reports Business Process Technical Technology Requirement Policies, Standards, QA External Environment Other Type of Requirement Complexity High Medium Low Priority Mandatory Value Added Optional Any Concerns Risks? Resources Needed Est. Effort Analyze Hrs/Days Develop Hrs/Days Overall Hrs/Days Costs Estimates Definition A description of the business requirement or feature that the business users want in their application. It’s a high-level natural language statement that is expressed as clearly as it is possible. Try to avoid ambiguity as much as possible. Importance Justification Ask the business/application users to express the importance of this requirement. How can you justify this requirement? What justifications can you make in regards to this new requirement? How important is it for the business? What are the consequences of not implementing the requirement? Type of Requirement This section is used to classify the requirement into six different categories. The Analyst must check the one(s) that apply: • Data: A new data requirement that needs to be captured. • Information/Report: A new report (information) needs to be included. • Business Process: A new/modified business process that results in how the application works. Processes have a tendency of changing often and therefore impact the application. • Technology/Technical Requirement: Some requirements may be specified in terms of technology and other hardware infrastructure. • Policies/Standards/QA: Requirements that are intended to enhance the quality of the system in question. Example: schedule of operations, training requirements, and performance standards. • External Environment/Other: Any non-functional requirement that comes from outside the business like government regulations. Complexity This is a ballpark estimation of how complex a given requirement could be. The estimation is based on the definitions given, the Analyst’s experience, and a highly attuned intuition. The gauge uses: • High: The requirement is highly complex (usually difficult to describe in simple terms and the definition is exhaustive). It may take weeks to develop and resolve. May be broken down into simpler activities. • Medium: The requirement is not overly complex but will require days to develop. • Low: The requirement is not complex (low complexity) and can be programmed and resolved in a few hours. Priority A requirement can be further classified as to its urgency and priority within the development efforts. Prioritization is extremely important in scope definition. • Mandatory: The requirement must be adopted as soon as possible and there is no alternative. The success of this project depends on this requirement. Not including this requirement in this project will be perceived as unsuccessful by the users. Directly affects the mission and objectives of the business. • Value Added: This is medium priority because the requirement in question adds real value to the project if we decide to include it. If the requirement in not included in this project, the project might still be successful. The requirement improves the existing application by adding something of value to the user community. Not implementing the feature might impact the morale and perception of the user. • Optional: A requirement that is optional is often referred to as “nice to have” but has no direct impact on the business mission and its objectives. They are often based on personal preferences like the color of the menu bar. Whether we implement it or not has no bearing on the success of the project. Any Concerns? This box is used to describe any concerns that may be expressed by anyone regarding this requirement. Concerns are often used to detect the level of risk in a project. Look at the comfort or body language of users when dealing with this requirement. Look for disagreements, expressed fears, ambiguity etc … Resources Needed Describe the special resources that you will need in integrating this requirement with the application/project. Special resources can be expressed in terms of dollars, people skills, training, equipment and technology. Est. Days Estimate the number of person-days effort needed to complete this requirement into this project. Based on experience and the facts presented so far, how much effort/time will be needed in terms of analysis, development and testing. Activities Involved Can the requirement be subdivided into several activities or several components? Some requirements are very complex and can be broken down into simpler tasks to do or activities. “Divide and Conquer.” Having several activities to estimate is easier than estimating just one big requirement.