Detailed on each

Whats the point of it?

• Figure out what you need to build

• Used to guide you though development

• Used to see if you have built what you intended to

• Should be concise

What should it be like?

Clear

• Clear, Concise, Easy to understand

• NOT vague nor ill-defined

• Can abbreviate only IF EVERYONE KNOWS WHAT IT IS

• No waffle to sound smart

Unambiguous

• You have got to tell what it requires

• Words like "best" and "faster" and "user-friendly" are BAD, need to be quantified

• Make sure you can only interpret them one way

Verifiable

• Can undisputedly be proven it has or hasn't been delivered

• Example - "Process at least 100 work orders per hour on average during a typical work day."

• Above define what a working day is

Consistent

• Dont let requirements contradict each other

• Go though all the requirements and look for inconstancies

• “Fast, good, cheap. Pick two.” - try to stay inline with this saying

Prioritised

• Need to prioritise requirments

• Leave High-Cost and Low-Priority requirements till last

• MoSCoW
  • Must have
  • Should have
  • Could have
  • Wont have this time

MoSCoW Rules

Must Have

"The project absolutely must have, find anyway to not put it here"

• Without this there is no point in delivering the solution

• Illegal without

• Unsafe without

Should Have

"Very painful to live without"

• Important but not a vital

• Painful without, but is still viable

• May need a workaround (even if temporary)

Could Have

"Only for best case scenario, first requirements to be dropped"

• Wanted but is less important

• Not much impact without it

Wont Have This Time

• Requirement the team has agreed wont be delivered

• Recorded so that in the future there are requirements to be added in updates

Verifiable