Nyanza campus
Module: Introduction to Software Engineering
Lecturer: Dr. Taiwo Adigun Email:
taiwofisayo2002@gmail.com
Lecture 3: Requirement Analysis & Specification
Requirement Engineering
Outline:
Software Requirements
Requirements Engineering
Requirement Engineering
Specific Objectives:
By the end of this lesson, you should be able:
Describe stakeholders’ requirements
Explain types of software requirements
Explain the different stages of requirement engineering
Software Requirements - Definition
The software requirements are description of features and
functionalities of the target system.
Software requirements for a system are the description of what
the system should do, the service or services that it provides
and the constraints on its operation.
Requirements convey the expectations of users from the
software product.
IEEE defines Requirement as :
1. A condition or capability needed by a user to solve a problem or
achieve an objective
2. A condition or capability that must be met or possessed by a
system or a system component to satisfy contract, standard,
specification or formally imposed document.
Software Requirements - Definition
The requirements can be obvious or hidden, known or unknown,
expected or unexpected from client’s point of view.
It a set of WHAT the system should do rather than HOW it
should do it.
Requirements are descriptions of the functionality or services
provided by a system and its operational constraints that
reflect the needs of customers for a system that helps solve
some problem.
The process of collecting, analyzing, documenting, and
checking the required services and constraints is called
Requirements Engineering (RE).
Software Requirements - Types
There are 3 major categories of requirement:
1. Functional Requirements
2. Non-functional Requirements
3. Domain Requirements
Functional Requirements
Functional requirements define all specific features and functionalities
that a system must offer.
These are statements of services the system should provide
showing:
what reactions to expect from the system when certain inputs are
supplied
expected behaviour of the system in particular situations.
These are directly visible in the final product and include tasks like
data manipulation, user interactions, and business processes.
Functional requirements are essential for meeting user needs and
expectations.
Software Requirements - Types
Functional Requirements – Examples
List some of the functional requirements of MoMo app
Software Requirements - Types
Non-Functional Requirements
It is also called "Quality Attributes"
They define system properties and constraints on functions
offered e.g. reliability, response time, etc.
Non-functional requirements are about the system’s behavior,
quality, and constraints. They ensure that the software meets
certain standards of performance, usability, reliability, and
security i.e
Performance: The system should process 1,000 transactions per
second.
Usability: The software should be easy to use and have a user-
friendly interface.
Reliability: The system must have 99.9% uptime.
Security: Data must be encrypted during transmission and storage.
Non-functional requirements may be more critical than
functional requirements. If these are not met, the system is
useless.
Software Requirements - Types
Non-Functional Requirements
Non-functional requirements include -
i. Portability
ii. Security
iii. Maintainability
iv. Reliability
v. Scalability
vi. Performance
vii. Reusability
viii. Flexibility
ix. Storage
x. Cost
xi. Interoperability
xii. Disaster recovery
xiii. Accessibility
Software Requirements - Types
Further explanation on some categories of non-functional
requirements
Security: Authorization, authentication and confidentiality.
Performance: Response time and resource usage.
Usability: User interface design, accessibility, user
experience.
Reliability: Availability, error handling, recoverability.
Maintainability: Modifiability, testability, scalability.
Portability: Transferability to different environments.
Software Requirements - Types
Non-Function Requirements Measurement
Non-functional requirements entail a definition and a measurable target value they
must meet. Below is a list of some non-functional requirements’ properties and their
respective parameter(s) for measurement
Property Measure
Speed Processed transactions/second
Us er/Event respons e time
Screen refresh time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robus tness Time to restart after failure
Percentage of events caus ing failure
Probability of data corruption on failu
re
Portability Percentage of target dependent
statements Number of target systems
Software Requirements - Types
Domain Requirements
Domain Requirements ensure that the software aligns with established
standards or regulation for that problem domain, which can be either
functional or non-functional.
Domain requirements reflect the unique needs and constraints of a particular
industry. They ensure that the software is relevant and compliant with
industry-specific regulations and standards.
They include terminology, rules, and standards relevant to that particular
domain.
Examples:
Healthcare: The software must comply with ministry of health regulations for
handling patient data.
Finance: The system should adhere to standards for financial reporting.
E-commerce: The software should support various payment gateways like
PayPal, Fluterwave, and credit cards.
Software Requirements – Logical Categories
Requirements are categorized logically as:
Must Have : Software cannot be said operational without them.
Should have : Enhancing the functionality of software.
Could have : Software can still properly function without these
requirements.
Wish list : These requirements do not map to any objectives of
software.
While developing software;
‘Must have’ must be implemented,
‘Should have’ is a matter of debate with stakeholders and
analysts,
‘could have’ and ‘wish list’ can be kept for software updates.
Group Assignment
Software Requirements – We start by identifying the
stakeholders
Who is a Stakeholder?
A Stakeholder is an individual, team, or organization with interests in, or
concerns relative to, the system to be developed
In other words, a stakeholder is an entity who “may be affected by” or “may
affect” the system
A Stakeholder is not necessarily an end-user. But an end-user is often times a
Stakeholder
A software engineer needs to be aware of Stakeholders’ concerns and/or
interests.
So, software requirements are defined by stakeholders, including users, clients,
developers, and business analysts.
Requirements Engineering
The process of gathering the software requirements from client, analyze
and document them is known as requirement engineering.
It is a systematic and strict approach to the definition, creation, and
verification of requirements for a software system.
The goal of requirement engineering is to develop and maintain
sophisticated and descriptive ‘System Requirements Specification’
document.
The requirements engineering process entails several tasks that help in
understanding, recording, and managing the demands of stakeholders.
Requirements Engineering
Requirements Engineering Stages – Feasibility
Studies
A feasibility study is mainly carried out to decide whether or not the proposed system is worthwhile
/achievable.
This study analyzes whether the software product can be practically materialized in terms of
implementation, contribution of project to organization, cost constraints and as per values and objectives
of the organization.
It is a short, focused study that asks
Is there a need?
What current process problems exist?
How will the proposed system help?
What will be the integration problems?
Does it require any new technology?
What skills are needed?
Who are the stakeholders?
Etc.
Requirements Engineering Stages – Feasibility
Studies
Types of Feasibility Studies
1. Technical Feasibility: Current resources and technologies to develop the project are analyzed/assessed
such as hardware and software along required technology. It also analyzes the technical skills and
capabilities of the technical team.
2. Operational Feasibility: It analyzes the degree of providing service to requirements is analyzed along
with how easy the product will be to operate and maintain after deployment.
3. Economic Feasibility: In the Economic Feasibility study cost and benefit of the project are analyzed. It is
analyzed whether the project will be beneficial in terms of finance for the organization or not.
4. Legal Feasibility: In legal feasibility, the project is ensured to comply with all relevant laws, regulations,
and standards. It identifies any legal constraints that could impact the project and reviews existing
contracts and agreements to assess their effect on the project’s execution.
5. Schedule Feasibility: In schedule feasibility, the project timeline is evaluated to determine if it is realistic
and achievable. Significant milestones are identified, and deadlines are established to track progress
effectively.
Requirements Engineering Stages – Elicitation and
Analysis
Requirements elicitation also called requirements discovery or requirements capture.
Requirements elicitation is the process of gathering information about the needs and
expectations of stakeholders for a software system.
Analysts and engineers communicate with the client and end-users to know their ideas on
what the software should provide and which features they want the software to include.
Requirement analysis invoves organizing requirements, negotiation & discussion, and
documentation.
This requires a careful analysis of the organization, the application domain and business
process in order to understand the problem that the software system is intended to solve and
the needs and expectations of the stakeholders who will use the system.
Requirements Engineering Stages – Elicitation and
Analysis
Requirement Elicitation Techniques
Interviews: These are one-on-one conversations with stakeholders to gather information about their needs and expectations.
Surveys: These are questionnaires that are distributed to stakeholders to gather information about their needs and expectations.
Focus Groups: These are small groups of stakeholders who are brought together to discuss their needs and expectations for
the software system.
Observation: This technique involves observing the stakeholders in their work environment to gather information about their
needs and expectations.
Prototyping: This technique involves creating a working model of the software system, which can be used to gather feedback
from stakeholders and to validate requirements.
Task analysis: Team of engineers and developers may analyze the operation for which the new system is required. If the client
already has some software to perform certain operation, it is studied and requirements of proposed system are collected.
Domain Analysis: Every software falls into some domain category. The expert people in the domain can be a great help to
analyze general and specific requirements.
Brainstorming: An informal debate is held among various stakeholders and all their inputs are recorded for further
requirements analysis.
Requirements Engineering Stages – Requirement
Specification
This mainly refers to the production of a requirement document, for systematic review,
evaluation and approval.
Requirements specification is the process of documenting the requirements identified in the
analysis step in a clear, consistent, and unambiguous manner.
Serves as the basis for agreement with customers, stating what the software product is
expected to do, and not to do. For non-technical readers, a requirements definition document
should also be provided
SRS should come up with following features:
User Requirements are expressed in natural language.
Technical requirements are expressed in structured language.
Design description should be written in Pseudo code.
Conditional and notations for ERD, DFDs, data dictionaries, etc.
Requirements Engineering Stages – Requirement Validation
After requirement specifications are developed, the requirements mentioned in this document
are validated.
Ensuring that the outlined requirements define the system that the customer really wants
It involves checking the following: Validity, Consistency, Completeness, Realism, and
Verifiability.
Requirements can be checked against following conditions -
If they can be practically implemented
If they are valid and as per functionality and domain of software
If there are any ambiguities
If they are complete
If they can be demonstrated
Requirements Document – SRS
Official statement of what is required of the system developers
Should include both a definition and a specification of requirements
Should:
– specify external system behaviour
– specify implementation constraints
– be easy to change (but changes must be managed)
– serve as a reference tool for maintenance
– record fore thought about the life cycle of the system (i.e. predict changes)
– characterize responses to unexpected events
It is not a design document
– it should state what the system should do rather than how it should do it
Requirements Document structure
1. Introduction
2. Glossary
3. User requirements definition
4. System architecture
5. System requirements specification
6. System models
7. System evolution
8. Appendices
9. Index
Requirements Document User
1. System customers: Specify the requirements and read them back to check that they meet
their needs; specify changes to the requirements
2. Development Managers: Use the requirements document to plan a bid for the system and to
plan the system development process
3. Implementation Programmers: Use the requirements to understand what system is to be
developed
4. Test programmers: Use the requirements to develop validation tests for the system
5. Maintenance programmers: Use the requirements to help understand the system and the
relationships between its parts
Thank
s
