by Conrad Weisert
© 2003 Information Disciplines, Inc., Chicago
NOTE: This article may be circulated freely as long as the copyright notice is included.
The principal result delivered by systems analysts is a rigorous specification of exactly what a proposed new or modified system will do. Influenced by packaged life-cycle products and fad methodologies such specifications have been known by a large and confusing number of names, including:
Between about 1977 and 1994 people argued about the form of those analysis deliverables and about the tools for producing them. Recently, however, a new phenomenon arose: the notion that "analysis" (or more often "analysis & design") and "requirements" are separate things. Just last month an internationally known speaker, poking fun at the waterfall approach, complained about a project's spending four months defining requirements and then another six months doing analysis!
That strange notion may have gotten its start among UML zealots when they began to concede that UML, whatever its virtues for modeling and internal design, is pretty useless for communicating what a system is to do. In response they grafted an extra phase onto the front end of the system life cycle, called it "requirements", and substituted for the established structured approaches a combination of these nearly forgotten techniques:
That didn't help. For non-trivial applications, that approach didn't work in 1966 and it doesn't work today, despite being packaged in new terminology and slick C.A.S.E. tools. Experience has repeatedly shown that user representatives are far too bewildered by the volume of unstructured information to approve such a requirements package with any confidence.
In response many UML proponents and leading tool purveyors are giving up on requirements altogether! Instead they favor the sort of incremental and iterative collaboration between developers and sponsoring users that was common in 1959, i.e. before we had thought much about systems analysis as a discipline.
Some methodology and tool purveyors have coined the ugly term "non-functional requirement" to denote what we used to call a "constraint". The new term can seriously mislead project stakeholders, especially the naive sponsoring end user in several ways:
Since the older term expresses exactly what we mean without misleading or confusing anyone, let's agree to call these things constraints and get rid of "non-functional requirement" wherever we see it.
We agree that constraints don't apply to what the proposed system does. What else is there? Here's a partial list:
On most projects we hope to avoid imposing constraints early. Most of them belong to the domain of system architecture or internal design and should be stated in the corresponding project phase, well after the users have understood and approved the real functional specifications.
In particular, we discourage end-user representatives from concerning themselves with such things, not only to keep from restricting the project team and raising costs, but also to avoid distracting those user representatives from their primary chore of understanding every detail of what the proposed system is going to do, i.e. the actual functional specifications or external system design.
There's another very important type of requirements that a project ought to state: the business requirements. Experienced systems analysts distinguish between specifying what a proposed new system will do and specifying what the user organization will be able to do given a solution to its problem. That solution will often but not always be a new system.
Unlike system requirements business requirements are often expressed as lists of discrete goals or objectives that will, when quantified, serve as justification for the project. For example:
In an enlightened system development life cycle, the Business Requirements phase occurs before the Functional Specifications phase. In theory, we can consider ways of satisfying them that do not call for a new system. Unfortunately, Business Requirements is the most often overlooked phase in the life cycle.
If the application isn't a business application, then we may choose a more descriptive name, such as engineering requirements.
The term "user requirements" has become tainted not only by the use-case and discrete list approach, but also by being used to describe three different kinds of thing. Let's avoid confusion by retiring that term.
Return to IDI home page
Return to Methodology shortcuts
Last modified April 22, 2003