Chapter 3Good Practices forRequirements Engineering
- 1. Chapter 3: Good Practices for Requirements Engineering © Karl E. Wiegers A Process � Be iterative, incremental, interleaved (overlapped) 2 Elicitation Analysis Specification Validation re-evaluate clarify rewrite correct and fill in 3.1 Elicitation, 1 � Define the requirements development process—its steps and activities. � Write a vision and scope document
- 2. ◦ define objectives ◦ set boundaries ◦ focus the project 3 Elicitation, 2 � Identify user classes ◦ Roles ◦ Goals ◦ Features used ◦ Frequency of use ◦ Knowledge and skill levels ◦ Location, attitude 4 Elicitation, 3 � Product champions from user classes ◦ Representatives of group
- 3. ◦ Speak for them ◦ Decide on their behalf ◦ Long-term commitment to project � Focus groups from user classes ◦ Describe functionality and quality needs ◦ Short-term commitment 5 Elicitation, 4 � Identify use cases ◦ Tasks to be accomplished ◦ Goals and purpose ◦ User/system interactions � Identify system events/responses ◦ External signals and data ◦ Temporal events ◦ Business events (customer calls, inventory changes,…) 6
- 4. Elicitation, 5 � Workshops ◦ Collaboration between analyst and user ◦ Discussions and draft documents � Observe users ◦ Current tasks establish context for new system ◦ Data flow can be captured 7 Elicitation, 6 � Examine problem reports ◦ Difficulties with old system can reveal needs for new one ◦ Enhancements may have been explicitly requested � Reuse requirements ◦ Look for similarities to previous projects, existing products
- 5. 8 3.2 Analysis, 1 � Draw a context diagram ◦ Show environment, boundaries, interfaces � Create prototypes ◦ User interfaces—to get feedback about a tangible entity ◦ Technical—to explore feasibility of potential problem areas 9 3.2 Analysis, 2 � Prioritize ◦ Allocate requirements to releases ◦ Adjust to changes in resources, needs, goals, market conditions � Model ◦ Use an abstract, flexible representation ◦ Use rigorous notation to reveal problems
- 6. (incomplete, inconsistent, conflicting) 10 Analysis, 4 � Identify the interfaces btw. To other systems � Identify the requirements to other subsystems. 11 3.3 Specification, 1 � Documentation—consistent, accessible, reviewable � Adopt SRS template—such as IEEE 830 � Identify sources ◦ Justify presence of requirements ◦ Support future clarification � Label requirements ◦ Have unique ID for traceability and management
- 7. 12 Specification, 2 � Record business rules ◦ Keep separate from SRS, they exist outside the scope of a single project. � Specify quality attributes ◦ Performance, efficiency, reliability, robustness, usability—all affect customer/user satisfaction. 13 3.4 Validation � Inspect documents ◦ Formal examinations by people with different perspectives and expertise. ◦ Informal reviews of drafts in progress. � Define test cases ◦ Describe expected behavior ◦ Review with customer/user ◦ Trace to specification
- 8. ◦ Define acceptance criteria 14 3.5 Management, 1 � Define change control process—proposal, analysis, resolution � Establish a Change Control Board—small, competent, empowered group � Perform impact analysis ◦ scope of change (other artifacts affected) ◦ effort and cost 15 Management, 2 � Establish baseline and version control ◦ Distinguish between release baselines ◦ Distinguish between previous and current versions � Maintain a change history—know the what, when, who, and why
- 9. � Track change status—know every requirement’s condition (proposed, approved, implemented, verified) 16 Management, 3 � Measure volatility ◦ Know the rate of change ◦ Identify problems (poor understanding, ill- defined scope, business dynamics, politics) � Use a tool—automation eliminates drudgery, enables previously-described tasks 17 Management, 4 � Create a traceability matrix ◦ Connect requirements, code, tests ◦ Ensure no requirements are missed ◦ Prevent extraneous features from appearing 18
- 10. 19 3.6 Summaries Development Process in Summary: 20