-
Notifications
You must be signed in to change notification settings - Fork 2
Requirements specification
At the start of the project, use this template to collect and record the project's requirements.
A table indicating any major revisions to the Requirements document. Table should be in reverse chronological order, i.e., the first item is the latest (and currently active) version of the document. Example:
| Version | Date | Major changes |
|---|---|---|
| Document version nr | Date it was created / approved | Significant changes introduced by the revision |
| Name | Role | Affiliation | |
|---|---|---|---|
Section containing any background information on the project.
A short description of the project and/or the specific RSE role in a larger project. Aim for clarity and readability.
Larger or more complex projects might have aspects of it that fall out of scope. Use this sections to make that distinction if necessary. For example, a project that, for the duration of its funding, only expects a few dozen users but that plans to be scale and become commercialised after the end of funding. Projects that will have sections of it contracted out (for example design spec) will also benefit from this distinction. Use the following headings to make clear what is the responsibility of the RSE team and what is not.
Larger projects that have multiple stakeholders (which might have differing and conflicting requirements) can be briefly described here.
If the project is building on existing software please list all technologies here, including whether these will need updating or rebuilding, or whether they should not be touched.
Use this section to make any necessary notes on project data (whether it has been collected, it uses an existing dataset, it has any special considerations, its structure, organisation, sources, etc.)
Use this section to record any decisions made on the technologies we will implement. The following headings are simply suggestions, feel free to re-organise as needed. Use the rationale section in particular if there are certain decisions made that have serious implications (i.e., needs to be a static generated site because the project has no budget for on-going maintenance, for example).
A table that records all project requirements. Requirements should, ideally, be transformable into issues or items in the backlog. Both functional and non-functional requirements can use the same suggested table headings.
| Requirement | Priority | Essential? | Stakeholder (optional) | Met? |
|---|---|---|---|---|
| Brief description of the requirement | Requirement priority in some consistent typology (low / medium / high) | Y or N (if not essential considered 'good to have') | If multiple stakeholders with differing requirements | Whether requirement has been met at end of project (Y or N) |
These are the requirements that the end user specifically demands as basic facilities that the system should offer. All these functionalities need to be necessarily incorporated into the system as a part of the contract.
Example: The system should support two factor authentication for administrators.
These are the quality constraints that the system must satisfy according to the project contract. The priority or extent to which these factors are implemented varies from one project to another. They are also called non-behavioral requirements. They deal with issues like:
- Portability
- Security
- Maintainability
- Reliability
- Scalability
- Performance
- Reusability
- Flexibility
Example: The system should comply with GDPR regulations.
Any useful information that could justify or explain the decisions made by the project.
Any constraints that have been put on the project that will explain why certain decisions were made. (For example, no budget for ongoing maintenance explaining the decisions to go static)
Any assumptions made that explain why certain decisions were made. (For example, assume the data comes from an existing dataset and will be accessed via an API, therefore no data storage was accounted for)
Modifications made to the project, who requested them and why -- these can be any modifications from the initial grant, to modifying requirements.
A list of questions to be put to the PI and the project team in the initial meeting(s) to clarify requirements, brief, infrastructure decisions, etc.
Larger projects might have sections of work divided into work packages with discrete teams, objectives, and requirements (for example: data gathering, data analysis, web app, mobile app). Use this section to document those work packages if necessary. At a minimum, it should have a brief description of each package.
Use this section to identify any risk factors that might jeopardise project delivery, or expose the project to attacks / litigation, etc. For example, projects making use of sensitive or protected data, or projects with critical dependencies on other work packages.
Use this section to keep a log of any relevant discussions or actions taken in the project.