Block I: From domain to requirements

Unit 2: Requirements concepts

1
 In this unit, you will see an approach that stresses the importance
of carefully documenting requirements, but you will also be
reminded of an agile approach to documentation.
 You will see the differences between functional and non-functional
requirements, and the ways each of these can be recorded.
 The importance of attaching measurable fit criteria to each
requirement will be established.
 Finally, you will see how you can make use of a template to help
ensure you cover all the categories of requirements, and how you
could document requirements in an agile approach.

Note that: All SAQs and Exercises in this unit are required.

2
 Section 1: Introduction
 In this unit we introduce the concepts of user and software
requirements.
 We discuss the importance of documenting and managing
requirements, and the complexity of the requirements engineering
process.
 Sections 3 and 4 define the two main classes of requirements:
functional and non-functional, and Section 5 discusses the links
between requirements and testing.
 In Section 6 we introduce a template for requirements
documentation that is based on a well-known method in the
literature.

3
 Requirements are the information about what a system will
be and do that needs to be known before development
starts.
 The process of reaching and documenting an agreed set of
requirements is known as requirements engineering

 This is a complex process that involves stakeholders of the

system
 Examples of stakeholders are:
◦ the people who are going to use the system
◦ those who are paying for it (the clients)
◦ those who are to benefit from it
◦ those who are developing it.

4
 Section 2: Requirements
 Requirements engineering is an important activity in software
development and the consequences of poor attention to this activity are
costly
 The Standish Group has been publishing reports on the success of
software projects since 1994. In its latest report (2012) it identified that:
◦ only 39 per cent of all projects were being delivered on time, on budget, with required
features and function
◦ 43 per cent were late or over budget or not delivering all required features
◦ 18 per cent were either cancelled before delivery or delivered but never used.
 In its 2010 report the Standish Group also identified major problems and
proposed its own solutions. Among these problems were the following:
◦ poor, or lack of, user involvement
◦ lack of clear business objectives
◦ under and over building – building features that are never used and not building all the required
.

features
◦ lack of support for agile processes and poor support for requirements and solutions evolving
.

together through collaborative teamwork.

5
 Section 2: Requirements
The nature of requirements

 The specification of the requirements for a system is not an

easy task because:
◦ requirements are not usually stable and they tend to
change as the environment changes
◦ there are usually many stakeholders and they do not
always have the same view or priorities for the system to be
developed
◦ it is not always clear and easy to identify what the
requirements for a system are
◦ there are many factors that influence what the requirements
are and these are not always explicit.

6
 Section 2: Requirements
Requirements need to be:
 Necessary and traceable – each requirement should fulfil a purpose and it
should be clear where each requirement comes from.
 Non-ambiguous and realistic – there should be no alternative interpretations for
one requirement and it should be possible to carry each requirement through to
development.
 Complete – in a plan-driven development all the intended functionality is
described as completely as possible, although in practice it is often not possible to
be absolute about this and it is important to allow for requirements that emerge
later in the system development and during maintenance.
 Consistent – requirements should not contradict each other.

 Verifiable and validated – it should be possible to check that a requirement has

been implemented, and that what is implemented corresponds to what was
intended.
 independent of design, avoiding design decisions that are not relevant
at this stage. However avoidance of all design issues is not always
practical

7
 Section 2: Requirements
 Requirements have numerous complex and non-trivial
dependencies: they often conflict with each other.
◦ For example: the required portability of the mobile phone, and therefore
its small size and display area, conflicts with the usability of the phone.
 The dependencies between requirements need to be
investigated at this stage of the software development life
cycle.
◦ 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.
◦ a scenario: is a specific sequence of activities that might occur when a
system is used.
◦ Scenarios can be helpful in contextualising the requirements and for
identifying the conflicts and cooperations between them.

8
 Section 2: Requirements
The requirements engineering process
 The inputs of a requirements engineering process:
1. Information from the stakeholders’ needs;
2. Information from existing knowledge of the domain and
associated regulations, the organization's standards, and any
systems that are already in place.
 The outputs of a requirements engineering process:
1. The main output is the contract between the customer and
the developers of the system.
2. The requirements document and the models of what the
system is intended to do.
 The requirements document includes the requirements
specification that contain the precise and accurate descriptions of
each requirement.

9
 Section 2: Requirements

The requirements engineering process

 Activities of the requirements
engineering process:
a. requirements elicitation,
b. requirements analysis and negotiation,
c. requirements documentation,
d. requirements validation.

