UNIT-4

Software Requirement Engineering

4. 1 Software Requirements:

The collection of software requirements is the basis of the entire software

development project. Hence, they should be clear, correct, and well-defined.

A complete Software Requirement Specifications should be:

o Clear

o Correct

o Consistent

o Understandable

o Modifiable

o Verifiable

o Prioritized

o Unambiguous

o Traceable

o Credible source

Software Requirements: Largely software requirements must be categorized into two

categories:

1. Functional Requirements: These are the requirements that define the functions and
features of the software system. They describe what the software should do, and how

it should behave when specific user actions or inputs are provided. Functional
requirements are often documented as use cases or user stories.

2. Non-functional Requirements: These requirements define the quality attributes of

the software system, such as performance, reliability, scalability, usability, security, and
 compatibility. Non-functional requirements are critical for ensuring that the software
meets the user’s needs and expectations.

Non-functional requirements are divided into two main categories:

o Execution qualities like security and usability, which are observable at run

time.

o Evolution qualities like testability, maintainability, extensibility, and scalability

that are embodied in the static structure of the software system.

4. 2 Requirement Engineering:

Requirements engineering (RE) refers to the process of defining, documenting, and

maintaining requirements in the engineering design process.

Requirement engineering provides the appropriate mechanism to understand what

the customer desires, analyze the need, and assessing feasibility, negotiate a
reasonable solution, specify the solution clearly, validate the specifications, and
manage the requirements as they are transformed into a working system. Thus,
requirement engineering is the disciplined application of proven principles, methods,
tools, and notation to describe a proposed system's intended behavior and its
associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study

2. Requirement Elicitation and Analysis

3. Software Requirement Specification

4. Software Requirement Validation

5. Software Requirement Management

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.

Types of Feasibility:Play Video

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

are needed to accomplish customer requirements within the time and budget.

2. Operational Feasibility - 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:

This is also known as the gathering of requirements. Here, requirements are

identified with the help of customers and existing systems processes, if available.

Analysis of requirements starts with requirement elicitation. The requirements are

analyzed to identify inconsistencies, defects, omissions, etc. We describe requirements
in terms of relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis:

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

o Stakeholders often don't know what they want

o Stakeholders express requirements in their terms.

o Stakeholders may have conflicting requirements.

o Requirement change during the analysis process.

o Organizational and political factors may influence system requirements.

3. Software Requirement Specification:

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

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

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

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

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this

document are validated. The user might demand illegal, impossible solution or experts
may misinterpret the needs. Requirements can be the check against the following
conditions -
 o If they can practically implement

o If they are correct and as per the functionality and specially of software

o If there are any ambiguities

o If they are full

o If they can describe

Requirements Validation Techniques:

o Requirements reviews/inspections: systematic manual analysis of the requirements.

o Prototyping: Using an executable model of the system to check requirements.

o Test-case generation: Developing tests for requirements to check testability.

o Automated consistency analysis: checking for the consistency of structured

requirements descriptions.

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

4.3 Extraction and Specification:

4.4 Feasibility Study:

4.5 Requirements Modelling:

Requirements modelling is the development projects where requirements and solutions

constantly change through collaborative efforts and teamwork . By using this method of cross-
functional and self-organizing teams, you can ensure that your team meets the exact needs of
the stakeholders.

Requirement modeling strategies

Following are the requirement modelling strategies:

1. Flow Oriented Modelling
2. Class-based Modelling

1. Flow Oriented Modelling:

It shows how data objects are transformed by processing the function.

The Flow oriented elements are:

i. Data flow model

 It is a graphical technique. It is used to represent information flow.
 The data objects are flowing within the software and transformed by
processing the elements.
 The data objects are represented by labeled arrows. Transformation
are represented by circles called as bubbles.
 DFD shown in a hierarchical fashion. The DFD is split into different
levels. It also called as 'context level diagram'.
ii. Control flow model
 Large class applications require control flow modelling.
 The application creates control information instated of reports or
displays.
 The applications process the information in a specified time.
 An event is implemented as a Boolean value.
For example, the Boolean values are true or false, on or off, 1 or 0.
iii. Control Specification
 A short term for control specification is CSPEC.
  It represents the behavior of the system.
 The state diagram in CSPEC is a sequential specification of the behavior.
 The state diagram includes states, transitions, events, and activities.
 State diagram shows the transition from one state to another state if a
particular event has occurred.
iv. Process Specification
 A short term for process specification is PSPEC.
 The process specification is used to describe all flow model processes.
 The content of process specification consists narrative text, Program
Design Language(PDL) of the process algorithm, mathematical
equations, tables or UML activity diagram.

