UNIT- II

Software Requirements- Requirements Engineering Process, Classification of

Software Requirements, Eliciting Requirements, Developing Use Cases, Requirement
Analysis and Modeling, Characteristics of a Good Software, Software Requirement &
Specification Document (SRS).

Understanding Requirements
REQUIREMENTS ENGINEERING
Requirements analysis, also called requirements engineering, is the process of
determining user expectations for a new or modified product. Requirements engineering is a
major software engineering action that begins during the communication activity and
continues into the modeling activity. It must be adapted to the needs of the process, the project,
the product, and the people doing the work. Requirements engineering builds a bridge to design
and construction.
Requirements engineering provides the appropriate mechanism for understanding what
the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution,
specifying the solution unambiguously, validating the specification, and managing the
requirements as they are transformed into an operational system. It encompasses seven distinct
tasks: inception, elicitation, elaboration, negotiation, specification, validation, and
management.
Inception : It establish a basic understanding of the problem, the people who want a solution,
the nature of the solution that is desired, and the effectiveness of preliminary communication and
collaboration between the other stakeholders and the software team.
Elicitation: In this stage, proper information is extracted to prepare to document the
requirements. It certainly seems simple enough—ask the customer, the users, and others what the
objectives for the system or product are, what is to be accomplished, how the system or product
fits into the needs of the business, and finally, how the system or product is to be used on a day-
to-day basis.
• Problems of scope. The boundary of the system is ill-defined or the customers/users
specify unnecessary technical detail that may confuse, rather than clarify, overall system
objectives.
• Problems of understanding. The customers/users are not completely sure of what is
needed, have a poor understanding of the capabilities and limitations of their computing
environment, don’t have a full understanding of the problem domain, have trouble
communicating needs to the system engineer, omit information that is believed to be
“obvious,” specify requirements that conflict with the needs of other customers/users, or
specify requirements that are ambiguous or un testable.
• Problems of volatility. The requirements change over time.
Elaboration: The information obtained from the customer during inception and elicitation is
expanded and refined during elaboration. This task focuses on developing a refined requirements
model that identifies various aspects of software function, behavior, and information. Elaboration
is driven by the creation and refinement of user scenarios that describe how the end user (and
other actors) will interact with the system.

Negotiation: To negotiate the requirements of a system to be developed, it is necessary to

identify conflicts and to resolve those conflicts. You have to reconcile these conflicts through a
process of negotiation. Customers, users, and other stakeholders are asked to rank requirements
and then discuss conflicts in priority. Using an iterative approach that prioritizes requirements,
assesses their cost and risk, and addresses internal conflicts, requirements are eliminated,
combined, and/or modified so that each party achieves some measure of satisfaction.

Specification: The term specification means different things to different people. A

specification can be a written document, a set of graphical models, a formal mathematical model,
a collection of usage scenarios, a prototype, or any combination of these.
Validation: The work products produced as a consequence of requirements engineering are
assessed for quality during a validation step. Requirements validation examines the specification
to ensure that all software requirements have been stated unambiguously; that inconsistencies,
omissions, and errors have been detected and corrected; and that the work products conform to
the standards established for the process, the project, and the product.
The primary requirements validation mechanism is the technical review. The review
team that validates requirements includes software engineers, customers, users, and other
stakeholders who examine the specification looking for errors in content or interpretation, areas
where clarification may be required, missing information, inconsistencies, conflicting
requirements, or unrealistic requirements.
Requirements management. Requirements for computer-based systems change, and the desire
to change requirements persists throughout the life of the system. Requirements management is a
set of activities that help the project team identify, control, and track requirements and changes
to requirements at any time as the project proceeds. Many of these activities are identical to the
software configuration management (SCM) techniques.

Classification of Software Requirements

According to IEEE standard 729, a requirement is defined as follows:
A condition or capability needed by a user to solve a problem or achieve an objective
A condition or capability that must be met or possessed by a system or system component to
satisfy a contract, standard, specification or other formally imposed documents
A documented representation of a condition or capability as in 1 and 2.
Main types of software requirement can be of 3 types:
 Functional requirements
 Non-functional requirements
 Domain requirements
