Software Requirements Specification:

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.