Technical writing/Specification exercise chair - Alan

From Wikiversity
Jump to navigation Jump to search

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.