Software Requirements

Definition
• The requirements for a system are the description of the services
provided by the system and it’s operational constraints.

• The requirements reflect the needs of the customers for a system and
help solve a number of problems such as controlling a device, placing an
order or finding information.

• A requirement is simply a high level, abstract statement of a service that

a system should provide or a constraint on a system.
Types of requirements
• User Requirements- These are statements in a natural language plus
diagrams of what services the system is expected to provide and the
constraints under which the system must operate.
• System Requirements- These requirements set out the system’s
functions, services and operational constraints in detail. The system
requirements produce a document which should be precise and
should define exactly what is to be implemented.
• Functional requirements- These are statement of services the system
should provide, hoe the system should react to particular inputs and how
the system should behave in a particular situation.
• Non- Functional requirements- These are the constraints on the services
and functions offered by the system. They include timing constraints,
constraints on the development process and standards.
• Domain requirements- These are the requirements that come from the
domain of the system and system environment.
Types of non-functional
requirements
• Product Requirements (Usability, Efficiency, Reliability, Portability) -
These requirements specify the product behavior, how fast a system
should execute, how much memory does it use.
• Organizational requirements (Delivery, Implementation, Standards) -
These requirements are derived from policies and procedures in the
customer’s and developer’s organization.
• External requirements (Interoperability, Ethical, Legislative) - These
cover all requirements derived from factors external to the system and
its development process.
Metrics for non-functional
requirements
• Speed- Depends on transactions, response time and no. of users.

• Size- Depends on no. of bytes of space used.

• Ease of use- Training time and no of help frames

• Reliability- Mean time to failure and rate of failure occurrence

• Robustness- Time to restart and %age of failure occurrence

• Portability- No. of target systems and %age of target dependent

statements.
Notations for requirement
specifications-
• Structured Natural Language- Defines standard forms or templates in
natural language.

• Design Description language- Defines the operational level

characteristics like pre-conditions, post-conditions and functions.

• Graphical notation- State changes, state diagrams and data flow

diagrams.

• Mathematical Specification- Notations based on mathematical

concepts like algebraic specification and finite state machines.
Software Requirements Specification
(SRS)
• The software requirements document also called the software
requirements specification (SRS) is the official statement of what the
system developers should implement. It includes user requirements
and system requirements. It is used by all people in the organization
including the developers, users, testers and managers.
Format of SRS-
• Introduction- Purpose of requirements document, Scope of product,
Definitions, acronyms and abbreviations, references and overview of
remaining document.
• General Description- Product perspective, product functions, user
characteristics, general constraints, assumptions and dependencies.
• Specific requirements- Functional, non-functional and interface
requirements.
• Appendices
• Index
Requirements Engineering
Process
• The goal of the requirement engineering process is to create and
maintain a system requirement document. The overall process
includes four high level requirement engineering sub processes.
The RE processes are concerned with-
• Assessing whether the system is useful to the business (feasibility
study).
• Discovering requirements (elicitation and analysis).
• Converting these requirements to standard form. (Specification).
• Checking that the requirements actually define the system that the
customer wants. Validation)
Feasibility Study
• The input to the feasibility study is a set of preliminary business
requirements, an outline description of the system and how the
system is intended to support business process.

• The result of the feasibility study is a report that recommends

whether or not it is worth carrying on with requirements engineering.

A feasibility study aims to answer the following questions-

• 1. Does the system contribute to the overall objective of the

organization?
• 2. Can the system be implemented using the current technology and
within the given cost and schedule constraints?
• 3. Can the system be integrated with other systems which are
already in place?
Requirements elicitation and
analysis
• In this activity, software engineers work with customers and system
end-users to find out about the application domain, what services the
system should provide, the required performance of the system,
hardware constraints and so on.
• Various methods of requirements discovery are-
• i) Viewpoints
• ii) Scenarios
• iii) Ethnography
• iv) Structured analysis
• v)Use-Cases
• vi) Prototyping
Viewpoints

• Viewpoints help in the elicitation process. In analysis it recognizes

multiple perspectives and provides framework for discovering conflicts in
the requirements.
Types of viewpoints-
• Interactive Viewpoints- These represent people or systems that interact
directly with the system (interfaces).
• Indirect Viewpoints- These represent stakeholders who do not use the
system themselves but who use requirements in some way. (Managers).
• Domain Viewpoints- They represents domain characteristics and
constraints that influence the system
Interviewing
• Interviewing is the process of questioning the users. Formal
and Informal interviews with the stakeholders are part of most
requirement engineering processes. Questions are put about
the system they use and system to be developed.

• Types of interviews-
• Closed Interviews- Stakeholders answer pre-defined questions.
• Open Interviews- There is no pre-defined agenda and
questions can be asked on any topic.
Scenarios

• Scenarios are real life examples, which are used to understand

how people interact with software system. Requirement
engineering is used to formulate the actual system and detail.

• Each scenario covers one possible interaction. A scenario can

be depicted as follows-

• Start->Flow of events->What can go wrong->Other activities-