10
 Section 2: Requirements

(a) Requirements elicitation is the activity concerned with

identifying the requirements; this is done by:
◦ consulting the stakeholders,
◦ reading existing documents,
◦ understanding the domain,
◦ defining the boundaries of the system, and
◦ understanding the possibilities for change.
 There are many techniques for elicitation, such as:
◦ interviews,
◦ focus groups,
◦ team meetings,
◦ brainstorming sessions.
◦ crowd sourcing
◦ There are also modeling techniques to help this process (e.g. activity
diagrams, use cases).
11
 Section 2: Requirements

(b) Requirements 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.
(c) Requirements documentation is usually done
using a template document.
 Documentation also includes the modelling artefacts

12
 Section 2: Requirements

(d) Requirements validation consists of a careful check of

the overall requirements documentation, usually following a
checklist of questions.
◦ This is a way of ensuring that the requirements correspond to what
is really intended of the system.
 Elicitation and analysis occur primarily, but not
exclusively, at the beginning of a project, and their
relative importance and effort vary over time.
◦ The process of requirements engineering is not generally linear
and sequential.
◦ At each iteration of the process, activities may be revisited and
adjustments made.

13
 Section 2: Requirements
The requirements engineering process
Figure illustrates the relative
effort of requirements elicitation
and analysis in the early
phases of a project and is
naturally a simplification
because it omits the other
activities of the requirements
engineering process. Initially,
elicitation is dominant. Most of
the time the two activities
interact and inform each other
– requirements elicitation
informs the modelling of
functionality and data (which is
part of analysis), while analysis
Figure: Relative effort of requirements elicitation versus helps to discover new
analysis over time requirements.

14
 Section 2: Requirements
An agile perspective of requirements

 The agile approach to software development has emerged from

concerns about the way software was being developed, the need for it
and its usefulness.
 Agile development stresses the importance of documenting only when
there is a well-defined purpose.
 In an agile approach, requirements documentation serves a purpose
and should be done only to the extent that it contributes to that
purpose.
 It should serve as a vehicle for common understanding,
communication and future traceability.

◦ In their latest edition of Mastering the Requirements Process (2012), Suzanne and
James Robertson accept that ‘The requirements do not have to be written, but they
have to become known to the builders’ (Truth 5, Chapter 1).

15
 Section 2: Requirements
Requirements and architecture

 Requirements may contradict each other, for example portability and

usability in a mobile device, and a compromise will need to be
achieved.

 Solving these conflicts involves taking decisions that will affect the
architecture of a system.

 Some techniques that we will use to represent requirements help in

taking decisions that affect the overall architecture of the intended
system

16
 Section 2: Requirements
Requirements and testing

 Testing is usually regarded as an activity that takes place at the end of

software development, and this is what a waterfall process model
suggests.
 Testing can be done as soon as requirements are being analysed.
 Requirements do not make much sense if there is no way that they can
be tested.
 When defining requirements, a developer may be implicitly thinking
about tests that a system will have to go through.

Requirements, if they are to be implemented successfully, must be

measurable and testable.
(Robertson and Robertson, 2012, Truth 10, Chapter 1)

17
 Section 2: Requirements
Summary of section

 In this section we introduced software requirements and discussed their

relevance in software development and the consequences that arise
from a poor effort at understanding the requirements for a system.
 We discussed the importance of involving the various stakeholders in the
definition of requirements and the need to document requirements as a
contract for development.
 We considered the perspectives on requirements documents of plan-
driven and agile approaches.
 We also described the activities that take place in a requirements
engineering process and other activities happening in parallel with
requirements engineering.

18
 Section 3: Functional requirements

 A functional requirement describes the

behavior of the system.
◦ specifications of the product’s functionality;
◦ actions that the product must take – check,
calculate, record, retrieve etc. (verbs are
functions);
◦ derived from the fundamental purpose of the
product;
◦ not a quality
 For example, ‘fast’ is a quality, and is therefore a non-
functional requirement.
 Adjectives talks about quality.

19
 Section 3: Functional requirements

Elicitation, analysis and negotiation

 When eliciting functional requirements, attention must be paid to their

relative importance.
 It is important to identify those requirements that are essential and
those that are inessential but would be nice to have.
 Identifying the core requirements ought to identify the minimum cost
and time for development.
 Functional requirements should be prioritised so that the most
important requirements can be identified.
 In practice, when eliciting requirements you would probably use a way
that best suits your experience and applications and that results
probably from a combination of different approaches.

