Understanding Software Requirements Specifications (SRS) in Software Engineering, Slides of Computer Science

Download Understanding Software Requirements Specifications (SRS) in Software Engineering and more Slides Computer Science in PDF only on Docsity!

Subject: Software Engineering

&

Introduction to software Engineering

Delivered by

Abdul Basit

After this presentation students will be able

to:

•

Understand software requirements specifications (SRS).

•

Understand why we use SRS documents.

•

Understand attributes of good SRS.

•

Understand software requirements specifications versus system

requirements specifications.

•

Understand how to write SRS.

What Is a 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 all

stakeholders (business, users) needs.



A typical SRS includes:

•

A purpose

•

An overall description

•

Specific requirements

•

The best SRS documents define how the software will interact when

embedded in hardware OR when connected to other software.

•

Good SRS documents also account for real-life users.

Why Use a SRS Document?

•

A software requirements specification is the basis for your entire project. It

lays the framework that every team involved in development will follow.

•

It’s used to provide critical information to multiple teams — development,

quality assurance, operations, and maintenance. This keeps everyone on

the same page.

•

Using the SRS helps to ensure requirements are fulfilled. And it can also

help you make decisions about your product’s lifecycle — for instance,

when to retire a feature.

•

Writing an SRS can also minimize overall development time and costs.

Embedded development teams especially benefit from using an SRS.

Attributes of good SRS document

Software Requirements Specification

versus

System Requirements Specification

•

A software requirements specification (SRS) includes in-depth descriptions of the software

that will be developed.

•

A system requirements specification (SyRS) collects information on the requirements for a

system.

•

“Software” and “system” are sometimes used interchangeably as SRS. But, a software

requirement specification provides greater detail than a system

Writing an SRS Document (The Outline)



A simple outline will look like this:

1. Introduction

1.1 Purpose

1.2 Intended Audience

1.3 Intended Use

1.4 Scope

1.5 Definitions and Acronyms

2. Overall Description

2.1 User Needs

2.2 Assumptions and Dependencies

3. System Features and Requirements

3.1 Functional Requirements

3.2 External Interface Requirements

3.3 System Features

3.4 Nonfunctional Requirements

Note:

Your first step is to

create an outline for

your software

requirements

specification. This

may be something

you create yourself.

Or you may use an

existing SRS

template.

Start your SRS with a purpose

• The introduction to your SRS is very important. It sets the expectation for the product you’re building.
• So, start by defining the purpose of your product.

 Intended Audience and Intended Use

Define who in your organization will have access to the SRS — and how they should use it. This may

include developers, testers, and project managers. It could also include stakeholders in other departments,

including leadership teams, sales, and marketing.

 Product Scope

Describe the software being specified. And include benefits, objectives, and goals. This should relate to

overall business goals, especially if teams outside of development will have access to the SRS.

 Definitions

• It’s smart to include a risk definition. Avoiding risk is top-of-mind for many developers — especially

those working on safety-critical development teams.

• Here’s an example. If you’re creating a medical device, the risk might be the device fails and causes a

fatality.

• By defining that risk up front, it’s easier to determine the specific requirements you’ll need to mitigate

it.

Give an Overview of What You will Build

• Your next step is to give a description of what you’re going to build. Is it an update to an existing product? Is it a new product?

Is it an add-on to a product you have already created?

• These are important to describe upfront, so everyone knows what you’re building.
• You should also describe why you’re building it and who it’s for.

 User Needs

• User needs — or user classes and characteristics — are critical. You’ll need to define who is going to use the product and how.
• You’ll have primary and secondary users who will use the product on a regular basis. You may also need to define the needs of

a separate buyer of the product (who may not be a primary/secondary user). And, for example, if you’re building a medical

device, you’ll need to describe the patient’s needs.

 Assumptions and Dependencies

• There might be factors that impact your ability to fulfill the requirements outlined in your SRS. What are those factors?
• Are there any assumptions you’re making with the SRS that could turn out to be false? You should include those here, as well.
• Finally, you should note if your project is dependent on any external factors. This might include software components you’re

reusing from another project.

Detail Your Specific Requirements

• The next section is key for your development team. This is

where you detail the specific requirements for building your

product.



Functional Requirements

• Functional requirements are essential to building your

product.

• If you’re developing a medical device, these requirements

may include infusion and battery. And within these

functional requirements, you may have a subset of risks and

requirements.



External Interface Requirements

• External interface requirements are types of functional requirements.

They’re important for embedded systems. And they outline how your

product will interface with other components.

• There are several types of interfaces you may have requirements for,

including:

• User
• Hardware
• Software
• Communications

 Other Nonfunctional Requirements

•

Nonfunctional requirements can be just as important as functional ones.

These include:

•

Performance

•

Safety

•

Security

•

Quality

•

The importance of this type of requirement may vary depending on your

industry. Safety requirements, for example, will be critical in the medical

device industry.

Writing a SRS in Microsoft Word

OR

Microsoft Power Point

• You can write your software requirement specification in

Microsoft Word. A smart way to do this is to create an SRS

template that you can use as a starting point for every project.

Summary

• Software requirements specifications (SRS) in detail

discussed with having good attributes.

• Why we use SRS documents , how to write SRS and

start your SRS with a purpose are briefly discussed.

• Microsoft tools are better options for designing the

SRS document.