Unit 2

Software Requirements Analysis,

Design and Construction

 Requirements engineering is the process of identifying, eliciting, analyzing,

specifying, validating, and managing the needs and expectations of

stakeholders for a software system. In this article, we’ll learn about it’s

process, advantages and disadvantages.

What is Requirements Engineering?

 What is Requirements Engineering?

 A systematic and strict approach to the definition, creation and verification of requirements for a

software system is known as requirements engineering. In order to guarantee the effective creation

of a software product, the requirements engineering process entails a number of tasks that help in

understanding, recording and managing the demands of stakeholders.

Steps in Requirements Engineering Process

 The requirements engineering process is an iterative process that involves several steps, including:

Requirements Elicitation

 This is the process of gathering information about the needs and expectations of stakeholders for

the software system. This step involves interviews, surveys, focus groups, and other techniques to

gather information from stakeholders.


 Requirements Analysis
 This step involves analyzing the information gathered in the requirements
elicitation step to identify the high-level goals and objectives of the software
system. It also involves identifying any constraints or limitations that may
affect the development of the software system.
 Requirements Specification
 This step involves documenting the requirements identified in the analysis
step in a clear, consistent, and unambiguous manner. This step also involves
prioritizing and grouping the requirements into manageable chunks.
 Requirements Validation
 This step involves checking that the requirements are complete, consistent,
and accurate. It also involves checking that the requirements are testable and
that they meet the needs and expectations of stakeholders.
 Requirements Management
 This step involves managing the requirements throughout the software
development life cycle, including tracking and controlling changes, and
ensuring that the requirements are still valid and relevant
 Requirement Engineering is the process of defining, documenting and

maintaining the requirements. It is a process of gathering and defining service

provided by the system. it is the disciplined application of proven principle ,

methods ,tools and notations to describe a proposed system’s intended behaviour

and its associated constraints.

 User and system requirements differ in what they define and how they define it. User

requirements define the results and qualities the user wants; system requirements define

what the system must do to achieve this. User requirements are owned by the users,

whereas system requirements are owned by the developers.

Main types of software requirement
can be of 3 types:
 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.

Non-functional requirements

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

Advantages of classifying software
requirements include:

 Better organization: Classifying software requirements helps organize them into

groups that are easier to manage, prioritize, and track throughout the
development process.
 Improved communication: Clear classification of requirements makes it easier
to communicate them to stakeholders, developers, and other team members. It
also ensures that everyone is on the same page about what is required.
 Increased quality: By classifying requirements, potential conflicts or gaps can
be identified early in the development process. This reduces the risk of errors,
omissions, or misunderstandings, leading to higher quality software.
 Improved traceability: Classifying requirements helps establish traceability,
which is essential for demonstrating compliance with regulatory or quality
standards
Functional vs Non Functional Requirements

 Requirements analysis is a very critical process

that enables the success of a system or software
project to be assessed. Requirements are
generally split into two types: Functional and
Non-functional requirements.
 Functional Requirements
 These are the requirements that the end user specifically demands as basic
facilities that the system should offer. All these functionalities need to be
necessarily incorporated into the system as a part of the contract.

Non-Functional Requirements
 These are the quality constraints that the system must satisfy according to
the project contract. The priority or extent to which these factors are
implemented varies from one project to another
Functional Requirements Non Functional Requirements

A non-functional requirement defines the quality attribute of a software

A functional requirement defines a system or its component.
system.

It places constraints on “How should the software system fulfill the functional
It specifies “What should the software system do?”
requirements?”

Non-functional requirement is specified by technical peoples e.g. Architect,

Functional requirement is specified by User.
Technical leaders and software developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system as a whole.

Helps you verify the functionality of the software. Helps you to verify the performance of the software.

Functional Testing like System, Integration, End to End, API testing, etc are Non-Functional Testing like Performance, Stress, Usability, Security testing,
done. etc are done.

Usually easy to define. Usually more difficult to define.

