FM-AA-CIA-15 Rev.

0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

STUDY GUIDE FOR MODULE NO. 3

CHAPTER 3: SOFTWARE REQUIREMENTS ANALYSIS

MODULE OVERVIEW

In this module, we will explore requirements specification or also known as requirements engineering and to
explain the processes involved by which requirements are elicited and defined. This is a particularly critical
stage of the software process, as mistakes made at this stage inevitably lead to later problems in the system
design and implementation.

This will also give you deeper knowledge and understanding on the different types of requirements and why
these requirements should be written in different ways, as well as the significant differences of functional and
non-functional requirements.

MODULE LEARNING OBJECTIVES

At the end of this chapter, the student should be able to:

1. Understand the concepts of user requirements and system requirements and why these requirements may
be expressed using different notations;
2. Differentiate functional and non-functional requirements;
3. Understand the two techniques for describing systems requirements, namely structured natural language
and programming language based descriptions;
4. Understand the main requirements engineering activities of elicitation, analysis, and validation, and the
relationships between these activities.

LEARNING CONTENTS (TOPIC 1: REQUIREMENTS ENGINEERING)

WHAT IS SOFTWARE REQUIREMENTS SPECIFICATION?

As discussed from the previous module, this is the process of establishing the services that the customer
requires from a system and the constraints under which it operates and is developed. It is also known as
Requirements Engineering.

The requirements for a system are the descriptions of the services that a system should provide and the
constraints on its operation. On the other hand, software specification / requirements engineering is the
process of:

- Finding out,
- Analysing,
- Documenting,
- Checking these services and constraints.

The term requirement is not used consistently in the software industry. In some cases, a requirement is
simply a high-level, abstract statement of a service that a system should provide or a constraint on a system.
At the other extreme, it is a detailed, formal definition of a system function. Davis (Davis 1993) explains why
these differences exist:

“If a company wishes to let a contract for a large software development project, it must define its needs in a
sufficiently abstract way that a solution is not predefined. The requirements must be written so that several
contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s
needs. Once a contract has been awarded, the contractor must write a system definition for the client in more
detail so that the client understands and can validate what the software will do. Both of these documents may
be called the requirements document for the system.”

PANGASINAN STATE UNIVERSITY 1

FM-AA-CIA-15 Rev. 0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

TYPES OF REQUIREMENTS

To make a clear separation between the different levels of description of the requirements, let us use the term
user requirements to mean the high-level abstract statement and system requirements to mean the
detailed description of what the system should do.

USER REQUIREMENTS VS. SYSTEM REQUIREMENTS

1. 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.

2. 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 kinds of requirement are needed to communicate information about a system to different types of
reader. Figure 3.1 illustrates the distinction between user and system requirements.

User requir ement definitio n

1. The softw are m ust p r ovide a means of representin g and

1. accessing e xternal files cr ea ted b y o ther to ols .

System requir ements specification

1.1 T he user sh ould be pr ovided with facilities to define the type of

1.2 external files .
1.2 Each e xternal file ty pe ma y h ave an associa ted too l w hich ma y be
1.2 applied to the file .
1.3 Each e xternal file ty pe ma y be r epr esented as a specific ico n on
1.2 the user’ s displa y.
1.4 Facilities sho uld be pr o vided f or the icon r epresentin g an
1.2 external file ty pe to be defin ed b y th e user .
1.5 When a user selects an icon r epr esentin g an e xternal file, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file rep resented by the selected ico n.

Figure 3.1 Example User Requirements and System Requirements

As you can see from Figure above, the user requirement is quite general. The system requirements provide
more specific information about the services and functions of the system that is to be implemented.

You need to write requirements at different levels of detail because different types of readers use them in
different ways. Figure 3.2 shows the types of readers of the user and system requirements

PANGASINAN STATE UNIVERSITY 2

FM-AA-CIA-15 Rev. 0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

Figure 3.2 Readers of Requirements Specifications

