-Be sensitive to organizational and political considerations
-Identify and consult system stakeholders
-Record requirements sources
-Use Business concerns to drive requirements elicitation
-Look for domain constraints
-Record requirements rationale
-Collect requirements from multiple viewpoints
-Prototype poorly understood requirements
-Use scenarios to elicit requirements
-Define operational processes
-Reuse requirements
Identify and Consult System Stakeholders
-If lacking consideration of everyone who is likely to be affected by the introduction of the system, there is a great likelihood of missing some critical requirements.
-“Identifying stakeholders and discussing the system with them makes people feel like they are part of the requirements elicitation process. In fact, it makes them a part of it.”
Use Business Concerns to Drive Requirements Elicitation
-If a system is to be useful, it must contribute to the key concerns of the business. If the concerns are identified and used as drivers of the requirements elicitation process, there will be higher confidence that the system will meet real organization needs.
-Making the business concerns explicit helps to focus and clarify these goals.
Collect Requirements from Multiple Viewpoints
-If requirements are collected from a single viewpoint, they are unlikely to meet other stakeholders’ requirements.
-Collecting requirements from multiple viewpoints is a useful way to prioritize requirements
-Identified viewpoints can be used to help
-organize requirements elicitation and
-organize the requirements specification, too.
Reuse Requirements
-Saves money and time. Studies have shown that similar systems can re-use up to 80% of the requirements.
-Reuse reduces risk. Reused requirements have a better chance of being understood by all the stakeholders.
-Requirements reuse may lead to additional reuse in other lifecycle activities.
-Component design
-Tests
-Code
No comments:
Post a Comment