43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
# Requirements
|
|
|
|
## Introduction
|
|
|
|
This document contains the user stories and requirements for the cosms (c open source media station) project. The whole application is based around the requirements set in this document. If at any point in the futhere there are any new requirements they should be documented here before the feature is implemented.
|
|
|
|
## How to document
|
|
|
|
When documenting the user stories and requirements there are a few rules that have to be followed to make sure that they are consistent and do not miss any important information.
|
|
|
|
### User stories
|
|
|
|
For the user stories the following format will be used:
|
|
|
|
```
|
|
Code: US-[user story number]
|
|
Description: As [type of user], I want [an action] so that [the benefits/value]
|
|
```
|
|
|
|
Using this structure helps identify who wants what and why. This method of documenting user stories focuses more on the value than the technical details making sure the needs of the user are met. To validate if the user story was implemented right accaptance criteria will also be setup along side the user stories. These accaptance criteria tell us when the user story can be seen as complete/accaptable. For documenting the accaptance criteria the following format will be used:
|
|
|
|
```
|
|
Accaptance:
|
|
* Given [how things begin] when [action taken] then [outcome of taking action].
|
|
```
|
|
|
|
These accaptance criteria will be placed in a list underneath the user story it is a part of as this will make it easier to find.
|
|
|
|
### Requirements
|
|
|
|
The requirements come forth from the user stories and define the functional and non-functional requirements the application must meet. When setting up the requirements the following format will be used:
|
|
|
|
```
|
|
Code: RQ-[requirement number]
|
|
User story: [the code of the user story this requirements comes from]
|
|
User: [the user this requirements comes from]
|
|
Requirement: [the requirement itself]
|
|
Type: [is it a functional or non-functional requirement]
|
|
Quality attribute: [ISO-25010 standard quality attribute (only for non-functionals)]
|
|
Priority: [how important is the requirement (low, medium, high, highest)]
|
|
```
|
|
|
|
By using this format the requirement will be easly retracable to the user story and user where it originated from. It also tells the type and importance of the requirements allowing us to more easly decide which requirement will be implemented first.
|