The different types of document readers shown in Figure 3.2 are examples of system stakeholders. As well as
users, many other people have some kind of interest in the system

FUNCTIONAL VS. NON-FUNCTIONAL REQUIREMENTS

Software system requirements are often classified as functional or non-functional requirements:

1. 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.

Here are examples of Functional Requirements for a Mentcare System:

 A user shall be able to search the appointments lists for all clinics.
 The system shall generate each day, for each clinic, a list of patients who are expected to attend
appointments that day.
 Each staff member using the system shall be uniquely identified by his or her eight-digit employee
number.

2. 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. These non-functional requirements usually specify or
constrain characteristics of the system as a whole. They may relate to emergent system properties such as
reliability, response time, and memory use. Alternatively, 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.

NOTE: Non-functional requirements may be more critical than functional requirements. If these are not met,
the system is useless.

Figure 3.3 is a classification of non-functional requirements. You can see from this diagram that the non-
functional requirements may come from required characteristics of the software (product requirements), the
organization developing the software (organizational requirements), or external sources:

PANGASINAN STATE UNIVERSITY 3

FM-AA-CIA-15 Rev. 0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

Non-functional
requir ements

Product Organisational External

requir ements requir ements requir ements

Effi ci ency Relia bility Porta bility Inter oper a bility Ethical
requir ements requir ements requir ements requir ements requir ements

Usa bility Deli very Impl ementa tion Standar ds Leg islative
requir ements requir ements requir ements requir ements requir ements

Performance Space Pri vacy Safet y

requir ements requir ements requir ements requir ements

Figure 3.3 Types of Non-Functional Requirements

Non-Functional Classifications and examples for the Mentcare System:

A. Product requirements

• Requirements which specify that the delivered product must behave in a particular way e.g.
execution speed, reliability, etc.

Example: The Mentcare system shall be available to all clinics during normal working hours
(Mon–Fri, 08:30–17:30). Downtime within normal working hours shall not exceed 5 seconds
in any one day.

B. Organizational requirements

• Requirements which are a consequence of organizational policies and procedures e.g.

process standards used, implementation requirements, etc.

Example: Users of the Mentcare system shall identify themselves using their health authority
identity card.

C. External requirements

• Requirements which arise from factors which are external to the system and its development
process e.g. interoperability requirements, legislative requirements, etc.

Example: The system shall implement patient privacy provisions as set out in HStan-03-
2006-priv.

PANGASINAN STATE UNIVERSITY 4

FM-AA-CIA-15 Rev. 0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

Whenever possible, you should write non-functional requirements quantitatively so that they can be
objectively tested. Table 3.1 shows metrics that you can use to specify non-functional system properties. You
can measure these characteristics when the system is being tested to check whether or not the system has
met its nonfunctional requirements.

PROPERTY MEASURE
Processed transactions/second User/event response time Screen refresh
Speed
time
Size Megabytes/Number of ROM chips
Ease of use Training time Number of help frames
Mean time to failure Probability of unavailability Rate of failure occurrence
Reliability
Availability
Time to restart after failure Percentage of events causing failure
Robustness
Probability of data corruption on failur
Portability Percentage of target dependent statements Number of target systems

Table 3.1 Metrics for specifying nonfunctional requirements

It is difficult to separate functional and non-functional requirements in the requirements document. If the non-
functional requirements are stated separately from the functional requirements, the relationships between
them may be hard to understand. However, you should, ideally, highlight requirements that are clearly related
to emergent system properties, such as performance or reliability. You can do this by putting them in a
separate section of the requirements document or by distinguishing them, in some way, from other system
requirements.

LEARNING CONTENTS (TOPIC 2: REQUIREMENTS ENGINEERING PROCESS)

WHAT ARE THE KEY ACTIVITIES OF SOFTWARE SPECIFICATIONS OR REQUIREMENTS

ENGINEERING?

Requirements engineering is an important aspect of any software project, and is a general term used to
encompass all the activities related to requirements. This involves three key activities:

