0% found this document useful (0 votes)
7 views

Chapter 10

The chapter discusses documenting software requirements specifications, including the purpose and structure of SRS documents. It covers why requirements are documented, what an SRS contains, a common SRS template, and how requirements specification differs for agile projects.

Uploaded by

Le Quyen
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

Chapter 10

The chapter discusses documenting software requirements specifications, including the purpose and structure of SRS documents. It covers why requirements are documented, what an SRS contains, a common SRS template, and how requirements specification differs for agile projects.

Uploaded by

Le Quyen
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

CHAPTER 10

Documenting the
requirements
Objectives

• This chapter addresses the purpose, structure, and


contents of the SRS (Software Requirement
Specification)
• After finish this chapter, student should understand the
purpose, structure of the SRS.
• Student could understand what they do and what they
have to write in every section of the SRS document.
• Student could enhance the difference in SRS document
between Agile projects and other projects
Contents

1. Why is documenting the requirements?


2. The software requirements specification
3. A software requirements specification
template
4. Requirements specification on agile projects
Why is documenting the
requirements?
• The result of requirements development is a documented
agreement among stakeholders about the product to be
built.
• The product’s functional and nonfunctional requirements
often are stored in a software requirements specification, or
SRS, which is delivered to those who must design, build, and
verify the solution.
• You can represent software requirements in several ways,
including:
– Well-structured and carefully written natural language.
– Visual models that illustrate transformational processes, system
states and changes between them, data relationships, logic flows,
and the like.
– Formal specifications that define requirements by using
mathematically precise specification languages.
The software requirements
specification
• It is sometimes called a business requirements document
(BRD), functional specification, product specification,
system specification, or simply requirements document.
• Audiences rely on the SRS: Customers, Project managers ,
Software development teams , Testers, Maintenance and
support staff, Documentation writers , Training personnel ,
Legal staff , Subcontractors
The software requirements
specification
• How many specifications?
• How to organize and write SRS (detail in page 185)
• Purpose, how to do?
– Labeling requirements
– Sequence number
– Hierarchical numbering
– Hierarchical textual tags
• Dealing with incompleteness
• User interfaces and the SRS
A software requirements
specification template
Requirements specification on
agile projects
• The extent to which just-in-time informal verbal and visual
communication between customers and developers can supply
the necessary details to permit the correct implementation of
each user requirement
• The extent to which informal communication methods can
keep the team effectively synchronized across time and space
• The extent to which it is valuable or necessary to retain
requirements knowledge for future enhancement,
maintenance, application reengineering, verification, statutory
and audit mandates, product certification, or contractual
satisfaction
• The extent to which acceptance tests can serve as effective
replacements for descriptions of the expected system
capabilities and behaviors
• The extent to which human memories can replace written
representations

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy