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