Functional Requirements: These are the requirements that the end user specifically demands as
basic facilities that the system should offer. 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. All these functionalities need to be necessarily incorporated into the
system as a part of the contract. These are represented or stated in the form of input to be given
to the system, the operation performed and the output expected. They are basically the
requirements stated by the user which one can see directly in the final product, unlike the non-
functional requirements. For example, in a hospital management system, a doctor should be able
to retrieve the information of his patients. Each high-level functional requirement may involve
several interactions or dialogues between the system and the outside world. In order to accurately
describe the functional requirements, all scenarios must be enumerated. There are many ways of
expressing functional requirements e.g., natural language, a structured or formatted language
with no rigorous syntax and formal specification language with proper syntax. Functional
Requirements in Software Engineering are also called Functional Specification.
Non-functional requirements: These are basically the quality constraints that the system must
satisfy according to the project contract.Nonfunctional requirements, not related to the system
functionality, rather define how the system should perform The priority or extent to which these
factors are implemented varies from one project to other. They are also called non-behavioral
requirements. They basically deal with issues like:
  Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility
NFR’s are classified into following types:
 Interface constraints
 Performance constraints: response time, security, storage space, etc.
 Operating constraints
 Life cycle constraints: maintainability, portability, etc.
 Economic constraints
The process of specifying non-functional requirements requires the knowledge of the
functionality of the system, as well as the knowledge of the context within which the system will
operate.
They are divided into two main categories: Execution qualities like security and usability, which
are observable at run time. Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software system.
Domain requirements: Domain requirements are the requirements which are characteristic of a
particular category or domain of projects. Domain requirements can be functional or
nonfunctional. Domain requirements engineering is a continuous process of proactively defining
the requirements for all foreseeable applications to be developed in the software product line.
The basic functions that a system of a specific domain must necessarily exhibit come under this
category. For instance, in an academic software that maintains records of a school or college, the
functionality of being able to access the list of faculty and list of students of each grade is a
domain requirement. These requirements are therefore identified from that domain model and are
not user specific.
Other common classifications of software requirements can be:
User requirements: These requirements describe what the end-user wants from the software
system. User requirements are usually expressed in natural language and are typically gathered
through interviews, surveys, or user feedback.
System requirements: These requirements specify the technical characteristics of the software
system, such as its architecture, hardware requirements, software components, and interfaces.
System requirements are typically expressed in technical terms and are often used as a basis for
system design.
Business requirements: These requirements describe the business goals and objectives that the
software system is expected to achieve. Business requirements are usually expressed in terms of
revenue, market share, customer satisfaction, or other business metrics.
Regulatory requirements: These requirements specify the legal or regulatory standards that the
software system must meet. Regulatory requirements may include data privacy, security,
accessibility, or other legal compliance requirements.
Interface requirements: These requirements specify the interactions between the software system
and external systems or components, such as databases, web services, or other software
applications.
Design requirements: These requirements describe the technical design of the software system.
They include information about the software architecture, data structures, algorithms, and other
technical aspects of the software.
Requirements elicitation
Requirements elicitation is the process of gathering and defining the requirements for a software
system. The goal of requirements elicitation is to ensure that the software development process is
based on a clear and comprehensive understanding of the customer’s needs and requirements.
Requirements elicitation involves the identification, collection, analysis, and refinement of the
requirements for a software system. It is a critical part of the software development life cycle and
is typically performed at the beginning of the project. Requirements elicitation involves
stakeholders from different areas of the organization, including business owners, end-users, and
technical experts. The output of the requirements elicitation process is a set of clear, concise, and
well-defined requirements that serve as the basis for the design and development of the software
system.
Requirements elicitation is perhaps the most difficult, most error-prone, and most
communication-intensive software development. It can be successful only through an effective
customer-developer partnership. It is needed to know what the users really need.
Requirements elicitation Activities:
Requirements elicitation includes the subsequent activities. Few of them are listed below –
 Knowledge of the overall area where the systems is applied.
 The details of the precise customer problem where the system is going to be
applied must be understood.
 Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.
Requirements elicitation Methods:
There are a number of requirements elicitation methods. Few of them are listed below –
 Interviews
 Brainstorming Sessions
 Facilitated Application Specification Technique (FAST)
 Quality Function Deployment (QFD)
 Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst, developers,
users, and the customer involved.
1. Interviews:
 Objective of conducting an interview is to understand the customer’s
