SOFTWARE ENGINEERING

UNIT – II
SOFTWARE REQUIREMENTS ANALYSIS & SPECIFICATION

IEEE defines a Requirement as “A condition of capability needed by a user to solve a

problem or achieve an objective and A condition or a capability that must be met or
own by a system to satisfy a contract, standard, specification, or other formally
imposed document”.

 WHAT IS 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).

● A software requirements specification (SRS) is a detailed description of a software

system to be developed with its functional and non-functional requirements.

● The SRS is developed based the agreement between customer and contractors. It
may include the use cases of how user is going to interact with software system.

● The software requirement specification document consistent of all necessary

requirements required for project development. To develop the software system, we
should have clear understanding of Software system. To achieve this, we need good
communication with customers to gather all requirements.

Value of a Good SRS

● A good SRS defines the how Software System will interact with all internal modules,
hardware, communication with other programs and human user interactions with
wide range of real-life scenarios.
● Using the Software requirements specification (SRS) document on QA lead, managers
create test plan. It is very important that testers must be cleared with every detail
specified in this document in order to avoid faults in test cases and its expected results.

Concise: The SRS document should be unambiguous, consistent, and complete.

Structured: A well-structured SRS document is easy to understand and modify.

1
Black-Box View: SRS should only specify what the system should do and restrict from
stating how to do.

Conceptual Integrity: Conceptual integrity in the SRS helps the reader to easily
understand it.

Traceable: Traceability means it can tell which code part related to which design
component, which test case related to which requirement and which design component
related to which requirement etc.

Verifiable: All requirements of the system should be verifiable. This means it should
be possible to tell whether or not the requirement has been met as specified in the
SRS. An SRS establishes the basis for agreement between the client and the supplier
on what the software product will do.

The SRS Document: -

Section – I

Name of reviewer
Organization
Group Number
Date of review
Project title

2
Section – II
checklist for the SRS Document

S.No Description Yes/No/NA

Remarks

Introduction
1. Is the purpose of the project clearly defined?

2. Is scope clearly defined?

3. Is document format as per standard of IEEE?

4. Is the project approved by the customer?

5. Are all requirements, interfaces, constraints, definitions,

Listed in the appropriate sections?

Ambiguity

1. Are functional requirements separated from non-functional

Requirements?

2. Is any requirement conveying more than one interpretation?

3. Are all requirements clearly understandable?

4. Does any requirement conflict with or duplicate other

Requirements?

5. Are there ambiguous or implied requirements?

Completeness

1. Are all functional & non - functional requirement stated?

2. Are forms available with validity checks?

3. Are all reports available in the specified format?

4. Has analysis been performed to identify missing requirements?

Consistency

1. Are the requirements specified at a consistent level of detail?

2. Should any requirement be specified in more detail?

3. Should any requirement be specified in less detail?

4. Are the requirements consistent with other documents of the

Project?

3
 REQUIREMENT PROCESS
The requirement process is the sequence of activities that need to be performed in the
requirements phase and that result in producing a high-quality document containing
the SRS.
The requirements process typically consists of three basic tasks:
 problem or requirement analysis
 requirements specification
 requirements validation

Problem analysis
● Problem analysis is starts with a high-level “problem statement.” During analysis
the problem domain and the environment are modelled in an effort to understand the
system behaviour, constraints on the system, its inputs and outputs, etc.
● The basic purpose of this activity is to understanding of what the software needs to
provide. During analysis, the analyst will have a series of meetings with the clients
and end users.
● In the early meetings, the clients and end users will explain to the analyst about
their work, their environment, and their needs as they perceive them.
● In these early meetings, the analyst is basically the listener, absorbing the
information provided. Once the analyst understands the system to some extent, he
uses the next few meetings to seek clarifications of the parts he does not understand.

It is a four-step process, which includes –

1) Feasibility Study
2) Requirement Gathering
3) Software Requirement Specification
4) Software Requirement Validation

