Requirements - a different IPO than that at the stock exchange

I really do love Mike Cohn's format for user stories, but while formulating requirements in the form

"As a <type of user> I want <desired system interaction> so that <desired outcome>"

is very helpful for capturing requirements, it is in no way sufficient.
The point is not only that user stories really have to be written from a user's point of view.
Writing genuinely from a users perspective means that there should not be any story

"As an internet-user I want the system to perform garbage collection so that the server doesn't have to have too much memory."

because, quite frankly, most internet users don't care about garbage collection or the server's memory - they care about response times, user experience and (hopefully) the service that is provided.

But there is more to good requirements than just writing a story from a users point of view – one of the intriguing stories from Tom DeMarco's The Deadline is the one where a bunch of people read a 18-binder specification for a system and none of them dared to tell the project manager that they did not really understand what it was all about. Those binders where full of technical detail and elaborate formulas but lacked a couple of important things nobody noticed at first.
Until somebody asked "Where does the data come from?" and another one chimed in "Where do the outputs go to?" After that magical moment the spell was lifted and all kinds of missing information were was surfaced. In the end the specification was reworked and the project could go ahead.
Which brings us to the basic point of every operation in a system - there has to be an Input, some kind of Processing and an Output. In the olden days there was a name for that concept, it was called the IPO model and used to be applied to hardware as well as to software.
And even though we (hopefully) don't write our programs anymore as the sequence 'input division', 'processing division' and 'output division' the basic structure for requirements is still quite valid. If the input or the source of the input is unclear it is hard to decide how it should be handled. If the postprocessing is unclear – the output – it is hard to decide what to do with the results from the processing.

So for every requirement – if it is formulated as a user story or in any other way – before the implementation starts it should be clear what that user-story's IPO is.

Till next time
  Michael Mahlberg