expectations from the software.
It is impossible to interview every stakeholder hence representatives from
groups are selected based on their expertise and credibility.
 Interviews maybe be open-ended or structured.
 In open-ended interviews there is no pre-set agenda. Context free questions may
be asked to understand the problem.
 In structured interview, agenda of fairly open questions is prepared. Sometimes
a proper questionnaire is designed for the interview.
2. Brainstorming Sessions:
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share
 views
 A highly trained facilitator is required to handle group bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and
their priority if possible.
3. Facilitated Application Specification Technique:

Its objective is to bridge the expectation gap – the difference between what the developers think
they are supposed to build and what customers think they are going to get. A team-oriented
approach is developed for requirements gathering. Each attendee is asked to make a list of
objects that are-
Part of the environment that surrounds the system
Produced by the system
Used by the system
Each participant prepares his/her list, different lists are then combined, redundant entries are
eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally a
draft of specifications is written down using all the inputs from the meeting.
4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it emphasizes on the
requirements which are valuable to the customer.
3 types of requirements are identified –
Normal requirements –
In this the objective and goals of the proposed software are discussed with the customer.
Example – normal requirements for a result management system may be entry of marks,
calculation of results, etc
Expected requirements –
These requirements are so obvious that the customer need not explicitly state them. Example –
protection from unauthorized access.
Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be very satisfying when
present. Example – when unauthorized access is detected, it should backup and shutdown all
processes.
 The major steps involved in this procedure are –
 Identify all the stakeholders, eg. Users, developers, customers etc
 List out all requirements from customer.
 A value indicating degree of importance is assigned to each requirement.
 In the end the final list of requirements is categorized as –
 It is possible to achieve
 It should be deferred and the reason for it
 It is impossible to achieve and should be dropped off
5. Use Case Approach:
This technique combines text and pictures to provide a better understanding of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional
view of the system.
The components of the use case design includes three major things – Actor, Use cases, use case
diagram.
Actor –
It is the external agent that lies outside the system but interacts with it in some way. An actor
maybe a person, machine etc. It is represented as a stick figure. Actors can be primary actors or
secondary actors.
Primary actors – It requires assistance from the system to achieve a goal.
Secondary actor – It is an actor from which the system needs assistance.
Use cases –
They describe the sequence of interactions between actors and the system. They capture
who(actors) do what(interaction) with the system. A complete set of use cases specifies all
possible ways to use the system.
Use case diagram –
A use case diagram graphically represents what happens when an actor interacts with a system. It
captures the functional aspect of the system.
A stick figure is used to represent an actor.
An oval is used to represent a use case.
A line is used to represent a relationship between an actor and a use case.
Designing Use Cases for a Project
How to plan use case?
Following example will illustrate on how to plan use cases:
Use Case: What is the main objective of this use case. For eg. Adding a software component, adding
certain functionality etc.
Primary Actor: Who will have the access to this use case. In the above examples, administrators will have
the access.
Scope: Scope of the use case
Level: At what level the implementation of the use case be.
Flow: What will be the flow of the functionality that needs to be there. More precisely, the work flow of
the use case.
Some other things that can be included in the use cases are:
 Preconditions
 Postconditions
 Brief course of action
 Time Period
Use Case Diagram
Below is a sample use case diagram which I have prepared for reference purpose for a sample project
(much like Facebook). It would help us to understand the role of various actors in our project. Various
actors in the below use case diagram are: User and System.
The main use cases are in the system and the diagram illustrates on how the actors interact with the use
cases.For eg. During Sign Up, only users need to interact with the use case and not the system whereas
when it comes to categorizing posts, only system would be required.
Elements of the Requirements Model

Requirements for a computer-based system can be seen in many different ways. Some software people argue
that it’s worth using a number of different modes of representation while others believe that it’s best to select
one mode of representation.
The specific elements of the requirements model are dedicated to the analysis modeling method that is to be
used.
Scenario-based elements :
Using a scenario-based approach, system is described from user’s point of view. For example, basic use cases
and their corresponding use-case diagrams evolve into more elaborate template-based use cases. Figure 1(a)
depicts a UML activity diagram for eliciting requirements and representing them using use cases. There are
three levels of elaboration.
Class-based elements :
A collection of things that have similar attributes and common behaviors i.e., objects are categorized into
classes. For example, a UML case diagram can be used to depict a Sensor class for the SafeHome security
function. Note that diagram lists attributes of sensors and operations that can be applied to modify these
attributes. In addition to class diagrams, other analysis modeling elements depict manner in which classes
collaborate with one another and relationships and interactions between classes.

