Software Requirements – A More
Rigorous Look
Requirements Engineering
1
Objectives
To introduce and understand the types of
software requirements.
2
Looking Deeper into Software
Requirements
Definition for a software requirement:
IEEE definition:
A condition or capability needed by a user to solve
a problem or to achieve an objective.
A condition or capability that must be met or
possessed by a system or a system component to
satisfy a contract, standard, specification, or other
formally imposed documents.
3
Looking Deeper into Software
Requirements
Requirements Engineering
• is the process of eliciting, analyzing, documenting,
and managing software requirements.
• It involves understanding the needs and expectations
of stakeholders, translating them into clear and
unambiguous requirements, and ensuring that these
requirements are feasible, complete, and consistent.
4
Looking Deeper into Software
Requirements
Five major classes of things are needed to fully
describe the behavior of a software system
1. Inputs to the system:
Not only the content of the input but also, as
necessary,
the details of input devices and the form, look,
and feel—
protocol—of the input.
2. Outputs from the system:
A description of the output devices, such as
voice-output
5
or visual display, that must be supported, as
Looking Deeper into Software
Requirements
3. Functions of the system:
The mapping of inputs to outputs, and their
various
combinations.
4. Attributes of the system:
non-functional requirements like reliability,
maintainability,
availability, and throughput that the developers
must taken
into account.
5.6 Attributes of the system environment:
System Elements
7
Users of the Requirements (Sommerville,
2000)
8
The Requirements Dilemma: What
versus How
Requirements shall tell us what the system is to
do, and NOT how the system shall do it.
Exclude project information:
Information associated with project management
(schedules, verification and validation plans, budgets,
and staffing schedules)
Information about how the system will be tested.
Exclude design information
System design or architecture.
9
Requirements Vs Design
Software requirements and design are iterative.
Requirements are concerned with the problem
to be solved.
Design is concerned with solution to the
problem.
Requirements engineering is about what has to
be done.
Design is about how it should be done.
10
Types of Requirements
Software requirements refer to the functional and non-
functional specifications that define what a software
system should do and how it should behave.
These requirements serve as the foundation for the
design, development, and testing of the software.
Functional software requirements:
Statements of services the system should provide.
How the system should react to particular inputs.
How the system should behave in particular
situations.
What the system will do.
Define what precisely a software must do and how the
system
11
must respond to inputs.
Types of Requirements
Examples:
The software system should be integrated with banking
API.
When you open a bank account, the system will send a
new user an email.
Only employees on the management level can view
salary data.
Authentication of user whenever he/she logs into the
system.
System shutdown in case of a cyber attack.
User authorization and authentication.
12
Types of Requirements
A user shall be able to search the appointments list 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 8-digit employee number.
13
Types of Requirements
Nonfunctional software requirements:
Define system properties and constraints e.g. reliability,
response time and storage requirements.
They may define constraints on the system implementation
such as the capability of I/O devices, or data representations
used in the interfaces with other systems.
Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standard, etc.
Often apply to the system as a whole rather than individual
features or services.
Requirement that specifies How the system performs a certain
function.
14
Types of Requirements
Examples:
A user must change their initial login password upon
logging in the first time.
Specify that a website must handle 10 million users
without having any performance challenges.
Every unsuccessful attempt by a user to access an
item of data shall be recorded on an audit trail.
The software must be capable of running on multiple
operating systems, including Windows, macOS, and
Linux, without any modifications.
15
Types of Requirements
Product search results should be displayed within 3
seconds for 90% of the searches under normal
conditions.
Non-functional requirements do not form the backbone
of the system. That means the system will still work if
the non-functional requirements are not met.
16
Types of Nonfunctional Requirements
17
Types of Nonfunctional Requirements
Usability:The ease with which a user can learn to operate, prepare
inputs for, and interpret outputs of a system.
-Relates to the user interface—number of nested levels
in menus, color schemes …, online help, level of
documentation.
Dependability: The property of a system such that reliance can
justifiably be placed on the service it delivers. Includes reliability,
robustness, and safety.
Reliability:
The ability of a system to perform its required functions
under stated conditions for a specified period of time.
-Includes acceptable mean time to failure, the ability to
detect specified faults or withstand specified security attacks.
Robustness:The degree to which a system can function correctly in
the presence of invalid inputs or stressful environment conditions.
Safety:
A measure of the absence of catastrophic consequences to
18
the environment.
Types of NF Requirements (cont.)
Performance: Quantifiable attributes of the system such
as response time, throughput, availability, accuracy.
Response time: How quickly the system reacts to a user
input.
Throughput: How much work the system can accomplish
within a specified amount of time.
Accuracy: A quantitative measure of the magnitude of
error.
Availability: The degree to which a system is operational
and accessible when required for use.
–E.g., an availability of 0.998 means that in every 1000 time units, the system
is likely to be available for 998 of these.
19
Types of Requirements
Design constraints:
Restrictions on the design of a system, or the process
by which a system is developed, that do not affect
the external behavior of the system but that must be
fulfilled to meet technical, business, or contractual
obligations.
Example:
You want to develop a website. You may use ASP.NET,
Java, PHP or any other languages but the company
impose a constraint on you to develop the website
using PHP.
A logo redesign that has to have the same colors as
the previous design
Compliance to applicable laws and standards.
20
Style/device specifics.
Functional Requirements Non Functional Requirements
A functional requirement defines a system A non-functional requirement defines the quality
or its component. attribute of a software system.
It places constraints on “How should the
It specifies “What should the software software system fulfill the functional
system do?” requirements?”
Non-functional requirement is specified by
Functional requirement is specified by technical peoples e.g. Architect, Technical
User. leaders and software developers.
It is mandatory. It is not mandatory.
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of the Helps you to verify the performance of the
software. software.
Functional Testing like System,
Integration, End to End, API testing, etc Non-Functional Testing like Performance, Stress,
are done. Usability, Security testing, etc are done.
Usually easy to define. Usually more difficult to define.
21
Types of Requirements
22
The Road Map
The problem domain represents the real-world area, the
business that the software is intended to address.
It focuses on understanding the needs, objectives,
constraints, and requirements of the stakeholders.
Requirements are gathered by analyzing the problem
domain, and they describe what the system is supposed
to accomplish without specifying how it will be
implemented.
It involves identifying the problems, challenges, and
opportunities that the software aims to address.
The language used in the problem domain is typically
more natural and business-oriented.
The problem domain is the problem, plus everything else
23
related that might solve for it.
The Road Map
Example
Consider a hospital management system.
In the problem domain, you would identify and
understand the challenges faced by the hospital staff in
managing patient records
scheduling appointments, and
handling billing.
You would gather requirements such as
The need for a centralized patient database
Appointment scheduling functionality, and
Billing features.
24
The Road Map
The solution domain is concerned with designing and
implementing the software system that addresses the
requirements identified in the problem domain.
It involves making decisions about the
architecture,
technology,
algorithms, and
other technical aspects of the system.
The solution domain focuses on how to build the
software to meet the specified requirements.
It uses technical language and involves detailed
specifications & designs.
25
The Road Map
In the solution domain, there are many steps and
activities:
1) Understand the User’s Needs
2) Define the System
3) Manage Scope and Manage Change
4) Refine the System Definition
5) Build the Right System
26
The Road Map
Example:
Continuing with the hospital management system, in the
solution domain, you would define:
How the patient database will be structured,
What programming language and framework will be
used,
How appointments will be scheduled, and
How billing processes will be implemented.
It deals with the technical aspects of the system's
development.
27
Moving Toward the Solution domain
A definition of a system in terms of the
features of the system and
The software requirements that will drive its
design and implementation.
28
Features of the System
A feature is a service provided by the system that fulfils
one or more stakeholder needs.
A feature refers to a distinct functionality or characteristic
that a software system or application provides.
It represents a specific capability or behaviour that is
designed to fulfil a user's needs or requirements.
Simple descriptions in the user's language.
Will be used as labels to communicate with the user.
Example:
For a word processing program, features like Spell
checking can be considered as a feature but not a
requirement.
“The car will have power windows.”
“Defect-trending charts will provide a visual means
of progress”.
29
Software Requirements
Once we have
1. Established the feature set &
2. Gained agreement with the customer
Then we move to defining the more specific
requirements needed in the solution.
If we build a system that conforms to those
requirements, we can be certain that the
system we develop will deliver the features
we promised.
30
Overview of the Problem Domain and the
Solution Domain
31
Key Points
A complete set of requirements can be
determined by defining the inputs, outputs,
functions, and attributes of the system plus the
attributes of the system environment.
Requirements should exclude project-related
information, such as schedules, project plans,
budgets, and tests, as well as design information.
The requirements/design process is iterative;
requirements lead to the selection of certain
design options, which in turn may initiate new
requirements.
Design constraints are restrictions on the design
of the system or on the process by which a
32system is developed.
Vision Document and Project Scope
In the next lectures we will introduce the
Vision Document which is used to establish
an agreement on the initial set of
requirements.
In the next lectures we will also see how to
examine the feasibility of the project scope
and how to reduce if required
33
