Commented IEEE 830-1998

---

• Table of Contents
• 1 Introduction
  • 1.1 Purpose
  • 1.2 Scope
  • 1.3 Definitions, acronyms, and abbreviations
  • 1.4 References
  • 1.5 Overview
• 2 Overall Description (largely textual restatement of C-reqs as you understand them)
• This section of the SRS describes the general factors that affect the product and its requirements. It does not state specific requirements, it only makes those requirements easier to understand.
  • 2.1 Product perspective
  • This subsection should not prescribe specific design solutions or design constraints on the solution. Rather it needs to explain why certain design constraints are specified in section 3. E.g.:
    • - What it the project from the customer's point of view? What niche does it fill?
    • - Is the product self contained? (standalone?)
    • - Is it part of a larger system? (which one?)
    • - Give high-level overview of the fundamental external interfaces (User interface, hardware interface,software interfaces, communications, etc).
    • - Note any known hardware/software to be used
    • - What are the concepts involved? How do they relate? (Conceptual diagram?)
  • 2.2 Product functions
  • This subsection provides a summary of the functions that the software will perform. It will discuss major functional areas without mentioning any of the large amount of detail that goes with those areas. The functions need to be organised so that the customer will understand them.
    • - High level summary of functions to be performed
    • - Data flow diagrams
    • - Reasons for specific requirements (relate them to the business processes that they support)
  • 2.3 User characteristics
  • This subsection describes the general characteristics of the users that will influence the SRS.
    • - Experience
    • - Technical Expertise
    • - Operational Environment (frequency of use: constant? occasional?; other expectations
  • 2.4 Constraints
  • This subsection gives a general description of any other items that will limit the developer's design options.
    • - Regulatory policies.
    • - Hardware/system software resource limitations (i.e. memory, disk space, OS, thread count, etc).
    • - External interfaces.
    • - Audit requirements.
    • - Communications protocols.
    • - Application criticality / Real time constraints
    • - Operations (i.e. unattended operation or supervised?).
    • - Anything else...
  • 2.5 Assumptions and dependencies
  • Define assumed factors that would cause the SRS to change should the assumption be incorrect. The successful operation of the system is dependant upon the following assumptions and dependencies. Acceptance of this specification means acceptance of the risks associated with these issues.
    • - Hardware Availability
    • - Behaviour and interface of external systems
  • 2.6 Apportioning of requirements
  • This subsection is used to describe which requirements are intended to be included in the project at the current date. It should also specify when (if ever) the remaining requirements will be implemented. Since this document typically constitutes a contract between developer and customer, you also need to specify the procedure and justification that will allow modification of the requirements.
    • - Which requirements will be left until later?
    • - When are they expected to be added?
    • - When are requirements-adjustments allowed?
    • - Through what process will they be negotiated?
• 3 Specific requirements (very detailed, well illustrated exposition of the requirements from the developer's point of view)
• This section contains a description, in final detail, of all requirements that must be satisfied by the software. This is the document that the customer must
  • 3.1 External Interfaces
  • What are the interfaces to your project? How will it be interacted with ? Can it be interacted with? This subsection describes every manner through which entities (users, software, foreign systems) may interact with your system.
    • - User interfaces
    • - Hardware interfaces
    • - Software interfaces
    • - Communications Interfaces
  • 3.2 Functions
  • This section describes, in final detail, all functional requirements of the system. They should be organized into a logical manner that facilitates easy reading. They should also be well-illustrated via Use- case/Data-flow/System-sequence diagrams.
  • 3.3 Performance Requirements
  • 3.4 Logical database requirements
  • 3.5 Design constraints
  • 3.6 Software system attributes
• Appendixes
• Index

Acknowledgements
Locations used	Source	URL (if applicable)
Description and breakdown of section 2	How to Write Software Requirements Specifications,David Tuffley	http://www.tuffley.aust.com/tcs20001contents.htm
Description and subsection breakdown of section 3	Software Engineering - An Object-Oriented Perspective, Eric Braude	N/A