The Requirements Problem Chapter 1. Standish Group Research. Research paper at: http://www.standishgroup.com/sample_research/chaos_1994_1.php (1994) 31.1% of project get canceled before they ever get started 52.7% of projects will cost 189% of their original estimates
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
The Requirements Problem
Unit cost of 1 is assigned to effort required to detect and repair an error during the coding stage, then the cost to detect and repair during the requirements stage is 5 to 10 times less
Intro to Requirements Management
• Assess the business and technical feasibility for the proposed system.
• Identify the people who will help specify requirements and understand their organizational bias.
• Define the technical environment (e.g., operating system, telecommunications needs) into which the system or product will be placed.
• Identify “domain constraints” (i.e., characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to be built.
• Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings).
• Solicit participation from many people so that requirements are defined from different points of view.
Analysis categorizes requirements and organizes them into related subsets; explores each requirement in relationship to others; examines requirements for consistency, omissions, and ambiguity; and ranks requirements based on the needs of customers/users.
As the requirements analysis activity commences, the following questions are asked and answered:
The following questions represent a small subset of those that might be asked:
• Are requirements clear? Can they be misinterpreted?
• Who is the source of the requirement? Has the final statement of the requirement been examined by or against him/her?
• What other requirements relate to this requirement?
• Does the requirement break any domain constraints?
• Is the requirement testable? If so, can we specify tests to implement the requirement?
• Is the requirement traceable to any system model that has been created?
• Is the requirement traceable to overall system/product objectives?
– in user terms
Features – a service provided by the system that fulfills a need
Software requirements – more specific