Chapter Two

Requirements Process

1 Yoseph B.
Topics to be covered
• Process Models
• Process Actors
• Process Support and Management
• Process Quality and Improvement

2 Yoseph B.
3 Yoseph B.
Process models
 Requirements engineering processes may include
four high-level activities.

1. Assessing if the system is useful to the business

(feasibility study),
2. Discovering requirements (elicitation and analysis),
3. Converting these requirements into some standard
form (specification), and
4. Checking that the requirements actually define the
system that the customer wants (validation).

4 Yoseph B.
Cont’d…

 However, in practice these activities are interwoven, incremental,

and iterative.
5 Yoseph B.
Requirements feasibility study
 A feasibility study decides whether or not the
proposed system is worthwhile.

 A short focused study that checks

 If the system contributes to organizational objectives;
 If the system can be implemented using current
technology, within given cost and schedule
constraints;
 If the system can be integrated with other systems
that are already in place.

6 Yoseph B.
Feasibility study implementation
• Feasibility study involves information assessment (what
is required), information collection and report writing.

• Questions for people in the organization for

information assessment and collection:
• What if the system wasn’t implemented?
• What are current process problems?
• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed? What skills?
• What facilities must be supported by the proposed system?
• Feasibility study report should make a recommendation about the
development to continue or not.
7 Yoseph B.
Requirements Elicitation and Analysis
 In this activity, software engineers work with
customers and system end-users to find out
about:-
• The application domain,
• What services the system should provide,
• The required performance of the system, and
• Hardware constraints, and so on.

 May involve end-users, managers, engineer involved in

maintenance, domain experts, etc. These are called
stakeholders.

8 Yoseph B.
Cont’d…
 Eliciting & understanding stakeholder requirement is
difficult due to the following reasons:

1. Stakeholders don’t know what they really want except

in most general.
2. Stakeholders express requirements in their own terms.
3. Different stakeholders may have different
requirements.
4. Organizational and political factors may influence the
system requirements.
5. The requirements change during the analysis process.
New stakeholders may emerge and the business
environment change.
9 Yoseph B.
Elicitation and analysis process

10 Yoseph B.
Cont’d…
 Requirements discovery
• Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
 Requirements classification and organization
• Group related requirements and organizes them into
coherent clusters.
 Requirements prioritization and negotiation
• Prioritizing requirements and finding and resolving
requirements conflicts.
 Requirements specification
• Requirements are documented and input into the next
round of the spiral.

11 Yoseph B.
Requirements Discovery
 The process of gathering information about the
proposed and existing systems and distilling the
user and system requirements from this
information.
 Approaches & techniques of requirements
discovery are:
• Questionnaire
• Interviewing
• Scenario
• Ethnography
• Document analysis
• Use-cases etc.

12 Yoseph B.
Requirements Specification
 The essence of requirements specification is to
document requirements of different types in a
consistent, accessible, and reviewable way that is
readily understandable by the intended audiences.

 User requirements typically are represented in the

form of use cases or user stories.

 Detailed software functional and non-functional

requirements are recorded in this specification,
software requirements specification (SRS).

13 Yoseph B.
Requirements Validation
 Concerned with demonstrating that the
requirements define the system that the customer
really wants.

 Validation is so important because errors in a

requirements document can lead to extensive
rework costs. (when problems are discovered during development
or after the system is in service.)

 Fixing a requirements error after delivery may cost up

to 100 times the cost of fixing an implementation error.

14 Yoseph B.
Requirements checking
 Validity: Does the system provide the functions which best
support the customer’s needs?

 Consistency: Are there any requirements conflicts?

 Completeness: Are all functions required by the customer

included?

 Realism: Can the requirements be implemented given available

budget and technology?

 Verifiability: Can the requirements be checked?

15 Yoseph B.
Requirements validation techniques
 Requirements reviews
– Systematic manual analysis of the requirements.

 Prototyping
– Using an executable model of the system to check
requirements.

 Test-case generation
– Developing tests for requirements to check testability.
– If test is difficult or impossible to design for the requirement
means it is difficult to implement that requirement.

16 Yoseph B.
Process actors
 The roles of the people who participate in the
requirements process.

 Fundamentally interdisciplinary.

 The requirements specialist needs to mediate

between the domain of the stakeholder and that
of software engineering.

17 Yoseph B.
Cont’d…
 There are often many people involved besides
the requirements specialist, each of whom has a
stake in the software.

 The stakeholders will vary across projects, but will

always include users/operators and customers.

 Typical examples of software stakeholders

include (but are not restricted to) the following:

18 Yoseph B.
Cont’d…
A. Users: This group comprises those who will operate the
software (often heterogeneous group).
B. Customers: This group comprises those who have
commissioned the software.
C. Market analysts: needed to establish what the market
needs and to act as proxy customers.
D. Regulators: Many application domains, such as
banking and telecom (Telebirr), are regulated. Therefore,
the software must comply with the regulatory
authorities.
E. Software engineers: individuals have a legitimate
interest in profiting from developing the software.
19 Yoseph B.
Process support and management
1. Select an appropriate software development life
cycle
 Each project manager should select and adapt the life
cycle that best suits her project
2. Plan requirements approach
 should plan how it will handle its requirements
development and management activities.
3. Estimate requirements effort
 know how long it’s going to take to develop the
requirements for a project and what percentage of their
total effort should be devoted to requirements
development and management.
20 Yoseph B.
Cont’d…
4. Base project plans on requirements
 Develop plans and schedules for your project iteratively
as the scope and detailed requirements become clear.

5. Identify requirements decision makers

 Conflicting user inputs must be resolved, commercial
package components must be selected, change requests
must be evaluated, and on and on.

6. Renegotiate project commitments when

requirements change

21 Yoseph B.
Cont’d…
7. Analyse, document, and manage requirements-
related risks
 Identify and document risks related to requirements as
part of the project’s risk-management activities

8. Track the effort spent on requirements

 Monitor the effect that your requirements activities have
on the project to help judge the return on your
investment in requirements engineering.

9. Review lessons learned regarding requirements

on other projects
22 Yoseph B.
Process quality and improvement
 Concerned with the assessment of the quality and
improvement of the requirements process.

 Its purpose is to emphasize the key role the

requirements process plays in terms of the cost and
timeliness of a software product and of the
customer’s satisfaction with it.

 It will help to orient the requirements process with

quality standards and process improvement models
for software and systems.

23 Yoseph B.
Cont’d…
 Process quality and improvement is closely
related to both the software quality & software
engineering process and comprising:

• requirements process coverage by process improvement

standards and models;
• requirements process measures and benchmarking;
• improvement planning and implementation;
• security/CIA - Confidentiality, Integrity and Availability
improvement/planning and implementation

24 Yoseph B.
 Reading Assignment

Chapter II: Requirement Process Sommerville - 2011 Wiegers – 2003

2.1. Process Models Chapter 4 – section 4 Chapter 3

2.2. Process Actors Chapter 1, 2, 4 & 6

2.3. Process Support and

Chapter 3
Management
2.4. Process Quality and
Chapter 22 & 23
Improvement

25 Yoseph B.
 END OF CHAPTER TWO

26 Yoseph B.