1. Requirements Elicitation & Analysis

2. Requirements Specification
3. Requirements Validation

Although they seem to be separate tasks, these three processes cannot be strictly separated and performed
sequentially. Some of the requirements are implicit in the working practices, while others may only arise when
design solutions are proposed. Figure 3.4 shows the process and stages of requirements engineering.

Figure 3.4 Requirements Engineering Process

PANGASINAN STATE UNIVERSITY 5

FM-AA-CIA-15 Rev. 0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

A feasibility study decides whether or not the proposed system is worthwhile. It is a short focused study that
checks
• If the system contributes to organisational objectives
• If the system can be engineered using current technology and within budget
• If the system can be integrated with other systems that are used

1. Requirements Elicitation & Analysis

- The aims of the requirements elicitation process are to understand the work that stakeholders do and
how they might use a new system to help support that work. During requirements elicitation, software
engineers work with stakeholders to find out about the application domain, work activities, the
services and system features that stakeholders want, the required performance of the system,
hardware constraints, and so on.

There are two fundamental approaches to requirements elicitation:

1. Interviewing, where you talk to people about what they do.

2. Observation or ethnography, where you watch people doing their job to see what artifacts
they use, how they use them, and so on.

You should use a mix of interviewing and observation to collect information and, from that, you
derive the requirements, which are then the basis for further discussions.

2. 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.

- User requirements are almost always written in natural language supplemented by appropriate
diagrams and tables in the requirements document. System requirements may also be written in
natural language, but other notations based on forms, graphical, or mathematical system models can
also be used. Figure 3.5 summarizes possible notations for writing system requirements and other
alternatives to Natural Language (NL) specifications.

NOTATION DESCRIPTION
Natural language The requirements are written using numbered sentences in natural
sentences language. Each sentence should express one requirement

The requirements are written in natural language on a standard

Structured natural
form or template. Each field provides information about an aspect
language
of the requirement.

Graphical models, supplemented by text annotations, are used to

define the functional requirements for the system. UML (unified
Graphical notations
modeling language) use case and sequence diagrams are
commonly used.
These notations are based on mathematical concepts such as
finite-state machines or sets. Although these unambiguous
Mathematical specifications can reduce the ambiguity in a requirements
specifications document, most customers don’t understand a formal
specification. They cannot check that it represents what they want,
and they are reluctant to accept it as a system contract.
Figure 3.5 Notations for Writing System Requirements

PANGASINAN STATE UNIVERSITY 6

FM-AA-CIA-15 Rev. 0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

NOTE: 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

However, there are problems with Natural Language (NL) Specifications, namely:

• Ambiguity - The readers and writers of the requirement must interpret the same words in the same
way. NL is naturally ambiguous so this is very difficult.
• Over-flexibility -The same thing may be said in a number of different ways in the specification.
• Lack of Modularisation -NL structures are inadequate to structure system requirements.

Here are some examples of Alternatives to Natural Language (NL) Specifications:

A. Form-based Node Specification (under Structured Natural Language)

Figure 3.6 The Structured Specification of a Requirement for an Insulin Pump

B. Tabular Specification (under Structured Natural Language)

Figure 3.7 The Tabular Specification of Computation in an Insulin Pump

PANGASINAN STATE UNIVERSITY 7

FM-AA-CIA-15 Rev. 0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

C. Sequence Diagram (under Graphical Notations)

ATM Database

Card
Card number

Card OK
PIN reques t
PIN
Option menu Validate card

<<exception>>
invalid card

Withdraw request Balance request

Balance
Amount request
Handle request
Amount
Debit (amount)

<<exception>> Debit respons e

insufficient cash

Card
Card removed
Complete
Cash transaction

Cash removed
Receipt

Figure 3.8 Sequence Diagram of ATM Withdrawal

D. Use-Case Diagram (under Graphical Notations)

Figure 3.9 Use Case Diagram for the Mentcare System

3. Requirements Validation

