Fad methodologies overlook logical starting point for user requirements . . .

Specifying System Output Requirements
© Conrad Weisert, Information Disciplines, Inc., Chicago
6 June 2003

May's issue of the month pointed out serious flaws in some recent trends in documenting user requirements. Several readers asked me to follow up with some positive recommendations on what should be in a complete and rigorous user-requirements specification.

This article is the first such recommendation. If you find it helpful, let me know and I'll continue. On the other hand, if you disagree with this recommendation, I'll be glad to publish your alternative suggestions.


Background -- a forgotten component

I recently reviewed yet another in-trouble system development project for a client. The project had suffered a sequence of missed target dates and cost overruns, and everyone understood that heads would roll if they should fail to make the latest "deadline" a couple of months away.

I began by examining the functional requirements. The project team had amassed over 250 use-cases along with a list of several hundred discrete requirements in a half-dozen categories.

I asked first to see the system output specifications, that is the reports and displays that users see. My request turned out to be impossible to satisfy:

So, there was no written record of what information the proposed new information system was to produce. I couldn't review them. The sponsoring users not only hadn't reviewed them, but were unaware that the omission was a serious problem.

Is that experience unusual? Not at all. Use-cases1 and discrete requirements lists, supported by popular C.A.S.E.2 tools, are driving out many components of a well-structured system specification.

Why start with outputs?

Not only are system output specifications one of the most important components of a detailed requirements specification, but they're also

Indeed, for many information systems, the system outputs are the very essence of the system.

Fortunately, system output specifications are also very easy for user-reviewers to understand without special orientation. Non-technical users find them natural and close to their interests and expectations.

Once the systems analyst knows exactly what information is to be produced by the system, he or she will be able:

Defining the content

Some systems analysis textbooks3 and packaged life-cycle methodologies contain forms or templates for specifying system outputs. The good ones call for at least the following information: