Requirements Engineering

◼ 1. Requirements concepts

Azeddine Chikh

University of Tlemcen
 Introduction
◼ Introduce the concepts of user and software requirements.

◼ Discuss the importance of documenting and managing

requirements, and the complexity of the RE process.

◼ Discuss the two main classes of requirement – functional

and non-functional.

◼ Discuss the links between requirements and testing.

◼ Introduce a requirements documentation template “Volere”,

which is based on a well known method.
 Requirements

◼ The final product of software development is a software system, whose success

will be judged by how well it meets its intended purpose. This purpose is defined
by the requirements.

◼ Requirements consist of what needs to be known about a system before we

start developing it. This involves descriptions of various aspects including
behavior of the system, constraints on its operation, specifications of properties,
etc.
 Requirements

◼ The process of reaching an agreed set of requirements is known as

requirements engineering. This is a complex process that involves diverse
interested parties (called stakeholders):
◼ the people that are going to use the system;
◼ those that are paying for it (the clients);
◼ those that are to benefit from it;
◼ and those that are developing it.

◼ RE is an important activity in software development and the consequences of

poor attention are:
◼ the system is delivered late and/or is more expensive;
◼ the system does not deliver what the end users want;
◼ the system is unreliable and has errors.
 The nature of requirements

◼ Reqs tend to change as the environment changes.

◼ In a “Hospital admissions service”, the stakeholders are many and with different
interests (doctors, nurses, administrative staff and patients). What is intended of
the system may not be clear until specific requests have been considered.

◼ Any change in the organization of the hospital may affect what is intended of the
system.

◼ In large organizations, there are organizational and political factors that will
influence the system but may not be clearly stated (example: conflicts between
the interests of doctors and administrators in the way the system is used).
 The nature of requirements
◼ Reqs need to be:

1. necessary and traceable: each requirement should fulfill a purpose, and it should be clear where each
requirement comes from;

2. non-ambiguous and realistic – there should be no alternative interpretations for a requirement, and it
should be feasible to carry each requirement through to development;

3. complete – all the intended functionality should be described;

4. consistent – requirements should not contradict each other;

5. verifiable – it should be possible to check that a requirement has been implemented.

6. independent of design.
 Requirements dependencies
◼ Reqs have numerous complex and non-trivial dependencies: they often conflict
with each other when they make contradictory statements about a system’s
properties; Example: In a mobile phone, portability (small size of the screen and
display area), conflicts with the usability of the phone. So the requirements of
usability and portability cannot both be implemented exactly as desired.

◼ A practical approach for investigating the dependencies between requirements

is to consider a few representative scenarios from a set of all the possible
scenarios that illustrate the requirements in practice.
 Requirements dependencies

◼ By a scenario, we mean a ‘specific sequence of activities that might occur when

a system is used’ (in a banking system we might consider the scenario of a
withdrawal…).

◼ Scenarios can be helpful in contextualizing the requirements, and for identifying

the conflicts and cooperation between them.

◼ Unfortunately, there is no formal way to select the ‘right’ scenarios. The selection
is based on an analyst’s experience.
 The RE process

◼ The RE process takes a set of inputs, consists of a set of activities, and delivers
a set of outputs.
 The RE process

The inputs of a RE process are the information from which the requirements can be
derived. The stakeholders’ needs are one of the inputs. Other inputs come from
existing knowledge of the domain and associated regulations, the organization’s
standards, and any systems that are already in place.
 The RE process

The outputs of a RE process are the reqs document and the models of what the
system is intended to do. The reqs document includes the reqs specification
containing the precise and accurate descriptions of each requirement.
 The RE process

3. As for the activities, there is a set of activities that can be identified as common
to many RE processes :
a) Elicitation,
b) Analysis and negotiation,
c) Documentation
d) Validation.
 The RE process

a) Elicitation is the activity concerned with identifying the requirements. This

involves identifying the system’s stakeholders, defining the boundaries of the
system, and determining the main objectives the system has to meet... .
Techniques for elicitation are : interviewing, brainstorming, running focus
groups and holding team meetings…
 The RE process

b) Analysis and negotiation is the activity where requirements are categorized and
prioritized, and examined for their properties of consistency, completeness and
non-ambiguity. Models of requirements are created to help communication with
the customers and developers.
 The RE process

b) Documentation is usually done using a template document.

 The RE process

b) Validation consists of a careful check of the overall requirements

documentation, usually following a checklist of questions.
 The RE process

◼ Elicitation and analysis occur primarily, but not exclusively, at the beginning of a
project, and their relative importance and effort vary over time.
◼ Thus the process of RE is not generally linear and sequential. At each iteration
of the process, activities may be revisited and adjustments made; some of the
activities may be carried out in parallel, to some extent.
 Functional requirements

◼ FR are those requirements that specify the behavior of a system (Ex: actions
that the product must take – check, calculate, record, retrieve etc.).
◼ This is in contrast to non-functional requirements, which specify properties like
usability, reliability & maintainability.
 Functional requirements
Elicitation and analysis and negotiation
◼ When eliciting FR, we should pay attention to their relative importance.

◼ It is important to identify those requirements that are essential (often said to be

‘core requirements’) and those that are inessential but would be nice to have.
The reason is simple: more reqs tend to increase the cost and the time.

◼ Thus, FR should be prioritised, so that the most important reqs can be identified.
This enables a judgment to be reached on what can be delivered for a given
price, or what the cost will be for a given set of reqs.

◼ The domain modeling activity will identify a set of business processes triggered
by business events.

◼ These business processes and events become the context for the system being
developed. Some of the business events will be directly relevant to the new
system; each of these events will then be associated with a Use Case – a
description of how the new system is to be used for a specific goal.
 Functional requirements
Elicitation and analysis and negotiation

◼ UCs are derived from business events, and each UC is described by a set of
scenarios.

◼ A scenario is a series of steps that complete the functional tasks of a UC,

described from the point of view of a user.

◼ In a scenario for “checking a guest into a hotel”, there is a step “allocate room’”
This step maps directly to the requirement: ‘The system shall allocate a room’.

◼ On the other hand the step “issue key to guest” might be a completely manual
operation, and is unlikely to involve any software requirements.
 Functional requirements
Elicitation and analysis and negotiation

◼ One advantage of deriving requirements from UC descriptions is that we can

then associate the requirements with the specific goal of the UC to which they
relate; this is a way of structuring requirements.

◼ Requirements that belong to several UCs are identified and this to be

implemented just once.

◼ It is likely that reqs will continue to emerge long after the system has to be
installed. It is therefore crucial that reqs are carefully managed.

◼ One approach used in the DSDM (Dynamic Systems Development Method)

framework is the MoSCoW scheme, where reqs are classified as ‘Must haves’,
‘Should haves’, ‘Could haves’, and ‘Won’t haves’.
 Functional requirements
Describing requirements
◼ In writing requirements, we are looking for clear statements of the form ‘The
system shall ...’. In doing this we need to be careful to avoid ambiguity, which is
not easy, because natural language is notoriously ambiguous.
‘The system shall allocate a room, and it should be cheap’.
By using the word ‘it’, we have introduced ambiguity: is it the room or the system that
should be cheap? (Furthermore, what does cheap mean?) Pronouns (‘it’, ‘their’...) should
be avoided.

◼ Another source of ambiguity is the way in which a word may have multiple
meanings, or can be interpreted in various ways by different people.

◼ Words that have technical meanings or meanings specific to the business

should be given definitions that get recorded in the requirements specification.
Abbreviations (including acronyms) should be defined there.

◼ Reqs should be described at a level of detail that the people commissioning the
system can understand. However, the question arises as to what is the
appropriate level of detail to be provided by a requirements analyst.
 Functional requirements
Describing requirements

◼ Ian Somerville distinguishes two types of requirement:

Requirements specification [is] the activity of translating the information gathered

during the analysis activity into a document that defines a set of requirements.
Two types of requirements may be included in this document:

User requirements are abstract statements of the software requirements for the customer and end-user
of the system;

Software requirements are a more detailed description of the functionality to be provided.

 Functional requirements
Describing requirements

◼ We need to work with both types of requirement. We need user requirements

when interacting with stakeholders external to the project, and software
requirements to inform system design. The two forms of requirement are related.

◼ The first type of requirement is usually written in natural language. Either natural
language or a more formal approach (for example mathematical specifications)
can be used for software requirements. In both cases, our requirements should
be recorded in a structured document (Volere template).

◼ There is a major distinction to be made between a requirement and its solution.

we must ensure that we do not write solutions instead of requirements. we need
to understand the essence of the business, not its implementation.
 Functional requirements
Describing requirements

◼ Another issue that arises because of solution considerations is that of technical

solution requirements.

◼ Technical solution requirements are not there for business reasons, but to make
the chosen implementation work correctly. They are constraints on the behavior
of the product.

◼ It is essential to ensure that the technical requirements are not introduced before
the business requirements have been fully understood.

Example: The need to authenticate the user of a system is a ‘business

requirement’. However, stating that this should be done in a particular way, for
ex, using a password (as opposed to, say, an iris scan), this is a ‘technical
solution requirement’.
 Non-Functional Requirements (NFRs)
◼ NFRs are qualities that the system should have, such as being secure, fast,
usable, maintainable…

◼ NFRs can be associated with a particular piece of functionality (a UC or group of

UCs) or with the overall system.

◼ One useful way to think of NFRs is as constraints on the functional requirements.