1) Feasibility study
● When the client go to the organization for getting the desired product developed, it
comes up with a 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 do a detailed study about whether the
desired system and its functionality are feasible to develop.

4
● This feasibility study is focused towards goal of the organization. This study analyses
whether the software product can be practically materialized in terms of
implementation, contribution of project to organization, cost, and as per values and
objectives of the organization.

2) Requirement Gathering
● If the feasibility report is positive towards doing 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.

3) Software Requirement Specification (SRS)

● SRS is a document created by system analyst after the requirements are collected
from customers, end users and project stakeholders.
● SRS defines how the software will interact with hardware, external interfaces, speed
of operation, response time of system, portability, maintainability, speed of recovery
after crashing, Security, Quality, Limitations etc.
SRS should come up with the following features:
1) User Requirements are expressed in natural language.
2) Technical requirements are expressed in structured language.
3) Design description should be written in Pseudo code.
4) Format of Forms and GUI screen prints.
5) Conditional and mathematical notations for DFDs etc.

4) Software Requirement Validation

● After requirement specifications are developed, the requirements mentioned in this
document are validated.
● User ask for illegal, impractical solution or experts may interpret the requirements
inaccurately. This results in huge increase in cost if not properly validated.
Requirements can be checked against following conditions -
a) If they can be practically implemented
b) If they are valid and as per functionality of software
c) If there are any ambiguities
d) If they are complete
e) If they can be demonstrated
5
 CHARACTERISTICS OF SRS
1. Correctness:
User review is used to ensure the correctness of requirements stated in the SRS. SRS is
correct if it covers all the requirements that are actually expected from the system.

2. Completeness:
Completeness of SRS indicates completion of the numbering of all the pages, resolving
the to be determined parts covers all the functional and non-functional requirements
properly.

3. Consistency:
Requirements in SRS are needs to be consistent. If conflicts like logical conflicts like
time period of report generation, etc. then SRS in inconsistent.

4. Unambiguousness:
An SRS is needs to be unambiguous if all the requirements stated have only 1
interpretation. Some of the ways to prevent unambiguousness include the use of
modelling techniques like ER diagrams, proper reviews and individual checks, etc.

6
5. Ranking for importance and stability:
There should be classification the requirements as less or more important or more
specifically as desirable or essential. An identifier mark can be used with every
requirement to indicate its rank or stability.

6. Modifiability:
SRS should be made as modifiable as possible and should be capable of easily accepting
changes to the system. Modifications should be properly indexed and cross-referenced.

7. Verifiability:
An SRS is verifiable means able to checked, if there exists a specific technique to able
to be measure every requirement is met by the system.

8. Traceability:
Traceability means it can tell which code part related to which design component,
which test case related to which requirement and which design component related to
which requirement etc.

9. Testability:
An SRS should be written in such a way that it is easy to generate test cases and test
plans from the document.

10. Understandable by the customer:

An end user maybe an expert in his/her specific domain but might not be an expert in
computer science. Hence, the use of formal notations and symbols. The language
should be kept easy and clear.

Types Of Errors in SRS

Let us consider the type of errors that typically occur in an SRS. Many different types
of errors are possible, but the most common errors classified in four types:
omission, inconsistency, incorrect fact, and ambiguity.

● Omission is a common error in requirements. In this type of error, some user

requirement is simply not included in the SRS; the omitted requirement may be related
to the behaviour of the system, its performance, limits, or any other factor.

7
 ● Another common form of error in requirements is inconsistency. Inconsistency can
be due to contradictions within the requirements themselves or to incompatibility of the
stated requirements with the actual requirements of the client.

● The third common requirement error is incorrect fact. Errors of this type occur when
some fact recorded in the SRS is not correct.
● The fourth common error type is ambiguity. Errors of this type occur when there are
some requirements that have multiple meanings, that is, their interpretation is not
unique.

 COMPONENTS OF AN SRS
The important parts of the Software Requirements Specification (SRS) document is:
1) Functional requirements of the system.
2) Non-functional requirements of the system.
3) Performance Requirements
4) Goals of implementation.

