System Requirements Specification

Definition

System Requirements Specification (SRS)

the requirements work product that formally specifies the system-level requirements of a single system or an application

Objectives

The typical objectives of a system requirements specification are to:

• Provide an overview of the application’s context and capabilities.
• Formally specify the application’s system-level requirements including its:
  • Functional Requirements.
  • Data Requirements.
  • Quality Requirements.
  • Constraints.
• Document any future planned enhancements.
• Document any open issues, major things to be completed, and assumptions.”
• Provide a baseline for:
  • Application validation.
  • Acceptance of the application by the customer organization.
• Be a basis for:
  • Establishing the scope, size, and complexity of the application and its related project(s).
  • Estimating the associated costs, schedule(s), and progress.
  • Future extensions and enhancements to the application.

Benefits

The typical benefits of a system requirements specification include:

• It helps to establish a consensus among the application’s stakeholders concerning its system-level requirements.
• A well-specified set of requirements reduces endeavor risks due to poorly analyzed, specified, and managed requirements.
• The requirements specified in the system requirements specification set the scope, size, and complexity of the application.
• The requirements specified in the system requirements specification drive the system architecture, design, implementation, and testing activities.

Contents

The typical contents of a system requirements specification include:

• System Overview:
  • System Definition
  • Businesss Goals
  • Business Objectives
  • System Context
  • Summary of System Capabilities
• Functional Requirements:
  • External (Actor) Types:
    • Externals (e.g., Actors):
      • Essential Use Cases:
        • Essential Use Case Paths
• Data Requirements:
  • Requirements Data Model
    (e.g., Business Object Model or Logical Data Model)
  • Required Data Type Descriptions
    (e.g., data dictionary with textual definitions and associated data expressions, XML DTDs)
• Quality Requirements:
  • Developer-Oriented Quality Requirements:
    • Maintainability:
      • Correctability
      • Extensibility
    • Portability
    • Reusability
    • Scalability
    • Testability
  • User-Oriented Quality Requirements:
    • Auditability
    • Branding
    • Capacity
    • Configurability:
      • Internationalization
      • Personalization
      • Variant Capabilities
    • Correctness:
      • Latent Defect
      • Accuracy
      • Precision
      • Timeliness
    • Dependability:
      • Defensability:
        • Safety
        • Security:
          • Access_Control:
            • Identification
            • Authentication
            • Authorization
          • Immunity
          • Integrity
          • Intrusion Detection
          • Nonrepudiation
          • Privacy
          • Security Auditing
          • Survivability
          • Physical Protection
          • System Maintenance Security
      • Operational Availability
      • Reliability
      • Robustness
    • Efficiency
    • Interoperability
    • Operational_Environment_Compatibility
    • Performance:
      • Jitter
      • Latency
      • Response Time
      • Schedulability
      • Throughput
    • Utility:
      • Accessibility
      • Installability
      • Operability
      • Transportability
      • Usability
• Constraints:
  • Physical Constraints
  • Business Rules:
    • Calculations
    • Logical Constraints
    • Logical Inferences
    • Physical Facts
    • Triggering Events
  • System Component Specific Constraints:
    • Data and Content Constraints
    • Hardware Constraints
    • Software Constraints
    • Personnel Constraints
  • Industry Standards
  • Legal and Regulatory Constraints
  • Production Environment Constraints
• Appendices:
  • Envisioned Future Enhancements
  • Tentative Requirements
  • Desirable Functional and Nonfunctional Capabilities (“should”)
  • Nice to Have Capabilities
  • Permitted Capabilities (“may”, if any)
  • Rejected “Requirements” (e.g., out of scope or inconsistent)
  • Major Issues
  • Major Items To Be Determined
  • Assumptions

Stakeholders

The typical stakeholders of a system requirements specification are:

• Producer:
  • Requirements Team (manual production)
  • Documentation Tool (automated production)
• Evaluator:
  • Requirements Inspection Team
• Approvers:
  • Technical Leader
  • Project Manager
  • Customer Representative(s)
• Maintainers:
  • Requirements Team (prior to delivery)
  • Maintenance Team (after delivery)