>Finish
Use-cases
• Use-Case is a fundamental feature of UML notation. Use Cases
identify the individual interactions with the system. They can be
documented with text or linked to UML model that develop scenario
in more detail.
• Use-cases involve-
• 1. Actors
• 2. Objects they interact with
• 3. Operations associated with these objects
Ethnography
• It is an observational technique. It can be used to understand social
and organizational requirements. An analyst immerses himself in the
working environment where the system will be used. He makes notes
of day to day tasks and understands complex and dynamic behavior
which may be oblivious to the user.

Two types of requirements can be understood-

• Requirements that are derived from the way in which people work.
• Requirements that are derived from cooperation and awareness of other
people activities
Requirements Validation
• Requirements Validation is concerned with showing that the
requirements actually define the system that the customer wants.
Requirements validation is important because errors in a requirement
document can lead to extensive rework costs when they are
discovered during development or after the system is in service.

• Steps in requirements validation are-

Validity Checks – Identify functions or requirements that are different
from the stated ones.
Consistency Checks- Requirements in the document should not conflict
and there are no contradictory constraints or descriptions.
Realism Checks- Using knowledge of existing technology the
requirements should be checked to ensure that they could actually be
implemented.
Verifiability- To reduce the potential for dispute between customer and
contractor, system requirements should always be written so that they
are verifiable
Requirements Management
• The requirements for large software systems are always changing. Once
end users have experience of a system they discover new needs.
Requirements management is the process of understanding and
controlling changes to system requirements.
There are two types of requirements-
• Enduring Requirements- These are relatively stable requirements that
derive from the core activity of the organization and which relate directly
to the domain of the system.
• Volatile Requirements- These are the requirements which are likely to
change during the system development process or after system has
become operational.
System Models
• A widely used technique is to document system specification as a set
of system models. These are graphical representations that describe
business process, the problem to be solved and the system to be
developed

• It is used in requirement analysis.

• Problem with this technique is that it is an abstraction which simplifies

and picks out the most salient features.
Types of System Models
• Data flow model- It shows how data is processed at different stages
in the system.
• Composition model- A composition or aggregation model shows how
entities in the system are composed of other entities.
• Architectural model- It shows the principal subsystems that make up
a system.
• Classification model- These are object/class or inheritance models
which shows how entities have common characteristics.
• Stimulus-response model- A stimulus response model or a state
transition diagram shows how the system reacts to internal and
external events.
• Context Models- In the requirements elicitation process it is important
to know system boundary. System boundary is decided by social and
organizational concerns.
• System context models help in interaction between current system
and the outside system.
• Process Model- Process model describes various processes involved for
a particular objective.
• Behavioral Model- It describes the overall behavior of the system.
• Data Flow Model- Data Flow Models are a graphical way of showing how
data is processed by a system. They should be used to model the way in
which data is processed by an existing system.
• State Machine Model- The state machine model shows the system
states and events that cause transition from one state to another. This
type of model is often used for modeling real-time system because these
systems are often driven by stimuli from system environment. In UML
state machine models are represented with state charts.
• Object Models- It is used for interactive systems development. Object
models developed during requirement analysis may be used to
represent both system data and it’s processing. Is consists of class and
objects.
• An object class is an abstraction over a set of objects that identifies that
identifies common attributes and services or operations provided by
each object.UML is a standard for object oriented modeling.

• Inheritance Models- After classes have been identified they are arranged
in a taxonomy. Taxonomy is a classification scheme that shows how an
object class is related other object classes through common attributes
and services.
Formal Specification
• The term formal method is used to refer to any activities that rely on
mathematical representation of software including formal system
specification, specification analysis and proof, transformational
development and program verification.
• Formal specification in the software process involves two main methods-
• Algebraic Approach- Here system is described in terms of operation and
relationship.
• A model based approach- In this method model of the system is built
using mathematical constructs such as sets and sequences and system
operations as defined by how they modify the system state.
Algebraic Approach
• Algebraic Approach- The algebraic approach was designed for
abstract data type specification. It consists of the following parts-
• Specification Structuring- Organize the informal specification into a
set of abstract data types or object classes.
• Specification Naming- Establish a name for each abstract type
specification.
• Operation selection- Choose a set of operations for each
specification.
• Informal operator selection- Write an informal specification of each
operation.
• Syntax definition- Define the syntax of the operation and the
parameter of each.
• Axiom definition- Define the semantics of the operations by
describing the conditions that are always true for different operation
combinations.
Model Based Specification

• Model Based Specification- Various tools include VDM, B, and Z

• Z- In Z systems are modeled using sets and relations between sets.

The Z schema is used to represent system inputs, system outputs
and state variables.
Requirements Specification
• There are a number of techniques of specifying requirements.
• Structured Natural Language
• Specification and Description Language
• Graphical Notation or Modeling Notation
• Mathematical specification or Algebraic specification
• Functionality Tree
• Behavior Table
• Fact based collaboration modeling methodology (FBCM)
Structured Natural Language
• Natural Language is often used to write system requirement
specifications as well as user requirements.

• Another form is structured natural language which is a way of writing

requirements in a standard way.

• The advantage is it maintains most of expressiveness and

