ST.

MARTIN’S ENGINEERING COLLEGE

SOFTWARE REQUIREMENTS

Unit-II
Software Requirements: These are the services that the user expects from the system.
or
The software requirements are description of features and functionalities of the target system.
Requirements convey the expectations of users from the software product. The requirements
can be obvious or hidden, known or unknown, expected or unexpected from client’s point of
view.

Broadly software requirements should be categorized in four categories:

Functional Requirements:
Requirements, which are related to functional aspect of software fall into this category. They
define functions and functionality within and from the software system.Functionality means
features offered by system to satisfy the customer needs. The functional requirements should
be complete and consistent. Completeness implies that all the user requirements are defined.
Consistency implies that all requirements are specified clearly without any contradictory
definition.

A function is nothing but inputs to the software system, its behavior, and outputs. It can be a
calculation, data manipulation, business process, user interaction, or any other specific
functionality which defines what function a system is likely to perform. Functional
Requirements in Software Engineering are also called Functional Specification.

Examples -
 Search option given to user to search from various invoices.
 User should be able to mail any report to management.
 Users can be divided into groups and groups can be given separate rights.
 Should comply business rules and administrative functions.
 Software is developed keeping downward compatibility intact.

Non-Functional Requirements:

Requirements, which are not related to functional aspect of software, fall into this category. It
will not show features of the system. It will show how these factures are provided to system.
Non-Functional Requirements are important then Functional Requirements.

Non-functional requirements should be accomplished in software to make it perform

efficiently. For example, if an aeroplane is unable to fulfill reliability requirements, it is not
approved for safe operation. Similarly, if a real time control system is ineffective in
accomplishing non-functional requirements, the control functions cannot operate correctly.
They are implicit or expected characteristics of software, which users make assumption of.

The description of different types of non-functional requirements is listed below

Product requirements: These requirements specify how software product performs.

Organizational requirements: These requirements are derived from the policies and
procedures of an organization.

External requirements: These requirements include all the requirements that affect the
software or its development process externally. External requirements comprise the following

Non-functional requirements include -

 Security
 Logging
 Storage
 Configuration
 Performance
 Cost
 Interoperability
 Flexibility
 Disaster recovery
 Accessibility
User Requirements:

User requirements are statements in natural language along with corresponding diagrams
(tables, forms, intuitive diagrams) detailing the services provided by the system and operational
constraints it must comply with. Additionally, it’s worth noting that user requirements
primarily focus on the user’s needs. Thus, these user requirements cater to the customer.

Essentially, it entails the requirement that the user wants or ability to perform a functionality
or action with the system. So, it outlines the activities a user can perform with the system.
User requirements entail both functional and non-functional requirements that are
understandable even by users without technical knowledge.

These requirements don’t contain details of the system design and don’t use technical
expressions or formal notations. Also, these user requirements are documented in a text as
“User Requirements Document” using narrative text.

System Requirements:

System requirements consist of a structured document that details the system’s functions,
services and operational constraints. It’s mainly written and serves as a tool for the
developers of the system to build and implement the system design. It contains the functionality
that’s needed by the system in order for it to fulfil the user requirements.

Along with that, it outlines both the functional and non-functional requirements the system
should fulfil. Hence, it consists of all things the system must contain to construct or develop it.
They’re often described as the expanded version of user requirements that engineers use at the
beginning of a system’s design. Hence, the system requirements serve as a blueprint for the
developer to follow defining the parts of a system that are to be implemented, so it acts as a
contract between the client and contractor.

These requirements can be written in natural language, and also possesses more structured
forms and graphical notations. However, as it’s primarily written for developers it possesses a
detailed description of the project services. It uses natural language and is documented as a
System Requirement Specification (SRS).
Interface specification:
Interface specification is a documents that stores the capture of the exchanging data between
two systems.

Almost all software systems operate in an environment where there are other systems. They
may be interfaces to these systems in different ways Three types of interface may have to be
defined in a requirements specification