- Requirements validation is the process of checking that requirements define the system that the
customer really wants. It overlaps with elicitation and analysis, as it is concerned with finding
problems with the requirements. Requirements validation is critically important because errors in a

PANGASINAN STATE UNIVERSITY 8

FM-AA-CIA-15 Rev. 0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

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. These checks include:

1. Validity checks. These check that the requirements reflect the real needs of system users.
Because of changing circumstances, the user requirements may have changed since they were
originally elicited.

2. Consistency checks. Requirements in the document should not conflict. That is, there should not
be contradictory constraints or different descriptions of the same system function.

3. Completeness checks. The requirements document should include requirements that define all
functions and the constraints intended by the system user.

4. Realism checks. By using knowledge of existing technologies, the requirements should be

checked to ensure that they can be implemented within the proposed budget for the system. These
checks should also take account of the budget and schedule for the system development.

5. Verifiability. To reduce the potential for dispute between customer and contractor, system
requirements should always be written so that they are verifiable. This means that you should be able
to write a set of tests that can demonstrate that the delivered system meets each specified
requirement.

REQUIREMENTS VALIDATION TECHNIQUES

A number of requirements validation techniques can be used individually or in conjunction with one another:

1. Requirements Reviews - The requirements are analyzed systematically by a team of reviewers who check
for errors and inconsistencies.

2. Prototyping - This involves developing an executable model of a system and using this with end-users and
customers to see if it meets their needs and expectations. Stakeholders experiment with the system and
feedback requirements changes to the development team.

3. Test-case generation - Requirements should be testable. If the tests for the requirements are devised as
part of the validation process, this often reveals requirements problems. If a test is difficult or impossible to
design, this usually means that the requirements will be difficult to implement and should be reconsidered.

LEARNING CONTENTS (TOPIC 3: THE SOFTWARE REQUIREMENTS DOCUMENT)

THE SOFTWARE REQUIREMENTS DOCUMENT

• The requirements document is the official statement of what is required of the system developers.
• Should include both a definition of user requirements and a specification of the system requirements.
• It is NOT a design document. As far as possible, it should set of WHAT the system should do rather
than HOW it should do it.

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. Figure
3.10 shows possible users of the document and how they use it.

PANGASINAN STATE UNIVERSITY 9

FM-AA-CIA-15 Rev. 0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

Figure 3.10 Users of Requirements Document

Figure 3.11 shows one possible organization for a requirements document that is based on an IEEE
standard for requirements documents (IEEE 1998). This standard is a generic one that can be adapted to
specific uses.

Figure 3.11 The Structure of Requirements Document

PANGASINAN STATE UNIVERSITY 10

FM-AA-CIA-15 Rev. 0 10-July-2020

Study Guide in CC 106 – Application Development and Emerging Technologie Module No.__

GUIDELINES FOR WRITING DOCUMENTS

• 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.

LEARNING ACTIVITY 3.1

Individual Activity 3.1

Give at least 2 User Requirements and 3 System Requirements (for each user requirement) for any kind of
applications of your choice under the area of emerging technologies assigned to you from the 1 st group
activity.

LEARNING ACTIVITY 3.2

Individual Activity 3.2

Identify at least 5 functional and 3 non-functional requirements of any application or system.

SUMMARY / KEY POINTS

• Requirements set out what the system should do and define constraints on its operation and
implementation.
• Functional requirements set out services the system should provide.
• Non-functional requirements constrain the system being developed or the development process.
• User requirements are high-level statements of what the system should do. User requirements should
be written using natural language, tables and diagrams.
• System requirements are intended to communicate the functions that the system should provide.
• A software requirements document is an agreed statement of the system requirements.
• The IEEE standard is a useful starting point for defining more detailed specific requirements
standards.

REFERENCES

Macaulay, L.A. (1996). Requirements Engineering, Springer, pp. 83-112

Sommerville, Ian. Software Engineering, 10 th Edition. 2016

PANGASINAN STATE UNIVERSITY 11