Software Specifications Review (SSR)

• Presenters
• Participants
• Time
• Agenda
• Materials Distribution
• Key Issues to be Addressed
• SSR Hardcopy Material
• Requirement and Functional Specifications Template
• Requirements Analysis Report

Presenters
Requirements definition team

Participants

• Customer representatives
• User representatives
• Senior development team representative(s)
• QA representatives

Time
After requirements definition is complete and before the requirements analysis phase begins.

Agenda
Selective presentation of system requirements, highlighting operations concepts and critical issues (e.g., TBD requirements)

Materials Distribution

• The requirements and functional specifications document is distributed 1 to 2 weeks prior to SSR.
• Hardcopy material is distributed a minimum of 3 days before the SSR.

Key Issues To Be Addressed

• What is the effect of the TBD items?
• What timetable has been established for resolving TBD items?
• Have all external interface requirements been defined?
• Are operational methods and performance constraints understood (e.g., timing, accuracy)?
• Is the project feasible, given the constraints on and assumptions about available resources?

SSR Hardcopy Material
An outline and suggested contents of the SSR hardcopy material are presented below.

1. Agenda - outline of review material.
2. Introduction - purpose of system and background of the project.
3. Requirements summary - review of top-level (basic) requirements developed to form the functional specifications.
4. Background of requirements - overview of project characteristics and major events.
   1. Derivation of requirements - identification of input from project office, support organization, and system engineering organization used to formulate the requirements, support instrumentation requirements document (SIRD), memoranda of information (MOIs), and memoranda of understanding (MOUs).
   2. Relationship of requirements to level of support provided - typical support, critical support, and special or contingency support.
   3. Organizations that provide system and support input and receive system output.
   4. Data availability - frequency, volume, and format.
   5. Facilities -target computing hardware and environment characteristics.
   6. Requirements for computer storage, failure/recovery, operator interaction, system error recovery, and diagnostic output.
   7. Requirements for support and test software - data simulators, test programs, and utilities.
   8. Overview of the requirements and functional specifications document - its evolution, including draft dates and reviews and outline of contents.
5. Performance requirements - system-processing speed, system response time, system failure recovery time, and output data availability.
6. Derived system requirements - List of those requirements not explicitly called out in the requirements document but representing constraints, limitations, or implications that must be satisfied to achieve the explicitly stated requirements.
7. Operations concepts
   1. High-level diagrams of operating scenarios showing intended system behavior from the user's viewpoint.
   2. Sample input screens, menus, etc.; sample output displays, reports, plots, etc; critical control sequences.
8. Requirements management approach
   1. Description of controlled documents, including scheduled updates.
   2. Specifications/requirements change control procedures.
   3. System enhancement/maintenance procedures.
9. Personnel organization and interfaces -
10. Milestones and suggested development schedule -
11. Issues, TBD items, and problems - a characterization of all outstanding requirements     issues and TBDs, an assessment of their risks (including the effect on progress), and a course of action to resolve them, including required effort, schedule, and cost.

Requirement and Functional Specifications Template
The requirement definition team as the key product of the requirement definition phase produces this document. It is often published in multiple volumes: volume 1 defines the requirements, and volume 2 contains the functional specifications. The document is distributed prior to the SSR. Functional specifications are updated during requirement analysis and baseline following the SSR.

1. Introduction -
   1. Purpose and background of the project.
   2. Document organization.
2. System overview -
   1. Overall system concept.
   2. Expected operational environment (hardware, peripherals, etc.).
   3. High-level diagrams of the system showing the external interfaces and data flows.
   4. Overview of high-level requirements.
3. Requirements - functional, operational (interface, resource, performance, etc.), and data requirements
   1. Numbered list of high-level requirements with their respective derived requirements (derived requirements are not explicitly called out in the requirements document but represent constraints, limitations, or implications that must be satisfied to achieve the explicitly stated requirements)
   2. For each requirement:
      1. Requirement number and name.
      2. Description of the requirement.
      3. Reference source for the requirement, distinguishing derived from explicit requirements.
      4. Interfaces to other major functions or external entities.
      5. Performance specifications - frequency, response time, accuracy, etc.
4. Functional specifications -
   1. Discussion and diagrams showing the functional hierarchy of the system.
   2. Description and data flow diagrams of the basic functions of each major subsystem.
   3. Description of general conventions used (mathematical symbols, units of measure, etc.).
   4. Description of each basic function.
      1. Input.
      2. Process - detailed description on how this function should work.
      3. Output.
      4. Identification of candidate reusable software.
      5. Acceptance criteria for verifying satisfaction of related requirements.
      6. Data dictionary - indicating name of item, definition, structural composition of the item, item range, item type.
5. Mapping of functional specifications to requirements - also distinguishes project-unique requirements from standard requirements for the project type.

Requirements Analysis Report
The development team at the conclusion of the requirement analysis phase prepares this report. It summarizes the results of requirement analysis and establishes a basis for beginning preliminary design. The suggested contents are as follows:

1. Introduction - purposes and background of the project, overall system concepts, and document overview.
2. Reuse proposal - key reuse candidates and overall architectural concept for the system.
3. Operations overview - updates to operations concepts resulting from work performed during the requirements analysis phase.
   1. Updated operations scenarios
   2. Operational modes - including volume and frequency of data to be processed in each mode, order and type of operations, etc.
   3. Updated descriptions of input, output, and messages
4. Specification Analysis
   1. Summary of classifications (mandatory, derived, "wish list", information only, or TBD) assigned to requirements and functional specifications
   2. Problematic specifications - identification and discussion of conflicting, ambiguous, infeasible, untestable, and TBD requirements and specifications.
   3. Unresolved requirements/operations issues, including the dates by which resolutions are needed.
5. System Constraints
   1. Hardware availability - execution, storage, peripherals
   2. Operating system limitations
   3. Support software limitations
6. Development Assumptions
7. Risks – both to costs and schedules. These should include risks related to TBD or changing requirements, as well as technical risks
8. Prototyping efforts needed to resolve technical risks, including the goals and schedule for each prototyping effort
9. Data Flow or object oriented diagrams – results of all functional decomposition or object oriented analysis of the requirements performed during the requirements analysis phase.
10. Data dictionary - for the updated processes, data flows, and objects shown in the diagrams.