In specifying a new information system a logical starting point is to identify the information that the system is to produce. That's often the main reason behind such a system.
The functionality of many application systems is driven by input transactions.
The users' perception of most systems is centered on the system outputs and the system inputs. Their complete and unambiguous specification is among the most critical components of an external system design (or detailed user requirements.
2 half-day sessions (a single-session seminar version omits workshop exercises and some examples, but presents all the concepts and techniques)
SA-02 -- Defining Data and Using a Data Dictionary
In the first session we categorize common kinds of reports and displays. We then enumerate the properties of an output specification, emphasizing content over format. The participants, working in teams of 3 or 4, develop specifications for outputs in their areas of interest.
We warn against clutering a system specification with false outputs, such as input prompts and error diagnostics, that support system operation but provide no useful information to the users.
We next consider when it's appropriate or desirable to specify format or layout in addition to content, and examine alternative ways of doing so, including I-O prototypes.
In the second session we switch our attention to the input side, starting with an examination of the transaction both as a collection of related data items and as a process-triggering event. We identify the sources of knowledge that motivate input specification and discuss criteria for determining when the input specifications are complete.
We conclude by discussing recent trends in interleaving inputs and outputs into so-called "dialogs". Finally we examine when an I-O prototype should evolve into permanent working software.
Return to
systems analysis courses
IDI home page