• Users:
  The System Requirements Specification is typically used by practically every endeavor organization and team including:
  • Organizations:
    • Customer Organization, which uses it to understand the scope of the application to be delivered.
    • Development Organization, which use it to drive their work.
    • Maintenance Organization, which use it to constrain their maintenance work.
    • Partner Organization, which use it to understand the application.
    • Subcontractor Organization, which use it to drive their work.
    • Support Organization, which uses it as input to the users manual and user support materials.
    • User Organization, which may use it to understand the application.
  • Teams:
    • Architecture Team, which uses it to drive and validate the system architectures.
    • Hardware Development Team, which uses it to drive the design of the hardware components.
    • Independent Test Team, which uses it to generate system and launch test cases.
    • Maintenance Team, which uses the requirements in it to constrain maintenance updates.
    • Metrics Team, which uses the requirements in it to estimate the size and scope of the endeavor.
    • Project Management Team, which uses it to manage project scope and schedule project activities.
    • Security Team, which uses it to drive the design of the resulting security mechanisms.
    • Software Development Team, which uses it to drive the design of the software components.
    • User Experience Team, which uses it to drive and validate the human interface prototype.
    • User Support Team, which uses it as input to the users manual and user support materials.

Phases

A system requirements specification is typically produced during the following phases:

• Business Strategy: Not Applicable
• Business Optimization: Not Applicable
• Initiation: Started.
  During this phase, approximately 80% of the requirements are typically specified (e.g., all use cases and significant quality requirements are specified, but only some of the use case paths and specified and they may not contain all required information). During this phase, the emphasis is on the high risk and architecturally significant requirements.
• Construction: Completed
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

A system requirements specification typically can be started if the following preconditions hold:

• The requirements team is staffed and trained in requirements engineering.
• The following requirements engineering tasks have been started:
  • Business analysis
  • Application visioning
  • Requirements identification
  • Requirements analysis
• Initial versions of one or more of the input work products and stakeholders are available.

Inputs

The typical inputs to a system requirements specification include:

• Work Products:
  • Requirements:
    • Functional Requirements
    • Data Requirements
    • Quality Requirements
    • External API Requirements
  • Diagrams:
    • Context Diagram
    • Domain Object Diagram
    • Actor State Transition Diagram
    • Use Case Diagrams
    • Use Case Sequence Diagram
  • Models:
    • Data Models (Logical Data Models)
    • Object Models (Business Object Models)
    • Quality Models (which defines the scope of the quality requirements)
    • State Models
    • Use Case Model
  • Documents:
    • Actor Cards
    • Application Vision Statement
    • Business Case
    • Competitor Profiles
    • Contract
    • Customer Analysis
    • Domain Model Document
    • Glossary
    • Human Interface Prototype
    • Market Analysis
    • Requirements Executive Summary
    • Statement Of Work
    • Technology Analysis
    • Use Case Cards
• Stakeholders:
  • Customer Organization
  • Development Organization and Industry domain experts
  • Maintenance Organization
  • Marketing Organization
  • Support Organization

Guidelines

• The requirements specification is the foundation on which the architecture, design, and implementation are built. At best, a poor requirements specification is a shaky foundation on which to build an application. An incorrect requirements specification is like a foundation built in the wrong place, and we can all imagine how difficult and expensive it will be to move a large shoddy structure that was built in the wrong location. Thus, the requirements specification is one of the most critical documents of an endeavor.
• As described above, the contents of this document are very complete and intended for use for large, complex, business-critical or safety-critical applications. Inappropriate contents (e.g., the quality requirement types that do not apply) should be tailored out of the specification and its associated conventions during the process tailoring task.
• This is a living document that is developed incrementally and iteratively in parallel with other work products (e.g., requirements executive summary, domain model document, and system architecture document).
• Different parts of this document are due at different times (i.e., by different milestones).
• Some parts of this document should be mandatory and some parts should be optional.
• Not all requirements are contained in this document; specifically, required APIs to external applications are specified in the external API specification.
• Note that there is typically no need for a separate “software requirements specification” or “hardware requirements specification” on most projects although such documents can be produced if appropriate (e.g., for subcontractors).
• Do not concentrate solely on the use cases of the functional requirements. For example, many quality requirements may have a larger impact on the architecture, cost, and schedule than most functional requirements.
• Note that the quality requirements are too critical to be specified in a separate “Supplementary Requirements Specification”.
• Reuse use cases by using a combination of:
  • The major functions listed in the application vision statement.
  • The standard mapping from functions to use cases.
  • Reusable requirements based on functional areas (e.g., Content Management).

Conventions

A system requirements specification is typically constrained by the following conventions:

• Content and Format Standard (69 KB)
• Inspection Checklist (70 KB)
• Microsoft Word Template (188 KB)
• Use Case Guidelines
• XML Document Type Definition (DTD)

Examples

• Example System Requirements Specification (947 KB) for an on-line auction application