From this perspective, FRs tell us what the system should do, and NFRs constrain
the ways in which those things are done: securely, quickly etc.

◼ This means that, in effect, NFRs only make sense in relation to what they say
about functional requirements.

◼ In recent times, requirements engineers have begun to change their terminology

from NFRs to ‘quality requirements’.
 Non-Functional Requirements (NFRs)

◼ Today, we view NFRs in the same light as FR:

to be useful, reqs must be testable, which means that they must be measurable

◼ NFRs constrain us in our choice of architecture, in that the chosen architecture

must allow us to achieve the qualities, such as speed and maintainability, that
we require.
 Non-Functional Requirements (NFRs)

◼ Some authors identify the following eight classes of NFRs:

1. look-and-feel requirements

2. usability requirements;

3. performance requirements;

4. operational requirements;

5. maintainability and portability requirements;

6. security requirements;

7. cultural and political requirements;

8. legal requirements.
 Look-and-feel requirements

◼ Look-and-feel requirements are about the overall impression a product will make
on a user, that is, the appearance and behavior of its interface.

◼ For example, in a banking environment, we might want the product to have a

conservative feel, with limited use of colors and animation. If the product is a
game, then the opposite might apply.

◼ The following are examples of look-and-feel req.:

◼ The product shall comply with the motif user-interface guidelines
◼ The product shall use only two colors.
◼ The product shall use lots of animation.
◼ The product shall use a large range of exciting sounds.
 Usability requirements
◼ A product with poor usability may result in poor productivity, high error rates due to
‘misuse’, and high stress levels for users. To specify usability requirements, we need to
think about the types of people who will use the system.

◼ Usability can be split into two issues: how ‘easy to learn’ is the software and how ‘easy to
use’ is it.

◼ ‘Easy to learn’ is contextual req: An easy-to-learn accounts package might require a two-
hour tutorial…

◼ An easy-to-use product is designed with a view to long-term efficiency, and may require
users to be trained before it can be used effectively. However, the cost of training is
compensated by the resulting efficiency gain.

◼ ‘Easy-to-learn’ products, on the other hand, are often aimed at those tasks that are
performed infrequently and so have to be “re-learnt” from time to time; these products are
often targeted at the public market. When training is infeasible, products have to be easy
to learn and are not normally complex.
◼ The following are examples of usability requirements.
◼ A university graduate should be able to learn to use 50% of the functionality of the product in 2
hours.
◼ 90% of the population should be able to place an order from a web interface within 5 minutes.
 Performance requirements
◼ Performance reqs relate to the capacity of a system to carry out its tasks. This
includes the speed with which the system should operate, how much data it can
handle, how accurately it can produce its results, and how reliable it is.

◼ Note that a system may be able to deal with a given transaction with the
requisite speed, but if the volume of transactions increases, the system may not
be able to perform well.

◼ Reliability is the ability of the system to behave consistently in a user-acceptable

manner when operating within the environment for which it was intended.

Examples: 1) The product shall calculate a guest’s bill in 2 seconds.

2)The product shall handle up to 10 users simultaneously.
 Operational requirements

◼ Operational requirements concern the environment in which a product is to be

used.
Example: In a “mountain rescue team” system, rescuer need to use portable
devices, and will therefore need to deal with extremes of temperature, humidity
and available light….

◼ The following are examples of operational requirements.

1. The product shall be usable at altitudes up to 1500 m, in icy and wet conditions, and in both darkness
and bright sunshine.
2. The product will be used in a standard office environment, except that high levels of background noise
may occur.
 Maintainability and portability requirements
◼ There are two quite different notions of maintaining a product:
1. keeping the product updated in the light of expected changes;
2. mending the product when it fails.

Examples:
The product shall be able to be modified to cope with new class of user.
The product shall be able to be modified to cope with minor changes to European law that occur every
six month.
The product shall be portable to all of the operating systems…
 Cultural requirements
◼ If a product is to be sold in a different country to our own, there will be potential
cultural requirements to consider.

◼ Less dramatic, but still important, are the cultural differences between
organizations. If we are eliciting requirements for an organization that is not our
own, be wary of cultural differences.

◼ A way to overcome these problems is to seek the help of someone who is

knowledgeable about the Culture.

◼ The following is an example of a cultural requirement.

The language used in the interface should be formal and polite.
 Political requirements
◼ A political requirement may be even more important to the project than, any
other requirement.
Example: ‘Product shall have the full support of the unions.’

◼ As a requirements analyst, we are more likely to encounter the political side of

organizational life.
Example: we may sometimes find it difficult to gain access to certain
stakeholders when eliciting requirements. In such cases, the project manager
may be able to help.
 Legal requirements

