Chapter Summary
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
◦ 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
◦ 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
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
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 (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
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
◦ 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
� 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
19
3.6 Summaries
Development Process in Summary:
20