Procedural interfaces - Sub-systems offer a range of services (Used for calling the existing
programs by the new programs)
Data interfaces - Data structures are exchanged (Provide data passing from one sub-system
to another)
Representation interfaces - Specific data representation patterns may have to be used
(ordering of bits to match with the existing system).

Software Requirement Specification (or) software requirements document:

System Requirements Document is also known as System Requirements Specifications.

System requirements document is a set of documentation that describes the behavior and
features of a software or system. It comprises of various elements that attempt to characterize
the functionality needed by the client to satisfy their users. In other words, the system
requirements document (SRD) describes the system-level performance and functional
requirements for a system.

System Requirements Document or System Requirements Specification is defined as a

document which defines what the software will do and how it will be required to perform, and
it also defines the functionality the software needs to satisfy all stakeholders (users, business)
requirements.

Software requirement specification is a kind of document which is created by a software analyst

after the requirements collected from the various sources - the requirement received by the
customer written in ordinary language. It is the job of the analyst to write the requirement in
technical language so that they can be understood and beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.

 Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a
company, an organization, a set of procedures, a computer hardware system, a software
 system, or any combination of the preceding. The DFD is also known as a data flow
graph or bubble chart.
 Data Dictionaries: Data Dictionaries are simply repositories to store information about
all data items defined in DFDs. At the requirements stage, the data dictionary should at
least define customer data items, to ensure that the customer and developers use the
same definition and terminologies.
 Entity-Relationship Diagrams: Another tool for requirement specification is the
entity-relationship diagram, often called an "E-R diagram." It is a detailed logical
representation of the data for the organization and uses three main constructs i.e. data
entities, relationships, and their associated attributes.

Purpose of SRS

SRS is a communication tool between Customer / Client, Business Analyst, System

developers, Maintenance teams. It can also be a contract between purchaser and supplier.

 It will give firm foundation for the design phase

 Supports project management and control
 Helps in controlling and evolution of system

A software Requirement specification should be Complete, Consistent, Traceable,

Unambiguous, and Verifiable.

SRS should come up with following features:

 User Requirements are expressed in natural language.

 Technical requirements are expressed in structured language, which is used inside the
organization.
 Design description should be written in Pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.

The following should be addressed in system specification −

 Define the functions of the systems

 Define the Hardware / Software Functional Partitioning
 Define the Performance Specification
 Define the Hardware / Software Performance Partitioning
 Define Safety Requirements
 Define the User Interface (user’s manual)
 Provide Installation Drawings/Instructions
 Software Requirement specification template

According to the IEEE standards, SRDs must cover the following important topics.

 Quality
 Security/Privacy
 Functional capabilities
  Safety
 Performance levels
 Constraints and Limitations
 Data Structure/Elements
 Reliability
 Interfaces

Requirements engineering process:

Requirement Engineering: The process to gather the software requirements from client,
analyze and document them is known as requirement engineering.

The goal of requirement engineering is to develop and maintain sophisticated and descriptive
‘System Requirements Specification’ document.

Requirement Engineering Process:

It is a four step process, which includes –

 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation

Requirements Validation Techniques

 Requirements reviews/inspections: 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.
 Automated consistency analysis: checking for the consistency of structured
requirements descriptions.
Let us see the process briefly –

1. Feasibility study:
The objective behind the feasibility study is to create the reasons for developing the software
that is acceptable to users, flexible to change and conformable to established standards.

When the client approaches the organization for getting the desired product developed, it comes
up with rough idea about what all functions the software must perform and which all features
are expected from the software.

Referencing to this information, the analysts does a detailed study about whether the desired
system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. 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 explores technical aspects of the project and product such as usability, maintainability,
productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project should be
undertaken.

1. Technical Feasibility - Technical feasibility evaluates the current technologies, which

are needed to accomplish customer requirements within the time and budget.
2. Operational Feasibility – How well a proposed system will solve the problems.
Operational feasibility assesses the range in which the required software performs a
series of levels to solve business problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software
can generate financial profits for an organization.

2. Requirement Elicitation and Analysis (or) Requirement Gathering:

