Requirements Eng (1997) 2:61-62 �9 1997 Springer-Verlag London Umited Requirements

Engineering

Viewpoints

: - : : , - . . . "'::. .'-~ . Y .~ '? ~ ":'~, ~ ~ : - : ~ %?,: ~ ~i~:.,", ~ : ~.:.-.~-,%~ : ~ : " ; ~ ' : ~ . .~- :~ ,:-;~_~:

�9 ~ , ' : " , ' "7 - , " : . ;: ~ ' : - " . " " - , , : , : , : ' - ~ ' - ~ ' : r , r : .:~-'~. , " ~ . , : z : ' .~ - .L~ ' : . ~ , ~ :~ . .~ . .~ t '~ - ; ; ~ i - ~ . , ~

.......... " ....... '

Last Words on the (Project) Flight Recorder: A Plea for User Requirements

Richard Stevens QSS Um~ed, Oxford, UK

As I wander round industrial companies, I sometimes come across the wreckage of projects - people, ideas, and dreams scattered across the organisation. This causes enormous pain in wrecked careers, disturbed lives and loss of money, even the loss of the whole company.

And the words which guarantee disasters like these are:

'Our users don't know what they want'

These words are invariably incorrec t - - they can be better translated into

'I can't talk in the user language'

or alternatively

'My project will be a failure'

We must get user requirements in order at the beginning of a project. After all, if you went in to buy a car and the salesman talked to you about the functional decomposition of the vehicle in Hatley-Pirbhai terms, you'd think he had gone crazy. What customers want to know is how much it costs, what it provides, what it can carry, fuel economy, comfort, safety and so on. They

Correspondence and offprint requests to: Richard Stevens, QSS Limited, Magdalen Centre, Oxford Science Park, Oxford OX4 4GA, UK. Email: 100010.3303@compuserve.tom

need a model in user terms, of what will be provided to them. This is what the user requirements are for.

A few weeks ago, I organised a requirements workshop for a project - good hard-working people, excellent quality engineers, full backing from the company. But they had already designed much of the hardware. The team had done some requirements work, but didn't have any user requirements at all - it started off from the functionality of the system. The only requirements the project had were systems require- ments. The net result would have been a technically advanced system that didn't do what the users wanted - so they would have rejected if after 10 minutes. And the tragic thing was that the group took only 20 minutes to understand the importance of user requirements. As Huxley said after Darwin explained the theory of evolution to him, 'It's so obvious, why didn't I think of it before?'

As software becomes the heart of all modern systems, software engineers will have to learn systems engineering, including how to capture and organise user requirements, and how they need to be kept separate from systems requirements. These require- ments are not about functionality, nor systems behav- iour, nor even about wonderful information models. After all, do you worry about the behavioural model of your car?

62 Viewpoints

Much as I respect them, the IEEE has really got it wrong in this area. Their standards muddle up the two kinds of requirements in their standards. And uni- versities are not much better. They are so focused on the latest technical whizz0 that they forget about the non-technical aspects of knowing what users actually want to do with the system.

So this is a plea - go out and grab the user requirements before you start any other work on the project. Keep them as an organised set, separate from but traceable to the business and systems requirements. It won't take long, and it won't cost much to do lffroperly. Have you started the project already? Well, it's never too late to do the job properly. Nothing in the project will give you such a payback. If you don't understand how to get user requirements, call someone who does to help you get started.

Business requirements? Well that's another story ...

About the Author:

Dr Richard Stevens is founder and technical director of QSS Ltd and has managed the development of the DOORS requirements management tool. Formerly, he was head of Methodology, Technology and Quality for information systems within the European Space Agency. He is the author of Software Engineering Standards (Prentice-Hall, 1994), Software Engineering Guidelines (Prentice-Hall, 1996), and Understanding Computers (Oxford University Press, 1986), plus numerous academic papers and magazine articles. For more information, see http://www.qssinc.com.