Requirements Engineering
1
Module -I
Introduction:Software Crisis, Need for Software Engineering. Professional
Software Development, Software Engineering Ethics. Case Studies.
Software Processes Models: Waterfall Model, Incremental Model and Spiral
Model. Process activities.
Requirements Engineering: Requirements Engineering Processes. Requirements
Elicitation and Analysis. Functional and non-functional requirements. The
software Requirements Document. Requirements Specification. Requirements
validation. Requirements Management.
What is a requirement?
• It may range from a high-level abstract statement of a service or of a
system constraint to a detailed mathematical functional
specification.
3
Requirements engineering
• The process of establishing the services that a customer requires
from a system and the constraints under which it operates and is
developed.
• The system requirements are the descriptions of the system services
and constraints that are generated during the requirements
engineering process.
4
Types of requirement
User requirements
Statements in natural language + diagrams of the services the system provides
and its operational constraints. Written for customers.
System requirements
A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints. Defines what should be
implemented so may be part of a contract between client and contractor.
5
User and system requirements
6
Functional and non-functional requirements
7
Types of nonfunctional requirement
8
Requirements engineering processes
9
Requirements engineering processes
• The processes used for RE vary widely depending on the
application domain, the people involved and the
organisation developing the requirements.
• However, there are a number of generic activities common
to all processes
• Requirements elicitation
• Requirements analysis
• Requirements validation
• Requirements management
10
A spiral view of the requirements engineering
process
11
Requirements elicitation
• Software engineers work with a range of system stakeholders to find
out about the application domain, the services that the system
should provide, the required system performance, hardware
constraints, other systems, etc.
• Stages include:
• Requirements discovery,
• Requirements classification and organization,
• Requirements prioritization and negotiation,
• Requirements specification.
12
The requirements elicitation and analysis
process
13
Process activities
• Requirements discovery
• Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
• Requirements classification and organisation
• Groups related requirements and organises them into coherent
clusters.
• Prioritisation and negotiation
• Prioritising requirements and resolving requirements conflicts.
• Requirements specification
• Requirements are documented and input into the next round of the
spiral.
14
Requirements discovery
• The process of gathering information about the required and existing
systems and distilling the user and system requirements from this
information.
• Interaction is with system stakeholders from managers to external
regulators.
• Systems normally have a range of stakeholders.
15
Interviewing
• Formal or informal interviews with stakeholders are part of most RE
processes.
• Types of interview
• Closed interviews based on pre-determined list of questions
• Open interviews where various issues are explored with stakeholders.
• Effective interviewing
• Be open-minded, avoid pre-conceived ideas about the requirements and are
willing to listen to stakeholders.
• Prompt the interviewee to get discussions going using a springboard
question, a requirements proposal, or by working together on a prototype
system.
16
Interviews in practice
• Normally a mix of closed and open-ended interviewing.
• Interviews are good for getting an overall understanding of
what stakeholders do and how they might interact with the
system.
• Interviewers need to be open-minded without pre-conceived ideas of
what the system should do
• You need to prompt the use to talk about the system by
suggesting requirements rather than simply asking them
what they want.
17
Problems with interviews
• Application specialists may use language to describe their work that
isn’t easy for the requirements engineer to understand.
• Interviews are not good for understanding domain requirements
• Requirements engineers cannot understand specific domain terminology;
• Some domain knowledge is so familiar that people find it hard to articulate
or think that it isn’t worth articulating.
18
Requirements validation
• 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.
19
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?
30/10/2014 Chapter 4 Requirements Engineering 20
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 2.
• Test-case generation
• Developing tests for requirements to check testability.
30/10/2014 Chapter 4 Requirements Engineering 21
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.
30/10/2014 Chapter 4 Requirements Engineering 22
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?
30/10/2014 Chapter 4 Requirements Engineering 23
Requirements management
• Requirements management is the process of managing
changing requirements during the requirements engineering
process and system development.
• New requirements emerge as a system is being developed and after
it has gone into use.
• You need to keep track of individual requirements and maintain links
between dependent requirements so that you can assess the impact
of requirements changes. You need to establish a formal process for
making change proposals and linking these to system requirements.
30/10/2014 Chapter 4 Requirements Engineering 24
Requirements management planning
• Establishes the level of requirements management detail that is required.
• Requirements management decisions:
• Requirements identification Each requirement must be uniquely identified so that it
can be cross-referenced with other requirements.
• A change management process This is the set of activities that assess the impact and
cost of changes. I discuss this process in more detail in the following section.
• Traceability policies These policies define the relationships between each
requirement and between the requirements and the system design that should be
recorded.
• Tool support Tools that may be used range from specialist requirements management
systems to spreadsheets and simple database systems.
30/10/2014 Chapter 4 Requirements Engineering 25
Requirements change management
26