3.1 Systems analysts

Systems analysts (SAs) are not programmers, but they do have a good understanding of how programs are written, and how software works, in general. A SA talks to a ``customer'' or ``client'' who is in need of a computer system. A SA understand the lingo ``of the business''.

For example, let's say a bank called ``UMISWU'' (Ur (your) Money Is Safe With Us) wants to implement a banking information system. A SA talks with the top management of UMISWU to find out what the information system should accomplish from management's point of view. These objectives may including improved work efficient, quality of service, redundancy, ease of management, security and reliability.

At the same time, a SA also talks with the middle managers who oversee the daily operation at the bank. From these managers, a SA gather information about procedures, operations and other information regarding the daily operation of a bank.

A SA may also interview tellers and individual bankers to see what they need in an information system. For example, a teller may indicate that ease-of-use is important, especially when new trainees are at the teller. Help screens and command prompts, for example, may be used to smooth the learning curve of the system.

Last, but not least, a SA designs the overall architecture of the information system in terms of database design, software architecture, hardware configuration and etc.

The most important outcome of a SA is a document called the specification. The specification of an information system specifies exactly what needs to be done, and logically how it is done. This document is, then, given to developers.