Requirements Engineering

Understand the concept of user and system requirements

and why these requirements should be written in different
ways.
Understand the difference between the functional and Non-
Functional requirements.
Understand the main requirements engineering activities
of elicitation, analysis and validation, and the relationship
between them.
Understand the requirement engineering management and
why it is necessary.
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
The process of finding out, analyzing, documenting and
checking these services and constraints is called
requirements engineering (RE)
User requirements are statements, in a natural language
plus diagrams, of what services the system is expected to
provide to system users and the constraints under which it
must operate
System requirements are more detailed descriptions of the
software system’s functions, services, and operational
constraints.
 The system requirements document (sometimes called a functional
specification) should define exactly what is to be implemented.
 It may be part of the contract between the system buyer and the
software developers
Different levels of requirements are useful
because they communicate information
about the system to different types of
reader
You need to write requirements at different
levels of detail because different readers
use them in different ways
Functional and non-functional requirements
Software system requirements are often classified as
functional requirements or non-functional requirements
Functional requirements
These are statements of services the system should provide,
how the system should react to particular inputs, and how the
system should behave in particular situations.
In some cases, the functional requirements may also explicitly
state what the system should not do
Non-functional requirements
These are constraints on the services or functions offered by
the system.
They include timing constraints, constraints on the
development process, and constraints imposed by standards.
Non-functional requirements often apply to the system as a
whole, rather than individual system features or services
The distinction between different types of requirement is
not as clear-cut
A user requirement concerned with security, such as a
statement limiting access to authorized users, may appear
to be a non-functional requirement.
However, when developed in more detail, this requirement
may generate other requirements that are clearly
functional, such as the need to include user authentication
facilities in the system.
Functional requirements
The functional requirements for a system describe what
the system should do
These requirements depend on the type of software being
developed, the expected users of the software, and the
general approach taken by the organization when writing
requirements
When expressed as user requirements, functional
requirements are usually described in an abstract way that
can be understood by system users
More specific functional system requirements describe the
system functions, its inputs and outputs, exceptions, etc.,
in detail
Example : MHC-PMS
1. A user shall be able to search the
appointments lists for all clinics.
2. The system shall generate each day, for
each clinic, a list of patients who are
expected to attend appointments that day.
3. Each staff member using the system shall
be uniquely identified by his or her eight-
digit employee number.
It is natural for a system developer to
interpret an ambiguous requirement in a
way that simplifies its implementation
In the first requirement, The medical staff
member specifying this may expect
‘search’ to mean that, given a patient
However, this is not explicit in the
requirement. System developers may
interpret the requirement in a different way
and may implement a search so that the
user has to choose a clinic then carry out
the search. This obviously will involve more
user input and so take longer.
In principle, the functional requirements
specification of a system should be both
complete and consistent.
Completeness means that all services
required by the user should be defined
Consistency means that requirements
should not have contradictory definitions
Non-functional requirements
Non-functional requirements, as the name suggests, are
requirements that are not directly concerned with the
specific services delivered by the system to its users.
They may relate to emergent system properties such as
reliability, response time, and store occupancy.
They may define constraints on the system
implementation such as the capabilities of I/O devices or
the data representations used in interfaces with other
systems
Non-functional requirements, such as
performance, security, or availability,
usually specify or constrain characteristics
of the system as a whole
Non-functional requirements are often more
critical than individual functional
requirements
System users can usually find ways to work
around a system function that doesn’t
really meet their needs. However, failing to
meet a non-functional requirement can
mean that the whole system is unusable
For example, if an aircraft system does not
meet its reliability requirements, it will not
be certified as safe for operation; if an
Non-functional requirements arise through user needs,
because of budget constraints, organizational policies, the
need for interoperability with other software or hardware
systems, or external factors such as safety regulations or
privacy legislation
Product requirements : These
requirements specify or constraints the
runtime behavior of the system.
Mentcare should be available to all clinics
during working hours.
Organizational requirements : These
requirements are broad system
requirements derived from policies and
procedures in the customer’s and
developer’s organization.
Users of the mentcare should be identified by
ID cards
External requirements : This broad
heading covers all requirements that are
derived from factors external to the
Whenever possible, you should write non-
functional requirements quantitatively so
that they can be objectively tested
The system should be easy to use by medical staff and
should be organized in such a way that user errors are
minimized

Medical staff shall be able to use all the system functions