1) Functional Requirements:
● The purposeful requirement’s part discusses the functionalities needed from the
system; Functional requirements are response time, speed, availability, recovery time of
various software.
● So, the system is used to perform a group of high- level functions.
● The functional view of the system is, each function of the system can be considered
as a transformation of a set of input data to the corresponding set of output is
knowledge.

2) Non-functional Requirements:
● Non-functional requirements needed to live the characteristics of the system which
may not be expressed as functions – like the maintainability of the system, movability
of the system, the usability of the system, etc.

● Non-functional requirements also include:

a. Reliability issues
b. Accuracy of results
c. Human-computer interface issues
d. Constraints on the system implementation, etc.
8
3) Performance Requirements
● The performance requirements part of an SRS specifies the performance limits on the
software system.
● All the requirements relating to the performance characteristics of the system must
be clearly specified.
● There are two types of performance requirements: static and dynamic.

Static requirements These include requirements like the number of terminals to be

supported, the number of concurrent users to be supported, and the number of files
that the system has to process and their sizes.

Dynamic requirements
These typically include response time and constraints on the system. Response time is
the expected time for the completion of an operation.

4) Goals of Implementation:
● The goals of implementation part consisted some general suggestions relating to
development.
● The goals of the implementation section included document problems like revisions to
the system functionalities that will be needed within the future, new devices to be
supported within the future, reusability problems, etc. These are the things are also
need to implement if the developers not given the attention for to meet the requirements.

9
 FUNCTIONAL SPECIFICATION WITH USE CASES
● It is a graphic demonstration of business needs, which describe how the end-user will
cooperate with the software or the application.
● The use cases provide us all the possible techniques of how the end-user uses the
application.
● Use cases specify the functionality of a system by specifying the behaviour of the
system, captured as interactions of the users with the system.
● The use case is functional testing and it is used to identify the test cases from the
beginning to the end of the system as per the usage of the system. By using this
technique, the test team creates a test scenario that can exercise the entire software
based on the functionality of each function from start to end.

Types of Use Cases

A) Business use case
B) System use case

A) Business Use Case

● Business use cases are about what the user expects from the system. We write
business use cases at a high level; it is also known as abstract level use cases.
● It focuses on how the user achieves the goal with respect to the business operation. It
provides meaningful, observable results as it defines business performs.

B) System Use Case

● The system use case is about what the system does. System use cases are at a low
level, it is also known as implementation use cases.
● It referring to specific processes that different parts of the system perform to reach the
goal of the end-users.
● It contains detailed functional specifications, such as dependencies, important
internal supporting features and optional internal functionalities.

1) Elements in Use Cases

a) Actor: It refers to the user, it can be anyone who performs something in the system.
It can be the customer, admin, vendor, delivery associate etc.
b) System: It is a product, service or software under discussion.
c) Goal: It is the successful user outcome.

10
d) Stakeholder: It refers to a person who interacts to find out the behaviour of the
system.
e) Precondition: It is the condition the system needs to be before the workflow starts.
f) Triggers: It is the event that initiates the use case.
g) Main success scenario: It is the scenario in which nothing fails, it’s also known as
basic flow.
h) Alternative paths: It is a different path compared to the main scenario.
i) Post condition: It is the condition which the system should have completed by the
end of the steps.

Use Case Diagrams and Notations: -

1) System:
A specific sequence of actions and interactions between actors and the system.
2) Use-case:
Use cases are used to represent high-level functionalities and how the user will handle
the system. It is denoted by an oval shape with the name of a use case written inside
the oval shape.

3) Actors:
An actor is anyone who performs an action using your system. Actors or users can be
a person, an organization, or an external system.

11
 4) Relationships:

Include relationship between Use Cases s (one UC must

<< Include>>
call another UC)

<< extend>> Extend relationship between Use Cases (one UC calls

Another under certain condition)

Purpose of Use Case diagrams

