• Software Requirements Specification (SRS)

Contents of this Course

- Basics of Software Requirements and Why its important

- What is Inception Process
- Different methods of Requirements Elicitation processes
- What is Requirements Analysis
- What is Requirements Specification
- Requirements in Agile methodology
- Requirements Validation
- Requirements Management
 IEEE Definition of SE

• “Software engineering is the application of a systematic, disciplined

and quantifiable approach to the development, operation and
maintenance of software; that is, the application of engineering to
software”.
 What is Software Engineering

• Software engineering is the engineering approach to develop software

systems.

(this term comes in after the software crisis in late 1960s)

• So, the introduction of the term ‘software engineering’ is to develop
quality software system.

• But what is a “quality software system” ??????????????????

 • A quality software must:

- fulfill all the requirements

- delivered within the agreed budget/cost
-delivered within the agreed schedule/time
 • So, well begun is half solved

If we focus more on the requirements analysis, the subsequent phases

would be smooth
 Software Requirements Engineering

• Requirements engineering define what the system is required to do

and the constraint under which it is required to operate.

• It is the description of what the system does (and not how it is done).
 A sample of requirements (abstract level)

• What the system will do and the constraint under which the system will perform.

• For example: A software system for the exam section need to keep record
of all the students evaluation (i.e. mid exam, final exam, assignments etc).
The system can display a student’s semester’s GPA as well as the overall
CGPA.

• At a time, the system should process at least 100 students when gets
online. The system should be built within three months and under the
budget of one million PKR.
 Types of Software Requirements (Example: Online Shopping
System)

(1). Functional Requirements: What the System is Required to Do

• Example: The system should allow users to browse a catalog of

products, add items to a shopping cart, and proceed to checkout.
Types of Software Requirements (Example: Online Shopping System)

(2). Non-functional Requirements: Constraints and Operational

Conditions

• Example: The system should be able to handle at least 100,000

simultaneous users during peak hours.
Clients are Naive
 Problems with software requirements

• Software requirements are provided in natural language, it is difficult to

understand and model this extensive data.

• Requirements are sometimes incomplete (e.g. we didnt ask enough questions)

• Requirements are sometimes inconsistent

• Unclear responsibilities (e.g not clear what to ask whom)

• Requirements could be easily misunderstood between the clients and analyst and
between the analyst and programmers.
 Some examples of requirements
• A functionality for users (e.g. the word processor must include a spell
checking command.)

• A user must be login (users should enter valid id/password to get login)

• Requirements related to some constraints (e.g. the system should be

developed in six months).

• Reliability-related requirements (e.g. the system should support at least

100 transactions at a time)
 Requirement Engineering Process

• Requirement Engineering is the process of defining (i.e. what are the

expected requirements), documenting (i.e. bring the details in a
document) and maintaining (i.e. managing the changes) the
requirements .
 Non Functional Requirements (a.k.a Project Requirements)

• The client might not mention about the non-functional requirements

i.e. the system should not operate slowly

• These requirements are also called quality attributes:

• Fast recovery (if power shut down etc)

• Response time (if we click on button, the response need to be fast)
• The system should support at least 100 transactions at a time.
 Requirements Engineering Tasks

• In small and simple projects, the software analysts may just go the
customer and get idea of what should be done but,

• In large projects, there are some steps that need to be followed in

