Chapter Four

Software Requirement Analysis

Introduction
• The requirements for a system are the descriptions of what the
system should do, the services that it provides and the constraints on
its operation
• These requirements reflect the needs of customers for a system that
serves a certain purpose such as controlling a device, placing an order,
or finding information.
4.1. Requirements Engineering Processes
• Requirements engineering processes may include four high-level
activities.
These focus on assessing if the system is useful to the business
(feasibility study),
Discovering requirements (elicitation and analysis),
Converting these requirements into some standard form
(specification), and
checking that the requirements actually define the system that the
customer wants (validation).
Already discussed in chapter three
4.2. User and system requirements
• 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.
• 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.
Example
• This example from a mental health care patient management system (MHC-PMS)
shows how a user requirement may be expanded into several system
requirements.
• User requirement
1. The MHC-PMS shall generate monthly management reports showing
the cost of drugs prescribed by each clinic during that month.
System requirement
1.1 On the last working day of each month, a summary of the drugs prescribed,
their cost, and the prescribing clinics shall be generated.
1.2 The system shall automatically generate the report for printing after 17.30 on
the last working day of the month.
Example….
1.3 A report shall be created for each clinic and shall list the individual
drug names, the total number of prescriptions, the number of doses
prescribed, and the total cost of the prescribed drugs.
1.4 If drugs are available in different dose units (e.g., 10 mg, 20 mg)
separate reports shall be created for each dose unit.
1.5 Access to all cost reports shall be restricted to authorized users
listed on a management access control list.
4.3. Functional and non-functional
requirements
A. Functional requirements
• The functional requirements for a system describe what the system
should do
• When expressed as user requirements, functional requirements are
usually described in an abstract way that can be understood by system
users.
• However, more specific functional system requirements describe the
system functions, its inputs and outputs, exceptions, etc., in detail
……Functional requirements
• For example, for functional requirement of the MHC-PMS system, used to
maintain information about patients receiving treatment for mental health
problems:
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.
These functional user requirements define specific facilities to be provided by
the system.
These have been taken from the user requirements document and
They show that functional requirements may be written at different levels of
detail
 …….functional requirements
• In principle, the functional requirements specification of a system
should be both complete and consistent.
• Completeness means that all services required by the user should be
defined.
• Consistency means that requirements should not have contradictory
definitions
B. 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.
• They may relate to system properties such as reliability, response
time, store occupancy, security etc.
• 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.
…… Non-functional requirements
• Non-functional requirements, such as performance, security, or availability, usually
specify or constrain characteristics of the system as a whole.
• Non-functional requirements are often more critical than individual functional
requirements.
• System users can usually find ways to work around a system function that doesn’t
really meet their needs.
• However, failing to meet a non-functional requirement can mean that the whole
system is unusable.
• For example, if an aircraft system does not meet its reliability requirements,
it will not be certified as safe for operation;
• If an embedded control system fails to meet its performance requirements, the
control functions will not operate correctly.
…… Non-functional requirements
• Non-functional requirements may affect the overall architecture of a
system rather than the individual components.
• For example, to ensure that performance requirements are met, you may
have to organize the system to minimize communications between
components.
• A single non-functional requirement, such as a security requirement, may
generate a number of related functional requirements that define new
system services that are required.
• In addition, it may also generate requirements that restrict existing
requirements.
…… Non-functional requirements
• Non-functional requirements arise through
• User needs, because of
• Budget constraints,
• Organizational policies,
• The need for inter-operability with other software or hardware
systems, or
• External factors such as
• Safety regulations or
• Privacy legislation.
…… Non-functional requirements
Metrics that you can use to specify non-functional system
properties
• Speed: Processed transactions/second, User/event response time,
Screen refresh time
• Size: Mbytes, Number of ROM chips
• Ease of use: Training time, Number of help frames, user interface
• Reliability: Mean time to failure, Probability of unavailability, Rate of failure
occurrence, Availability
• Robustness: Time to restart after failure, Percentage of events causing failure,
Probability of data corruption on failure
4.4. The software requirements document
• It also called the software requirements specification or SRS
• Is an official statement of what the system developers should
implement.
• It should include both the user requirements for a system and a detailed
specification of the system requirements.
• Sometimes, the user and system requirements are integrated into a single
description.
• In other cases, the user requirements are defined in an introduction to the
system requirements specification.
……. The software requirements
document
• If there are a large number of requirements, the detailed system
requirements may be presented in a separate document.
• Requirements documents are essential specially when an outside
contractor is developing the software system.
• However, agile development methods argue that requirements
change so rapidly that a requirements document is out of date as soon
as it is written, so the effort is largely wasted.
• The level of detail that you should include in a requirements document
depends on the type of system that is being developed and the
development process used.
……. The software requirements
document
• Critical systems need to have detailed requirements because safety
and security have to be analyzed in detail.
• When the system is to be developed by a separate company (e.g.,
through outsourcing), the system specifications need to be detailed
and precise.
• If an inhouse, iterative development process is used, the
requirements document can be much less detailed and any
ambiguities can be resolved during development of the system.
Sample Software Requirements Specification
Template
1. Introduction
1.1. Purpose
Identify the product whose software requirements are specified in this
document, including the revision or release number. Describe the scope
of the product that is covered by this SRS, particularly if this SRS describes
only part of the system or a single subsystem.
….Sample SRS template
1.2 Intended Audience and Reading Suggestions
Describe the different types of reader that the document is intended
for, such as developers, project managers, marketing staff, users,
testers, and documentation writers.
1.3 Product Scope
Provide a short description of the software being specified and its
purpose, including relevant benefits, objectives, and goals
1.4 References
List any other documents or Web addresses to which this SRS
….Sample SRS template
2.Overall Description
2.1Product Perspective
Describe the context and origin of the product being specified in this SRS. For
example, state whether this product is a follow-on member of a product
family, a replacement for certain existing systems, or a new, self-contained
product.
2.2 Product Functions
Summarize the major functions the product must perform or must let the
user perform. Details will be provided in Section 4,
2.3User Classes and Characteristics
Identify the various user classes that you anticipate will use this product.
….Sample SRS template
2.4. Operating Environment
Describe the environment in which the software will operate, including
the hardware platform, operating system and versions, and any
2.5. Design and Implementation Constraints
Describe any items or issues that will limit the options available to the
developers. These might include: corporate or regulatory policies; etc..
….Sample SRS template
2.6. User Documentation
List the user documentation components (such as user manuals, on-
line help, and tutorials) that will be delivered along with the software.
2.7. Assumptions and Dependencies
List any assumed factors (as opposed to known facts) that could affect
the requirements stated in the SRS.
These could include third-party or commercial components that you
plan to use, issues around the development or operating environment,
or constraints.
….Sample SRS template
3.External Interface Requirements
3.1User Interfaces
Describe the logical characteristics of each interface between the software
product and the users.
This may include sample screen images, any GUI standards or product
family style guides that are to be followed, screen layout constraints, etc..
3.2Hardware Interfaces
Describe the logical and physical characteristics of each interface between
the software product and the hardware components of the system.
….Sample SRS template
3.3Software Interfaces
Describe the connections between this product and other specific
software components (name and version), including databases, operating
systems, tools, libraries, and integrated commercial components