The purposes of use case diagrams can be said to be as follows −
a) Used to gather the requirements of a system. These requirements are mostly
design requirements.
b) Identify the external and internal factors the system.
c) Show the interaction among the requirements are actors.
d) system is analysed to gather its functionalities.
e) When the initial task is complete, use case diagrams are modelled to present the
outside view.

 DEVELOPING USE CASES

● UCs not only document requirements, as their form is like storytelling and uses text,
both of which are easy and natural with different stakeholders, they also are a good
medium for discussion.
● UCs can also be used for requirements elicitation and problem analysis. While
developing use cases, informal or formal models may also be built.
● UCs can be evolved in a stepwise refinement manner with each step adding more
details. The actor-goal list counts the use cases and specifies the actors for each goal.

Some of the examples of the actors used in the case study of ‘University registration
system’.
Example: -1) case study of ‘University registration system’
A) Administrator
B) Student
C) Faculty
D) Data entry operator

12
The URS will allow the above actors to interact with the system with their specific
roles. Depending upon the role, an actor will be able to access only the defined
information from the system. We may define the role of every actor as:
A) Administrator: Able to add, modify or delete a programme, school, scheme, paper,
student, faculty and login information. Able to generate student registration card and
other reports.
B) Student: Able to add and modify his/her details and register for papers to be
studied in the current semester. Able to generate student registration card.
C) Faculty: Able to generate desired reports.
D) Data entry operator: Able to add, modify or delete student and faculty
information.

13
Creation of Use Case ‘University registration system’

S.No Use Case Actors Description

1. Login Administrator, student, faculty, DEO Login

Change Password

2. Maintain School Details Administrator Add school

Edit school

Delete school

View school

3. Maintain Programme details Administrator Add Programme

Edit Programme
Delete programme

View programme

4. Maintain Scheme Details Administrator Add scheme

Edit scheme

Delete scheme
View scheme

5. Maintain Student Registration Administrator, Student Add student info.

Details
6. Generate Report Administrator, faculty Roll no wise

Program wise

Semester wise

Paper wise

7. Generate Regis. Card Administrator, Student Printing Regis. Card

14
 Use Case Diagram depicting University Registration system

 OTHER APPROACHES FOR ANALYSIS

1) problem analysis
● The basic aim of problem analysis is to obtain a clear understanding of the needs of
the clients and the users, what exactly is desired from the software.
● The analysts have to ensure that the real needs of the clients and the users are
uncovered. The analysts are not just collecting and organizing information about the
client’s organization and its processes, but they also act as consultants who play an
active role of helping the clients and users identify their needs.
● The basic principle used in analysis is the same as in any complex task: divide and
conquer. That is, partition the problem into subproblems and then try to understand
each subproblem.

15
 2) state and projection
● A state of a system represents some conditions about the system. when using state,
a system is first viewed as operating in one of the several possible states, and then a
detailed analysis is performed for each state. This is used in real-time software.
● In projection, a system is defined from multiple points of view. While using
projection, different viewpoints of the system are defined and the system is then
analysed from these different views.

 DATA FLOW DIAGRAMS

● A Data Flow Diagram (DFD) is a 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 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 limitations of a system.
● It may be used as a communication tool between a system analyst and any person
who starting point for designing a system.
● The DFD is also called as a data flow graph or bubble chart.

Naming & Diagrammatic Conventions of DFDs:

1) All names should be unique. This makes it easier to refer to elements in the DFD.
these names are chosen so that they convey some meaning about what the data is.
2) DFD is not a flow chart. Arrows represents the order of events; arrows in DFD
represents flowing data.
3) A diamond-shaped box is used in flow charts to represents decision points with
multiple exists paths of which the only one is taken.
4) DFD does not represent procedural information, so procedural thinking must be
avoided.
5) To define the data structure, a regular expression type notation is used. While
specifying the structure of a data item, sequence or composition is represented by “+”,
selection by vertical bar “|” and repetition by “*”.

