Download Insight (PDF) »

I recently watched the movie ‘The Devil Wears Prada’ starring Meryl Streep and Anne Hathaway. In the movie, despite having no interest in fashion, Hathaway’s character begrudgingly takes a job at a fashion magazine where Streep is the editor.

In one scene, Streep lectures Hathaway about her poor clothing choices. You see, Hathaway tries very hard to be anti-fashion as a reaction against the preening fashionistas who work for the magazine, so she is wearing a cheap supermarket sweater in a particular shade of blue. Streep’s character gloats that the shade of blue had provenance in a designer’s choice of that colour for a particular season several years previous, after which it was picked up by other designers, and so on, until finally the colour choice filtered down to supermarket clothing. Her thesis is that Hathaway would not have had that choice to make were decisions not agonised over further up the ‘decision chain’.

Why do I tell you this? Well, as a consultant specialising in requirements I am very often faced with the dilemma of how to sell designer clothes (textbook requirements engineering) to clients who want supermarket sweaters (an Excel spreadsheet of ‘system shall…’ statements). Requirements are often seen as ‘just a bit of business analysis’ at the front of a project and so are commoditised to the point where the client decides how much of a requirements consultant’s time he or she is willing to buy. We, as consultants, are then faced with the dilemma of how to select and implement the right requirements methods, but at the same time persuade the client that requirements management is a full-lifecycle activity.

I have been to a number of conferences recently where large requirements projects that are run in the university sector with private sector collaboration, such as SeCSE, have presented really quite wonderful, detailed analyses of how requirements can contribute towards project success. Often, these large projects involve a number of graduate students, who have a need for their research to continue for a number of years before concluding in that corollary of a functional specification: the PhD thesis. This contrasts starkly with the often compressed time periods devoted in private sector projects for requirements-related work.

So how does a consultant take the best practices defined by academic studies of requirements and persuade a client that they are worth investing in? I believe a direct translation of the academic approach to the private sector is not intended – it is there to influence, to direct, to recommend. Academic study can be likened to the ‘designer’ end of the ‘decision chain’. It helps define the future methods and techniques precisely because things happen more slowly, people have more time, and the quantitative and qualitative analysis that defines scientific progress can occur within a nurturing environment. None of these things characterises projects in the private sector. We face time-poor, price-conscious buyers who want results and want them fast. Our job as requirements managers and engineers is to assess the situation, to decide upon an appropriate plan of action and then recommend this to the client. In order to do this we need to have an appreciation of the breadth and depth of methods, techniques and tools that are available to help with requirements work. We are like buyers for clothing stores, or like personal shoppers: making choices for our clients because they have neither the time nor the inclination to do these things for themselves.

It’s where we add value (to coin some consultancy speak). And the wardrobe that we pick and choose from, our skill-sets, our tool-kits, are only available because somebody somewhere had the luxury of the time to develop them. As consultants we’re lower down the ‘decision chain’, but we have our friends in academia to thank for keeping us one step ahead of our clients, and for making sure that requirements as a discipline has matured to the point where clients accept that good requirements management is a full lifecycle activity, and not just a ‘bit of business analysis’.

Remember that next time you spot a client who’s chosen to develop some ‘run-of-the-mill’ use cases, which may not be technically-pure but will advance their understanding of how the proposed development will work. They were only able to make that choice because Ivar Jacobson, the father of UML, had already made it for them in 1986. So read papers, go to conferences, make friends with an academic – we owe it to future generations of requirements managers.

This article appeared in Requirements Quarterly in June 2007.