So, exactly, what does being a Systems Analyst mean? Do you, to paraphrase the words of a well-known comedian, “walk around, going mm-hmm, mm-hmm, yes, you are a system?”
Not exactly. In fact, not at all.
Webster’s online dictionary defines system analysis as:
the act, process, or profession of studying an activity (as a procedure, a business, or a physiological function) typically by mathematical means in order to define its goals or purposes and to discover operations and procedures for accomplishing them most efficiently
Being a Systems Analyst requires a variety of skills, and the vast majority are not technical skills, but people skills. A Systems Analyst must be able to communicate effectively; manage often disparate groups of clients, developers, users, operators, technical writers, etc.; lead a project through to completion through a jungle of situations; and do it all with tact, diplomacy, and a firm hand – velvet glove not required, but probably a good idea.
In other words, bring your dancing shoes, Jack – you’re gonna need them.
A Systems Analyst is not limited to the Information Technology profession, but the majority of them will be found in the halls of IT. An analyst’s primary job function is to gather information about a request, analyze – through various processes – the information, and determine the best way to handle the need. Sometimes, you may decide a custom-built application is the best way to go. Sometimes, you determine the job can best be handled with off-the-shelf commercially available products. Or, perhaps, you’ll decide on a mix of the commercially available products with a custom-built framework tying everything together. You may conclude the cost/benefit ratio makes the project too expensive, or the technology to solve the problem just isn’t available, or at least not at an affordable rate. Once the preliminary analysis is done, you write up your results and present them.
Once you’ve gathered the requirements and done enough analysis to determine what to do, made your pitch and you have a viable project, you start the next phase in the Software Development Life Cycle (SDLC.)
Basically, the next phase is a repeating cycle of user meetings, analysis, design changes, and client presentations. These are design sessions with the users of the current system – not their managers or supervisors. If you’re not meeting with the folks who are actually doing the work, your system will undergo major changes in the test phase, or could wind up unused with dissatisfied customers.
The net result of the design sessions is a viable system design. Once signed off on by the client, the next step is writing detailed design specifications, and then writing detailed program specifications. The specification documents are necessary for several reasons:
- The documents are the blueprints for application development. The hardcopy provides a frame of reference as development progresses.
- The documents provide the basis for system documentation.
- The documents are a means of settling disputes and resolving discrepancies, with developers and/or clients. They are written proof of agreed-upon elements.
This not to say that the specifications are set in stone; no one can think of everything, and very often design modifications are necessary. These modifications are incorporated into the design document, to preserve the validity of the documents as the project progresses.
Once design and specifications are complete, you may think the analyst’s job is done. Not so, my friend; the Systems Analyst signs on until the project is completely finished. The analyst and the Project Manager oversee all phases, from requirements gathering through go-live.
After specifications are completed, development phase begins. This is an iterative process of coding, testing, and debugging. The process starts at the unit level, moves up to the module level, then subsystem, system, and finally the full application.
After the development phase, the testing phase begins. The level of testing and quality assurance an application is subjected to depends on its complexity, but every application needs to go through this phase. After the application has completed testing and QA, very often a period of parallel processing begins, where traffic from the production system is also run through the new application and the results are then compared. This phase lasts until the client is satisfied with the results. Once this happens, the system go-live date is determined and a plan is formulated for a smooth cutover. Once the system is live, a period of reverse parallel testing may be run, for however long it takes for all phases of the new application to be verified and any necessary bug fixes to be made. At this point, a full review with the clients is done, all documentation is produced and distributed, and a final sign-off is done.
This is a description of what a systems analyst does on a major project, but all development requiring a design goes through the same steps – they’re just not as involved. All phases of the SDLC are followed, even if abbreviated.
