Requirement Specification

 Requirements specification is the process of

writing down the user and system requirements
in a requirements document.
 The user and system requirements should be
clear, unambiguous, easy to understand,
complete, and consistent.
 In practice, this is difficult to achieve as
stakeholder interpret the requirements in
different ways and there are often inherent
conflicts and inconsistencies in the
requirements.
 The requirements document should not include
details of the system architecture or design.
Requirement Specification
 We should write user requirements in natural
language, with simple tables, forms, and
intuitive diagrams.
 System requirements are expanded versions of
the user requirements that are used by software
engineers as the starting point for the system
design.
 the system requirements should simply describe
the external behavior of the system and its
operational constraints.
 They should not be concerned with how the
system should be designed or implemented.
Ways of writing a simple requirement
specification
 Natural Language Sentence
 The requirements are written using numbered
sentences in natural language. Each sentence
should express one requirement.
 Structure Natural Language
◦ The requirements are written in natural language
on a standard form or template. Each field
provides information about an aspect of the
requirement.
 Graphical Notation
 Graphical models, supplemented by text
annotations, are used to define the functional
requirements for the system; UML use case and
sequence diagrams are commonly used.
Ways of writing a simple requirement
specification
 Design Description Language
◦ This approach uses a language like a
programming language, but with more abstract
features to specify the requirements by defining
an operational model of the system.
◦ This approach is now rarely used although it can
be useful for interface specification.
 Mathematical Specification
◦ These notations are based on mathematical
concepts such as finite-state machines or sets.
Although these unambiguous specifications can
reduce the ambiguity in a requirements
document, most customers don’t understand a
formal specification.
User and System Requirement
 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 should
define exactly what is to be implemented. It may
be part of the contract between the system
buyer and the software developers.
Functional and Non Functional Req.
 Functional requirements 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 not do.
 Non-functional requirements are constraints
on the services or functions offered by the
system.
 They include constraints on timing, development
process, and constraints imposed by standards.
 Non-functional requirements often apply to the
system as a whole.
Functional Requirements
 The functional requirements for a system
describe what the system should do.
 These requirements depend on the type of
software being developed, the expected users
of the software, and the general approach taken
by the organization when writing requirements.
 Functional requirements are usually described
in an abstract way that can be understood by
system users.
 Functional system requirements describe the
system functions, its inputs and outputs,
exceptions, etc., in detail.
Non Functional Requirement
 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 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, such as
performance, security, or availability, usually
specify or constrain characteristics of the system
as a whole.
 Failing to meet a non-functional requirement
can mean that the whole system is unusable
Non Functional Requirement Continue
 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.
 It may also generate requirements that restrict
existing requirements.
Non Functional Requirement Continue
 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.
 It may also generate requirements that restrict
existing requirements.
The Software Requirement Document
 The software requirements document is an official
statement of what the system developers should
implement.
 The user and system requirements are integrated
into a single description.
 The user requirements are defined in an
introduction to the system requirements
specification.
 Requirements documents are essential when an
outside contractor is developing the software
system.
 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 Software Requirement Document
 The requirements document has a diverse set
of users, ranging from the senior management
of the organization that is paying for the system
to the engineers responsible for developing the
software.
 The diversity of possible users means that the
requirements document has to be a
compromise between communicating the
requirements to customers, defining the
requirements in precise detail for developers
and testers, and including information about
possible system evolution.
Qualities of Software Specification
 Complete: The SRS should include all the requirements
for the software system, including both functional and
non-functional requirements.
 Consistent: The SRS should be consistent in its use of
terminology and formatting, and should be free of
contradictions.
 Unambiguous: The SRS should be clear and specific, and
should avoid using vague or imprecise language.
 Traceable: The SRS should be traceable to other
documents and artifacts, such as use cases and user
stories, to ensure that all requirements are being met.
 Verifiable: The SRS should be verifiable, which means
that the requirements can be tested and validated to
ensure that they are being met.
Qualities of Software Specification
 Modifiable: The SRS should be modifiable, so that it can
be updated and changed as the software development
process progresses.
 Prioritized: The SRS should prioritize requirements, so
that the most important requirements are addressed first.
 Testable: The SRS should be written in a way that allows
the requirements to be tested and validated.
 High-level and low-level: The SRS should provide both
high-level requirements (such as overall system
objectives) and low-level requirements (such as detailed
functional requirements).
 Relevant: The SRS should be relevant to the software
system that is being developed, and should not include
unnecessary or irrelevant information.
Qualities of Software Specification
 Human-readable: The SRS should be written in a way
that is easy for non-technical stakeholders to understand
and review.
 Aligned with business goals: The SRS should be aligned
with the overall business goals and objectives of the
organization, so that the software system meets the needs
of the business.
 Agile methodologies: Agile methodologies, such as
Scrum and Kanban, provide an iterative approach to
requirements capturing and validation, where
requirements are captured and validated in small chunks
of functionality and feedback is gathered from the
customer.
Structure of SRS(Guidelines)
 Functionality: It should be separate from
implementation.
 Analysis model: It should be developed according to the
desired behavior of a system. This should include data
and functional response of a system to various inputs
given to it.
 Cognitive model: It should be developed independently
of design or implementation model. This model
expresses a system as perceived by the users.
 The content and structure of the specification: It
should be flexible enough to accommodate changes.
 Specification: It should be robust. That is, it should be
tolerant towards incompleteness and complexity.
The Users of Requirement Document
The Structure of Requirement Document
 Preface
 Introduction
 Glossary
 User Requirement definition
 System Architecture
 System Requirement Specification
 System Models
 System Evolution
 Appendices
 Index
Requirement Specification
 Requirements specification is the process of
writing down the user and system requirements
in a requirements document.
 The user and system requirements should be
clear, unambiguous, easy to understand,
complete, and consistent.
 In practice, this is difficult to achieve as
stakeholder interpret the requirements in
different ways and there are often inherent
conflicts and inconsistencies in the
requirements.
 The requirements document should not include
details of the system architecture or design.
Classification of Specification Styles
 It can be termed as formally or informally.
Informal specifications are written in a natural
language they can however also make the use
of figures, tables and other notations.
 A notation that has precise syntax and meaning
is called a formalism.
 We use formalism to create formal
specifications.
 A formal language called OCL also available to
provide precise semantics of classes.
Operational Specification
 Operational specification describes the intended
system by described its desired behaviour,
usually by providing a model implementation of
the system.
 Descriptive specification try to state the desired
properties of the system in a purely declarative
fashion.
Verification Specification
 Observing the dynamic behavior of the specified
system in order to check whether it conforms to
the intuitive understanding we had of the
behavior of the ideal system.
 Analyzing the properties of the specified system
that can be deduced from the specification. The
properties that are deduced are then checked
against the expected properties of the system.
 Most commonly used dynamic system behavior.
◦ Simulation
◦ Prototyping
Operational Specification(DFD)
 DFDs are well known and widely used
notation for specifying the function of an
information system and how data flow
from function to functions.
 It describes the collection of function that
manipulate data.
 In DFD data can be stored in data
repositories or it work as data flow.
 DFDs are success because it can be used
by means of attractive graphical notation
that makes them easy to use.
Basic elements of DFD
 Functions represented by bubbles.
 Data flows represented by arrows.
 Data Store represented by open boxes.
 Input Output represented by special kind
of boxes.