Software Engineering

Requirements Analysis and Specification

Software requirements:
Y Sujana
CSE(DS)

1
Module-II
 Contents

REQUIREMENTS ANALYSIS AND SPECIFICATION

Software requirements:
• Functional and nonfunctional,
• user requirements,
• system requirements
• software requirements document
Requirement engineering process:
• Feasibility studies,
• requirements elicitation and analysis
• requirements validation,
• requirements management
Classical analysis:
• Structured system analysis,
• petri nets,
• data dictionary.
 Requirements engineering
• The process of establishing the services that the customer requires from a system and the
constraints under which it operates and is developed.
• The requirements themselves are the descriptions of the system services and constraints that
are generated during the requirements engineering process.
• Types of Software requirements:
User requirements
• User requirements are statements, in a natural language plus diagrams of the services the
system provides and its operational constraints. Written for customers.
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.
 Software requirements

 User and System requirements:

 Software requirements
 Readers of different types of requirements specification
 Software requirements
Example: system stakeholders for the system include:

1. Patients whose information is recorded in the system and relatives of these patients.
2. Doctors who are responsible for assessing and treating patients.
3. Nurses who coordinate the consultations with doctors and administer some treatments.
4. Medical receptionists who manage patients’ appointments.
5. IT staff who are responsible for installing and maintaining the system.
6. A medical ethics manager who must ensure that the system meets current ethical
guidelines for patient care.
7. Health care managers who obtain management information from the system.
8. Medical records staff who are responsible for ensuring that system information can be
maintained and preserved, and that record keeping procedures have been properly
implemented
 Software 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.

2. Non-functional requirements These are constraints on the services or functions offered

by the system. They include timing constraints, constraints on the development process,
and constraints imposed by standards. Non-functional requirements often apply to the
system as a whole rather than individual system features or services.
 Software requirements
Functional requirements

• The functional requirements for a system describe what the system should do.
• When expressed as user requirements, functional requirements should be written in natural
language so that system users and managers can understand them.
• Functional system requirements expand the user requirements and are written for system
developers. They should describe the system functions, their inputs and outputs, and exceptions in
detail.
• Describe functionality or system services.
• Depend on the type of software, expected users and the type of system where the software is used.
• Functional user requirements may be high-level statements of what the system should do.
• Functional system requirements should describe the system services in detail.
 Software requirements
For example,
Functional requirements for the Mentcare system, used to maintain information about patients
receiving treatment for mental health problems:
1. A user shall be able to search the appointments lists for all clinics.

2. The system shall generate each day, for each clinic, a list of patients who are expected to attend
appointments that day.

3. Each staff member using the system shall be uniquely identified by his or her eight-digit
employee number.

These user requirements define specific functionality that should be included in the system
 Software requirements
Requirements completeness and consistency

• In principle, requirements should be both complete and consistent.

• Complete
• They should include descriptions of all facilities required.

• Consistent
• There should be no conflicts or contradictions in the descriptions of the system
facilities.

• In practice, it is impossible to produce a complete and consistent requirements

document.
 Software requirements
 Non-functional requirements

• Non-functional requirements may affect the overall architecture of a system rather than the
individual components.

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

• Process requirements may also be specified mandating a particular IDE, programming

language or development method.

• Non-functional requirements may be more critical than functional requirements. If these are not
met, the system may be useless.
 Software requirements

 Types of non-functional requirements

 Software requirements

1. Product requirements These requirements specify or constrain the runtime behavior of the
software.
Examples include performance requirements for how fast the system must execute
and how much memory it requires; reliability requirements that set out the acceptable failure
rate; security requirements; and usability requirements.
2. Organizational requirements These requirements are broad system requirements derived
from policies and procedures in the customer’s and developer’s organizations.
Examples include operational process requirements that define how the system will
be used; development process requirements that specify the programming language; the
development environment or process standards to be used; and environmental requirements that
specify the operating environment of the system.
 Software requirements
 3. External requirements All requirements that are derived from factors external to the system
and its development process.
 Examples include
 regulatory requirements that set out what must be done for the system to be
approved for use by a regulator, such as a nuclear safety authority;
 legislative requirements that must be followed to ensure that the system operates
within the law; and ethical requirements that ensure that the system will be acceptable to its users
and the general public
 Example:
 Software requirements

Goals and requirements

• Non-functional requirements may be very difficult to state precisely and

imprecise requirements may be difficult to verify.

• Goal
• A general intention of the user such as ease of use.

• Verifiable non-functional requirement

• A statement using some measure that can be objectively tested.

• Goals are helpful to developers as they convey the intentions of the system
users.
 Software requirements
 Usability requirements

• The system should be easy to use by medical staff and should be organized in such a way
that user errors are minimized. (Goal)
• Medical staff shall be able to use all the system functions after four hours of training. After
this training, the average number of errors made by experienced users shall not exceed two
per hour of system use. (Testable non-functional requirement)
• Metrics for specifying nonfunctional requirements
 Software requirements

Domain requirements

• The system’s operational domain imposes requirements on the system.

For example, a train control system has to take into account the braking
characteristics in different weather conditions.

• Domain requirements be new functional requirements, constraints on existing requirements or

define specific computations.