3.4Communications Interfaces
Describe the requirements associated with any communications
functions required by this product, including e-mail, web browser,
network server communications protocols, electronic forms, and so on.
….Sample SRS template
4. System Features
This template illustrates organizing the functional requirements for the product
by system features, the major services provided by the product.
You may prefer to organize this section by use case, mode of operation, user
class, object class, functional hierarchy, or combinations of these, whatever
makes the most logical sense for your product.
4.1System Feature 1
Don’t really say “System Feature 1.” State the feature name in just a few words.
4.1.1 Description and Priority
Provide a short description of the feature and indicate whether it is of High,
Medium, or Low priority.
….Sample SRS template
4.1.2 Stimulus/Response Sequences
List the sequences of user actions and system responses that stimulate the
behavior defined for this feature.
4.1.3 Functional Requirements
Itemize the detailed functional requirements associated with this feature.
These are the software capabilities that must be present in order for the user to
carry out the services provided by the feature, or to execute the use case.
Include how the product should respond to anticipated error conditions or invalid
inputs.
Each requirement should be uniquely identified with a sequence number or a
meaningful tag of some kind.
4.2System Feature 2 (and so on)
….Sample SRS template
5. Other Nonfunctional Requirements
5.1. Performance Requirements
If there are performance requirements for the product under various circumstances,
state them here and explain their rationale, to help the developers understand the
intent and make suitable design choices.
5.2 Safety Requirements
Specify those requirements that are concerned with possible loss, damage, or harm
that could result from the use of the product
5.3. Security Requirements
Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product.
….Sample SRS template
5.4. Software Quality Attributes
Specify any additional quality characteristics for the product that will be
important to either the customers or the developers.
5.5. Business Rules
List any operating principles about the product, such as which
individuals or roles can perform which functions under specific
circumstances.
….Sample SRS template
6. Other Requirements
Define any other requirements not covered elsewhere in the SRS.
This might include database requirements, internationalization requirements,
legal requirements, reuse objectives for the project, and so on.
Appendix A: Glossary
Define all the terms necessary to properly interpret the SRS, including
acronyms and abbreviations
Appendix B: Analysis Models
Optionally, include any pertinent analysis models, such as data flow
diagrams, class diagrams, state-transition diagrams, or entity-relationship
diagrams