Explanation of the Requirements Template
From DIT Experimental Gaming Group
Purpose Of This Page
This page describes a requirement template that Garret is suggesting for use in the MLNPI project.
Clear requirements will clarify what people expect of the games in advance and save time during development.
Two Examples
Requirement Id: Req1_Languages_Equally_Represented
From Game Design: All Games
Description: each language must be equally well represented by multimedia content (including text)
Rationale: This is a mandate from the funding body
Originator: Joe Bloggs
Status: under discussion
Likelihood of change: low
How to measure success: each language has equal number of minutes of audio/video/textual content
Conflicts: none
Importance to Customer: medium
See Also: word dictionaries
Possible Implmentations/Further Notes We plan to use word dictionaries for textual content. A/V clips will be of a standard length of 1:30 minutes. Note: copyright must be considered.
Requirement Id: Req2_Present_Tense_Only
From Game Design: Escape from the Dungeon
Description: The language teaching elements of the game will only teach the present tense
Rationale: complex tenses will be too difficult for the target audience
Originator: Joe Bloggs
Status: accepted
Likelihood of change: low
How to measure success: The language team will confirm that all language elements in this game are present tense only
Conflicts: none
Importance to Customer: medium
See Also:
Potential Implementations/Further Notes:
The Template
Requirement Id:
This is just a label that people can refer to in discussion
From Game Design: what game does this requirement come from
If we are developing from use cases then we can trace the requirement back to its origin
Description: brief description of the requirement
This is what people think of as the requirement itself. This describes one single behaviour or attribute that the final product should have. It must be a clear, unambiguous, simple statement. It should not describe any design or implementation details. It should describe "what" not "how"
Rationale: a justification of the requirement
It’s important to record why a requirement is justified. It can highlight requests that have not yet been fully considered or thought through. This answers “why” a solution should be provided
Originator: the person who raised the requirement
In case people need to ask for more detail
Status: potential / under discussion / accepted / dropped / delivered
This just helps keep track of what stage a requirement is at. All ideas are potential requirements. A requirement should only be accepted once it has been discussed, clarified, reviewed, and agreed on.
Likelihood of change: how likely is this requirement to change in the future: low / medium / high
Highly changeable requirements can lead to costly rework for the developer. If we can anticipate change then we can design for minimum disruption accordingly.
How to measure success: an empirical measure to test if the solution matches the original requirement
How can we measurably prove that a requirement has been satisfied? This avoids disagreement or disappointment during user acceptance testing and product hand-over.
Conflicts: other requirements that cannot be implemented if this one is implemented
Sometimes requirements will contradict each other, it is best to resolve these before development begins.
Importance to Customer: how important is this requirement for the customer: low / medium / high
Users should prioritise requirements in case the project cannot deliver all that the customer asks for due to time/money constraints.
See Also: Link to supporting material...
Are there any external resources or other requirements that are relevant here?
Possible implementation / Further notes:
People will often state requirements by describing specific implementations. It’s useful to know what the user has in mind, but it may prevent the developer from using a better implementation. If the user states a specific implementation then record it here as one possibility, then derive the underlying requirement that led to their suggestion.
