SRS

The Software Requirements Specification (SRS) is the final product of this course. It is the outcome:

  • of your team’s progression from an idea for a project;
  • to seeking the users’ requirements and their feedback on your ideas;
  • to devising the software requirements (only) of a potential solution to the users’ key problems and requirements;
  • to documenting your software requirements insufficient detail for others to understand, to design and develop a product or test plan from, or to certify.

The SRS video describes the purpose, content, and format of each of the sections of the SRS. The video is based on the ISO/IEC/IEEE International Standard on Requirements Engineering. Many of the sections will include updated artifacts that you have been developing all term, specifically:

  • Use Case Diagram and descriptions for at least three rich orthogonal use cases
  • Dataflow Diagrams OR Activity Diagrams for these three use cases
  • User Stories for these three use cases
  • User Characteristics (in part from your personas)
  • Assumptions (about the environment, about dependent systems and infrastructure, about the fidelity between system inputs/outputs and the real-world phenomena being monitored and controlled)
  • Quality Requirements (three highest-priority quality attributes, with objective metrics and rich fit criteria)
  • (specification-level) Domain Model
  • Scenarios
  • Annotated UI sketches
  • Navigation Diagram

Keep in mind that the final document is expected to be a single coherent, internally consistent technical document. Thus, the above need to:

  • all be with respect to the same three, rich, orthogonal use cases
  • all be mutually consistent with respect to the vocabulary used (e.g., f or actors, information) and with respect to the requirements, functionality, interfaces, behaviour, etc. being specified
  • updated with respect to the TA’s feedback (updates to the UI sketches should incorporate feedback from interviewees who participated in the Solution-Fit Interviews as well as feedback from the TAs)

There are some sample SRSs from previous terms on the Resources→SRS Examples course Web page that are useful as references on how previous terms’ project teams specified particular aspects of their SRS. There is a complete SRS for a PBX Information System, there is the SRS for the WATTalk project, and there are several partial SRSs for automative software features. Do not use these as your sole guide for your SRS. What past project teams were asked to produce does not correspond exactly to what you are being asked to deliver this term (for example, the international standard has changed). So, focus on what is being asked for in the video on SRSs, the current international standard on SRSs, and the marking scheme.

Marking Scheme: The SRS is not due until Tuesday, April 6th.

The marking scheme gives the SRS 20 CoursePoints (from Deliverables). The rubric is out of about 295 points, allocated as follows:

  • ~10pts: Introduction
  • ~60pts: Overall Description
  • ~70pts: Interface Specifications and Domain Model
  • ~50pts: Scenarios
  • ~60pts: State Machine Models
  • ~20pts: Quality Requirements
  • ~15pts: Front/Back matter
  • ~10pts: Readability and structure

Each of these areas will be marked on the basis of its Completeness (with respect to sections of the SRS and use cases), its Coherence and Consistency, its Level of Detail, and its Correctness (with respect to modelling syntax and conventions).