Behavioral elements :
Effect of behavior of computer-based system can be seen on design that is chosen and implementation
approach that is applied. Modeling elements that depict behavior must be provided by requirements model.

Figure 1(a):UML activity diagrams for eliciting requirements

 Class diagram for sensor

Method for representing behavior of a system by depicting its states and events that cause system to change
state is state diagram. A state is an externally observable mode of behavior. In addition, state diagram
indicates actions taken as a consequence of a particular event.

To illustrate use of a state diagram, consider software embedded within safeHome control panel that is
responsible for reading user input. A simplified UML state diagram is shown in figure 2.

Figure 2: UML state diagram notation

Flow-oriented elements :
As it flows through a computer-based system information is transformed. System accepts input, applies
functions to transform it, and produces output in a various forms. Input may be a control signal transmitted
by a transducer, a series of numbers typed by human operator, a packet of information transmitted on a
network link, or a voluminous data file retrieved from secondary storage. Transform may compromise a
single logical comparison, a complex numerical algorithm, or a rule-inference approach of an expert system.
Output produce a 200-page report or may light a single LED. In effect, we can create a flow model for any
computer-based system, regardless of size and complexity.

Analysis Modelling in Software Engineering

Analysis Model is a technical representation of the system. It acts as a link between system
description and design model. In Analysis Modelling, information, behavior, and functions of the
system are defined and translated into the architecture, component, and interface level design in
the design modeling.
Objectives of Analysis Modelling:
It must establish a way of creating software design.
It must describe the requirements of the customer.
It must define a set of requirements that can be validated, once the software is built.

Elements of Analysis Model:

Data Dictionary:
It is a repository that consists of a description of all data objects used or produced by the
software. It stores the collection of data present in the software. It is a very crucial element of the
analysis model. It acts as a centralized repository and also helps in modeling data objects defined
during software requirements.

Entity Relationship Diagram (ERD):

It depicts the relationship between data objects and is used in conducting data modeling activities.
The attributes of each object in the Entity-Relationship Diagram can be described using Data
object description. It provides the basis for activity related to data design.

Data Flow Diagram (DFD):

It depicts the functions that transform data flow and it also shows how data is transformed when
moving from input to output. It provides the additional information which is used during the
analysis of the information domain and serves as a basis for the modeling of function. It also
enables the engineer to develop models of functional and information domains at the same time.

State Transition Diagram:

It shows various modes of behavior (states) of the system and also shows the transitions from
one state to another state in the system. It also provides the details of how the system behaves
due to the consequences of external events. It represents the behavior of a system by presenting
its states and the events that cause the system to change state. It also describes what actions are
taken due to the occurrence of a particular event.

Process Specification:
It stores the description of each function present in the data flow diagram. It describes the input
to a function, the algorithm that is applied for the transformation of input, and the output that is
produced. It also shows regulations and barriers imposed on the performance characteristics that
are applicable to the process and layout constraints that could influence the way in which the
process will be implemented.

Control Specification:
 It stores additional information about the control aspects of the software. It is used to indicate
how the software behaves when an event occurs and which processes are invoked due to the
occurrence of the event. It also provides the details of the processes which are executed to
manage events.

Data Object Description:

It stores and provides complete knowledge about a data object present and used in the software.
It also gives us the details of attributes of the data object present in the Entity Relationship
Diagram. Hence, it incorporates all the data objects and their attributes.

Characteristics of good Software

Software is treated as a good software by the means of different factors. A software product is concluded as a
good software by what it offers and how well it can be used. The factors that decide the software properties
are divided into three categories: Operational, Transitional, and Maintenance. These are explained as
following below.
Software engineering is the process of designing, developing, and maintaining software systems. A good
software is one that meets the needs of its users, performs its intended functions reliably, and is easy to
maintain. There are several characteristics of good software that are commonly recognized by software
engineers, which are important to consider when developing a software system. These characteristics include
functionality, usability, reliability, performance, security, maintainability, reusability, scalability, and
testability.

