CS-326 : Software Engineering
Lecture # 09
Fiza Abdul Razzaq
Requirements engineering
2
What is a requirement?
3
Requirements must be complete and consistent
• In principle, requirements should be both complete and
consistent.
• Complete
• They should include descriptions of all facilities required.
• Consistent
• There should be no conflicts or contradictions in the descriptions
of the system facilities.
• In practice, because of system and environmental
complexity, it is impossible to produce a complete and
consistent requirements document.
4
Non-functional requirements
• These define system properties and constraints e.g.
reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.
• Process requirements may also be specified mandating
a particular IDE, programming language or development
method.
• Non-functional requirements may be more critical than
functional requirements. If these are not met, the system
may be useless.
5
Non-functional requirements implementation
• Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.
• For example, to ensure that performance requirements are met,
you may have to organize the system to minimize
communications between components.
• A single non-functional requirement, such as a security
requirement, may generate a number of related
functional requirements that define system services that
are required.
• It may also generate requirements that restrict existing
requirements.
6
Requirements engineering processes
7
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.
• In practice, RE is an iterative activity in which these
processes are interleaved.
8
A spiral view of the requirements engineering
process
9
Requirements elicitation
10
Requirements 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.
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
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.
• Organisational and political factors may influence the
system requirements.
• The requirements change during the analysis process.
New stakeholders may emerge and the business
environment may change.
13
The requirements elicitation and analysis
process
14
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.
15
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.
16
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.
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
Stories and scenarios
• Scenarios and user stories are real-life examples of how
a system can be used.
• Stories and scenarios are a description of how a system
may be used for a particular task.
• Because they are based on a practical situation,
stakeholders can relate to them and can comment on
their situation with respect to the story.
19
Scenarios
• A structured form of user story
• Scenarios should include
• A description of the starting situation;
• A description of the normal flow of events;
• A description of what can go wrong;
• Information about other concurrent activities;
• A description of the state when the scenario finishes.
20
Requirements specification
21
Requirements specification
• The process of writing down the user and system
requirements in a requirements document.
• User requirements have to be understandable by end-
users and customers who do not have a technical
background.
• System requirements are more detailed requirements
and may include more technical information.
• The requirements may be part of a contract for the
system development
• It is therefore important that these are as complete as possible.
22
Requirements and design
• In principle, requirements should state what the system
should do and the design should describe how it does
this.
• In practice, requirements and design are inseparable
• A system architecture may be designed to structure the
requirements;
• The system may inter-operate with other systems that generate
design requirements;
• The use of a specific architecture to satisfy non-functional
requirements may be a domain requirement.
• This may be the consequence of a regulatory requirement.
23
Guidelines for writing requirements
• Invent a standard format and use it for all requirements.
• Use language in a consistent way. Use shall for
mandatory requirements, should for desirable
requirements.
• Use text highlighting to identify key parts of the
requirement.
• Avoid the use of computer jargon.
• Include an explanation (rationale) of why a requirement
is necessary.
24
Example requirements for the insulin pump
software system
3.2 The system shall measure the blood sugar and deliver
insulin, if required, every 10 minutes. (Changes in blood sugar
are relatively slow so more frequent measurement is
unnecessary; less frequent measurement could lead to
unnecessarily high sugar levels.)
3.6 The system shall run a self-test routine every minute with
the conditions to be tested and the associated actions defined
in Table 1. (A self-test routine can discover hardware and
software problems and alert the user to the fact the normal
operation may be impossible.)
25
Requirements validation
26
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.
27
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?
28
Requirements change
29
Changing requirements
• The business and technical environment of the system
always changes after installation.
• New hardware may be introduced, it may be necessary to
interface the system with other systems, business priorities may
change (with consequent changes in the system support
required), and new legislation and regulations may be introduced
that the system must necessarily abide by.
• The people who pay for a system and the users of that
system are rarely the same people.
• System customers impose requirements because of
organizational and budgetary constraints. These may conflict
with end-user requirements and, after delivery, new features may
have to be added for user support if the system is to meet its
goals.
30
Changing requirements
• Large systems usually have a diverse user community,
with many users having different requirements and
priorities that may be conflicting or contradictory.
• The final system requirements are inevitably a compromise
between them and, with experience, it is often discovered that
the balance of support given to different users has to be
changed.
31
Requirements evolution
32
Use cases
• Use-cases are a kind of scenario that are included in the
UML.
• Use cases identify the actors in an interaction and which
describe the interaction itself.
• A set of use cases should describe all possible
interactions with the system.
• UML sequence diagrams may be used to add detail to
use-cases by showing the sequence of event processing
in the system.
33
