 |
|
Some people like to start with standard business processes, leaven them with transactional analysis as regards the social interactions, and try to feed the resultant soup to the technical disciplines. This sort of thing is the favorite food of those in our industry who occupy the role that has come, erroneously, to be called architect in many organizations. A genuine software architect, in my estimation, is one who understands the details of software design down to the coding and at the same time is gifted in big-picture thinking and in collaboration with customers. Obviously, such mature careers are fewer than the demand for same, hence the modern omnipresence of the software-architect-who-is-not-a-software-engineer.
Requirements by Collaboration is the sort of thing you will like if you like that sort of thing. Gottesdiener "is a pioneer in the uses of facilitated workshops to elicit business rules and other user requirements." She's propounding her workshop-style methodology for requirements definition in this book. This might send a geek off into reveries, but we deal with such folk on a daily basis, often as the internal departmental consumers of our department's output. How well do they know their stuff, and how smoothly can they make their noncoding approach to software specification operate?
Gottesdiener and her target audience are neither trying to milk the cow, nor give milk themselves. Their job is to facilitate the collaborative milk collection of others by encouraging proper placement of the pail, use of an ergonomic stool, and good elbow technique during the milking. Those who can, do; the rest lead workshops.
That sounds too cynical. The truth is, Requirements by Collaboration is a fairly complete literary description of the ins and outs of a painful process to which software engineers are often subject. Sure, it's annoying to have Who? What? Where? Why? When? and How? harped on, but these questions are precisely those we, from time to time, forget to make sure we have answered. The overarching problem of requirements gathering is paralysis, when and as often as it arises. The whole thrust of the book is finding procedural ways to turn things sideways and shake them to reboot the process when it crashes as you sit there at the conference table with one elbow in mummified pizza and the other in a pool of spilled softdrinks. At that, if not at CORBA, Java, or even Forth, Gottesdiener is a life master.
|
-- Jack J. Woehr (http://www.softwoehr.com)
|
From Byte On-Line, September 3, 2002 |
|
|
|