1. Operational: In operational categories, the factors that decide the software performance in operations. It
can be measured on:
  Budget
 Usability
 Efficiency
 Correctness
 Functionality
 Dependability
 Security
 Safety
2. Transitional: When the software is moved from one platform to another, the factors deciding the software
quality:

 Portability
 Interoperability
 Reusability
 Adaptability
3. Maintenance: In this categories all factors are included that describes about how well a software has the
capabilities to maintain itself in the ever changing environment:
 Modularity
 Maintainability
 Flexibility
 Scalability
Good software is characterized by several key attributes, including:
Functionality: The software meets the requirements and specifications that it was designed for, and it
behaves as expected when it is used in its intended environment.
Usability: The software is easy to use and understand, and it provides a positive user experience.
Reliability: The software is free of defects and it performs consistently and accurately under different
conditions and scenarios.
Performance: The software runs efficiently and quickly, and it can handle large amounts of data or traffic.
Security: The software is protected against unauthorized access and it keeps the data and functions safe from
malicious attacks.
Maintainability: The software is easy to change and update, and it is well-documented, so that it can be
understood and modified by other developers.
Reusability: The software can be reused in other projects or applications, and it is designed in a way that
promotes code reuse.
Scalability: The software can handle an increasing workload and it can be easily extended to meet the
changing requirements.
Testability: The software is designed in a way that makes it easy to test and validate, and it has a
comprehensive test coverage.
By adhering to these characteristics, software engineers can develop software that is functional, reliable, and
maintainable, thus providing the best experience to the end-users.

Software Requirement Specification (SRS) Format

In order to form a good SRS, here you will see some points which can be used and should be considered to
form a structure of good SRS. These are as follows :
1. Introduction
(i) Purpose of this document
(ii) Scope of this document
(iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
Software Requirement Specification (SRS) Format as name suggests, is complete specification and
description of requirements of software that needs to be fulfilled for successful development of software
system. These requirements can be functional as well as non-functional depending upon type of requirement.
The interaction between different customers and contractor is done because its necessary to fully understand
needs of customers. Depending upon information gathered after
interaction, SRS is developed which describes requirements of software that may include changes and
modifications that is needed to be done to increase quality of product and to satisfy customer’s demand.
Introduction :
(i) Purpose of this Document – At first, main aim of why this document is necessary and what’s purpose of
document is explained and described.
(ii) Scope of this document – In this, overall working and main objective of document and what value it will
provide to customer is described and explained. It also includes a description of development cost and time
required.
(iii) Overview – In this, description of product is explained. It’s simply summary or overall review of product.
General description : In this, general functions of product which includes objective of user, a user
characteristic, features, benefits, about why its importance is mentioned. It also describes features of user
community.
Functional Requirements : In this, possible outcome of software system which includes effects due to
operation of program is fully explained. All functional requirements which may include calculations, data
processing, etc. are placed in a ranked order.
Interface Requirements : In this, software interfaces which mean how software program communicates with
each other or users either in form of any language, code, or message are fully described and explained.
Examples can be shared memory, data streams, etc.
Performance Requirements : In this, how a software system performs desired functions under specific
condition is explained. It also explains required time, required memory, maximum error rate, etc.
Design Constraints : In this, constraints which simply means limitation or restriction are specified and
explained for design team. Examples may include use of a particular algorithm, hardware and software
limitations, etc.
Non-Functional Attributes : In this, non-functional attributes are explained that are required by software
system for better performance. An example may include Security, Portability, Reliability, Reusability,
Application compatibility, Data integrity, Scalability capacity, etc.
Preliminary Schedule and Budget : In this, initial version and budget of project plan are explained which
include overall time duration required and overall cost required for development of project.
Appendices : In this, additional information like references from where information is gathered, definitions
of some specific terms, acronyms, abbreviations, etc. are given and explained.
Uses of SRS document:
 Development team require it for developing product according to the need.
 Test plans are generated by testing group based on the describe external behavior.
 Maintenance and support staff need it to understand what the software product is
supposed to do.
 Project manager base their plans and estimates of schedule, effort and resources on it.
 customer rely on it to know that product they can expect.
 As a contract between developer and customer.
 in documentation purpose.