Scribd
Upload
31 views10 pages

How to Write an SRS Document

The document provides guidance on how to write an effective Software Requirements Specification (SRS) document in 5 steps: 1. Create an outline or use a template with typical SRS sections like introduction, overall description, and specific requirements. 2. Start with defining the purpose, intended audience, scope, and definitions. 3. Give an overview of the product being built including perspectives, functions, users, assumptions, and requirements allocation. 4. Detail the specific requirements including functional, interface, features, and non-functional requirements. 5. Review and finalize the SRS document.

Uploaded by

e1840006
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
31 views10 pages

How to Write an SRS Document

The document provides guidance on how to write an effective Software Requirements Specification (SRS) document in 5 steps: 1. Create an outline or use a template with typical SRS sections like introduction, overall description, and specific requirements. 2. Start with defining the purpose, intended audience, scope, and definitions. 3. Give an overview of the product being built including perspectives, functions, users, assumptions, and requirements allocation. 4. Detail the specific requirements including functional, interface, features, and non-functional requirements. 5. Review and finalize the SRS document.

Uploaded by

e1840006
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Lesson 3. How to Write an SRS Document?

Introduction
Throughout the last lesson, you learned about what an SRS is and why
we have to prepare an SRS. This is the third lesson of the course module:
Programming group Project. This lesson covers how we can prepare an
SRS. You will also be guided to the standard templates in SRS.

Learning Outcomes
After completing this lesson you would be able to,
· Describe major parts of SRS
· Design an Outline of an SRS

3.1 Steps in SRS preparation

User requirements are almost always written in natural language


supplemented by appropriate diagrams and tables in the requirements
document. Software requirements may also be written in natural
language, but other notations based on forms, graphical, or
mathematical system models can also be used.

Figure 3.1 summarizes possible notations for writing software


requirements.

1
Figure 3.1 – Notations to be followed in SRS

The user requirements for a software system should describe the


functional and other requirements so that they are understandable by
system users who don’t have detailed technical knowledge. If you are
writing user requirements, you should not use software jargon,
structured notations, or formal notations. You should write user
requirements in natural language, with simple tables, forms, and
intuitive design diagrams.

Writing an SRS document is important. But it isn’t always easy to do. Here
are five steps you can follow to write an effective SRS document.

The first step is to create an outline. Let us see in detail what we should
do as the first step.

2
Step 1. Create an Outline (Or Use an SRS Template)

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. If you’re creating this by yourself, here’s
what your outline might look like:

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 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Assumptions and dependencies
2.5 Apportioning of requirements
3. System Features and Requirements
3.1 Functional Requirements
3.2 External Interface Requirements
3.3 System Features
3.4 Non-functional Requirements
Specific requirements (i.e. the organization of this section 3 can be varied. See
also Annex A of IEEE guidelines for SRS for several different ways of organizing
this section 3)

Note: IEEE guidelines for SRS has been uploaded to the course page of the
Moodle.

3
Once you have your basic outline, you’re ready to start filling it out.

Step 2: Start 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. It includes benefits, objectives,


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

More specifically, this subsection should;

a) Identify the software product(s) to be produced by name (e.g., Host


DBMS, Report Generator, etc.);
b) Explain what the software product(s) will, and, if necessary, will not
do;
c) Describe the application of the software being specified, including
relevant benefits, objectives, and goals;
d) Be consistent with similar statements in higher-level specifications
(e.g., the system requirements specification), if they exist.

4
Definitions and Acronyms

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 upfront, it’s easier to determine the specific


requirements you’ll need to mitigate it

Step 3. Give an Overview of What You’ll Build

Your next step is to give a description of what you’re going to build. This
associate with section 2 of the SRS. Is it an update to an existing product?
Is it a new product? Is it an add-on to a product you’ve 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.

This section usually consists of five subsections, as follows:

a) Product perspective;
b) Product functions;
c) User characteristics;
d) Assumptions and dependencies;
e) Apportioning of requirements.

5
Product perspective

This subsection of the SRS should put the product into perspective with
other related products. If the product is independent and totally self-
contained, it should be so stated here. If the SRS defines a product that
is a component of a larger system, as frequently occurs, then this
subsection should relate the requirements of that larger system to the
functionality of the software and should identify interfaces between that
system and the software.
A block diagram showing the major components of the larger system,
interconnections, and external interfaces can be helpful.
This subsection may also describe in brief how the software operates
inside various constraints. For example, these constraints could include

a) System interfaces;
b) User interfaces;
c) Hardware interfaces;
d) Software interfaces;
e) Communications interfaces;
f) Memory;
g) Operations;
h) Site adaptation requirements.

Product functions

This subsection of the SRS should provide a summary of the major