2020
 Section 3: Functional requirements
Elicitation, analysis and negotiation

 Iterative requirements gathering

◦ One approach to prioritisation, which is used in the DSDM framework (dynamic systems development
method), is the MoSCoW scheme, where requirements are classified as must have, should have,
could have, and won’t have.
◦ This classification scheme can be used at the level of each iteration, allowing an iteration to be
timeboxed.
◦ When the time allocated runs out, ‘should have’ and ‘could have’ requirements are delayed to a later
iteration.
 Requirements through stories
◦ A requirements capture process based on user stories usually starts with a brainstorming workshop
with users and customers to generate an initial set of stories.
◦ A story is recorded on a card and triggers a conversation which helps with understanding the detail,
and outline tests for each story.
◦ Stories are prioritised, grouped and allocated to an iteration. The outcome of an iteration is validated
against its user stories.

2121
 Section 3: Functional requirements

Types of functional requirements:

 Business requirement: tasks that system should do.

Examples:
 X must check a user’s identity.
 X must produce a statement of the user’s account.
- The requirement states what needs to be done, not how to do it.

 Technical solution requirements: is a constraint on the

product due to the technology of the solution that must be
adopted.
◦ X must check a user’s password
◦ X must employ the company’s proprietary password maintenance system
 Specific technology is mandated.

22
 Section 3: Functional requirements

Overall process (based on use cases) for determining a

set of functional requirements

1. Understand the domain, determining the business processes that

rare triggered by business events.
2. Determine the scope of the new system, and which business events
are relevant.
3. Draw up a set of use cases for the product associated with those
events.
4. Describe each use case by one or more scenarios – sets of steps.
5. Work through each step of each scenario to determine a set of
system requirements.
6. Check for similar requirements from different use cases.
7. Search out and remove ambiguity.

23
 Section 3: Functional requirements

 User requirements are usually written in natural

language for obvious reasons.
 Natural language or more formal approaches such as
mathematical specifications can be used for system
requirements
 the major problem with a requirement that is written in a
natural language such as English is ambiguity.
 To avoid ambiguity attention has to be given to the
language used to represent requirements.

24
 Section 3: Functional requirements

Sommerville distinguishes two types of requirements as follows:

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; system requirements are a more detailed
description of the functionality to be provided.

(Sommerville, 2011)

25
 Section 3: Functional requirements
Summary of section

 In this section we defined functional requirements and

illustrated a process for eliciting them.
 Also we discussed briefly an alternative agile process for
dealing with requirements based on user stories.
 We considered issues around the documentation of
requirements and distinguished between technical solution
requirements and business functional requirements.

26
 Section 4: Non-Functional requirements

 Non-functional requirements are qualities that

the system should have: such as being secure,
fast, usable or maintainable.
 Examples of NFR:
◦ X must validate the user’s identity and password within
3 seconds:
◦ X must be usable by users with limited skills.
◦ X must operate in arctic climates (freezing weather).
◦ X must work fast, secure, etc.

27
 Section 4: Non-Functional requirements

Important points about NFR:

 Non-functional requirements may be associated with a particular piece of

functionality or with the overall system
 One useful way to think of non-functional requirements is as constraints on the
functional requirements
◦ From this perspective, functional requirements tell you what the system
should do, and non-functional requirements constrain the ways in which
those things are done – securely, quickly, and so on.
 Non-functional requirements make sense only in relation to what they say
about functional requirements
 To have useful NFR, NFR must be testable (measurable) as well as FR.
 In this respect the idea of fit criteria is introduced.
 A fit criterion is a measurement of a requirement that will ultimately enable a
tester to determine whether or not the delivered product satisfies, or fits, the
requirement.

28
 Section 4: Non-Functional requirements

Robertson and Robertson (2012) identify the following eight classes of

nonfunctional requirements:

1. Look-and-feel requirements. The spirit of the product’s appearance.

2. Usability and humanity requirements. The product’s ease of use and any
special usability considerations.
3. Performance requirements. How fast, how safe, how accurate, how reliable,
and how available the functionality must be.
4. Operational and environmental requirements. The environment on which
the product will have to work (under water, for example), and what
considerations must be made for this environment.
5. Maintainability and support requirements. Expected changes, and the time
allowed to make them.
6. Cultural requirements. Special requirements that come about because of the
people involved in the product’s development and operation.
7. Legal requirements. The laws and standards that apply to the product.
8. Security requirements. The security and confidentiality of the product

