Systems Analysts

Systems analysts form the glue or cement of a systems development team. Let's revisit the main responsibilities of a systems analyst, and comment on favorable personality traits.

Communication with ``the client''.

A systems analyst discusses requirements, objectives and details of an information system with the client. The client, in most cases, is not an expert in computer related technologies. As a result, a systems analyst must know what types of questions to ask, how to ask the questions, and how to interpret the response.

For this responsibility, a systems analyst must communicate well both in written and spoken form. In addition, a systems analyst must dress professionally (at least while meeting with a client) and behave professionally. Good interpersonal communication skills are a plus.

Documenting the Systems Specifications.

Systems analysts document the specifications of an information system. The specifications can be documented in text, diagrams, charts and any other means that is appropriate. The language of systems specifications evolves over time, as do the tools. The topics we covered in this course is just the tip of the iceberg. Note that documenting the systems specifications is a big responsibility because other processes of systems development hinge on it.

For this responsibility, a systems analyst must be logical, detail oriented and careful. ``Logical'' because most the design of an information system is, aferall, logical. ``Detail oriented'' because in the design of an information system, it is the details that makes or breaks the final implementation. ``Careful'' because if the specifications of a system is wrong, the rest of the process will fall apart.

Communicate with technical staff.

Even though a systems analyst should have broad and up-to-date knowledge about information systems, he/she cannot know everything about an information system. For instance, is 2Gb/s a sustainable bandwidth between a storage subsystem and a mainframe?

In order to ensure a system meets all the requirements, a systems analyst often needs to communicate with experts in various areas. This means a systems analyst must have sufficient background and overall technical knowledge. Otherwise, a discussion with an expert in a particular area can be ineffective.

It is important for a systems analyst to keep an eye on the trends of different information system technologies. How things work is not necessarily important to an analyst, but knowing what a particular device can do is important.

Problem solving.

In the design or redesign of an information system, a systems analyst may encounter problem solving sessions. A ``problem'' does not automatically mean a ``bug''. A problem is simply an issue that cannot be dealt with using established techniques and knowledge.

For example, an existing information system may require the database be shut down before data can be backed up. What if the client requests that the daily downtime (to backup the system) be completely eliminated?

Problem solving requires as much research and logical thinking as creative thinking. In our example, the first question is ``has this been done already?'' Researching on the internet and contacting the database vendor may yield canned solutions. If there is no available solution, the next logical step is to consider options. Do we need to change the database backend to one that supports live backup? Is it possible to deny just update queries while the database is being backed up? Is the client okay with denying update queries for the duration of backing up? Can we freeze one of the RAID images, apply pending queries, and back that up? Is it cost effective to run two redundant database servers so that we can pause one for backup? What do we do to synchronize the two servers?...

Team playing.

I know, this term is so cliche. Nonetheless, this is particularly important for systems analysts. The reason is quite obvious: a systems analyst gets to play with the whole team, all the time.