If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. 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.

Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of
relationships and also resolve conflicts if any.
Problems of Elicitation and Analysis

 Getting all, and only, the right people involved.

 Stakeholders often don't know what they want
 Stakeholders express requirements in their terms.
 Stakeholders may have conflicting requirements.
 Requirement change during the analysis process.
 Organizational and political factors may influence system requirements.

3. Software Requirement Validation:

After requirement specifications are developed, the requirements mentioned in this document
are validated. User might ask for illegal, impractical solution or experts may interpret the
requirements incorrectly. This results in huge increase in cost if not nipped in the bud.
Requirements can be checked against following conditions –

 If they can practically implement

 If they are correct and as per the functionality and specially of software
 If there are any ambiguities
 If they are full
  If they can describe

Requirements Validation Techniques

 Requirements reviews/inspections: 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.
 Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

4. Software Requirement Management:

Requirement management is the process of managing changing requirements during the

requirements engineering process and system development. New requirements emerge during
the process as business needs a change, and a better understanding of the system is developed.

The priority of requirements from different viewpoints changes during development process.
The business and technical environment of the system changes during the development.

System Modelling: System modelling is the process of developing abstract models of a

system. Each model presents a different view or perspective of that system. Represent the
system using some kind of graphical notation (Mostly based on UML). System modelling helps
the analyst to understand the functionality of the system and models are used to communicate
with customers. It also provides the developer and the customer with the means to assess
quality, once the software is built.

Existing and planned system models

• Models of the existing system are used during requirements engineering. They help clarify
what the existing system does and can be used as a basis for discussing its strengths and
weaknesses. These then lead to requirements for the new system.

• Models of the new system are used during requirements engineering to help explain the
proposed requirements to other system stakeholders. Engineers use these models to discuss
design proposals and to document the system for implementation.
• In a model-driven engineering process, it is possible to generate a complete or partial system
implementation from the system model.

Different Models different perspectives

You may develop different models to represent the system from different perspectives. For
example:

 An external perspective, where you model the environment of the system.

 An interaction perspective where you model the interactions between a system and its
environment or between the components of a system.
 A structural perspective, where you model the organization of a system or the
structure of the data that is processed by the system.
 A behavioural perspective, where you model the dynamic behaviour of the system
and how it responds to events

What is UML?

UML stands for Unified Modeling Language,

The Unified Modeling Language (UML) is a general-purpose, developmental, modelling

language in the field of software engineering that is intended to provide a standard way to
visualize the design of a system. It is quite similar to blueprints used in other fields of
engineering.

UML is not a programming language, it is rather a visual language. We use UML diagrams to
portray the behaviour and structure of a system. UML helps software engineers, businessmen
and system architects with modelling, design and analysis.

It is a standard modelling for Object-oriented modelling (OOM).OOM is an approach to

modeling an application that is used at the beginning of the software life cycle when using an
object-oriented approach to software development.

Characteristics of UML

The UML has the following features:

 It is a generalized modeling language.

 It is distinct from other programming languages like C++, Python, etc.
 It is interrelated to object-oriented analysis and design.
  It is used to visualize the workflow of the system.
 It is a pictorial language, used to generate powerful modeling artifacts.

UML diagrams represent two different views of a system model.

1. Static (or structural) view: emphasizes the static structure of the system using objects,
attributes, operations and relationships. It includes class diagrams and composite structure
diagrams.

2. Dynamic (or behavioural) view: emphasizes the dynamic behaviour of the system by
showing collaborations among objects and changes to the internal states of objects. This view
includes sequence diagrams, activity diagrams and uses case diagrams.

Essential UML diagrams for system modelling:

Note: Diagrams for understanding purpose only.

Use case diagrams, which show the interactions between a system and its environment

Sequence diagrams, which show interactions between actors and the system and between
system components.
Activity diagrams, which show the activities involved in a process or in the data processing.
Class diagrams, which show the object classes in the system and the associations between
these classes.

State diagrams, which show how the system reacts to internal and external events.

CONTEXT MODEL:
 This model show how the system being modelled is placed in an environment with