after four hours of training. After this training, the average
number of errors made by experienced users shall not
exceed two per hour of system use
Requirement engineering process
Requirements elicitation and
analysis
After an initial feasibility study, the next stage of the
requirements engineering process is requirements
elicitation and analysis
In this activity, software engineers work with customers
and system end-users to find out about the application
domain, what services the system should provide, the
required performance of the system, hardware constraints,
and so on.
Requirements elicitation and analysis may involve a variety
of different kinds of people in an organization
The requirements elicitation and analysis process
Requirements discovery
This is the process of interacting with
stakeholders of the system to discover their
requirements.
Domain requirements from stakeholders
and documentation are also discovered
during this activity
Requirements classification and
organization
This activity takes the unstructured
collection of requirements, groups related
requirements, and organizes them into
coherent clusters.
The most common way of grouping
requirements is to use a model of the
Requirements prioritization and negotiation
Inevitably, when multiple stakeholders are involved,
requirements will conflict.
This activity is concerned with prioritizing requirements
and finding and resolving requirements conflicts through
negotiation.
 Usually, stakeholders have to meet to resolve differences
and agree on compromise requirements
Requirements documentation
The requirements are documented and input into the next
round of the spiral
Requirements elicitation and analysis is an iterative
process with continual feedback from each activity to other
activities.
The process cycle starts with requirements discovery and
ends with the requirements documentation.
The analyst’s understanding of the requirements improves
with each round of the cycle.
The cycle ends when the requirements document is
complete
Eliciting and understanding requirements from system
stakeholders is a difficult process for several reasons:
Stakeholders often don’t know what they want from a
computer system except in the most general terms; they
may find it difficult to articulate what they want the system
to do; they may make unrealistic demands because they
don’t know what is and isn’t feasible
Stakeholders in a system naturally express requirements in
their own terms and with implicit knowledge of their own
work. Requirements engineers, without experience in the
customer’s domain, may not understand these
requirements
Different stakeholders have different
requirements and they may express these
in different ways. Requirements engineers
have to discover all potential sources of
requirements and discover commonalities
and conflict.
Political factors may influence the
requirements of a system. Managers may
demand specific system requirements
because these will allow them to increase
their influence in the organization.
The economic and business environment in
which the analysis takes place is dynamic.
It inevitably changes during the analysis
process. The importance of particular
Requirements discovery
Requirements discovery (sometime called requirements
elicitation) is the process of gathering information about
the required system and existing systems, and distilling
the user and system requirements from this information
Sources of information during the requirements discovery
phase include documentation, system stakeholders, and
specifications of similar systems.
You interact with stakeholders through interviews and
observation and you may use scenarios and prototypes to
help stakeholders understand what the system will be like.
Stakeholders range from end-users of a
system through managers to external
stakeholders such as regulators, who certify
the acceptability of the system
Interviewing
Formal or informal interviews with system stakeholders are
part of most requirements engineering processes.
In these interviews, the requirements engineering team
puts questions to stakeholders about the system that they
currently use and the system to be developed.
Requirements are derived from the answers to these
questions.
Interviews may be of two types:
Closed interviews, where the stakeholder
answers a pre-defined set of questions
Open interviews, in which there is no pre-
defined agenda.
The requirements engineering team
explores a range of issues with system
stakeholders and hence develop a better
understanding of their needs.
In practice, interviews with stakeholders
are normally a mixture of both of these
You may have to obtain the answer to
certain questions but these usually lead on
to other issues that are discussed in a less
structured way.
Completely open-ended discussions rarely
Interviews are good for getting an overall understanding of
what stakeholders do, how they might interact with the
new system, and the difficulties that they face with current
systems
However, interviews are not so helpful in understanding
the requirements from the application domain
It can be difficult to elicit domain knowledge through
interviews for two reasons:
All application specialists use terminology and jargon that
are specific to a domain. It is impossible for them to
discuss domain requirements without using this
terminology. They normally use terminology in a precise
and subtle way that is easy for requirements engineers to
misunderstand.
Some domain knowledge is so familiar to stakeholders that
they either find it difficult to explain or they think it is so
fundamental that it isn’t worth mentioning. For example,
for a librarian, it goes without saying that all acquisitions
are catalogued before they are added to the library.
However, this may not be obvious to the interviewer, and
so it isn’t taken into account in the requirements.
Interviews are also not an effective
technique for eliciting knowledge about
organizational requirements and
constraints because there are subtle power
relationships between the different people
in the organization
Effective interviewers have two
characteristics:
They are open-minded, avoid pre-
conceived ideas about the requirements,
and are willing to listen to stakeholders. If
the stakeholder comes up with surprising
requirements, then they are willing to
change their mind about the system
They prompt the interviewee to get
Ethnography
Software systems do not exist in isolation.
They are used in a social and organizational context and
software system requirements may be derived or
constrained by that context.
Satisfying these social and organizational requirements is
often critical for the success of the system
Ethnography is an observational technique that can be
used to understand operational processes and help derive
support requirements for these processes..
An analyst immerses himself or herself in the working
environment where the system will be used.
The day-to-day work is observed and notes made of the
actual tasks in which participants are involved.
The value of ethnography is that it helps discover implicit
system requirements that reflect the actual ways that
people work, rather than the formal processes defined by
the organization
Ethnography is particularly effective for discovering two
types of requirements:
Requirements that are derived from the way in which
people actually work, rather than the way in which process
definitions say they ought to work
Requirements that are derived from cooperation and
awareness of other people’s activities
Because of its focus on the end-user, this approach is not
always appropriate for discovering organizational or
domain requirements.
They cannot always identify new features that should be
added to a system.
Ethnography is not, therefore, a complete approach to
elicitation on its own
Scenarios
People usually find it easier to relate to real-life examples
rather than abstract descriptions.
They can understand and criticize a scenario of how they
might interact with a software system.
Requirements engineers can use the information gained
from this discussion to formulate the actual system
requirements.
Each scenario usually covers one or a small number of
possible interactions.
Different forms of scenarios are developed and they
provide different types of information at different levels of
detail about the system
At its most general, a scenario may include:
A description of what the system and users expects when
the scenario starts.
A description of the normal flow of events in the scenario.
A description of what can go wrong and how this is handled
Information about other activities that might be going on
at the same time
A description of the system state when the scenario
finishes
Requirements specification
Requirements specification is the process of writing down
the user and system requirements in a requirements
document
Ideally, the user and system requirements should be clear,
unambiguous, easy to understand, complete, and
consistent
The user requirements for a system should describe the
functional and nonfunctional requirements so that they are
understandable by system users who don’t have detailed
technical knowledge
The requirements document should not include details of
the system architecture or design
If you are writing user requirements, you should not use
software jargon, structured notations, or formal notations.
You should write user requirements in natural language,
with simple tables, forms, and intuitive diagrams
System requirements are expanded versions of the user
requirements that are used by software engineers as the
starting point for the system design.
They add detail and explain how the user requirements
should be provided by the system
Ideally, the system requirements should simply describe
the external behavior of the system and its operational
constraints.
They should not be concerned with how the system should
be designed or implemented.
However, at the level of detail required to completely
specify a complex software system, it is practically
impossible to exclude all design information
There are several reasons for this:
You may have to design an initial architecture of the
system to help structure the requirements specification.
The system requirements are organized according to the
different sub-systems that make up the system
In most cases, systems must interoperate with existing
systems, which constrain the design and impose
requirements on the new system.
The use of a specific architecture to satisfy non-functional
requirements (such as N-version programming to achieve
reliability)
The possible notations that could be used for writing
system requirements
Natural language specification
Natural language has been used to write requirements for
software since the beginning of software engineering.
It is expressive, intuitive, and universal.
It is also potentially vague, ambiguous, and its meaning
depends on the background of the reader
To minimize misunderstandings when writing natural
language requirements, follow some simple guidelines:
Invent a standard format and ensure that all requirement
definitions adhere to that format
Use language consistently to distinguish
between mandatory and desirable
requirements. Mandatory requirements are
requirements that the system must support
and are usually written using ‘should’.
Desirable requirements are not essential
and are written using ‘shall’
Use text highlighting (bold, italic, or color)
to pick out key parts of the requirement
Do not assume that readers understand
technical software engineering language
Whenever possible, you should try to
associate a rationale with each user
requirement. The rationale should explain
why the requirement has been included
Structured specifications
Structured natural language is a way of writing system
requirements where the freedom of the requirements
writer is limited and all requirements are written in a
standard way
This approach maintains most of the expressiveness and
understandability of natural language but ensures that
some uniformity is imposed on the specification.
Structured language notations use templates to specify
system requirements.
The specification may use programming language
constructs to show alternatives and iteration, and may
highlight key elements using shading or different fonts
When a standard form is used for
specifying functional requirements, the
following information should be included:
A description of the function or entity being
specified.
A description of its inputs and where these
come from.
A description of its outputs and where
these go to.
Information about the information that is
needed for the computation or other
entities in the system that are used (the
‘requires’ part).
A description of the action to be taken.
If a functional approach is used, a pre-
Using structured specifications removes
some of the problems of natural language
specification.
Variability in the specification is reduced
and requirements are organized more
effectively.
However, it is still sometimes difficult to
write requirements in a clear and
unambiguous way, particularly when
complex computations (e.g., how to
calculate the insulin dose) are to be
specified
To address this problem, you can add extra
information to natural language
requirements, for example, by using tables
or graphical models of the system.
Use cases
Use cases are a requirements discovery technique that
were first introduced in the Objectory method
They have now become a fundamental feature of the
unified modeling language
In their simplest form, a use case identifies the actors
involved in an interaction and names the type of
interaction
Use cases are documented using a high-level use case
diagram.
The set of use cases represents all of the possible
interactions that will be described in the system
requirements.
Actors in the process, who may be human or other
systems, are represented as stick figures.
Each class of interaction is represented as a named ellipse.
Lines link the actors with the interaction.
Optionally, arrowheads may be added to lines to show how
the interaction is initiated
The software requirements document
The software requirements document (sometimes called
the software requirements specification or SRS) is an
official statement of what the system developers should
implement
It should include both the user requirements for a system
and a detailed specification of the system requirements
Sometimes, the user and system requirements are
integrated into a single description
The requirements document has a diverse
set of users, ranging from the senior
management of the organization that is
paying for the system to the engineers
responsible for developing the software
documents
Requirements validation
Requirements validation is the process of checking that
requirements actually define the system that the customer
really wants.
Requirements validation is important because errors in a
requirements document can lead to extensive rework costs
when these problems are discovered during development
or after the system is in service.
During the requirements validation process, different types
of checks should be carried out on the requirements in the
requirements document
Validity checks
Consistency checks
Completeness checks
Realism checks
Verifiability
There are a number of requirements
validation techniques that can be used
individually or in conjunction with one
another:
Requirements reviews
The requirements are analyzed
systematically by a team of reviewers who
check for errors and inconsistencies
Prototyping
In this approach to validation, an
executable model of the system in question
is demonstrated to end-users and
customers. They can experiment with this
model to see if it meets their real needs
Test-case generation
Requirements change
The requirements for large software systems are always
changing
One reason for this is that these systems are usually
developed to address ‘wicked’ problems—problems that
cannot be completely defined
Because the problem cannot be fully defined, the software
requirements are bound to be incomplete
During the software process, the stakeholders’
understanding of the problem is constantly changing
The system requirements must then also evolve to reflect
this changed problem view.
Once end-users have experience of a system,
they will discover new needs and priorities.
There are several reasons why change is
inevitable:
The business and technical environment of the
system always changes after installation.
 New hardware may be introduced
 Business priorities may change
 New legislation and regulations may be introduced

