Unit 4 Software Requirement Analysis & Specification

4.1. 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,
analyzing the need, and assessing feasibility, negotiating a reasonable solution,
specifying the solution clearly, validating the specifications and managing the
requirements as they are transformed into a working system.

4.2. Requirement 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.
4.2.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.
1. In open-ended interviews there is no pre-set agenda. Context free questions may be
asked to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.

4.2.2. Brainstorming series

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

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

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

2. 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.
3. 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.

4.3. Requirement analysis

4.3.1. Data flow diagram

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system
requirement graphically. It can be manual, automated, or a combination of both.

It shows how data enters and leaves the system, what changes the information, and
where data is stored. The objective of a DFD is to show the scope and boundaries of a
system as a whole. It may be used as a communication tool between a system analyst
and any person who plays a part in the order that acts as a starting point for
redesigning a system. The DFD is also called as a data flow graph or bubble chart.
4.3.2. Data dictionary
A data dictionary is a file or a set of files that includes a database's metadata. The data
dictionary hold records about other objects in the database, such as data ownership,
data relationships to other objects, and other data. The data dictionary is an essential
component of any relational database.
The data dictionary, in general, includes information about the following:
Name of the data item

Aliases include other names by which this data item is called DEO for Data Entry
Operator and DR for Deputy Registrar.

Description/purpose is a textual description of what the data item is used for or why it
exists.

Related data items capture relationships between data items e.g., total_marks must
always equal to internal_marks plus external_marks.

Range of values records all possible values, e.g. total marks must be positive and
between 0 to 100.

Data structure Forms: Data flows capture the name of processes that generate or
receive the data items. If the data item is primitive, then data structure form captures the
physical structures of the data item. If the data is itself a data aggregate, then data
structure form capture the composition of the data items in terms of other data items.

4.3.3. Entity-Relationship diagram

An Entity Relationship Diagram (ERD) is a visual representation of different entities within a system
and how they relate to each other. It is a tool used to design and model relational databases, and
shows the logical structure of the database. ER diagrams are commonly used in software engineering
and database design to help developers and stakeholders understand and design complex databases .
Components of an ER Diagrams

Entity: An entity can be a real-world object, either animate or inanimate, that can be
merely identifiable. An entity is denoted as a rectangle in an ER diagram.

Attributes: Entities are denoted utilizing their properties, known as attributes. All
attributes have values.

Relationships: The association among entities is known as relationship. Relationships

are represented by the diamond-shaped box.

4.4. Requirement documentation

4.4.1. Nature of SRS

1. Functionality: What the software is supposed to do?

2. External Interfaces: How does the software interact with people, system's hardware, other hardware
and other software?

3. Performance: What is the speed, availability, response time, recovery time etc.

4. Attributes: What are the considerations for portability, correctness, maintainability, security, reliability
etc.
5. Design Constraints Imposed on an Implementation: Are there any required standards in effect,
implementation language, policies for database integrity, resource limits, operating environment etc.

4.4.2. Characteristics of a good SRS

A software requirements specification (SRS) is a document that describes what the
software will do and how it will be expected to perform. It also describes the functionality
the product needs to fulfill the needs of all stakeholders (business, users).
1. Completeness: The SRS should include all the requirements for the software
system, including both functional and non-functional requirements.
2. Correctness: SRS is said to be correct if it covers all the requirements that are
actually expected from the system.
3. Consistent: The SRS should be consistent in its use of terminology and
formatting, and should be free of contradictions.
4. Unambiguous: The SRS should be clear and specific, and should avoid using
vague or imprecise language.
5. 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.
6. Verifiable: The SRS should be verifiable, which means that the requirements can
be tested and validated to ensure that they are being met.
7. Modifiable: The SRS should be modifiable, so that it can be updated and
changed as the software development process progresses.
8. Prioritized: The SRS should prioritize requirements, so that the most important
requirements are addressed first.
9. Testable: The SRS should be written in a way that allows the requirements to be
tested and validated.

4.4.3. Organization of SRS

Organizing an SRS is important to ensure clarity, completeness, and ease of
understanding for all stakeholders involved in the software development process. Here's
a typical organization structure for an SRS in software engineering:
1. Introduction:
- Purpose
- Scope
- Definitions, Acronyms, and Abbreviations

2. Overall Description:
- Product Perspective
- Product Functions
- User Characteristics
 - Constraints
- Assumptions and Dependencies

3. Specific Requirements:
- Functional Requirements
- Non-Functional Requirements
- External Interface Requirements
- System Features
- Data Requirements
- Performance Requirements
- Security Requirements
- Software Quality Attributes
- Design Constraints

4. Other Requirements:
- Documentation Requirements
- Legal and Regulatory Requirements
- Support and Maintenance Requirements