other system.
 Context models are used to illustrate the operational context of a system - they show
what lies outside the system boundaries. (It Shows the boundaries of system).
 However they do not show types of relationship between the system in the environment
and the system being specified. Normally environment includes many automated
systems.
 It involves working with system stakeholders to decide what functionality should be
included in the system and what is provided from system environment.
 Social and organisational concerns may affect the decision on where to position system
boundaries.
 Architectural models show the system and its relationships with other systems.
 The main purpose of context model is to understand the environment in which our
system going to operate along with other systems which are surrounded by our
system.
 Context model is static model which defines the system and its boundaries and
other systems which are surrounded by our system.
System boundaries
 System boundaries are established to define what is inside and what is outside the
system.
 They show other systems that are used or depend on the system being developed.
 The position of the system boundary has a profound effect on the system requirements.
 Defining a system boundary is a political judgment there may be pressures to develop
system boundaries that increase / decrease the influence or workload of different parts
of an organization.
 Fig shows simple context model that shows the patient information system and the
other systems in its environment.
 From fig it is seen that the MHC-PMS is connected to an appointments system and a
more general patient record system with which it shares data.
 The system is also connected to systems for management reporting and hospital bed
allocation and a statistics system that collects information for research.
 Finally, it makes use of a prescription system to generate prescriptions for patients’
Medication

The context of the MHC-PMS

Behavioural models: Behavioral models are models of the dynamic behavior of a system
as it is executing. They show what happens or what is supposed to happen when a system
responds to a stimulus from its environment. Two types of stimuli:

 Some data arrives that has to be processed by the system.

 Some event happens that triggers system processing. Events may have associated
data, although this is not always the case.

Based on the stimulus Behavioural models are classified into two models.

Data-driven model:

Many business systems are data-processing systems that are primarily driven by data. They are
controlled by the data input to the system, with relatively little external event processing. Data-
driven models show the sequence of actions involved in processing input data and generating
an associated output. They are particularly useful during the analysis of requirements as they
can be used to show end-to-end processing in a system. Data-driven models can be created
using UML activity diagrams:

An activity model of the insulin pump’s operation

An activity model of the insulin pump’s operation

Data-driven models can also be created using UML sequence diagrams

 An activity model of the order processing

Event-driven models: Real-time systems are often event-driven, with minimal data
processing. For example, a landline phone switching system responds to events such as
'receiver off hook' by generating a dial tone. Event-driven models shows how a system
responds to external and internal events. It is based on the assumption that a system has a finite
number of states and that events (stimuli) may cause a transition from one state to another.
Event-driven models can be created using UML state diagrams:
 State machine models are used represent the Event-driven models. In this states are
represents with node and events are represents with arcs.
 State diagrams show system states and events that cause transitions from one state to
another.
 They do not show the flow of data within the system but may include additional
information on the computations carried out in each state.
 The sequence of actions in using the microwave is:
1. Select the power level (either half power or full power).
2. Input the cooking time using a numeric keypad.
3. Press Start and the food is cooked for the given time.
 From fig , it can be seen that the system starts in a waiting state and responds
Initially to either the full-power or the half-power button.
 Users can change their mind after selecting one of these and press the other button.
 The time is set and, if the door is closed, the Start button is enabled. Pushing this
button starts the oven operation and cooking takes place for the specified time.
  This is the end of the cooking cycle and the system returns to the waiting state.
 Figure shows a tabular description of each state and how the stimuli that force
state transitions are generated.

State diagram of a microwave oven

States and stimuli for the microwave oven:

Micro oven operation
Advantages :

 Behavior and working of a system can easily be understood without any effort.
 Results are more accurate by using this model.
 This model requires less cost for development as cost of resources can be minimal.
 It focuses on behavior of a system rather than theories.

Disadvantages:

 This model does not have any theory, so trainee is not able to fully understand basic
principle and major concept of modeling.
 This modeling cannot be fully automated.
 Sometimes, it’s not easy to understand overall result.
 Does not achieve maximum productivity due to some technical issues or any errors.