2. Class-based Modeling:

 Class based modeling represents the object. The system manipulates

the operations.
 The elements of the class based model consist of classes and object,
attributes, operations, class – responsibility - collaborator (CRS)
models.
Classes
Classes are determined using underlining each noun or noun clause and enter
it into the simple table.

Classes are found in following forms:

 External entities: The system, people or the device generates the
information that is used by the computer based system.
 Things: The reports, displays, letter, signal are the part of the
information domain or the problem.
 Occurrences or events: A property transfer or the completion of a
series or robot movements occurs in the context of the system
operation.
 Roles: The people like manager, engineer, salesperson are interacting
with the system.
 Organizational units: The division, group, team are suitable for an
application.
 Places: The manufacturing floor or loading dock from the context of the
problem and the overall function of the system.
  Structures: The sensors, computers are defined a class of objects or
related classes of objects.
Attributes
Attributes are the set of data objects that are defining a complete class within
the context of the problem.
For example, 'employee' is a class and it consists of name, Id, department,
designation and salary of the employee are the attributes.

Operations
The operations define the behaviour of an object.

The operations are characterized into following types:

 The operations manipulate the data like adding, modifying, deleting and
displaying etc.
 The operations perform a computation.
 The operation monitors the objects for the occurrence of controlling an
event.
CRS Modeling
 The CRS stands for Class-Responsibility-Collaborator.
 It provides a simple method for identifying and organizing the classes
that are applicable to the system or product requirement.
 Class is an object-oriented class name. It consists of information about
sub classes and super class.
 Responsibilities are the attributes and operations that are related to the
class.
 Collaborations are identified and determined when a class can achieve
each responsibility of it. If the class cannot identify itself, then it needs
to interact with another class.

Behavioral patterns for requirement modeling

Behavioral model shows the response of software to an external event.

Steps for creating behavioral patterns for requirement modeling as

follows:
 Evaluate all the use cases to completely understand the sequence,
interaction within the system.
 Identify the event and understand the relation between the specific
event.
 Generate a sequence for each use case.
 Construct a state diagram for the system.
  To verify the accuracy and consistency review the behavioral model.

Software Requirement Specification (SRS)

 The requirements are specified in specific format known as SRS.

 This document is created before starting the development work.
 The software requirement specification is an official document.
 It shows the detail about the performance of expected system.
 SRS indicates to a developer and a customer what is implemented in
the software.
 SRS is useful if the software system is developed by the outside
contractor.
 SRS must include an interface, functional capabilities, quality, reliability,
privacy etc.

Characteristics of SRS

 The SRS should be complete and consistence.

 The modification like logical and hierarchical must be allowed in SRS.
 The requirement should be easy to implement.
 Each requirement should be uniquely identified.
 The statement in SRS must be unambiguous means it should have only
one meaning.
 All the requirement must be valid for the specified project.

4.6 Object Oriented Analysis:

In the system analysis or object-oriented analysis phase of software development, the system
requirements are determined, the classes are identified and the relationships among classes are
identified.
The three analysis techniques that are used in conjunction with each other for object-oriented
analysis are object modelling, dynamic modelling, and functional modelling.

Object Modelling
Object modelling develops the static structure of the software system in terms of objects. It
identifies the objects, the classes into which the objects can be grouped into and the
relationships between the objects. It also identifies the main attributes and operations that
characterize each class.
The process of object modelling can be visualized in the following steps −

 Identify objects and group into classes

 Identify the relationships among classes
 Create user object model diagram
 Define user object attributes
 Define the operations that should be performed on the classes
 Review glossary

Dynamic Modelling
After the static behavior of the system is analyzed, its behavior with respect to time and
external changes needs to be examined. This is the purpose of dynamic modelling.
Dynamic Modelling can be defined as “a way of describing how an individual object responds
to events, either internal events triggered by other objects, or external events triggered by the
outside world”.
The process of dynamic modelling can be visualized in the following steps −

 Identify states of each object

 Identify events and analyze the applicability of actions
 Construct dynamic model diagram, comprising of state transition diagrams
 Express each state in terms of object attributes
 Validate the state–transition diagrams drawn

Functional Modelling
Functional Modelling is the final component of object-oriented analysis. The functional model
shows the processes that are performed within an object and how the data changes as it moves
between methods. It specifies the meaning of the operations of object modelling and the
actions of dynamic modelling. The functional model corresponds to the data flow diagram of
traditional structured analysis.
The process of functional modelling can be visualized in the following steps −

 Identify all the inputs and outputs

 Construct data flow diagrams showing functional dependencies
 State the purpose of each function
 Identify constraints
 Specify optimization criteria