Next: Homework Assignment (100 points, Up: Information Systems Previous: What is an information Contents
An excellent resource is http://www.umsl.edu/~sauter/analysis/analysis_links.html, you should read through some of the stories (fables). Not only are they easy to read, but they are also so true in the realm of systems analysis.
A systems analyst is not a programmer. A programmer writes programs to meet pre-determined specifications. A systems analyst is responsible for the specifications.
A systems analyst is not a tester. A tester executes tests to determine whether a computer system does what it claims to do. A systems analyst specifies what a computer system is supposed to do.
A systems analyst is not a system administrator. A system administrator maintains the operation of a computer system. A systems analyst specifies the components that make up the computer system.
I am sure you are painting a picture of what a systems analyst does not do. Does a systems analyst do anything?
The simplest functional description of what a systems analyst do is ``to design, modify or enhance an information system that meet the requirements and objectives of a client and maintains its specifications.'' Let's pick this sentence apart and explain the components.
``Client'' in this context simply means an organization (possibly of one person) that is in need of a new or better information system. If you are a systems analyst working for the Board of Equalization, your client is most likely internal, the Board of Equalization itself. If you are a consultant or work for a consulting group, your client is most likely external, a company that pays for your services.
``Requirements'' are a set of quantified or qualified statements that the information must meet. For example, a growth related requirement may state that ``the system must be scaleable to handle a data size growth of 30% annually.'' An efficiency related requirement may state that ``the system must reduce the current transaction processing time by 40%.'' A requirement can also defer much details. For example, a security requirement may simply state ``the system must be rated level 3 or above by computer security consulting firm XYZ.'' In short, ``requirements'' is ``what the system does.''
``Specifications'' are a collection of documents (text, charts, diagrams and etc.) that describes how the proposed system operates. A common question is ``how detailed?''. There is no clear answer to this question. It suffices, however, to say that the specifications must be sufficiently detailed for other parties in the development, deployment and maintenance of the computer systems. In other words, the ``specifications'' are documents that programmers, testers, system administrators, purchasers and etc. use to do their jobs.
Some believe a systems analyst is also responsible for the management and execution of the development of an information system. In other words, a systems analyst makes decisions and tells others what to do. This is not the case in general. A systems analyst is responsible for projecting a proposed timeline/plan, but this is a specification that results from the analysis of task dependency, available resources and task resource requirements (more on this later). A systems analyst usually does not determine task dependency, available resources or task resource requirements.
You can also see a systems analyst as the glue that holds all other participants together so everyone is ``on the same page''. Please note that the systems analyst does not necessarily determine the content of that ``same page''. A systems analyst is, however, responsible to communicate with other participants so that whatever is determined is written precisely, completely and distributed efficiently.