29
 Section 4: Non-Functional requirements

 1. Look-and-feel requirements describe the overall

appearance of the product to its users.
 The look-and-feel requirements are not about the specifics of
the user interface.
 The look and feel is concerned with the impression you wish
to make. You want it to reflect the distinctive values, ethos
and style of your organisation

 Some examples of look-and-feel requirements are:

◦ the product shall comply with the iOS human interface guidelines
◦ the product shall use only two colours
◦ the product should use a lot of animation
◦ the product shall use a large range of exciting sounds.

30
 Section 4: Non-Functional requirements

 2. Usability and humanity requirements: They describe how easy to use the
product should be for its intended users under specified circumstances, and
how satisfied they are with it. This includes how easy it is to learn to use the
product
 Usability and humanity impacts on productivity, error rates, stress levels and
acceptance. It determines how well the human part of the system can perform
 A usability and humanity requirement can be expressed more precisely by
describing the level of achievement required after the required training or
learning period.

 Some examples of usability and humanity requirements are:

◦ a university graduate should be able to learn to use 50 per cent of the functionality of
the product in 2 hours
◦ ninety per cent of the general population should be able to place an order from a web
interface within 5 minutes – 90 per cent of elderly users should be able to place an
order from a web interface within 10 minutes
◦ it should be possible to use the system to pay in different currencies
◦ the system should comply with the Disability Discrimination Act.

31
 Section 4: Non-Functional requirements

Usability and humanity requirement can be split into two requirements:

 An Easy to learn requirement: is contextual

◦ An easy-to-learn website for buying books might require zero training.
◦ An easy-to-learn accounts package might require a two-hour tutorial
rather than a week of onsite training.
◦ An easy-to-learn nuclear reactor control system might require several
months of training but not several years of experience
 Easy-to-learn products are often aimed at tasks that are performed
infrequently and that therefore have to be relearned from time to
time, and are often aimed at the public market.

 An easy to use product:

◦ Easy-to-use products are designed to facilitate efficiency and users may
require training to be done before the product can be used effectively.

32
 Section 4: Non-Functional requirements

3. Performance requirements: relate to the effectiveness of a system in

carrying out its tasks.
 Normally the main performance requirements involve speed (the time
to do something), capacity, safety, accuracy, reliability and availability.
 You should look for requirements that specify the speed and efficiency
in ways that can be measured objectively.
 It is hard to specify performance of web-based systems because there
are too many unknowns, for example the speed of connection.

 Some examples of performance requirements are:

◦ the product shall calculate a guest’s bill in 2 seconds
◦ the product shall handle up to 10 users simultaneously
◦ the product shall report wind speeds within 5 miles per hour of the actual
speed
◦ the product shall, on average, operate without failure for 20 days.

33
 Section 4: Non-Functional requirements

4. Operational and environmental requirements: relate to the

environment in which a product is to be used.
 Operational and environmental requirements describe the operational
environment (factors external to the product) in which the product must
function correctly
 One approach to finding the operational and environmental requirements
is to investigate the product boundary (the scope as defined by the use
cases) and consider the needs of each system it interacts with

 Some examples of operational and environmental requirements are:

◦ the product shall be usable above an altitude of x, in icy and wet conditions,
and both in the dark and in bright sunshine
◦ the product will be used in a standard office environment, except that high
levels of background noise may occur
◦ the product will need to be installed at 58 locations around the proposed route
of the race in 2 days by 3 semi-skilled workers

34
 Section 4: Non-Functional requirements

5. Maintainability and support requirements: There are

two quite different notions of maintaining and supporting a
product.
1. Keeping the product updated in the light of expected changes.
2. Fixing the product when it fails.

 Some examples of maintainability and support

requirements are:
◦ the product shall be able to be modified to cope with a new class of
user
◦ the product shall be able to be modified to cope with minor changes
to European law that occur every six months on average
◦ the product shall be portable to all the operating systems currently
used in our Slough office.

35
 Section 4: Non-Functional requirements

(6) Cultural requirements

 Cultural requirements usually arise when:

◦ (i) the aim is to sell a product in a different country, particularly a country with a
different culture and language from the one that the product was initially designed for
◦ (ii) eliciting requirements in an organisation different from one’s own
 the best approach to dealing with cultural issues is to obtain the help of
stakeholders from that culture.
 Cultural and political requirements often involve having to ask personal
questions and can be difficult to quantify. Such questioning is likely to
be sensitive.

 An example of a cultural requirement is:

