Most modern schools of requirements gathering and system specification development are user driven; this can often be the death of a development project. The truth which is known to the more successful technology development outfits is this: the user is irrelevant, the user does not know what is good for the system, and the user will often try to mislead you into developing software which does something they find useful.

Why do we develop software requirements specifications?

The primary purpose of enterprise software, it should be remembered, is to provide background for the writing of press releases expounding the new technological breakthrough which will bankrupt the competitors and thereby to stampede them into wasting money on competing and equally illogical systems. As a secondary objective, enterprise software is often required to provide credible justifications for the plummeting productivity figures presented at the annual general assembly. It should look exotic and alien; the average shareholder should feel that, because of the very avant garde GTK theme used, it is alien technology which implies that the company is leaps and bounds ahead.

As such, it would make sense for business analysts to spend time watching Independence Day or Minority Report as part of the requirements gathering phase, and possibly also keep a close eye at the latest gentoo screenshots posted. In reality, however, the user-centric specification development cult determines system capabilities, laying waste to the chances for effective systems being developed in the enterprise.

Complicating matters is that the user in question will often be wary of the inclinations to proper project scoping and will instinctively try to lead the project scope amiss. Users are incorrigibly capability driven, and an overbearing focus on capability detracts materially from the resources available for UI obfuscation. Users think business process, communication, process automation, and many other things which bore programmers.

This is another aspect which is often missed in enterprise development: if you bore your coders, you will end up with substandard systems. If the developers want to do an accounting system with a front-end based on the Doom code, the system specifications should be refitted to account for this (including stamping out cheat codes; auditors don't like it when a bean counter can idkfa and iddqd their way to positive cash flows). Bored coders are likely to come up with things like Microsoft Exchange, ODBC, and emacs.

The problem with users

Most users lack vision when it comes to understanding what can really be done with modern technology. This is why development teams are often disparaged for including an email client, an RSS aggregator, CD burning functionality, skinnability, export to Autocad, and embedded flying simulators in the newly launched invoicing system. The user has a very narrow weltanschauung which encompasses only the narrow subset of tasks they are charged to perform, and their consequent failure to evaluate holistic feature impact is therefore a primary culprit responsible for the plethora of uninspiring systems serving the modern business.

Monkeys and compilers

Many requirements analysts employ the focus group as a means of soliciting user requirements. This should be regarded as simply another manifestation of the user centricity blight, albeit one where users can gang up on the analyst and present unreasonable expectations as sine qua non. The focus group as a requirements gathering vehicle may be imposed on the analyst by superiors, but it does not have to be as traumatic as all that given the provision of sufficient alcohol (while corporate policy may need to be reviewed before getting the users drunk, it can often pass if the lunch hour is co-opted for focus group activity). Most marketing officers will be happier to sign off on a requirements document calling for a striped pink and purple UI theme than admit they were drunk at lunch.

Use cases and reality

The manner in which use cases are normally mapped and translated into specifications also is strikingly deficient. Use cases assume simplistic processes where the user engages in absolutely no activity extraneous to the base business processes. The reality is that most users check their e-mail an average of 44 times in the duration it takes to enter a new client's first and last name in the CRM. This, to extend the example, is why most programs assume the natural and eventually grow up and include e-mail functionality. The user will also have a video running, and many more sophisticated users work with very advanced VAPs (Visible Activity Purifiers), more commonly known as Boss Keys. The puritanical uptightness of traditional use case specification prevents these forms of computer use from being acknowledged for what they are, which is integral if de facto components of the organizational process. None of this is conducive to the development of software which is truly user centric.

Top down or bottom up?

In the titillating debates which you might hear at a dinner table populated by software requirements analysts, one frequent discussion revolves around whether successful software specifications are more often imposed from top down in a display of visioneering pioneershipping leadership, or whether they are driven from bottom up as a means to leverage the synergistic empowerment of people power to, em. Younger requirements analysts will often flee for the safe haven of stance ambiguity: "I think, it has to be a little of both bottom up and top down". We have mentioned earlier that organizational objectives like pissing off the competition is a strong software design consideration, but that is very high level and a software specification still requires more specificificificificity to be actionable. Top down design objectives and key considerations are usually more comfortable since the people who make them are rarely the people who will use the eventual software; that apart from the fact that it often comes with a healthy load of contempt of the unique form which trickles down the corporate hierarchy.

The difficulty with top down requirements is that they will often be more inconsistency-ridden to the point of self-contradiction. A famous specification document leaked from a Fortune Twenty IT department calls for "clear, distinct, unobtrusive, and somewhat but not entirely accessible push buttons for making sounds to get the attention of cubicle workers, but not in an annoying fashion. In red."

Bottom up requirements development is also problematic - the people contributing to a software specification are by definition not smart enough to have risen to the top of the organization, and it shows in the realized systems. Such systems are typically expensive, over-simple, too oriented to what the enterprise actually does to earn money, and most alarmingly, very sober and distinctly devoid of e-mail functionality.

If top down and bottom up doesn't work, what does then? Some systems requirement schools advocate a blend of both approaches, gleaning requirements from that point somewhere in the middle where the top down train crashed into the bottom up locust swarm. This is pandering to techno-moral relativism, and it is inadvisable. The optimal solution is far more intuitive and effective than most people will realize: industrial espionage. Or, as the more experienced analyst will know to call it, stealth outsourcing.

In summary

The requirements specification phase of software projects can be the most sensitive stage of the development project. In Zen fashion, sensitive tasks should be met with brunt approaches. In the case of software requirements specification, this means having a cavalier attitude to users, a fawning attitude to senior management, carefully measured methodology, and an idolatrous devotion to making angry people use software they never asked for.

If you like this, check out The Banjo Players Must Die!