9.4 Starting a conversation

The core to eliciting good requirements is having good conversations.

This is the function of ‘stories’ in the Agile method. Stories are a useful formalisation of conversations between requesters and producers.

Once these conversations, and consequently the associated stories, are mature enough (notice, not ‘complete’, they are never really complete), we are ready to formalise these stories into requirements. (On projects where Agile is being fully implemented—a customer advocate is on hand—the story may be appropriate as a requirement.)

This is an oft repeated error. Stories are generally not good requirements! They are close, but win no cigar. A story will typically yield more than one requirement. Not all requirements will have a story, but some requirements may lead to a story being generated if the development team need to clarify something (this clarification may lead to yet more requirements).

Stories have acceptance criteria, these are the closest to requirements.

9.4.1 Traceability—sexy!

Before we get too far into this let’s talk about traceability. One of the problems faced by a project of any size is traceability. How do we know that we have done the right thing and that we have done everything asked for and only the things asked for8?

For any given piece of the final system I want to be able to say, ‘this feature was requested in requirement by’. If I cannot answer this basic question then why does this feature exist? Why did we expend resources to create it? Why did we adopt the cost of increased product complexity and maintenance?

All the cycling through requirements and stories in §9.4 leads to a history for requirements, this is another dimension of traceability.

If you work in a regulated environment you will find a need to maintain detailed audit-able traceable records. Generally, the more regulated your environment the stricter your traceability requirements. That said, regardless of any external requirements your project will benefit from effective traceability.

Traceability requires that we clearly and unambiguously identify each project asset. Identity schemes are an extended topic, there are as many schemes as there are projects (or so it often seems).

8Delivering more than requested means we are ‘giving away’ project resources.