functions that the software will perform. For example, an SRS for an
accounting program may use this part to address customer account
maintenance, customer statement, and invoice preparation without

6
mentioning the vast amount of detail that each of those functions
requires.
Sometimes the function summary that is necessary for this part can be
taken directly from the section of the higher-level specification (if one
exists) that allocates particular functions to the software product. Note
that for the sake of clarity
a) The functions should be organized in a way that makes the list of
functions understandable to the customer or to anyone else reading
the document for the first time.
b) Textual or graphical methods can be used to show the different
functions and their relationships. Such a diagram is not intended to
show a design of a product, but simply shows the logical relationships
among variables.
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? Or maybe your
system/software might work under certain constraints. You may need to
make some assumptions when you are designing and developing your
software system. They all should go here.

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

Apportioning of requirements

This subsection of the SRS should identify requirements that may be


delayed until future versions of the system.

Step 4. Detail Your Specific Requirements

The next section is key to 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

8
 Hardware
 Software
 Communications

System Features

System features are types of functional requirements. These are features


that are required in order for a system to function.

Other Nonfunctional Requirements

Non-functional 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.

Step 5. Get Approval for the SRS

Once you’ve completed the SRS, you’ll need to get it approved by key
stakeholders. And everyone should be reviewing the latest version of the
document.

9
Summary

From this lesson, you learned what should be included in the SRS and
how to outline an SRS. You were guided to the standard SRS template
developed by IEEE. The next lesson takes you through the sample SRS
developed based on IEEE SRS templates.

10

Common questions

Powered by AI

An SRS document should include the following components: Introduction, Overall Description, System Features and Requirements. The Introduction covers the Purpose, Intended Audience, Intended Use, Scope, and Definitions and Acronyms. Overall Description provides Product perspective, Product functions, User characteristics, Assumptions and dependencies, and Apportioning of requirements. The System Features and Requirements section details Functional Requirements, External Interface Requirements, System Features, Non-functional Requirements such as Performance, Safety, Security, and Quality .

'External Interface Requirements' in an SRS document outline how a product will interact with other components, including user, hardware, software, and communication interfaces. For embedded systems, these are crucial as they determine the product's integration capabilities with existing systems, ensuring that it can communicate effectively and perform its intended functions without errors .

Creating an outline for an SRS document involves the following steps: 1) Include an Introduction outlining the Purpose, Intended Audience and Use, Scope, and Definitions and Acronyms; 2) Provide an Overall Description covering Product Perspective, Product Functions, User Characteristics, and Constraints; 3) Detail System Features and Requirements, specifying Functional and Non-functional Requirements .

Defining user needs and characteristics in an SRS is crucial as it guides the development process by clarifying who the primary and secondary users are and how they will interact with the software. This ensures the developed product meets the actual needs of its users and aids in tailoring functionalities that enhance user experience, thereby increasing product usability and satisfaction .

System Features, categorized as functional requirements in an SRS, directly impact software design and implementation by defining essential operations the software must perform. This structured categorization ensures clarity in translating stakeholder needs into technical specifications, guiding developers in creating a system architecture that fulfills all mandated operations effectively and efficiently, thus minimizing potential design ambiguities and errors .

The 'Overall Description' section of an SRS document contributes to clarity and direction by providing a comprehensive description of the product, including its perspective, functions, user characteristics, assumptions, and dependencies. This ensures that all stakeholders, including developers and project managers, have a clear understanding of the project's objectives and constraints, which aligns efforts and resources effectively .

'Apportioning of Requirements' in an SRS document involves identifying requirements that can be postponed for later versions of the software, which helps in managing project scope and timeline more effectively. This impacts the development cycle by allowing teams to focus on critical functionalities for initial releases, and planning feature expansions systematically, ensuring ongoing product evolution and maintenance .

The 'Product Scope' section in an SRS document defines the software to be developed, including its benefits, objectives, and goals, and aligns them with business goals. This is important for stakeholders, as it ensures that everyone has a shared understanding of the project's purpose and objectives. It also outlines what the product will and will not do, setting boundaries that manage stakeholder expectations and guide development efforts .

The detailed execution of an SRS document affects the final delivery and success of a software product by providing a comprehensive blueprint that guides the development team. It minimizes misunderstandings and misinterpretations of requirements, ensuring that the final product aligns closely with user needs and stakeholder expectations. This reduces risk, facilitates smooth project management, encourages precise resource allocation, and fosters communication among all parties involved, ultimately increasing the likelihood of project success .

An SRS document outlines risks by including a section that describes potential risks, such as software failure that could lead to severe consequences like fatalities in safety-critical applications, e.g., medical devices. This inclusion is crucial because it allows for proactive planning to mitigate identified risks, ensuring robust design and better adherence to safety standards, ultimately protecting both the user and the developer legally and ethically .

You might also like