Technical writing/Specification exercise chair - Alan
Exercise 1
[edit | edit source]Structure
Must have a tubular frame
Will have 4 legs
Will have arm rests (plastic)
Must have a back rest (fabric)
Must have a seat (fabric)
Will use nuts & bolts for connecting components
Will have feet for legs
Use
The chair must hold a user when they sit on it
The chair must be sturdy enough to enable a user to stand on it
The chair must enable a user to lie on it (when used in tandem with other chairs)
The chair must enable a user to be affixed to the chair through use of binding materials
The chair must enable the user to hold objects up to a combined weight of 150kg
The chair must enable a juggler to use the chair as part of a defined balancing trick
The chair must pass the defined standards in order to be used as a barrier and shield
The chair design must enable stacking with other chairs
The chair must enable a child up to height of 100cm to hide under it
The chair must pass defined acceptability standards in order to represent a symbol of power
The chair must enable its use as a table
The chair must pass defined acceptability standards in order to enable use as a fashion / style icon
The chair must allow it to be used as a representation of another object
Users
Grandmother
Electrician
Homeless
Hostage
Startup businessman
Juggler
Soldier
Caretaker
Child
King
Mother
Guru
Architect
Users demand functions, which demand structures --> Requirements
SDLC
[edit | edit source]The idea - initialization, analysis and planning (creating requirements)
Building the idea - design, development, testing and integration (updating requirements)
Using the idea - delivery, maintenance, improvement (complete requirements)
... but without accurate requirements, none of this works!
Good requirements
[edit | edit source]Necessary, unambiguous (no vague terms), concise, consistent, complete, reachable (money, resources, time), testable, traceable
Use - strong commands, strong prohibitions (shall, must, will, must not, cannot, may not, shall not)
Do Not Use - weak suggestions, useless generalities (can, may, should, big, small, easy, friendly)
Provide examples, cite references, use tables and charts, use careful word order, keep it short, use consistent terminology, break it down into chunks and gloms
Successful projects spend at least 25% of the time on analysis and requirements specification.