Archive

Archive for May 27, 2011

User story vs use case vs “what are we trying to accomplish”

May 27, 2011 2 comments

User story vs user case …

Word documents capturing functional requirements …

Word documents – as attachments – capturing non-functional requirements …

I believe that the reason why this dialog remains very active is simple. Every framework, approach, methodology is – “a virtual construct upon reality” (not my words) that we – as humans – need as a structure to solve a particular problem.

Since every problem is unique, in almost every instance we need to find the right balance between techniques available to us.

The key in any problem definition:

– Identify interaction owners (call them actors, call them users – it does not matter)
– Identify all relevant interaction between these owners

There is absolutely nothing wrong to treat every interaction owner in any technical problem as a user and then write either Agile-centric description of the goal or Rup-centric description of the goal.

The real challenge is not writing the user story or use case in a pure format. The real challenge is to describe the problem in such a manner that it facilitates and expedites the implementation details in order to solve the problem correctly – the first time.

For example: let’s assume we are designing software which informs the pilot in the cockpit of the aircraft’s speed.

“As a speed indicator gauge, I need to be informed of correct airspeed by air speed sensor in the nose of the aircraft”.  This example clearly defines 2 interaction owners.

“As a speed indicator gauge, I need to receive information every 20 ms in a certain format”. This example defines the order of precedence and rules. The gauge has already been designed and available;  it has certain interfaces which influence data collection downstream.   We just have to honor these design elements in any subsequent interaction description.

“As an airspeed indicator, I need to measure the air pressure and convert this metric to something that speed indicator gauge understands, sent every 20 ms”. Do not know yet what the message format is.  But – engineering intent is clear.   These interaction owners have to find a way to talk to each other.

“As an airspeed indicator, I also need to inform another diagnostic device in the aircraft every 1000 ms that I am healthy and working”.  This is an example of an instrumentation requirement written as a user story.

The goal is the same: the functionality being developed must serve the consumer perfectly – as intended. The rest is simply how we get to the point of success.

Imagine if someone forgot to write the user story which captures the need to check periodically that the airspeed sensor is still working …

The results would be catastrophic regardless of adherence to any preferred process or methodology or framework.

Frame the problem correctly.  Then use all available techniques to solve it correctly.

Categories: Software Engineering