• If domain requirements are not satisfied, the system may be unworkable.

 Software requirements

Domain requirements problems:

 Understandability
• Requirements are expressed in the language of the application domain;
• This is often not understood by software engineers developing the system.

 Implicitness
• Domain specialists understand the area so well that they do not think of
making the domain requirements explicit.
 Software requirements

Key points

• Requirements for a software system set out what the system should do and define constraints
on its operation and implementation.

• Functional requirements are statements of the services that the system must provide or are
descriptions of how some computations must be carried out.

• Non-functional requirements often constrain the system being developed and the development
process being used.

• They often relate to the emergent properties of the system and therefore apply to the system as
a whole.
 Software requirements

Software requirements document

• The software 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.
 Software requirements

Purpose of SRS

• Communication between the Customer, Analyst, System Developers, Maintainers

• Firm foundation for the design phase

• Support system testing activities

• Support project management and control

• Controlling the evolution of the system

 Software requirements

Requirements document variability

• Information in requirements document depends on type of system and the

approach to development used.

• Systems developed incrementally will, typically, have less detail in the

requirements document.

• Requirements documents standards have been designed e.g. IEEE standard.

These are mostly applicable to the requirements for large systems engineering
projects.
 Software requirements
Users of a requirements document
IEEE Requirements Standard
Software requirements
• Defines a generic structure for a requirements document that must be instantiated for each specific
system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview
2. General description
Software requirements
2.1 Product perspective
2.2 Product function summary
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific Requirements
- Functional requirements
- External interface requirements
- Performance requirements
- Design constraints- Attributes eg. Security, availability, maintainability,
transferability/conversion- Other requirements
• Appendices
• Index
 Software requirements
 The structure of a requirements document
 Software requirements

Requirements Engineering Processes

• Requirement engineering helps software engineers to better understand the problem to solve.
• It is carried out by software engineers (analysts) and other project stakeholders
• It is important to understand what the customer wants before one begins to design and build a
computer based system
• Work products include user scenarios, functions and feature lists, analysis models

Requirements engineering (RE) is a systems and software engineering process which covers all of
the activities involved in discovering, documenting and maintaining a set of requirements for a
computer-based system The processes used for RE vary widely depending on the application
domain, the people involved and the organisation developing the requirements.
 Software requirements
• Activities within the RE process may include:

– Requirements elicitation- discovering requirements from system stakeholders

– Requirements Analysis and negotiation- checking requirements and resolving stakeholder conflicts
– Requirements specification (Software Requirements Specification)- documenting the requirements
in a requirements document.
– System modeling- deriving models of the system, often using a notation such as the Unified
Modeling Language.
– Requirements validation- checking that the documented requirements and models are consistent
and meet stakeholder needs.
– Requirements management- managing changes to the requirements as the system is developed and
put into use.
 Software requirements
 Feasibility studies

The purpose of feasibility study is not to solve the problem, but to determine whether the problem
is worth solving.
• A feasibility study decides whether or not the proposed system is worthwhile.
• The feasibility study concentrates on the following area.
– Operational Feasibility
– Technical Feasibility
– Economic Feasibility
• 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. Based on
information assessment (what is required), information collection and report writing.

 Software requirements

• Questions for people in the organization

– What if the system wasn’t implemented?
– How will the proposed system help?
– What will be the integration problems?
– Is new technology needed? What skills?
– What facilities must be supported by the proposed
system?
 Software requirements

Requirement Elicitation and Analysis: Requirement discovery, Interviewing,

 Requirements analysis in systems engineering and software engineering, encompasses those
tasks that go into determining the needs or conditions to meet for a new or altered product,
taking account of the possibly conflicting requirements of the various stakeholders, such as
beneficiaries or users.

 Requirements analysis is critical to the success of a systems or software project. The

requirements should be documented, actionable, measurable, testable, traceable, related to
identified business needs or opportunities, and defined to a level of detail sufficient for
system design. Requirements analysis includes three types of activities
– Eliciting requirements
– Analyzing requirements
– Recording requirements:
 Software requirements
Requirement Validation
• Concerned with demonstrating that the requirements define the system that the customer really wants.
• Requirements error costs are high so validation is very important
-Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an
implementation error.
During the requirements validation process, different types of checks should be carried out on the
requirements in the requirements document. These checks include:
• Validity. Does the system provide the functions which best support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer included?
• Realism. Can the requirements be implemented given available budget and technology
• Verifiability. Can the requirements be checked
 Software requirements
 Requirements Validation Techniques

• Requirements reviews– Systematic manual analysis of the requirements.

• Prototyping– Using an executable model of the system to check requirements.
• Test-case generation– Developing tests for requirements to check testability
 Requirements Reviews

• Regular reviews should be held while the requirements definition is being formulated.
• Both client and contractor staff should be involved in reviews.
•Reviews may be formal (with completed documents) or informal. Good communications between
developers, customers and users can resolve problems at an early stage.
 Software requirements

 Requirement Management

 Requirements management is the process of managing changing requirements during the

requirements engineering process and system development. Requirements are inevitably
incomplete and inconsistent

– New requirements emerge during the process as business needs change and a
better understanding of the system is developed;

 – Different viewpoints have different requirements and these are often

contradictory.
Thank You

36