Atsa Etoundi Roger

Full professor
University of Yaounde
I
atsa.etoundi@ict4d.cm
Waterfall Model
The Requirement Engineering
Process
The process of establishing what services are required and the
constraints on the system’s operation and development
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
Process activities
 Domain understanding
 Requirements collection
 Classification
 Conflict resolution
 Prioritisation
 Requirements checking
The Requirements Engineering
Process
Feasibility studies
 A feasibility study decides whether or
not the proposed system is worthwhile
 A short focused study that checks
 If the system contributes to organisational objectives
 If the system can be engineered using
current technology and within budget
 If the system can be integrated with other systems
that
are used
Feasibility study
implementation
 Based on information assessment (what is
required), information collection and report writing
 Questions for people in the organisation
 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?
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
 Problems of Requirement Elicitation
 Problems of scope: The boundary of system is
ill- defined. Or unnecessary details are provided.
 Problems of understanding: The users are not sure
of what they need, and don’t have full understanding of
the problem domain.
 Problems of volatility: the requirements change
overtime.
Requirements Elicitation
 Guidelines of Requirements Elicitation
 Assess the business and technical feasibility for the proposed system
 Identify the people who will help specify requirements.
 Define the technical environment (e.g. computing architecture,
operating system, telecommunication needs) into which the system or
product will be placed
 Identify “domain constraints” (i.e. characteristics of the
business environment specific to the application domain) that
limit the functionality or performance of the system or product
to build
 Define one or more requirements elicitation methods (e.g. interviews,
team meetings, ..etc)
 Solicit participation from many people so that requirements are
defined from different point of views.
 Create usage scenarios of use cases to help customers/ users better
identify key requirements.
Requirements Analysis
 Requirements Analysis, determining whether
the stated requirements are clear, complete,
consistent and unambiguous.
Requirements Analysis
 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

Requirements Analysis
 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 Analysis
Types of Requirements:
 Customer Requirements:
 Operational distribution or deployment: Where will the system
be used?
 Mission profile or scenario: How will the system accomplish its
mission objective?
 Performance and related parameters: What are the critical
system parameters to accomplish the mission?
 Utilization environments: how are the various system components
to be used?
 Effectiveness requirements: How effective or efficient must the
system be in performing its mission?
 Operational life cycle: How long will the system be in use by
the user?
 Environment: what environments will the system be expected
to operate in an effective manner?
Requirements Analysis
 Types of Requirements:
 Architectural Requirements:
 A formal description and representation of a system,
organized in a way that support reasoning about the
structure of the system which comprises system
components, the externally visible properties of those
components, the relationships and the behavior between
them, and provides a plan from which products can be
procured and systems developed, that will work together to
implement the overall system.
Requirements Analysis
 Types of Requirements:
 Functional Requirements:
 Defines functions of a software system or its components.
They may be calculations, technical details, data
manipulation and processing and other specific
functionality that define “what a system is supposed to
accomplish?”
 They describe particular results of a system.

 Functional requirements are supported by Non-functional

requirements.
Requirements Analysis
 Types of Requirements:
 Non-Functional Requirements:
 They are requirements that specify criteria that can be used to
judge the operation of a system, rather than specific behavior.
 Functional requirements define what the system is supposed to
do, whereas non-functional requirements define how a system is
supposed to be.
 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.
System models
 Different models may be produced during
the requirements analysis activity
 Requirements analysis may involve three
structuring
activities which result in these different models
 Partitioning. Identifies the structural (part-
of) relationships between entities
 Abstraction. Identifies generalities among entities
 Projection. Identifies different ways of looking at
a problem
Problems of requirements
analysis
 Stakeholders don’t know what they really want
 Stakeholders express requirements in their own
terms
 Different stakeholders may have conflicting
requirements
 Organisational and political factors may influence
the system requirements
 The requirements change during the analysis
process. New stakeholders may emerge and the
business environment change
Elicitation and analysis
 Sometimes called requirements