16
Standard symbols for DFDs

Circle: A circle (bubble) shows a process that transforms data inputs into data
outputs.

Data Flow: A curved line shows the flow of data into or out of a process or data store.

Data Store: A set of parallel lines shows a place for the collection of data items. A data
store indicates that the data is stored which can be used at a later stage or by the other
processes in a different order.
Source or Sink: Source or Sink is an external entity and acts as a source of system
inputs or sink of system outputs.

17
 Examples of DFD:
1) Data flow diagram of ATM.

2) DFD for the word-counting problem.

 LEVELS IN DATA FLOW DIAGRAMS (DFD)

The DFD may be used to perform a system or software at any level of abstraction.
Infact, DFDs may be partitioned into levels that represent increasing information flow
and functional detail. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see
primarily three levels in the data flow diagram, which are: 0-level DFD, 1-level DFD,
and 2-level DFD.

18
1) 0-level DFD
● It is also known as fundamental system model, or context diagram represents the
entire software requirement as a single bubble with input and output data denoted by
incoming and outgoing arrows.
● Then the system is decomposed and described as a DFD with multiple bubbles. Parts
of the system represented by each of these bubbles are then decomposed and
documented as more and more detailed DFDs.
● This process may be repeated at as many levels as necessary until the program at
hand is well understood. It is essential to preserve the number of inputs and outputs
between levels, this concept is called levelling by DeMacro.

2) 1-level DFD
In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In
this level, we highlight the main objectives of the system and breakdown the high-level
process of 0-level DFD into subprocesses.

19
3) 2-Level DFD
2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project
or record the specific/necessary detail about the system's functioning.

Advantages of using Data Flow Diagrams (DFD):

1) Easy to understand: DFDs are graphical representations that are easy to

understand and communicate, making them useful for non-technical stakeholders and
team members.
2) Improves system analysis: DFDs are useful for analyzing a system’s processes and
data flow, which can help identify inefficiencies, redundancies, and other problems
that may exist in the system.
3) Supports system design: DFDs can be used to design a system’s architecture and
structure, which can help ensure that the system is designed to meet the requirements
of the stakeholders.
4) Enables testing and verification: DFDs can be used to identify the inputs and
outputs of a system, which can help in the testing and verification of the system’s
functionality.
5) Facilitates documentation: DFDs provide a visual representation of a system,
making it easier to document and maintain the system over time.

Disadvantages of using DFDs:

1) Can be time-consuming: Creating DFDs can be a time-consuming process,

especially for complex systems.
2) Limited focus: DFDs focus primarily on the flow of data in a system, and may not
capture other important aspects of the system, such as user interface design, system
security, or system performance.
20
 3) Can be difficult to keep up-to-date: DFDs may become out-of-date over time as
the system evolves and changes.
4) Requires technical expertise: While DFDs are easy to understand, creating them
requires a certain level of technical expertise and familiarity with the system being
analyzed.

 ER DIAGRAMS ( ENTITY RELATIONSHIP DIAGRAMS )

● An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how
“entities” such as people, objects or concepts relate to each other within a system.
● ER Diagrams are used to design or debug relational databases in the fields of software
engineering, business information systems, education and research.
● Also known as ERDs or ER Models, they use a defined set of symbols such as
rectangles, diamonds, ovals and connecting lines to depict the interconnectedness of
entities, relationships and their attributes.

Purpose of ERD
● The database analyst gains a better understanding of the data to be contained in the
database through the step of constructing the ERD.
● The ERD is used to connect the logical structure of the database to users. In
particular, the ERD effectively communicates the logic of the database to users.

ER Diagrams & Notations

21
 1. 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. For example, in a
school database, students, teachers, classes, and courses offered can be treated as
entities.
Entity Set
An entity set is a collection of related types of entities. An entity set may include entities
with attribute sharing similar values. For example, a student set may contain all the
students of a school, a teacher set include all the teachers of a school from all faculties.

