Requirements

The following material helps you draft and finalise requirements for your teams robots. The drafting process should occur as a group and be documented on your team wiki. You may find the discussion board of your Team Wiki useful for this.

There are 4 kinds of statements that can be made regarding the requirements of a project. You do not have to use all of them, but it is important that you specify requirements (and refine them if needed) before going ahead with implementation of the final robot.


 * 1) **Requirement** - Something that your final system must be able to do. For example: "The robot __**shall**__ move around the arena and react intelligently to obstacles". Be careful not to specify design guides into the requirements as well. "The robot shall use tactile switches placed at 90-degree spacing around the robot to sense obstacles and move back 20cm when ... etc". You can use R000, R001 etc to list out your requirements
 * 2) **Design** **Guide** - Design and implementation ideas that you have regarding the final system. For example: "The robot __**may**__ use differential drive with 2 drive wheels and 2 roller castors". Design guides are often specified after a related requirement as DGXXX.
 * 3) **Assumption** - Assumptions about what the client (unit staff in your case) will be providing. For example: "Arena will be roughly 3x3m in size". These can be specified after related requirements or on their own as AXXX
 * 4) **Caveat** - Things that are NOT required, basically a negative requirement. For example, after the requirement example above, one may wish to specify this caveat: "The robot will not sense the presence of the opposing robot". Note how this caveat example removes a subset of "requirement space". As such, caveats are often specified after a related requirement to clearly state what a system will not do. Caveats can be labelled as CXXX.

Note also that requirements may require building simple prototypes to test whether the requirement is "sane" or unachievable given your resources (time, expertise, money). Prototyping and testing is especially important when approach a new problem that you are unfamiliar with.

Example Requirements Specification kindly provided by Grey Innovation [|GRY-1000-0025-A-Sample Phase 1 Requirements Specification.pdf]