The people who pay for a system and the users of

that system are rarely the same people.
 System 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
Large systems usually have a diverse user
community,.
 Different users have 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.

Requirements management is the process

of understanding and controlling changes
to system requirements.
You need to keep track of individual
requirements and maintain links between
dependent requirements so that you can
assess the impact of requirements changes
Requirements management planning
Planning is an essential first stage in the requirements
management process
The planning stage establishes the level of requirements
management detail that is required
During the requirements management stage, you have to
decide on:
Requirements identification :
 Each requirement must be uniquely identified so that it can be cross-
referenced with other requirements and used in traceability assessments
A change management process :
 This is the set of activities that assess the impact and cost of changes
Traceability policies :
These policies define the relationships between each
requirement and between the requirements and the system
design that should be recorded
Tool support :
Requirements management involves the processing of large
amounts of information about the requirements
Example : spreadsheets and simple database
Requirements management needs
automated support and the software tools
for this should be chosen during the
planning phase.
You need tool support for:
Requirements storage
 The requirements should be maintained in a secure,
managed data store that is accessible to everyone
involved in the requirements engineering process
Change management
 The process of change management is simplified if
active tool support is available
Traceability management
 Tool support for traceability allows related
requirements to be discovered
Requirements change management
Requirements change management should be applied to
all proposed changes to a system’s requirements after the
requirements document has been approved
Change management is essential because you need to
decide if the benefits of implementing new requirements
are justified by the costs of implementation.
There are three principal stages to a change management
process:
Problem analysis and change specification
The process starts with an identified requirements problem or,
sometimes, with a specific change proposal.
During this stage, the problem or the change proposal is
analyzed to check that it is valid.
This analysis is fed back to the change requestor who may
respond with a more specific requirements change proposal,
or decide to withdraw the request.
Change analysis and costing
The effect of the proposed change is assessed using
traceability information and general knowledge of the system
requirements.
The cost of making the change is estimated both in terms of
modifications to the requirements document and, if
appropriate, to the system design and implementation.
Once this analysis is completed, a decision is made whether
or not to proceed with the requirements change.
Change implementation
The requirements document and, where necessary, the
system design and implementation, are modified.
You should organize the requirements document so that you
can make changes to it without extensive rewriting or
reorganization.