CHAPTER 3
Requirement Engineering
SOFTWARE REQUIREMENTS
Requirements are descriptions of the services that a software system must provide and the
constraints under which it must operate
Requirements Engineering is the process of establishing the services that the customer requires
from the system and the constraints under which it is to be developed and operated
The requirements for a system are the descriptions of what the system should do—the services that
it provides and the constraints on its operation.
These requirements reflect the needs of customers for a system that serves a certain purpose such
as controlling device, placing an order, finding information.
The process of finding out, analyzing, documenting and checking these services and constraints is
called requirements engineering (RE).
The term ‘requirement’ is not used consistently in the software industry. In some cases, a requirement is
simply a high-level, abstract statement of a service that a system should provide or a constraint on a
system.
Requirements may serve a dual function:
As the basis of a bid for a contract
As the basis for the contract itself
Characteristics of a Good Requirement
Clear and Unambiguous
standard structure
has only one possible interpretation
Not more than one requirement in one sentence
Correct
A requirement contributes to a real need
Understandable
A reader can easily understand the meaning of the requirement
Verifiable
A requirement can be tested
Complete
Consistent
Traceable
Types of requirement
Functional and non-functional and requirements
Functional requirements
Describe functionality or system services
Depend on the type of software, expected users and the type of system where the software is used
They describe particular results of a system.
Functional requirements are supported by Non-functional requirements
Non-functional requirements
o constraints the system being developed or the development process
o Functional requirements define what the system is supposed to Do whereas non
o functional requirements define how a system is supposed to be
o Non-functional requirements can be divided into two main categories:
Execution qualities such as security and usability, which are observable at runtime.
Evolution qualities, such as testability, maintainability and scalability.
The Requirement Engineering Process
Requirements engineering help software engineers to better understand the problem they will work to
solve.
It encompasses the set of tasks that lead to an understanding of what the business impact of the software
will be, what the customer wants and how end-users will interact with the software
Requirement Engineering Process
Feasibility Study
Requirements elicitation and analysis
Requirements Specification
Requirements Validation
Requirements Elicitation
It is the practice of obtaining the requirements of a system from users, customers and other stakeholders.
The practice is also sometimes referred to as Requirement gathering. Requirements elicitation practice
include the following:
Interviews
Questionnaires
User observation
Workshops
Brain storming
Use cases
Role playing
And prototyping
Requirements elicitation includes the following activities:
1.Identifying actors. During this activity, developers identify the different types of users the future system will
support.
2.Identifying scenarios: During this activity, developers observe users and develop a set of detailed scenarios for
typical functionality provided by the future system.
scenarios are concrete examples illustrating a single case,
3.Identifying use cases: developers derive from the scenarios a set of use cases that completely represent the
future system.
use cases are abstractions describing all possible cases
4.Refining use cases: developers ensure that the system specification is complete, by detailing each use case and
describing the behavior of the system in the presence of errors and exceptional conditions.
5.Identifying relationships among use cases: developers consolidate the use case model by eliminating
redundancies. This ensures that the system specification is consistent.
6.Identifying nonfunctional requirements: 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.
Scenarios
Scenarios are real-life examples of how a system can be used.
They should include
A description of the starting situation;
A description of the normal flow of events;
What can go wrong and how this is handled
Information about other concurrent activities;
A description of the state when the scenario finishes.
Problems of requirements elicitation
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organizational and political factors may influence the system requirements.
The requirements change during the analysis process. New stakeholders may emerge and the business environment
change.
Requirements Analysis
Requirements Analysis, determining whether the stated requirements are clear, complete, consistent and unambiguous.
Stakeholder Identification
Stakeholders are people or organizations that have a valid interest in the system.They may be affected by it directly or
indirectly.
Stake holders may include:
Anyone who operates the system
Anyone who benefits from the system
Anyone involved in purchasing or procuring the system
People opposed to the system (negative stakeholders)
Organizations responsible for the system
Stakeholder Interviews
Interviews are a common technique used in requirement analysis.
This technique can serve as a means of obtaining the highly focused knowledge from different stakeholders
perspectives
Requirements Specifications
Requirements Specification is the direct result of a requirement analysis and can refer to:
Software Requirements Specification
Hardware Requirements Specification
A Software Requirements Specification (SRS) –is a complete description of the behavior of a system to be
developed.
It includes a set of use cases that describe all the interactions the users will have with the software. In
addition to use cases, the SRS also contains non-functional requirements (such as performance
requirements, quality standards, or design constraints) .
The software requirement specification document enlists all necessary requirements for project
development. To derive the requirements we need to have clear and thorough understanding of the products
to be developed.
A general organization of an SRS is as follows:
Introduction
Purpose, Scope, Definitions, System Overview, References
Overall Description
Product Perspective, Product functions, User characteristics, constraints, assumptions and
dependencies.
Specific Requirements
External Interface requirements, functional requirements, performance requirements, design
constraints, logical database requirement, software system attributes.
Information Hiding
Why Information Hiding?
Reduces the likelihood of “side effects”
Limits the global impact of local design decisions
Emphasizes communication through controlled interfaces
Discourages the use of global data
Leads to encapsulation—an attribute of high quality design
Results in higher quality software
THE END