2. Attributes
Entities are denoted utilizing their properties, known as attributes. All attributes have
values. For example, a student entity may have name, class, and age as attributes.
For example, a student's name cannot be a numeric value. It has to be alphabetic. A
student's age cannot be negative, etc.

There are five types of Attributes:

A. Key attribute
B. Composite attribute
C. Single-valued attribute
D. Multi-valued attribute
E. Derived attribute

A) Key attribute:
Key attributes are those attributes that can uniquely identify the entity in the entity set.
Example: Roll-No is the key attribute because it can uniquely identify the student.

B) Composite attribute:
An attribute that can be split into components is a composite attribute.
Example: The address can be further split into house number, street number, city,
state, country, and pin code, the name can also be split into first name middle name,
and last name.
C) Single-valued attribute:
The attribute which takes up only a single value for each entity instance is a single-
valued attribute.
Example: The age of a student.

22
D) Multi-valued Attribute: If an attribute can have more than one value, it is known
as a multi-valued attribute. Multi-valued attributes are depicted by the double ellipse.
Example: a person can have more than one phone number, email-address, etc.

E) Derived attribute: Derived attributes are the attribute that does not exist in the
physical database, but their values are derived from other attributes present in the
database.
Example: age can be derived from date_of_birth. In the ER diagram, Derived attributes
are depicted by the dashed ellipse.

Relationships
The association among entities is known as relationship. Relationships are represented
by the diamond-shaped box. For example, an employee works_at a department, a
student enrolls in a course. Here, Works_at and Enrolls are called relationships.

Examples of ERD:-

23
 REQUIREMENT VALIDATION
● Requirements validation is the process of checking that requirements actually define
the system that the customer really wants.
● Requirements validation is important because errors in a requirements document can
lead to extensive rework costs when these problems are discovered during development
or after the system is in service.
different types of checks of the requirements These checks include:

1. Validity checks A user may think that a system is needed to perform certain
functions. However, further thought and analysis may identify additional or different
functions that are required. Systems have diverse stakeholders with different needs and
any set of requirements is inevitably a compromise across the stakeholder community.

2. Consistency checks Requirements in the document should not conflict. That is,
there should not be different descriptions of the same system function.

3. Completeness checks the requirements document should include requirements that

define all functions and the constraints intended by the system user.

4. Realism checks Using knowledge of existing technology, the requirements should be

checked to ensure that they can actually be implemented. These checks should also
take account of the budget and schedule for the system development.
5. Verifiability This means that you should be able to write a set of tests that can
demonstrate that the delivered system meets each specified requirement.

24
 REQUIREMENTS VALIDATION TECHNIQUES
1. Requirements reviews the requirements are analysed systematically by a team of
reviewers who check for errors and inconsistencies.
• Regular reviews should be held while the requirements definition is being formulated.
• Both client and contractor staff should be involved in reviews.
• Reviews may be formal or informal. Good communications between developers,
customers and users can resolve problems at an early stage.
• Dont underestimate the problems involved in requirements validation. Ultimately, it
is difficult to show that a set of requirements does in fact meet a user‘s needs.

2. Prototyping In this approach to validation, an executable model of the system in

question is demonstrated to end-users and customers. They can experiment with this
model to see if it meets their real needs.

3. Test-case generation Requirements should be testable. If a test is difficult or

impossible to design, this usually means that the requirements will be difficult to
implement and should be reconsidered. Developing tests from the user requirements
before any code is written is an integral part of extreme programming.

Requirements Management Planning

During the requirements engineering process, one has to plan:
• Requirements identification
How requirements are individually identified;
• A change management process
The process followed when analysing requirements change;
• Traceability policies
The amount of information about requirements relationships that is maintained;
CASE tool support
• The tool support required to help manage requirements change;
• Should apply to all proposed changes to the requirements.

Principal stages
• Problem analysis- Discuss requirements problem and propose change;
• Change analysis and costing- Assess effects of change on other requirements;
• Change implementation- Modify requirements document and other documents to
reflect change.

25