UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 1.6 Free with a free account
The Systems Analyst: What They Do and Why It Matters
System Analysis and Design · Chapter 1: Introduction to Systems Analysis and the Analyst's RoleSection 1.6 · lesson 6 of 699 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of System Analysis and Design.
Lesson complete
Earn the 3 college credits for System Analysis and Design
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Applying Systems Analysis and Design in Business Settings →← Why the Life Cycle Is Iterative: Feedback Loops, Phase Revisits, and Continuous RefinementNext lesson: Applying Systems Analysis and Design in Business Settings →
In this lesson
What they do, what they need, and where the role leads.
- Describe a systems analyst's day-to-day responsibilities
- Identify the 4 skill areas the role draws on
- Explain the ethical responsibilities of the role
- Outline career paths, and distinguish related roles
Transcript
Everything said in the video, section by section (1,184 words). Read along, or search it.
Systems Analysis and the Analyst's Role
The Systems Analyst
So far, this chapter has talked about systems, and about the life cycle for building them. Now we turn to the person at the center of the analysis phase. The systems analyst. We will look at what the job involves, day to day. We will look at the four skill areas the role draws on. We will cover the ethical responsibilities that come with it. And we will look at where the career can lead, and how this role differs from two others it is often confused with.
The Day-to-Day
5 Recurring Activities
Behind every requirements document is a set of ongoing responsibilities. Most of an analyst's day-to-day work falls into five recurring activities. The first is eliciting requirements. That means running interviews and workshops, and directly observing how work actually happens, to surface what a system needs to do. The second is documenting and modeling. What was elicited becomes requirements documents, use cases, and diagrams that a development team can build from. The third is validating with stakeholders. Before development starts, the analyst confirms that what was documented matches what stakeholders meant. The fourth is bridging business and technical teams. The analyst translates business language into terms developers can act on. And translates technical constraints back into terms stakeholders can weigh in on. The fifth is supporting testing and rollout. The analyst stays involved once development starts, to confirm that what gets built still matches the original requirement.
Two Easily Confused Steps
Eliciting Is Not Waiting; Documenting Is Not Validating
Two of those activities are worth looking at more closely, because each is easy to underestimate. The first is elicitation. Elicitation is an active process. The analyst draws requirements out of stakeholders, through interviews, workshops, and observation. The alternative, simply waiting to be told what is needed, tends to produce a thin and incomplete picture. The second is validation. Validation means confirming with stakeholders that the documented requirements actually match what they meant, before development begins. Why is that a separate step from documenting? Because documentation captures what the analyst understood. And that understanding can still be wrong. Validation is how you find out while it is cheap to fix.
Figure 1
The Skill Set: 4 Areas
What does it take to do all of that well? No single skill makes someone a good systems analyst. The role sits at the intersection of four skill areas. Technical skills, business skills, communication skills, and problem-solving skills. And they have to work together. A gap in any one of them shows up in the quality of the requirements the analyst produces. Strength in only one or two areas tends to produce requirements that are accurate in some ways, but incomplete or unusable in others. Picture an analyst who is strong technically, but weak at communicating. The requirements might be precise, but written in language stakeholders cannot understand, or confirm. They get signed off, without ever really being validated. That is a communication gap, showing up as a requirements problem.
A Position of Trust
Why the Role Carries Ethical Weight
The analyst's position also carries ethical weight. Here is why. First, analysts routinely see information that is confidential. Second, they sit between stakeholders with competing interests. Third, they produce documents that other people will rely on, without independently checking them. Put those three together, and you have a position of trust. That position comes with real ethical responsibilities.
Ethics in Practice
4 Principles
Four principles capture those responsibilities. The first is confidentiality. Business data, financial figures, and internal processes seen during analysis are protected, and shared only with those who need them. The second is objectivity. Requirements are documented based on what stakeholders actually need. They are not shaped to favor one department's preferred outcome over another's. The third is honest representation. The costs, risks, and limitations of a proposed system are represented accurately, rather than downplayed to keep a project moving. The fourth is conflict of interest. Any personal or financial interest in a particular vendor, tool, or outcome is disclosed, rather than left to influence the analysis quietly. These are not optional extras. They are core parts of doing the job responsibly.
A Closer Look
Why Honest Representation Is an Ethical Duty
Honest representation deserves a closer look, because it can feel like mere good practice. Why is it an ethical duty? Because stakeholders and decision-makers rely on the analyst's representation, to decide whether to proceed. Now imagine an analyst who downplays a risk, or trims a cost estimate, to keep a project moving. The decision-makers are trusting that information. So downplaying it is not just sloppy. It misleads the very people who are relying on it. That is what turns an accuracy problem into an ethical one.
Career Paths
How People Grow Into - and Beyond - the Role
Where does the career go? Most systems analysts do not start in the role. A common path begins in a junior or business-analyst position. There, the emphasis is on gathering and documenting requirements, under supervision. Experience leads to a systems analyst role, with fuller ownership of a project's requirements. Then comes a senior systems analyst role, leading requirements work across larger or more complex systems. From there, the path tends to branch in one of three directions. One goes deeper into the technical side, toward solutions architecture. Another goes deeper into the business side, toward business analysis leadership, or product management. The third leads toward project and program management. There, the analyst's experience coordinating stakeholders becomes the foundation for coordinating entire projects.
Often Confused
Systems Analyst, Business Analyst, Solutions Architect
Finally, three titles that are often confused. A systems analyst focuses on understanding and documenting what a specific system must do. The scope is usually one system or project at a time. People often move into it from a technical or business-adjacent position, and specialize in requirements and modeling. A business analyst focuses on a business problem, and on shaping the case for addressing it. That work sits at the enterprise or process level, often before a specific system has even been chosen. Business analysts often come from operations or business backgrounds. A solutions architect designs how technology components fit together, to meet business and technical requirements. That scope often spans multiple systems, or an organization's broader technology landscape. Solutions architects usually come from senior developer or architecture backgrounds, combined with strong business communication. In a smaller organization, one person may hold all three responsibilities at once. In larger organizations, they are usually distinct roles that cooperate.
Key Terms
The Vocabulary of This Section
Let's lock in the key terms. Elicitation is the active process of drawing requirements out of stakeholders, rather than waiting to be told what is needed. Validation is confirming with stakeholders that documented requirements match what they meant, before development begins. A conflict of interest is a personal or financial interest that could influence an analyst's judgment, if left undisclosed. And a solutions architect is a role focused on designing how technology components fit together across systems.
Key Takeaways
What to Carry Forward
To pull this together. A systems analyst's core responsibilities are eliciting, documenting, validating, and translating requirements. And the analyst stays involved through testing and rollout. The role draws on technical, business, communication, and problem-solving skills together. A gap in any one of them weakens the requirements the analyst produces. Confidentiality, objectivity, honest representation, and disclosing conflicts of interest are core parts of the job. And systems analyst, business analyst, and solutions architect are distinct roles with different scopes. Even when, in a smaller organization, one person covers all three.
About System Analysis and Design at UPI Study
System Analysis and Design (Computer Science 390) is a self-paced online course of 69 video lessons in 9 chapters, from the analyst's role and requirements to UML modeling, interface and database design, testing, maintenance and project management. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →
Why take it here
Why students take System Analysis and Design with UPI Study
Where the credit goes
Universities that work with NCCRS
System Analysis and Design carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About The Systems Analyst: What They Do and Why It Matters
What does a systems analyst do day to day?
What skills does a systems analyst need?
What ethical responsibilities does a systems analyst have?
What is the typical career path for a systems analyst?
About the System Analysis and Design course
How many college credits is System Analysis and Design?
How much does System Analysis and Design cost and what is included?
Which universities accept UPI Study credits?
How long does System Analysis and Design take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in System Analysis and Design.
69 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →