Chapter 8
Requirements Specification

Ways to Write an SRS

1.1 Purpose

• Identifies the product, application, or subsystem specified
• Include the release/version number
• Describe the intended reader audiences (developers, PMs, marketing, users, testers, documentation writers)

1.2 Document Conventions

• Standards or typographical conventions used (meaning of specific text styles, highlighting, notations)
• Manual standard for labeling requirements

1.3 Project Scope

• Short description of the SW and its purpose
• Relate to business objectives and user/corporate goals
• Summary of major features
• Refer to Vision & Scope (V&S) document if it exists

1.4 References

• Resources the SRS refers to (contracts, standards, system requirements spec, interface spec)
• Include hyperlinks if possible
• Include enough info so the reader can access each resource (title, author)

2.1 Product Perspective

• Context & origin: next product in a line? New version? Replacement? Entirely new?
• If a subsystem: how does it relate to the overall system? What interfaces exist?
• Consider including visual models (ecosystem map, context diagram)

2.2 User Classes and Characteristics

• Anticipated user classes and their characteristics
• Identify the favored user class
• User classes = subset of the stakeholders defined in V&S document

2.3 Operating Environment

• HW platform, OS version
• Geographical locations of users, servers, and databases
• Organizations that host related databases, servers, and websites
• Other SW with which the system must coexist

2.4 Design and Implementation Constraints

• Programming language, code library restrictions
• Factors that constrain developers and the rationale for each constraint
• Watch out for unnecessary design constraints - don't over-specify

2.5 Assumptions and Dependencies

• Assumptions about system functionality (business-related assumptions go in V&S)
• Dependencies on external components (e.g., a certain SW must be installed first)

3.x System Feature X (repeated for each feature)

4.1 Logical Data Model

• Visual representation of data objects and their relationships
• Use ER diagrams or UML class diagrams

4.2 Data Dictionary

• Composition of data structures
• Meaning, data type, length, format, and allowed values for each data element
• May be stored as a separate artifact for reusability

4.3 Reports

• Describe any reports to be generated and any layouts they must follow
• Defer detailed report layout to the design stage

4.4 Data Acquisition, Integrity, Retention, and Disposal

• How data is acquired and maintained (e.g., initial dump + incremental feeds)
• Techniques: backups, checkpointing, data accuracy verification
• Policies for retaining or disposing of data (temporary data, local copies, deleted records)

5.1 User Interfaces

• References to UI standards or product style guides
• Standards for fonts, icons, button labels, images, color schemes, field tabbing sequences
• Screen size, layout, or resolution constraints
• Standard buttons/navigation appearing on every screen (e.g., help button)
• Shortcut keys, message display conventions
• Data validation guidelines
• Accommodations for visually impaired or color-blind users

5.2 Software Interfaces

• Connections to other SW systems (name + version), message formats, data exchanged
• E.g., other applications, databases, websites, OS, commercial components
• Input/output data mappings and translations between systems
• Services needed from external SW components

5.3 Hardware Interfaces

• Characteristics of each interface between SW components and HW components
• Supported device types, communication protocols
• Lists of inputs/outputs, their formats, valid value ranges, and timing

5.4 Communications Interfaces

• Communication functions: email, web browser, network protocols, electronic forms
• Message formatting standards
• Communication security and encryption, data transfer rates
• Constraints on interfaces (e.g., acceptable email attachment types)

6.1 Usability

• Ease of learning, ease of use, error avoidance and recovery
• Efficiency of interactions, and accessibility
• Helps the UI designer create the optimum user experience

6.2 Performance

• Specific performance requirements for various system operations
• If different functional requirements have different performance needs, specify those together

6.3 Security

• Requirements regarding security or privacy issues that restrict access/use
• Security requirements often originate in business rules - reference the business rules document if it exists

6.4 Safety

• Requirements about possible loss, damage, or harm from using the product
• Safeguards or actions that must be taken
• Potentially dangerous actions that must be prevented

6.x Others

Create a separate section for each additional quality attribute important to customers, developers, or testers:

What to Address

8. Other Requirements

Requirements not covered elsewhere in the SRS, such as:

• Legal, regulatory, or financial compliance and standards requirements
• Requirements for product installation, configuration, startup, and shutdown
• Logging, monitoring, and audit trail requirements

Appendix A: Glossary

• Define specialized terms, acronyms, and abbreviations
• Consider building a reusable enterprise-level glossary
• Note: Data definitions belong in the data dictionary, not the glossary

Appendix B: Analysis Models (Optional)

• Data flow diagrams, feature trees, state-transition diagrams, ER diagrams
• May be better placed inline in relevant sections rather than all at the end

The Golden Rules of SRS Writing

Quick Reference - What Goes Where

Exam Checklist - Things to Remember