CHAPTER

THREE
Requirements
Elicitation
 Overview of requirements Elicitation
Encompass all activities involved in discovering the requirements of a system
System developers and engineers work in close relationship with customer and
end-users to
Find out more about the problem to be solved
To describe the functionality of the system
Understand the application domain (“speak its language”)
Hardware constraints … and so forth
Not just a simple process about fishing for requirements, but a highly complex
process:
Customer rarely have a clear picture of their requirements
Different people have conflicting requirements
Bridging the gap between user and developer:

2
 Requirements elicitation concepts
Requirements elicitation is the process of gathering, analyzing, and defining the
needs and expectations of stakeholders for a software system. Some key concepts
in requirements elicitation include:
1. Stakeholder identification: Identifying all individuals or groups who have a vested interest
in the software system and understanding their needs and expectations.

2. Requirement gathering techniques: Various techniques such as interviews, surveys,

workshops, and observations are used to collect requirements from stakeholders.

3. Requirement analysis: Analyzing and prioritizing the gathered requirements to ensure

they are clear, complete, and consistent.

4. Requirement validation: Validating the requirements with stakeholders to ensure they

accurately reflect their needs and expectations.

3
 Cont…
5. Requirement documentation: Documenting the requirements in a clear and organized
manner to serve as a reference for the development team.

6. Requirement management: Managing changes to requirements throughout the project

lifecycle to ensure that the software system meets stakeholder needs.

7. Communication: Effective communication with stakeholders is crucial throughout the

requirements elicitation process to ensure that their needs are accurately captured and
addressed.

Overall, requirements elicitation is a critical phase in the software development process as it

lays the foundation for the successful delivery of a system that meets stakeholder
expectations.

4
 Fundamental Requirement Gathering techniques

Interviewing: A fact finding technique where by a systems analysts

collect information from individuals through face- to - face interaction

Questionnaires and Surveys: To collect structured feedback on

specific requirements, preferences, and priorities.

Observations: Observing end-users or stakeholders in their work

environment to understand their workflows, behaviors, challenges, and
preferences.
5
 Brainstorming
Brainstorming is a technique where groups of people discuss a topic,
and say any thing that comes to their minds about it.
The following are rules of brainstorming
1. All ideas are good; ideas are not judged by the group
2. All ideas are owned by the group; not the individual
3. All ideas become public property; any body is allowed to expand some
Give the brainstorming rules to the group before the session
Ideas are recorded by a scribe
The facilitator starts by introducing the rules and the topic of the discussion

6
 issues to discuss at a brainstorming session
Who is this system for?

What will they do with the system?

What business needs does this system support?

What will our customers want from us?

How the business is changing?

How will peoples jobs be affected? are we empowering or

disempowering them?

7
What information will people need to do their jobs?

Are there any trivial tasks we can automate?

Will the system pay for it self?

Do our users have the skills/education necessary to use this system?

What training will they need?

What are our organizations strategic goals and objectives ?Does this
system support them?

8
How can we do this faster?
How can we do this cheaper ?
How can we do this better?

9
 Types of requirements
There are two main types of requirements in software engineering:
Functional Requirements

Non- functional Requirements

 Functional Requirements
These describe the specific functions or tasks that the software
system must perform.

Define what the software should do, such as user interactions, data
processing, and system behavior.

Non-functional Requirements
These specify the quality attributes or constraints that the software
system must satisfy.

focus on aspects like performance, security, reliability, usability,

scalability, and maintainability.
 Types of Nonfunctional Requirements
Usability Requirement
Define how user-friendly and intuitive the software system should be for its
intended users.
Usability requirements address aspects such as user interface design,
accessibility, learnability, and overall user experience.
Examples include navigation simplicity, error handling clarity, and consistency in
design.
Reliability Requirement
Describe the system's ability to perform consistently and predictably over time
without failures or errors.
Reliability requirements ensure that the software system operates reliably under
normal and exceptional conditions.
Examples include fault tolerance, error recovery mechanisms, and system
availability targets.
 Cont…
Security Requirements
Specify how the software system should protect data, resources, and
functionality from unauthorized access, tampering, or misuse.
Security requirements address aspects such as authentication, authorization,
data encryption, and compliance with privacy regulations.
Examples include access control policies, data encryption and algorithms
Compatibility Requirements
describe the software system's ability to operate effectively with other systems,
platforms, browsers, or devices.
ensure that the software can interoperate with external components without
compatibility issues.
Examples include cross-browser support, operating system compatibility, and
integration with third-party APIs.
 Completeness, Consistency, Clarity, and
Correctness
The first step towards specifying requirements is to gather as many
potential requirements as possible, regardless of quality
considerations.
However before the final set of requirements can be accepted, both
individual requirements and the overall set of requirements must pass
through a "quality gateway" that only accepts high-quality
requirements, and rejects others, ( or sends them back for further
review and refinement. )
For example, some of the qualities that might be examined include:

14
 Cont…
Complete:- All features of interest are described by requirements

Consistent:- No two requirements of the specification contradict each

other.

Unambiguous:- A requirement cannot be interpreted in two mutually

exclusive ways.

Correct:- The requirements describe the features of the system and

environment of interest to the client and the developer, but do not
describe other unintended features.
15
 Cont…
Realism:- Is the requirement reasonably attainable?

Verifiability/Measurable:- Progress can be measured by

completing courses, projects, and problem-solving ability

16
 Requirements Elicitation activities

Identifying Actors
Actors represent external entities that interact with the system

May be human or an external system

Questions to identify actors:

Which user groups are supported directly?

Which user groups perform secondary functions, e.g. maintenance?

What external hardware or software system will the system interact with?

17
 Identifying scenarios
Developers observe users and develop a set of detailed scenarios for
typical functionality provided by the future system.

Scenarios are concrete examples of the future system in use.

Developers use these scenarios to communicate with the user and

deepen their understanding of the application domain.

18
 Identifying use cases
Once developers and users agree on a set of scenarios, developers
derive from the scenarios a set of use cases that completely represent
the future system.

Whereas scenarios are concrete examples illustrating a single case,

use cases are abstractions describing all possible cases.

When describing use cases, developers determine the scope of the

system

19
 Identifying relationships
Refining use cases
among use cases
developers ensure that the developers identify dependencies
requirements specification is
complete by detailing each use among use cases. They also
case and describing the behavior consolidate the use case model
of the system in the presence of
errors and exceptional conditions. by factoring out common
functionality. This ensures that
the requirements specification is
consistent.

20
 Identifying nonfunctional requirements

During this activity, developers, users, and clients agree on aspects

that are visible to the user, but not directly related to functionality.

These include constraints on the performance of the system, its

documentation, the resources it consumes, its security, and its quality

21
 Requirements validation techniques

To validate requirements we may use the following requirement

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.
Automated consistency analysis
Checking the consistency of a structured requirements description

22
 Requirement Document
The software requirements document (SRS) is the official statement of
what is required of the system developers
It should include both the user requirements for a system and a
detailed specification of the system requirements.
The requirements document has diverse set of users, for example :
 System customers, Managers, System Engineers, System Test
Engineer, System Maintenance Engineers
Writing SRS
• Write each clause so that it contains only one requirement
• Avoid having one requirement refer to another requirement
• Collect similar requirements together

23
 Requirement Document…
The requirement document should be
Complete - the set of requirements must be complete.
If requirements are missing, then the product will also be incomplete.
It is likely that the missing requirements will turn up at inopportune times and
cause problems throughout the project life cycle.
Consistent - set of requirements must be consistent.
If there are requirements in your specification that conflict with each other,
then the product will not be able to meet all of your requirements.
Inconsistencies must be resolved in order for your project to succeed.
Updateable
If you have to change a requirement (create, edit, or delete), you must be able
to evaluate the impact of that change on all of the other requirements.
24
 Requirement Document…
 Traceability - Each requirement should be contained in a single,
numbered paragraph so that it may be referred to in other
documents:
 Prioritization - Each requirement has to be ranked against the
others according to its implementation importance.
More over SRS should
Specify external system behaviour
Specify implementation constraints
Easy to change
Serve as reference tool for maintenance etc

25
 IEEE 830-1998. requirements standard
1. Introduction to the Document 3.2 Functional Requirements
1.1 Purpose of the Product 3.2.1 Class 1
1.2 Scope of the Product 3.2.2 Class 2
…
1.3 Acronyms, Abbreviations, Definitions
3.3 Performance Requirements
1.4 References
3.4 Design Constraints
1.5 Outline of the rest of the SRS 3.5 Quality Requirements
2. General Description of Product 3.6 Other Requirements
2.1 Context of Product 4. Appendices
2.2 Product Functions
2.3 User Characteristics 5. Index
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
26
 Requirements management
Requirements management is the process of managing changing
requirements during the requirements engineering process and
system development.
Requirements change for the following reasons:
The priority of requirements from different viewpoints changes
during the development process.
System customers may specify requirements from a business
perspective that conflict with end-user requirements.
The business and technical environment of the system changes
during its development.
Requirement change management should be applied to all proposed changes to
the requirements so that changes are treated consistently and the changes to
the requirements document are made in controlled way.
27
 Requirement change management...
Principal stages to change management process are
Problem analysis - Discuss requirements problem and propose
change;
Change analysis and costing - Assess effects of change on other
requirements;
Change implementation - Modify requirements document and other
documents to reflect change.
From an evolution perspective, requirements fall into two classes
Enduring requirements: Stable requirements derived from the core
activity of the customer organisation. May be derived from domain models
E.g. a hospital will always have doctors, nurses, etc.
Volatile requirements: Requirements which change during
development or when the system is in use.
In a hospital, requirements derived from health-care policy 28
 Requirements management planning
During the requirements engineering process, you have to plan and
decide on:
Requirements identification
How requirements are individually identified;
A change management process
The process followed when analysing a requirements change;
Traceability policies
The amount of information about requirements relationships that is
maintained;
CASE tool support
The tool support required to help manage requirements change

29
END of Chapter 3

30