understandability of natural language but ensures uniformity.
Structured Natural Language
( Example)
• Function- Compute the cash and amount and withdraw cash (ATM)
• Description- Allow customer to withdraw cash.
• Inputs- PIN, Account type, Cash Amount
• Outputs- Transaction Slip
• Destination- Cash slot
• Action- Input the PIN and cash amount, verify the pin and withdraw the
cash.
• Requires- Access to customer database
• Pre-condition- Access to database and cash
• Post-condition- Update customer account
• Side effects- Low cash, No transaction
Specification and Description
Language
• SDL is a specification language targeted at unambiguous specification
and description of the behavior of reactive and distributed systems.
• A system is specified as a set of interconnected abstract machines
which are extensions of finite state machines (FSM)
• SDL is formally complete and can be used for code generation and
simulation purposes.
Graphical Notation or Modeling
Notation for requirement specification
• These modeling notations represent the system in a graphical way.
• The information is encapsulated in the form of a chart or a diagram.
• At a later stage these can be used to further design and code the
system.
• A number of such methods are available which can be used to
represent the system.
Context Model
• Context models are used to illustrate the boundaries of a system.
• Social and organizational concerns may affect the decision on where
to position system boundaries.
• Architectural models show the a system and its relationship with
other systems.
• An SDL system is made of five components- structure,
communication, behavior, data and inheritance.
• The behavior of the system is explained by partitioning the system
into a set of hierarchies.
• SDL has many versions latest being SDL-2000 accompanied by
SDL-UML profile.
Process Model
• Process models show the overall process and the processes that are
supported by the system.

• Data flow models may be used to show the processes and the flow of
information from one process to another
Data Processing Model
• Data flow diagrams are used to model the system’s data processing.

• These show the processing steps as data flows through a system.

• Intrinsic part of many analysis methods.

• Simple and intuitive notation that customers can understand.

• Show end-to-end processing of data.

State Machine Model
• These model the behavior of the system in response to external and
internal events.

• They show the system’s responses to stimuli so are often used for
modeling real-time systems.

• When an event occurs, the system moves from one state to another.

• State charts are an integral part of the UML.

State charts
• Allow the decomposition of a model into sub models.

• A brief description of the actions is included following the ‘do’ in each

state.

• Can be complemented by tables describing the states and the stimuli

Semantic Data Model
• Used to describe the logical structure of data processed by the system.

• Entity-relation-attribute model sets out the entities in the system, the

relationships between these entities and the entity attributes.

• Widely used in database design.

• Can readily be implemented using relational databases.

• No specific notation provided in the UML but objects and associations

can be used
Data Dictionary
• Data dictionaries are lists of all of the names used in the system
models.

• Descriptions of the entities, relationships and attributes are also

included which support name management and avoid duplication.

• Storeage of organizational knowledge linking analysis, design and

implementation

• Many CASE workbenches support data dictionaries

Unified Modeling Language
• Devised by the developers of widely used object oriented analysis
and design methods has become an effective standard for object
oriented modeling.

• Object classes are rectangles with the name at the top, attributes in
the middle section and operations in the bottom section,relationships
between object classes depict linking objects.

• Inheritance is referred to as generalization and is shown ‘upwards’

rather than ‘downwards’ in a hierarchy.
Multiple Inheritance
• Rather than inheriting the attributes and services from a single parent
class, a system which supports multiple inheritance allows object
classes to inherit from several super-classes that can lead to
semantic conflicts where attributes/services with the same name in
different super-classes have different semantics.

• Makes class hierarchy reorganization more complex.

Object Aggregation
• Aggregation model shows how classes which are collections are
composed of other classes
• .
• Similar to the part-of relationship in semantic data models.
Object Behavior Modeling
• A behavioral model shows the interactions between objects to
produce some particular system behavior that is specified as a use-
case.

• Sequence diagrams (or collaboration diagrams) in the UML are used

to model interaction between objects.
Mathematical or Algebraic
Specification
Introduction
• Defines the sort (the type name) and declares other specifications
that are used.

Description
• Informally describes the operations on the type

Signature
• Defines the syntax of the operations in the interface and their
parameters

Axioms
• Defines the operation semantics by defining axioms which
characterize behavior
Functionality Tree
• System stimuli can be represented in two ways:
• 1) by grouping stimuli into stimulus sets based on functional, physical,
and temporal cohesion, and
• 2) arranging the stimulus sets into a hierarchy called a functionality tree.

• Syntactically, a functionality tree is a horizontal hierarchy with the

hierarchical levels arranged in columns.
• Each column represents a “depth level,” which is the hierarchical
distance of the stimulus sets in that level from the “root” of the tree.
• The root consists of the stimulus sets in the leftmost column, designated
as “Level 0” because they are zero distance from the root.
Behavior Table
• A behavior table is a tabular notation that serves as a container for
recording the total response behavior for all stimuli of a single
stimulus set in a regular and systematic way.

• Guideline 1: One column is created for each response classification

list category.

• Guideline 2. One row is created for each stimulus of the stimulus set.
References
• Software Engineering By Somerville
• Software Engineering : A practioner’s approach by Roger S
Pressman
• Illustrations From Software Engineering Presentation By Somerville