◦ the language used in the interface should be formal and polite.

36
 Section 4: Non-Functional requirements

7. Legal requirements : concern with two important areas

from which requirements must be elicited are the law and
the standards that apply to the product.
 A third area related to law is the regulatory structure that
controls some industries.
 The cost of litigation is one of the major risks for
commercial software, and can be expensive for other
kinds of software.
◦ There are penalties for non-conformance with the law:
fines, imprisonment and loss of reputation.
 To determine the appropriate law that affects the product
is to obtain help from the company’s lawyers.

37
 Section 4: Non-Functional requirements

8. Security requirements
 In the context of a computer system Security is about the prevention of
unauthorised access to the system.

 With a standalone computer it is possible to achieve security by physical

means and you may wish to restrict the actions of individual users.
 For a distributed computing system, which involves a number of
interconnected computers, security becomes an issue.
 On an external network, such as the internet, communications pass via a
number of computer systems over which the user has no control.
 A particular example where security is a major issue is that of ecommerce

 Therefore security goes beyond the basic protection of resources to

considering the computing system in its surroundings or environment

38
 Section 4: Non-Functional requirements

8. Security requirements (contd.)

 It is possible to make a system secure to deter unauthorised access but
at the cost of making access by legitimate users extremely difficult.

 Security requirements cover access, privacy, integrity, audit and immunity:

◦ access addresses uninterrupted or continual access to data and
functionality by authorised users
◦ privacy addresses the protection of data from unauthorised access and
disclosure
◦ integrity addresses consistency of data, the ability to prevent
unauthorised modification or deletion of data
◦ audit addresses both how the correctness of product and data can be
verified, and how to help detection of inappropriate access and
intrusion
◦ immunity addresses the protection of a system against threats and
attacks.

39
 Section 4: Non-Functional requirements

8. Security requirements (contd.)

 A computing system and its resources need to be protected from
unauthorised access by those who seek to gain some advantage or act
maliciously. They are intruders who try to read, change or delete the data
that is stored, processed or passed around a computing system.

 Some examples of intruders are:

◦ ‘crackers’ who test their skills against the security measures of a

system for their personal pleasure
◦ competitors who try to gain access to commercially secret information
◦ fraudsters who try to obtain financial gain from the owner of the system
or some third party.

40
 Section 4: Non-Functional requirements
8. Security requirements (contd.)
 The forms an attack might take are as follows:
 Disclosure of private information or the unauthorised release of information
◦ Example, an intruder might intercept the network and read your messages en route. From an ecommerce transaction
such as an electronic order you have placed, an intruder might be able to access your credit card details and illegally
use them.

 Modification, loss of integrity, or the unauthorised alteration of data or information

◦ Intruders might change messages or stored data. They might increase their bank balance either by directly modifying
the data or by altering a message so that they become the payee of an online fund transfer, withdraw all the funds and
then disappear.

 Denial of use or service or loss of access, where there is some denial of network
service to its authorised (legitimate) users.
◦ The intruder redirects messages or creates congestion by recycling messages. They might also covertly gain control of
the computers owned by innocent third parties and use these computers to bombard a site with messages. The intruder
might be a competitor who is trying to put the company out of business by preventing access to its system by its
customers.

 Repudiation, where a legitimate user claims that they did not send or receive a
particular message that was sent or received
◦ Example, somebody who ordered holiday insurance online might after the holiday claim that they did not order the
insurance. The insurer could do a similar thing and repudiate that the customer ordered insurance if an insurance claim
is made.

41
 Section 4: Non-Functional requirements

Summary of section

 In this section we described the different types of non-

functional requirements and their main characteristics and
illustrated each type of non-functional requirement.
 We looked in more detail at security requirements and the
issues they raise.

42
 Section 5: Conformance testing and fit criteria

 The software product that we develop should satisfy all of the

functional and nonfunctional requirements we identify.
 Therefore, we need to test the product against its requirements. This
test is known as conformance testing.

 In order to do so, some criteria should be added to FR and NFR to

make it measurable and testable at the end to see if they meet users’
need. These criteria are known as fit-criteria.
 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.

43
 Section 5: Conformance testing and fit criteria

 Benefits of attaching fit-criteria to requirements:

◦ Helps to clarify the requirement;
◦ Helpful communication tool for interacting with different stakeholders to
check that the criteria being specified are acceptable and reflect the
correct understanding of the requirement.

 The fit criteria can be written or elicited as the

