A systems analyst is a person who uses analysis and design techniques to solve business problems using information technology.Systems analysts may serve as change agents who identify the organizational improvements needed, design systems to implement those changes, and train and motivate others to use the systems.
1. Systems Analysts
Collaborate with IT Professionals All Throughout the SDLC
Systems analysts certainly aren’t limited
to working just on software development projects. Yet, for some systems
analysts, this is all they work on. At every stage of the systems development
life cycle (SDLC), they team up with programmers, UX designers, QA testers, and
so forth, to build systems.
The SDLC is just one of many software
development methodologies, and its numerous benefits are compounded by its
drawbacks. However, most people who work on dev projects understand it. When
reading this article, consider keeping in mind the following standard SDLC
phases:
- Analysis
- Design
- Development
- Testing
- Installation/Deployment
- Maintenance
2. Systems Analysts
Document Systems
Because they collaborate with professionals
across the entire SLDC, systems analysts often serve as information brokers.
This role is critical, with the documentation prepared by systems analysts
often becoming the final word on what a system is or does.
Systems analysts document IT systems to
understand, change, improve, and help build these systems. Broadly, they
document what is happening in current systems. But they also document what can
be expected in systems that haven’t been built yet. This work is often done in
collaboration with technical writers, systems designers, and systems
architects. Typical things that systems analysts document include:
- User
scenarios
- Functional
activities
- Classes
- Data flows
- Interfaces
between systems
Examples of documents that systems analysts
author or co-author include:
- Requirements
documents
- Feasibility
studies
- Design
specifications
- Software
development kits (SDKs)
- Flowcharts
and diagrams
- Training
documents
- Testing
documents
- Disaster
recovery plans (DRPs)
3. Systems Analysts
Gather and Analyze Requirements
Information overload occasionally happens
to each of us. This is where systems analysts come in handy. They
transform a seemingly incomprehensible avalanche of information into something
useful. Reports. Diagrams. Paragraphs. Bullet points. You name it. Anything
that will translate business goals into technical solutions. Here are some
examples of questions that systems analysts can ask during the requirements
phase of a project:
Objectives
- What do
you want the system do?
- What is in
and out of scope for this project?
- When do
you want the system to go live?
- How much
money in the budget is there for systems analysis?
Problems
- What
problems will the proposed new system fix?
- What
problems do you want fixed that relate to the existing system?
- Is there a
log of all software bugs?
- Have the
bugs been prioritized and ranked?
- What bug
tracking software do you use?
Changes
- What kinds
of changes are needed?
- Are the
changes classified as modifications or enhancements?
There are many types of requirements that a
systems analyst will collect and analyze. Three of the main ones are:
- Business
Requirements. High level requirements that managers and directors
would typically understand.
- Functional
Requirements. Detailed requirements that specify exactly what
needs to be delivered. These are generally read by business analysts,
software engineers, and project managers.2
- Technical
Requirements. Detailed requirements about how the system is built,
including which language it will be programmed in, what standards are to
be followed, etc. Technical requirements are often read by software
architects and developers.3
4. Systems Analysts
Choose, Upgrade, and Configure Software
Clearly, not all software is custom-built.
There are thousands of applications that are prepackaged. These kinds of
programs can be customized by setting various preferences, yet they can’t be as
individualized as custom-programmed software.
Implementing a packaged system that will be
used by dozens, thousands, or tens of thousands of people can take months of
planning and a crazy amount of money.5 If
you think it’s difficult to download an app to your smartphone, consider
implementing a system that, for instance, requires impenetrable security and
high availability.6 Systems
analysts often play a crucial role in both picking and configuring software.
Here are some examples of tasks that systems analysts do in conjunction with
system architects and system designers:
Software Selection
- Inviting
software vendors to submit request for proposals (RFPs).
- Vetting
vendors.
- Reviewing
systems.
- Determining
which system most fits your requirements.
- Recommending
which system to implement.
Software Configuration
- Working
with the system administrator to install the software.
- Assigning
roles and privileges to users.
Other
- Decommissioning
legacy applications.
5. Systems Analysts Work
with Tons of People
To get the job done, systems analysts have
to work with a large variety of people, on top of the IT professionals they
always collaborate with. Here are a few of them:
- Sponsors are the people who want a system
to be built so they can—to get down to brass tacks—make money from it. In
business speak: systems analysts work with sponsors to assess whether the
financial investment in a system will be recouped by gains in efficiency
and effectiveness.7
- Depending
on the audience of a system—such as employees or customers—users can be
categorized as internal or external. Internal users are
people such as your company’s finance and marketing staff that use an
enterprise wiki. External users are generally customers
that form part of your company’s monetary backbone.
- Depending
on the level of involvement with a system, users can be categorized as
power users or regular users. Power users are those who
know a system from back to front, who have more extensive rights and
permissions, and/or who use the system’s advanced features. All other
users can be considered regular users. They generally use
a system to accomplish basic functions.
- Systems
analysts often work with programmers who write code to
modify existing systems and/or build new ones.
- Business
analysts and
systems analysts often work in tandem on projects. One way of
understanding the role of business analysts is to view them like a bridge
that spans between business and IT. Often, they have just enough business
knowledge to hold their own when talking with salespeople, marketers, and
the chief financial officer (CFO). Likewise they can speak the techie
jargon of software developers, database guys, and the chief technology officer
(CTO).
- Systems
analysts work with technical writers to draft user
guides, technical overviews, instruction manuals, and frequently asked
questions (FAQs).
- Systems
analysts work with Quality Assurance (QA) analysts to
test systems to ensure that critical requirements are met.
6. Systems Analysts
Monitor Systems
The role of some systems analysts is to act
like digital versions of police officers and crime scene investigators. Typical
tasks might include:
- Finding
out why a system is failing.
- Monitoring
systems in relation to cost, time, quantity, and quality.
- Using
monitoring software to track operating systems, applications, databases,
and