elicitation or requirements discovery
 Involves technical staff working with customers to
find out about the application domain, the services
that the system should provide and the system’s
operational constraints
 May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders
Requirements Specifications
 Requirements Specification is the direct result
of a requirement analysis and can refer to:
 Software Requirements Specification
 Hardware Requirements Specification
Requirements Specifications
 A Software Requirements Specification (SRS) – a
requirements specification for a software system – 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)
Requirements Specifications
A Software Requirements Specification (SRS)
 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.
Requirements Validation and
Verification
 Validation (& Verification), is the process of
checking whether the requirements, as identified, do
not contradict the expectations about the system of
various stakeholders and do not contradict each
other.
 It is Requirements Quality Control
Validation Vs. Verification
 Validation: “Am I building the right product?”
checking a work product against higher-level
work products or authorities that frame this
particular product.
 Requirements are validated by stakeholders

 Verification: “Am I building the product right?”

checking a work product against some standards
and conditions imposed on this type of product and
the process of its development.
 Requirements are verified by the analysts mainly
More about validation
 Requirements validation makes sure that
requirements meet stakeholders’ goals and don’t
conflict with them.
 Concerned with demonstrating that the
requirements
define the system that the customer really wants
 Requirements error costs are high so validation is
very important
 Fixing a requirements error after delivery may cost up
to 100 times the cost of fixing an implementation error
Characteristics of a good
requirement
 Feasible
 Valid
 Unambiguous
 Verifiable
 Modifiable
 Consistent
 Complete
 Traceable
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?
Requirements validation
techniques
 Requirements reviews
 Systematic manual analysis of the requirements
 Prototyping
 Using an executable model of the system to check
requirements. Covered in Chapter 8
 Test-case generation
 Developing tests for requirements to check testability
 Automated consistency analysis
 Checking the consistency of a structured
requirements description
Requirements reviews
 Regular reviews should be held while the
requirements definition is being formulated
 Both client and contractor staff should be involved
in
reviews
 Reviews may be formal (with completed
documents) or informal. Good communications
between developers, customers and users can resolve
problems at an early stage
Review checks
 Verifiability. Is the requirement realistically
testable?
 Comprehensibility. Is the requirement
properly understood?
 Traceability. Is the origin of the requirement
clearly
stated?
 Adaptability. Can the requirement be changed
without a large impact on other requirements?
Requirements management
 Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development
 Requirements are inevitably incomplete and
inconsistent
 New requirements emerge during the process as
business needs change and a better understanding
of the system is developed
 Different viewpoints have different requirements
and these are often contradictory
Requirements change
 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
Requirements management
planning
 During the requirements engineering process,
you have to plan:
 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
Traceability
 Traceability is concerned with the relationships
between requirements, their sources and the
system design
 Source traceability
 Links from requirements to stakeholders who
proposed these requirements
 Requirements traceability
 Links between dependent requirements
 Design traceability
 Links from the requirements to the design
Social and organisational
factors
 Software systems are used in a social and
organisational context. This can influence or
even dominate the system requirements
 Social and organisational factors are not a single
viewpoint but are influences on all viewpoints
 Good analysts must be sensitive to these factors
but currently no systematic way to tackle their
analysis
Scope of ethnography
 Requirements that are derived from the way
that people actually work rather than the way I
which process definitions suggest that they ought
to work
 Requirements that are derived from cooperation
and
awareness of other people’s activities
Key points
 The requirements engineering process includes a
feasibility study, requirements elicitation and
analysis, requirements specification and
requirements management
 Requirements analysis is iterative
involving domain understanding, requirements
collection, classification, structuring, prioritisation
and validation
 Systems have multiple stakeholders with different
requirements
Key points
 Social and organisation factors influence
system requirements
 Requirements validation is concerned with
checks for validity, consistency, completeness,
realism and verifiability
 Business changes inevitably lead to
changing requirements
 Requirements management includes planning
and change management