Standard Template
COMP50315: SOFTWARE ENGINEERING FOR THE INTERNET
2016/17
Requirements Document
Project Name:
Team Number:
Team Members:
The document must include the following:
1. Summary
An overview, justification and the proposed goals for the system e.g. here you should provide a description of what the system does or sets out to do – “Our brief is to develop a system that ..” you should also provide why the system is needed. You should explain what the software product will and if necessary will not do (think of any boundaries of the system). This section should describe all relevant benefits, objectives and goals as precisely as possible (maximum of 2 pages).
2. Domain Analysis
This is research into the background to the problem domain. This describes the business environment that the project would typically fit in to. Are there other similar type systems already available; what are their key features (positive and negative) that could be adopted in the proposed system? For example, for a Patient Records system, the domain analysis would describe what systems may exist already, and what kinds of processes it supports (maximum of 2 pages).
3. Solution requirements
This will be the largest and most important section of the document. Each requirement should be: correct, traceable, unambiguous, verifiable, prioritised, complete, consistent and uniquely identifiable. Attention should be paid to the careful presentation of the requirements so they can be easily accessed and understood.
a) Functional requirements:
Your functional requirements (FR) must follow a suitable numbering and naming format which is for you to decide. The table below shows how each requirement should be presented. The expected results will be used to determine at the point of acceptance testing if the requirement has been fulfilled As a minimum all ‘High’ priorities must be implemented. If desired, some requirements may be better or more easily specified in the use case format and listed in a use case section (only if you think this is helpful!).
2
ID, type and title
e.g. FR1.2 Mobile application – filtering results.
Description
A use can filter results in a list or a map. When viewing the results in a list or a map a user should be able to filter the results ……… Filtering options provided are:
· Filter by choosing a restaurant type
· Filter by a specific food dish
Priority
e.g. High
Dependencies
e.g. N/A or FR7 and FR20
b) Non-functional Requirements:
Non-functional Requirements (NFR) may exist for the following quality measures. Often these requirements must be achieved at a system-wide level. State the requirements in measurable terms. These can be presented in tabular form (as for FR) or whichever form clearly shows them:
· Performance
· Reliability
· Availability
· Security
· Maintainability
· Portability
For example:
Performance
Customer details should be retrievable within 5 seconds.
Security
Supervisor privileges is required to delete a customer.
4. Definition of terms, references
All terms, acronyms and abbreviations used within the document must be defined alongside a brief description. References to all sources you use must be listed. This includes technical support documentation and websites.
3