order to deliver the high-quality software system (i.e. accomplish what
the customer wants and what is needed by the customer.

• There are seven steps/tasks needed.

Requirements Engineering 7 Tasks
 1. Inception
• In the inception phase, all the basic questions are asked on how to go
about a task.

• The focus would be:

• Understand the problem.

• Understand the people (all stakeholders) who want a solution.
• Nature of the solution.
 2. Elicitation
• This phase focuses on gathering the requirements from the stakeholders.
• In this process, mistakes can happen in regard to, not implementing the
right requirements or forgetting a part.

The following problems may occur:

• Problem of Scope: The requirements given are of unnecessary detail, ill-defined, or not possible to
implement.
• Problem of Understanding: Sometimes the customer might not know what they want or not explicitly
mentioning (they think its obvious)
• Problem of Volatility: Requirements changing over time can lead to loss and wastage of resources and
time.
 3. Elaboration

• In the elaboration process, it takes the requirements that have been

stated and gathered in the first two phases and refines them.

• It describes how the end users are going to interact with the system,
possibly using use-case diagrams.
 4. Negotiation
• In this phase, negotiation is between the developer and the customer
about how to go about the project with limited resources.

• Customers want more functionalities in the system which could go

beyond the project’s budget and schedule, so it should be discussed.

“Customer might demand that students result should be displayed on computer as well as with all
handheld devices but budget is only allocated for computers”

• Project’s cost, delivery date, scope/boundary of requirements,

availability of resources are discussed with the customer in details.
 5. Specification
• In this phase, both requirements and constraints are specified.

• The specification could be performed either via:

 Written document
 Diagrams (e.g. Entity Relationship (ER) diagrams, Data Flow
Diagram (DFD) etc
 Some mathematical forms
 Or the combination of all these
 6. Validation

• This phase focuses on checking for errors and debugging.

• In the validation phase, the developer scans the specification document and checks for the
following:

• All the requirements have been stated and met correctly

• Errors (e.g. conflicting requirements, misinterpretation etc) have been debugged and
corrected.

• This phase is called “formal technical review” where all the stakeholders (i.e. software
engineers, customers, users) work together and validate the requirements
 7 Requirements Management

• In this phase, the team is responsible for managing any changes that
may occur during the project.

• New requirements emerge, so responsibility should be taken to

manage and prioritize as to where its position is in the project and how
this new change will affect the overall system
 Investment in the Requirements Process
• The industries invest in the requirements process for a typical system is 2% to 3% of
total project cost (this is why mostly projects failed to complete).

• According to the National Aeronautics and Space Administration (NASA), the

projects that invest an:

 average of 2% to 3% of total project cost/effort on the requirements process,

experienced an 80% to 200% cost overrun.

average of 8% to 14% of total project cost/effort on the requirements process

experienced an 0% to 50% cost overrun.
 Software Requirements Specification (SRS)
• A document used to specify in detail both the functional and non-
functional requirements of the develpment system.

Users of SRS

• Development team (they need to know which functionalities to include)

• Mainenance team (if changes are needed, they might refer to SRS doc)
• Clients (to validate requirements with the clients)
• Technical writers (After software is completed, SRS is needed to mention the
required functionalities in the final document)
 Contents of the SRS

• What type of software is developing (e.g. desktop, web-based).

• What is the purpose of the software system (e.g. students can access
their exams results while setting in home).

• What is the scope and boundaries of the software system (e.g. only for
exam section and no details about fee etc will be covered herer)

• Functional and non-functional requirements should be montioned in

detail.
 Contents of the SRS

• All the software tools should be mentioned that could be used in the
development process (e.g. ASP.net with C#).

• What kind of harware is needed during the deveopment.

• What kinds of hardware/software need to be used in the client

computer to deploy the system (RAM, Processor speed etc).

• Gantt chart is used for schedule purposes, so optionally it could also

be mentioned in the document.
A sample Gantt chart
• Requirements rarely lie on the surface. Normally, they're buried
beneath layers of assumptions, misconceptions, and politics.

Steve McConnell
• A sample SRS document can be found on the web. There are a lot
of SRS documents available you will find easily.
• What repercussions/consequences have companies faced as a result of
bypassing the requirements phase?
 Case Study 1: Denver International Airport (DIA) Baggage Handling System

In the 1990s, Denver International Airport rushed the implementation of an automated baggage handling
system to meet aggressive construction deadlines, skipping a thorough requirements phase.

Consequences:

- Operational Failures:
System glitches led to lost, misdirected, or damaged baggage, causing flight delays and passenger
frustration.

- Cost Overruns:
The project's budget skyrocketed from $200 million to over $1 billion due to troubleshooting efforts.

- Reputational Damage:
DIA's image suffered globally, and it took years to recover from the negative publicity.
 Case Study 1: Denver International Airport (DIA) Baggage Handling System

In the 1990s, Denver International Airport rushed the implementation of an automated baggage handling
system to meet aggressive construction deadlines, skipping a thorough requirements phase.

Consequences:

- Operational Failures:
System glitches led to lost, misdirected, or damaged baggage, causing flight delays and passenger
frustration.

- Cost Overruns:
The project's budget skyrocketed from $200 million to over $1 billion due to troubleshooting efforts.

- Reputational Damage:
DIA's image suffered globally, and it took years to recover from the negative publicity.
 Case Study 2: Healthcare.gov Launch

In 2013, Healthcare.gov was launched without proper requirements gathering, leading to technical glitches,
user confusion, and political controversy.

Consequences:

- Technical Glitches:
System crashes and errors hindered user enrollment, causing widespread frustration.

- Political Backlash:
The botched launch sparked political controversy and debates over government competence.
 Other examples include:

• Royal Bank of Scotland (RBS) IT Failure (2012):

• The Challenger Space Shuttle Disaster (1986):
• Therac-25 Radiation Therapy Machine Accidents (1985-1987):
• Thank you