Requirements

Engineering
 Functional and non-functional requirements

The software requirements document

Requirements specification
Topics Requirements engineering processes
covered
Requirements elicitation and analysis

Requirements validation

Requirements management
 What is requirements engineering?

Requirements
engineering
The process of establishing the services
required from a system and the
constraints under which it operates and
is developed.
 • The requirements themselves are the
descriptions of the system services and
Requirements constraints that are generated during the
engineering requirements engineering process.
 It may range from:
• a high-level abstract statement of a service
What is a The system must output the roots of a
requirement? quadratic equation.
• a system constraint
‘a’ must not be zero
• a detailed mathematical functional
specification.
ax + bx + c = 0
 • Requirements may serve a dual function
What is a • May be the basis for a bid for a contract,
therefore must be open to
requirement? interpretation;
• May be the basis for the contract itself,
therefore must be defined in detail;
• Both these statements may be called
requirements
Requirements
abstraction (A.M. • “If a company wishes to let a contract for a
large software development project, it must
Davis .Software define its needs in a sufficiently abstract way that
Requirements: a solution is not pre-defined. The requirements
must be written so that several contractors can
Objects, Functions bid for the contract, offering, perhaps, different
and States., ways of meeting the client organization’s needs.
Once a contract has been awarded, the
EnglewoodCliffs, contractor must write a system definition for the
client in more detail so that the client
1993) understands and can validate what the software
will do. Both of these documents may be called
the requirements document for the system.”
Types of • User requirements
• Statements in natural language,
requirements • Diagrams of the services the system
provides,
• Operational constraints,
• Written for customers.
Types of requirements

• System requirements
• A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints.
• Defines what should be implemented so may be part of a contract
between client and contractor.
User and
system
requirements
Chapter 4 Requirements engineering

Readers of different types of

requirements specification
IEEE software The basic issues that the software
requirements requirements writer(s) shall address are the
following:
standards • a) Functionality. What is the software
(Robert supposed to do?
Japenga) • b) External interfaces. How does the
software interact with people, the system’s
hardware, other hardware, and other
software?
 • c) Performance. What is the speed,
availability, response time, recovery time of
various software functions, etc.?
IEEE software • d) Attributes. What are the portability,
correctness, maintainability, security, etc.
reqirements considerations?
standards • e) Design constraints imposed on an
implementation. Are there any required
standards in effect, implementation
language, policies for database integrity,
resource limits, operating environment(s)
etc.?
Characteristics of great software requirements

From the IEEE standard, software requirements should be:

• a) Correct
• b) Unambiguous
• c) Complete
• d) Consistent
• e) Ranked for importance and/or stability
• f) Verifiable
• g) Modifiable
• h) Traceable
Characteristics cont.

• Correct - No one writes a specification that they know is incorrect. The

discipline is keeping the specification up to date when you find things that
are not correct.
• Unambiguous – Software requirements are unambiguous if every
requirement stated has only one interpretation. As you find ambiguities -
fix them.
• Complete – The software requirements should be all that is needed by the
software designers to create the software.
Characteristics cont.

• Consistent - The requirements should be consistent in itself and consistent

in its reference documents. If you call an input "Start and Stop" in one
place, don't call it "Start/Stop" in another.
• Ranked for Importance - Very often a new system has requirements that
are really marketing wish lists. Some may not be achievable. It is useful
provide this information in the requirements documentation.
• Verifiable - Don't put in requirements like - "It should provide the user a
fast response." This should be quantifiable, set a specific time limit. "Every
key stroke should provide a user response within 100 milliseconds."
Characteristics cont.

• Modifiable - Having the same requirement in more than one place may not
be wrong but tends to make the document not maintainable.
• Traceable - Often, this is not important in a non-politicized environment.
However, in most organizations, it is sometimes useful to connect the
requirements to a higher-level document. Why?
 • Functional requirements
• Statements of services the system should
provide, how the system should react to
Functional particular inputs and how the system should
behave in particular situations.
and non- • May state what the system should not do.
• Non-functional requirements
functional • Constraints on the services or functions offered
by the system such as timing constraints,
requirements constraints on the development process,
standards, etc.
• Often apply to the system as a whole rather than
individual features or services.
 • Describe functionality or system services.
• Depend on the type of software, expected
users and the type of system where the
Functional software is used.
• Functional user requirements may be
requirements high-level statements of what the system
should do.
• Functional system requirements should
describe the system services in detail.
 • Define system properties and constraints
e.g. reliability, response time and storage
Non-functional requirements. Constraints are I/O device
capability, system representations, etc.
requirements • Process requirements may also be
specified mandating a particular
programming language or method.
Non-functional requirements

MAY BE MORE CRITICAL THAN IF NOT MET, THE SYSTEM MAY

FUNCTIONAL REQUIREMENTS. BE USELESS.
End of part 1