◼ Two important areas from which requirements must be elicited are the law and
the standards specific to a product:
◼ When developing computer systems, we must satisfy ourselves that the relevant laws will be
complied with (either by examining the legislation or by asking a lawyer). Failure to comply with the
law might involve a range of penalties.
◼ It is also important to look at the environment within which the system will operate, and what other
systems and people it will interact with.

◼ A third area related to law is the regulatory structure that controls some
industries. Ex: Companies that make computer-based medical devices must
have their equipment approved by the relevant regulatory authority (or
‘regulatory compliance’) before it can be used in a medical setting.
 Security requirements
◼ Security is also a good illustration of conflicting requirements: we can make a
system very secure to deter unauthorized access, but it may be at the cost of
making access by legitimate users extremely difficult !
◼ Security covers confidentiality, integrity and availability (often abbreviated to
CIA) :
1. Confidentiality refers to the protection of data from unauthorized access and discovery;
2. integrity refers to consistency of data; and
3. availability refers to access by authorized users.
◼ As well as the costs incurred if data is lost as a result of its integrity being
compromised, there may be costs as a result of data being unavailable, as work
cannot then be completed, and contractual arrangements may not be met.
◼ Substantial costs incurred also with loss of confidentiality, as commercial secrets
may be exposed, individuals may take legal action, and an organization's
reputation may be harmed…
There is a need to protect a computing system and its resources from
unauthorized access by those who seek to gain some advantage or act
maliciously. There are intruders who try to read, change or delete the data that is
stored in, processed by or passed around a computing system.
 Conformance testing and fit criteria
◼ The software product that we develop should satisfy all of the FR and NFRs. In
other words, the software product must conform to its requirements.
◼ To find out if this is the case, we need to test the product against its
requirements, that is, perform conformance testing.
◼ To be able to do this, each requirement needs to be expressed in a way that it
can indeed be tested. We will therefore consider what criteria can be added to
each FR and NFR, to allow us to tell whether it has been satisfied.
◼ A fit criterion is a precise and testable statement of a requirement. It may
specify a quantitative measure for some aspect of the system’s behavior or
performance, or define some other quality that the system must possess if it is to
meet the requirement.
◼ Whatever form it takes, it must be capable of being tested in an objective
fashion.
◼ The process of attaching a fit criterion to a requirement helps to clarify the
requirement; determining the fit criteria will also involve interacting with the client
and other stakeholders to check that the criteria being specified are acceptable.
 Fit criteria for a FR

◼ The fit criteria for a functional requirement need to be written in such a way that
we can tell whether the product satisfies the requirement.
Example: For the requirement “The system shall accept a credit card number from a client”, the
following fit criterion might be suitable:
A valid credit card number has been stored in the system.
 Fit criteria for a NFR

◼ The fit criterion for a NFR needs to be expressed in terms of some measurable
quantity (some scale of measurement).

◼ A scale of measurement is the unit against which the conformance of the

product is tested. It is the unit used in defining the fit criterion. Ex: A usability
requirement of “time taken to complete a task” has the scale of time – ms,
seconds…

◼ To find an appropriate scale of measurement, we need to analyze the

description and rationale of the requirement.
Ex: For the NFR “The credit card number should be accepted securely”, the following fit criterion might
be appropriate: The credit card number should be revealed to a third party in less than 0.0001% of
cases.

◼ The fit criteria are like benchmarks, or goals, with which the testers can compare
the delivered product or solution against the original req.
 Representing the requirement

◼ Requirements need to be documented within a project. There are many reasons

why this is so. Requirements documents are an aide-memoire to record
decisions agreed among the system’s stakeholders.

◼ They are the starting point from which the system is designed and built, and are
the basis for the validation of the system, once it is built.

◼ Documentation may take many forms. The one we adopt here is based on the
Volere approach.
 The Volere template

◼ The Volere template is a document template that gathers all the reqs of a
system, together with other issues that may affect those reqs.

◼ Note that a reqs document is organic. It grows and changes throughout the
duration of a project. The Volere template supports a disciplined way of
recording reqs as they are discovered and refined.

◼ The template is organized into four main sections, each including a number of
requirements categories.
 The Volere template
◼ The following should be recorded for each FR/NFR:
√ requirement number – a number uniquely identifying the req.;

√ events/UCs – the UCs or events that are associated with this req.;

√ description – a one-sentence statement of the intent of the req.;

√ rationale – a statement of why the req is considered important or necessary;

√ source – a record of who raised the req in the first instance;

√ fit criteria – acceptance criteria, written in a quantified manner so that the solution can be tested against
the req;

√ dependencies – the identifying numbers of other reqs that have an impact on this one;

√ conflicts – the identifying numbers of reqs that contradict this one, or make this one less feasible;

√ history – the origin of the req, and any changes to it.

◼ In large projects, the use of CASE tools for reqs management is beneficial, if not essential