Example
Example
1) Emails should be sent with a latency of no greater than 12 hours from such
1) Authentication of user whenever he/she logs into the system.
an activity.
2) System shutdown in case of a cyber attack.
2) The processing of each request should be done within 10 seconds
3) A Verification email is sent to user whenever he/she registers for the first
3) The site should load in 3 seconds when the number of simultaneous users
time on some software system.
are > 10000
Software Requirements Specification
(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. Correctness: User review is used to provide the accuracy of requirements

stated in the SRS. SRS is said to be perfect if it covers all the needs that are

truly expected from the system.

 2. Completeness: The SRS is complete if, and only if, it includes the following
elements:
 (1). All essential requirements, whether relating to functionality,
performance, design, constraints, attributes, or external interfaces.
 (2). Definition of their responses of the software to all realizable classes of
input data in all available categories of situations.
 3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict
in the SRS:

 (1). The specified characteristics of real-world objects may conflicts. For

example,

 (a) The format of an output report may be described in one requirement as

tabular but in another as textual.

 (b) One condition may state that all lights shall be green while another states
that all lights shall be blue.
 4. Unambiguousness: SRS is unambiguous when every fixed requirement has

only one interpretation. This suggests that each element is uniquely

interpreted. In case there is a method used with multiple definitions, the

requirements report should determine the implications in the SRS so that it is

clear and simple to understand.

 5. Ranking for importance and stability: The SRS is ranked for importance

and stability if each requirement in it has an identifier to indicate either the

significance or stability of that particular requirement.

 Modifiability: SRS should be made as modifiable as likely and should be
capable of quickly obtain changes to the system to some extent. Modifications
should be perfectly indexed and cross-referenced.
 7. Verifiability: SRS is correct when the specified requirements can be
verified with a cost-effective system to check whether the final software
meets those requirements. The requirements are verified with the help of
reviews.
 8. Traceability: The SRS is traceable if the origin of each of the requirements
is clear and if it facilitates the referencing of each condition in future
development or enhancement documentation.
 9. Design Independence: There should be an option to select from multiple design

alternatives for the final system. More specifically, the SRS should not contain any

implementation details.

 10. Testability: An SRS should be written in such a method that it is simple to

generate test cases and test plans from the report.

 11. Understandable by the customer: An end user may be an expert in his/her explicit

domain but might not be trained in computer science. Hence, the purpose of formal

notations and symbols should be avoided too as much extent as possible. The language

should be kept simple and clear.

 12. The right level of abstraction: If the SRS is written for the requirements stage, the

details should be explained explicitly. Whereas,for a feasibility study, fewer analysis can

be used. Hence, the level of abstraction modifies according to the objective of the SRS.
Software Requirements Specification
(SRS): The software requirements

 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

 Requirement Engineering Process

 It is a four step process, which includes –

 Feasibility Study

 Requirement Gathering

 Software Requirement Specification

 Software Requirement Validation

Software Requirement Specification

 SRS is a document created by system analyst after the requirements are collected from

various stakeholders.

 SRS defines how the intended software will interact with hardware, external interfaces, speed

of operation, response time of system, portability of software across various platforms,

maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

 The requirements received from client are written in natural language.

 It is the responsibility of system analyst to document the requirements in

technical language so that they can be comprehended and useful by the

software development team.

SRS should come up with following
features:

 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

 Functional requirements specify the expected behavior
of the system-which outputs should be produced from the
given inputs.
 They describe the relationship between the input and
output of the system.
 For each functional requirement, detailed description all
the data inputs and their source, the units of measure,
and the range of valid inputs must be specified
 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.
 The performance requirements part of an SRS
specifies the performance constraints on the
software system.
 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
Uses of SRS document

 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 behaviour.
 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.
1. Why is it important to define the scope of an SRS document?
 ANS.

 Defining the scope in an SRS document helps the customer understand the

goals and worth of the software. It also has details about how much it will

cost to create and how long it will take, so that the project’s limits are clear.
2. What are functional requirements in an SRS
document, and why are they important?

 Functional requirements describe how the software system is supposed to

work, including how it should react to inputs and make outputs. They help

you figure out what the software needs to do and give you a place to start

building and testing it.

 why writing down clear software requirements guarantees your development
team will build the product matching your needs. What’s more, an SRS is
helpful for:

Stakeholders to understand what is going to happen

with a project and which requirements
must be met

Investors, if there are any to evaluate the prospects of tool to

make an informed decision

Software engineers to define the programming languages

and plan their work

Designers to create mockups based on

requirements and use cases

QA specialists to evaluate the prospects of tools to

make an informed decision
What Does an SRS Include?

 What Does an SRS Include?

 Software requirements specification is a blueprint for the development team,
providing all the information they need to build the tool according to your
requirements. But it also should outline your product’s purpose, describing
what the application is supposed to do and how it should perform.
 An SRS can vary in format and length depending on how complex the project
is and the selected development methodology. However, there are essential
elements every good SRS document must contain:
 Purpose of the digital product is a clear and concise statement that defines the intent of the solution. This statement
should address your needs, outlining what the app will achieve once completed.
 Description of the product provides a high-level overview of the future tool, including intended users, the type of
environment it will operate in, and any other relevant information that could impact the software development process.
 Functionality of the product describes the features, capabilities, and limitations or constraints that might affect the
tool’s performance.
 Performance of the product should include requirements related to its performance in a production environment: speed,
efficiency, reliability, and scalability.
 Non-functional requirements address such factors as security, compatibility, and maintainability.
 External interfaces include information about how the application will interact with other systems it must connect to.
So, here communication protocols and data formats are described. Also, it outlines details of the screen layout, logic
interface, hardware interface, and design.
 Design constraints or environmental limitations that may impact the development process or the software’s
functionality.
 Assumptions and dependencies note the presuppositions made during the SRS document formulation and any external or
third-party dependencies critical for project planning and risk assessment.
 Quality attributes define the standards for usability, reliability, and accessibility you expect in terms of the software’s
quality.
 Security protocols explain the security requirements to protect the software against unauthorized access and ensure data
privacy.
 Acceptance criteria specify the must-do list for the software to be considered finished and ready to go live, including all
the tests the software needs to pass
 Acceptance criteria specify the must-do list for the software to be
considered finished and ready to go live, including all the tests the software
needs to pass and the goals it must achieve.
 https://relevant.software/blog/software-requirements-specification-srs-
document/
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.

 Steps Of Requirements Elicitation:
 Identify all the stakeholders, e.g., 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
Requirement validation

Requirement validation is the process of checking and confirming that

the requirements defined for development accurately capture the needs
and expectations of the stakeholders.
Elicitation techniques

 List of elicitation techniques

 Interviews.
 Existing System.
 Project Scope.
 Brain Storming.
 Focus Groups.
 Exploratory Prototypes.
 User Task Analysis.
 Observation.
 1. Interviews
 Objective of conducting an interview is to understand the customer’s
expectations from the software.
 2 Brainstorming Sessions
 It is a group technique
 Finally, a document is prepared which consists of the list of requirements and
their priority if possible.
Advantages of Requirements
Elicitation:
 Advantages of Requirements Elicitation:
 Clear requirements: Helps to clarify and refine customer requirements.
 Improves communication: Improves communication and collaboration
between stakeholders.
 Results in good quality software: Increases the chances of developing a
software system that meets customer needs.
 Avoids misunderstandings: Avoids misunderstandings and helps to manage
expectations.
Advantages of Requirements
Elicitation:
 Supports the identification of potential risks: Supports the identification of
potential risks and problems early in the development cycle.
 Facilitates development of accurate plan: Facilitates the development of a
comprehensive and accurate project plan.
 Increases user confidence: Increases user and stakeholder confidence in the
software development process.
 Supports identification of new business opportunities: Supports the
identification of new business opportunities and revenue streams.
2.3 Requirement Modeling

 Defination

 Requirements Modeling is a systematic procedure of documenting,

analyzing, and further managing the requirements.

2.3.1 Decision table


A decision table is a brief visual representation

for specifying which actions to perform depending

on given conditions
Event Tables

 Event Tables

 Event Table. The event table is a table of data that is

typically written to the logfile for each scenario and also

appears in the Analysis window.

2.3.3 Petri net

A Petri net, also known as a place/transition

(PT) net, is one of several mathematical
modeling languages for the description of
distributed systems. It is a class of discrete
event dynamic system. A Petri net is a
directed bipartite graph that has two types
of elements: places and transitions.
2.3.4 Class Responsibility Collaborator
(CRC) model.

 Class-responsibility-collaborator (CRC) modeling provides a simple means

for identifying and organizing the classes that are relevant to system or product

requirements.
CONTINUE……..
CONTINUE……..
CONTINUE……..
CONTINUE……..
How to Create a CRC Model?

 1 Read the description. Again. And again.

 Identify core classes (simplistic advice: look for nouns).

 Create a card per class (begin with class names only).

 Add responsibilities (simplistic advice: look for verbs).

Perform The Iterative Steps of CRC
Modeling
The steps of CRC modeling are

1 Find classes

2.Find responsibilities

3. Define collaborators

4. Define use-cases

5. Arrange the cards on the table

CONTINUE……..

 Finding Class
 Look for anything that interacts with the system, or is part of the system
 · Ask yourself “Is there a customer?”
 · Follow the money
 · Look for reports generated by the system
 · Look for any screens used in the system
 · Immediately prototype interface and report classes
 · Look for the three to five main classes right away
 · Create a new card for a class immediately
 · Use one or two words to describe the class
 · Class names are singular
 Finding Responsibilities
 · Ask yourself what the class knows
 · Ask yourself what the class does
 · If you’ve identified a responsibility, ask yourself what class it "belongs" to
 · Sometimes get responsibilities that we won’t implement, and that’s OK
 · Classes will collaborate to fulfil many of their responsibilities
 Defining Collaborators
 · Collaboration occurs when a class needs information that it doesn’t have
 · Collaboration occurs when a class needs to modify information that it
doesn’t have
 · There will always be at least one initiator of any given collaboration
 · Sometimes the collaborator does the bulk of the work
 · Don’t pass the buck
Task

To create the CRC for Your

project