requirements are elicited.
 The parties that need fit criteria are:
◦ The developers of the product use the fit criteria to develop the product to
meet those criteria.
◦ The testers use the fit criteria to determine whether the delivered product
meets the original requirements.
◦ The clients for whom the product is being developed use the fit criteria as
acceptance criteria for the product.

44
 Section 5: Conformance testing and fit criteria

 A fit criterion for a functional requirement specifies the

completion of the function of the product that is specified
by that functional requirement.

 Example 1: FR fit criteria

◦ FR: send an email to the student after a marked TMA has been
uploaded by the tutor,
◦ Fit criterion: an email should indeed be sent to the student and
reflected in their mailbox on the forum.
 Example 2: FR fit criteria
◦ FR: The system shall accept a credit card number from a client.
◦ Fit criterion: A valid credit card number has been stored in the
system.

45
 Section 5: Conformance testing and fit criteria

 A fit criterion for a non-functional requirement specifies a value or

values, on a particular scale of measurement, that must be attained by
the property or quality with which the requirement is concerned.

 Example 1:
 Look-and-feel requirement
 Description. The student website for this module shall have a similar look
and feel to other OU module websites.
 Fit criterion. The TM354 module website shall conform to the OU web
design and accessibility guidelines..
 Example 2:
 Maintainability and support requirement
 Description. The websites of OU modules shall be updated frequently.
 Fit criterion. Updates to OU module websites shall be made weekly and
be visible to students within eight hours of being loaded.NFR fit criteria
 Refer to the course material for more examples

46
 Section 5: Conformance testing and fit criteria

Summary of section

 In this section we discussed the need for, and the concept

of, fit criteria and applied them to different types of functional
and non-functional requirements

47
 Section 5: Representing the Requirements

 Requirements need to be documented within a project.

 Documentation may take many forms.
 The one we adopt in this module is based on the
Volere approach by Robertson and Robertson (2012),
 The Volere template is a template for a document that
collates all the requirements of a system, together
with other issues that may affect those requirements.

48
 Section 5: Representing the Requirements

 The Volere template is organised into five main sections,

each including a number of requirements categories.
◦ Project drivers
◦ Project constraints
◦ Functional requirements
◦ Non-functional requirements
◦ Project issues
Please refer to page number 115-122
 Functional and non-functional requirements are the core of
the requirements document. While all other sections of the
template can be filled in as freestyle text, the Volere approach
recommends a more formal recording of functional and non-
functional requirements.

49
 Section 5: Representing the Requirements

Information recorded for each FR/NFR:

 requirement number – this is to identify the requirement uniquely .

 event/use case – identify which use case or event is associated with this
requirement
 description – a one-sentence statement of the intent of the requirement

 rationale – why the requirement is considered important or necessary

 originator – who raised the requirement in the first instance

 fit criterion – this is the acceptance criterion, written in a quantified manner so that
the solution can be tested against the requirement
 customer satisfaction/dissatisfaction – this is an indication of the customer’s
reaction to the requirement’s omission from the solution
 priority – a mark of the value of the requirement for the customer

 conflicts – requirements that contradict this one or make this one less feasible

 supporting materials – link to other documents to help understand the requirement

 history – origin of and changes to the requirement.

50
Section 5: Representing the Requirements

Figure: Requirements snowcard

51
 Section 5: Representing the Requirements

Advantage of capturing requirements using a template

 The template is divided into a fixed set of categories, which means you
are less likely to forget some types of requirements.
 It also saves having to work out what categories of requirements to
deal with each time you start a new document.
 It helps to communicate requirements to other developers because if
there is a standard template then everyone will know what information
to expect and in what order.
 It might also allow projects to be compared and even requirements to
be reused more easily.

52
 Section 5: Representing the Requirements

Summary

 In this section we introduced the Volere template for the description of

requirements.
 We will give a detailed example of how the Volere template is used in
Unit 4.
 We also briefly introduced cards as a representation commonly used in
agile development to trigger discussions on requirements.

53
 Unit Summary

After studying this unit you should be able to:

 understand the nature and importance of requirements

 describe the activities of a requirements engineering process

 be aware of an agile approach to requirements

 define and distinguish between functional and non-functional

requirements
 describe the various types of non-functional requirements

 discuss the relation between requirements and testing

 produce clear functional and non-functional requirements

 produce measurable, and hence testable, functional and non-functional

requirements
 discuss the relation between requirements and testing

 use a requirements template to write a requirements document in a

structured way.

54