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.

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

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.

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

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.