Documenting the

requirements
SRS lecture 12
Outline
• Users of SRS

• Labeling requirements

• Sequence number

• Hierarchical numbering

• Hierarchical textual tags

• Dealing with incompleteness

• User interfaces and the SRS

• SRS template
Users of SRS

• Customers, the marketing department, and sales staff

• Project managers base their estimates of schedule, effort,

and resources.

• Software development teams.

• Testers use it to develop requirements-based tests.

Users of SRS continued

• Maintenance and support staff.

• Documentation writers base user manuals.

• Training personnel.

• Legal staff.

• Subcontractors base their work on.

Tool to write SRS

• What you think?

• Word processor

• Software Tool
How many SRS for a project?

• 1?

• Many?

• Versions?
Labeling requirements

• a unique and persistent identifier.

• refer to specific requirements in a change request,

modification history, cross-reference, or requirements
traceability matrix.

• Number or bullets?
Sequence number

• such as UC-9 or FR-26.

• The prefix indicates the requirement type.

• doesn’t provide any logical or hierarchical grouping.

• the number doesn’t imply any kind of ordering.

• labels give no clue

Hierarchical numbering

• 3.2

• 3.2.1

• 3.2.1.1

• The labels can grow to many digits in even a medium-sized SRS.

• If you insert a new requirement, the numbers of the following

requirements in that section all will be incremented.
Hierarchical textual tags
• “The system shall ask the user to confirm any request to print more than 10
copies.”

• This requirement might be tagged Print.ConfirmCopies.

• Hierarchical textual tags are structured, meaningful, and unaffected by

adding, deleting, or moving other requirements.

• A good convention is to write the parent requirement to look like a title, a

heading, or a feature name, rather than looking like a functional requirement
in itself
• The Product statement is written as a heading.

• The first functional requirement is tagged Product.Cart.

• The full ID for the third requirement is

Product.Discount.Error.
Dealing with incompleteness

• Use the notation TBD (to be determined) to flag these

knowledge gaps.
User interfaces and the SRS

• Incorporating user interface designs in the SRS has both benefits and drawbacks.

• makes the requirements tangible to both users and developers.

• could be disappointed if their expectations weren’t fulfilled.

• screen images and user interface architectures describe solutions.

• Can delay baseline requirements.

• Include user interface in design constraints, if you do not want to implement certain
functionality with specific UI controls and screen.
• If the SRS is specifying an enhancement to an existing
system.

• makes sense to include screen displays in SRS.

• A sensible balance is to include conceptual images.

SRS Template
SRS Template
IEEE/ANSI 830-1993 Standard
1. Introduction

2. Overall description

3. Specific requirements/ system features

4. Data requirements

5. External interface requirements

6. Quality attributes

7. Internationalization and localization requirements

8. Other requirements

9. Appendices
1. Introduction
1.1 Purpose of the requirements document
1.2 Document Conventions
1.3 Scope of the product
1.4 References

18
1. Introduction

1.1 Purpose of the requirements document

Release number

Types of readers
1. Introduction

1.2 Document Conventions

• Standards
• Typographical conventions
• Manual labeling format
1. Introduction

1.3 Project Scope

• Short description of software being specified.
• Relate to business goals and objectives.
• If specified in vision document already, refer it
• Do not duplicate.
• If SRS specifies incremental release, then it may have its own scope.
1. Introduction

1.4 references
• List documents
• Hyperlinks
• Uer interfaces style guides
• Contracts
• Title, author, version number, date, source, storage location,or url
2. Overall description

2.1 Product Perspective

• Describe product’s context and origin.
• Replacement for an existing system
• How this product relates to other systems
• Use eco system maps, context diagram
2. Overall description contd..

2.2 user classes and characteristics

• Users that will use the product.
2. Overall description contd..

2.3 Operating environment

• Hardware platform,
• Operating systems
• Versions,
• Geographical location of users, servers, databases
• Organizations that host the related databases, servers and websites.
• List any other software applications.
2. Overall description contd..

2.4 design and implementation constraints

• Certain programming language
• Particular library code
• Any factors or rationale that restricts the options to developers.
2. Overall description contd..

2.5 Assumptions and dependencies

• Problems arise if not shared
• Example
• .net framework 4.5 or recent version must be installed
3. System Features

3.X System Feature X

Spell check

3.x.1 Description

Short description of spell check

3.x.2 Functional requirements

4. Data requirements

4.1 logical data model

• UML class diagrams , entity relationship diagrams

4.2 data dictionary

• Meaning of data type, length, format, allowed values

4.3 reports
• Characteristics of reports
• Layouts
• Sort sequence
4. Data requirements contd..

• 4.4 data acquisition, integrity, retention and disposal

• Need to protect the integrity, mirroring, check pointing,
accuracy, residual data, local copies, interim backups
5 External interface requirements

• System will communicate properly with users and with

external hardware or software elements

• A complex system with multiple sun components should

create a separate interface specifications.

• Reference other interface documments

5 External interface requirements contd..

5.1 user interfaces

Reference to user interface standards
Standards for fonts, icons, buttons, labels, images, color schemes etc..
Screen size, layouts or resolution constraints
Standard buttons, functions, or navigation links that will appear on every screen such as
help button
Shortcut keys
Message display and phrasing conventions
5 External interface requirements contd..

• Data validation guidelines

layout standards to facilitate software localization

• Accommodation for users who are visually impaired,

color blind, or have other limitations
5 External interface requirements contd..

• 5.2 software Interfaces

• Connections between this product and other software componenets
identified by name and version.
• Purpose, formats of messages, control values, input, outputs, translation,.
• Data shared, exchanged
• Non functional requirements such as response time, frequencies, or security
controls, restrictions, interoperability requirements.
5 External interface requirements contd..

5.3 Hardware interfaces

• Supported devices
• Data components, if any
• Input output formats
5 External interface requirements contd..

5.4 Communication interfaces

• Email, web browser, network protocols and electronic forms
• Data encryption, data transfer rate, handshaking and
synchronization.
• Email attachments acceptable, not acceptable.
6 quality attributes

6.1 usability

6.2Performance

6.3Security

6.4Safety

6.xOthers

• Availibility, integrity, modifiability, interoperability, reliability, etc..

7. Internationalization and localization
requirements
• Product suitable for use in nations, cultures, organization,
geographical locations, currency, formatting of dates, numbers,
addresses, telephone numbers, language, spelling conventions,
symbols uses, international regulations an laws, cultural and
political issues, paper sizes used, weights and measures,
electrical voltages and plug shapes and many others.
8. Other requirements

• Legal, regulatory,

• Financial compliance

• Product installation

• Configuration

• Startup, shut down

• Monitoring, logging
Appendix A: Glossary

• Spell each acronym and provide definition

Appendix B: analysis models

• Data flow diagrams

• Sequence diagrams

• etc
Summary