Deliverable 2: Requirements Specification
Updated Requirements Specification - 21 Sep 2015
Following the session on writing requirements, and seeing the documents produced by students, the requirements specification will be simplified to contain TWO sections (each with sub-sections) only:
- 1. System Description
- 1.1 Perspective
- 1.2 Functions
- 2. Requirements
- 2.1 xxx (use sub-sections related to your functions/features)
- 2.2 xxx
That is, you should not have separate sections for "Interface Requirements", "Design Constraints" etc. Simply list all requirements, including interface, functional, performance, constraints, under Section 2. However you should use sub-sections, based on the functions/features of your system.
Also, according to feedback to simplify the template, you can:
- Delete the title page
- Delete the 'Table of Contents' page
- Add the project information at the start of the first page, similar to the Project Concept
The following is the old instructions. The information still applies, however the structure/format of the document is changed.
A list of things that are required of the system for it to be completed successfully. This list requires input from the client. The final version of the requirements specification will be used in evaluating the project, i.e. which requirements were (not) met.
The organisation of the requirements specification may take different forms. The following is one organisation you may use; other examples are listed in “IEEE Recommended Practice for Software Requirements Specifications” (download the PDF from IEEExplore within SIIT). The following is a simplification of that recommended by IEEE. Each section may or may not be divided into subsections.
1. System Description
2. Interface Requirements
3. Functional Requirements
3.1 Feature A
3.2 Feature B
4. Performance Requirements
5. Design Constraints
6. System Attributes
Content Type(s): mainly text, which pictures in System Description
Length: several to tens of pages
A template for Word (.doc) and LaTeX (.tgz) is available for the Requirements Specification (it can also be used for other documents). You may use these or other document formats (.odt, .pages, ...), so long as the resulting PDF is similar to that produced by the templates. Here is an example PDF.
A brief description of the system (1 or 2 paragraphs), followed by the perspective and functions.
The Perspective sub-section explains how the system fits into a larger system (or if it is a self-contained system). Users should also be considered. For example, if your project is a online course evaluation system, then it may have to interface to the registration system (to get course and student information). Therefore you would explain this as part of the perspective. A good way to explain this is with the aid of a block diagram, which each block showing the different systems (e.g. one of them is yours, one is registration system and one is users).
The Functions sub-section lists the set of functions or features of your system. It may be useful to get each a short name, and then describe it in 2 or 3 sentences. Also, a block diagram can be used to show the functions and the relationship between each.
Writing Requirements, Constraints and Attributes
The next sections are the main parts of the Requirements Specification. They define what the system is required to do. The Interface and Functional Requirements are perhaps the most important. Performance requirements may not be relevant or easy to define for some groups, and design constraints may not be present for many groups.
Interface, functional and performance requirements can be grouped as “functional” requirements: they define how the system should function. For example, “The system must do ...”. Non-functional requirements define what the system should be, such as properties or attributes of the system, e.g. “The system must be ...”.
List all the requirements of the interfaces of your system to users and other systems. Note these are external interfaces only (not interfaces between different functions or blocks of your system). For example, with the course evaluation system, there are interfaces with the users and interfaces with the registration system. The requirements of those interfaces must be listed here.
List all the actions that must take place in the system. Usually these will be grouped into sub-sections based on feature. For example, with the course evaluation system there may be a feature of “Statistics Collection” and another feature of “User Login”. The requirements of each feature should be listed in separate sub-sections.
List all the requirements of the performance of the system. These must be described in measureable terms. For example, for the course evaluation system a performance requirement may be: “The system must generate a printable PDF report in less than 10 seconds.”. (A non-measureable requirement may be “The system must generate a printable PDF report in a short amount of time” - there is no way to check if this requirement is met or not).
List any constraints on the design, such as constraints imposed on hardware, meeting standards, legal or regulatory requirements.
List any required attributes of the system in terms of: reliability, availability, security, maintainability, portability, compatibility, ... . See the Wikipedia page on “Non-functional Requirement” for a longer list of examples.
Numbering and Formatting Requirements
Every requirement should be given a unique identifier, so that you can later refer to an individual requirement. A simple scheme is to number each, e.g.
Requirement 1. The system must support users with names up to 60 characters.
Requirement 2. The system must support users with names both English and Thai character sets.
Requirement 3. ...
However you can choose other schemes, so long as each requirement can be uniquely identified. E.g. FR1, FR2, ... for functional requirements, PR1, PR2, ... for performance requirements.