Requirements versus Stories

In this article, we’ll compare and contrast the definition of a requirement, with a ‘story’, which is used in agile/scrum.

Both requirements and stories establish a clear understanding of customer needs in the context of desired functionality.

The framework for each is somewhat different, however.

Recall the definition of a requirement:

…a requirement defines “what the product (or process) design shall provide <output> at operating conditions <input>”

The framework of a story is as follows:

“as a <user> I want <action> so that <benefit>”

It can be seen that a requirement is somewhat more specific to the product design (or business sub-process).  The specific desired output @ input conditions is established.

In contrast, the story is a higher-level ‘need’ and benefit statement surrounding the desired functionality and is more closely associated with the ‘voice-of-customer’.  Stories can therefore be an important tool in virtually any project (including product development projects), even if agile methodologies aren’t used.

The example we’ll use is along the lines of a business requirement….let’s say we want to extract business intelligence data to provide a key performance indicator measurement (KPI): productivity.

The story might be:  As a functional manager, I want to be able to view a weekly measurement of productivity including performance trends.  I also want to be able to determine productivity trend drivers so countermeasures can be identified, and productivity improved accordingly.

A corresponding requirement might be somewhat more descriptive as follows:

“The productivity KPI view shall provide productivity (volume/work hours) where volume is defined as number of items and work hours is determined by time clock readings.  The view shall also include volume separately (since volumes can affect productivity).”

Also:  “Drill-down views shall show productivity of individuals by week and by day…etc.”  (Note: here we’re also defining ‘use cases’ which might also be considered a form of requirement as long as they’re output/input oriented).  Of course, the requirement might also include a graphic and/or the requirement can be validated with a working model of the productivity KPI tool being developed.

So the requirement is somewhat more specific, identifying the output (trend metric) and inputs (volume = items and time clock hours).  However, it fits with, and enables the benefit of the described by the story.

Stories and requirements are both quite useful.  Properly applied stories and requirements enables good critical thinking and the clarity that is necessary for high-quality project results.