Ethiopian Design

Software requirements should be driven by usability requirements and task analysis. Establishing requirements and specifications has a long history in software engineering and is a basic component of most standard engineering methods, such as the Waterfall (Royce 1970) and Spiral methods (Boehm 1988).

What those methods do not include are clear linkages from usability requirements. They typically specify what will be built and how it will function, but not why it is needed or how it will be used. Consequently, many systems are built that function according to specification, but are useless.

From task analysis, we’ve established the pages needed for each task and the system functions required for each page. This is a blueprint for the overall system requirements. That is, we can say, “This is the behavior required by the system.” The next step is to take each system function and completely specify its design.

This includes a detailed description of what it does, a description for how it will be implemented, a range of acceptable inputs and outputs, and a list of things that can go wrong and what will be done in each event.

This allows the interfaces between system functions and components to be verified to ensure that the outputs from one component are those expected as input to the next component.

For example, when a user enters an account and password to log in, client-side validation can be written in Javascript to make sure the account name contains only valid letters and numbers before passing the data to the server for back-end processing.

However, we cannot rely completely on validation done on the client side. For a more robust system, the back-end software at the server should also specify what will happen if bad data does come in from the browser (perhaps as part of a communications failure or a security breach), and what to do if a password or user name is incorrect. This level of specification is driven by, but not replaced by, usability requirements.

Report This Post