Where Systems Analysis Fits in Software Engineering, Explained

UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 1.3 Free with a free account

Where Systems Analysis Fits in Software Engineering

System Analysis and Design · Chapter 1: Introduction to Systems Analysis and the Analyst's RoleSection 1.3 · lesson 3 of 698 min · free with a free account

← Why Systems Analysis MattersNext lesson: The Five Core Phases of the Systems Analysis and Design Life Cycle →

Earn 3 college credits for System Analysis and DesignRecommended for credit by NCCRS · Computer Science 390 · self-paced · one payment, lifetime access
Enroll in System Analysis and Design · $250 →Download the syllabus (PDF)

In this lesson

One practice inside software engineering, and the handoffs around it.

  • Define software engineering and place systems analysis within it
  • Distinguish business analysis, systems analysis, architecture, and project management
  • Describe what each role hands off to the next, and why it matters
  • Explain how a project struggles even when every role does its job

Transcript

Everything said in the video, section by section (1,189 words). Read along, or search it.

Systems Analysis and the Analyst's Role

Where Systems Analysis Fits

Systems analysis never happens in isolation. It sits inside a larger discipline, and it sits between other roles on every real project. This section maps out that territory. First, what software engineering is, and where systems analysis fits inside it. Then four roles that work on the same project, each asking a different question. Then the handoffs between those roles, and why they matter so much. And finally, a surprising idea. A project can struggle even when every single person on it is doing good work.

The Discipline

What Software Engineering Is

Start with the discipline itself. Software engineering is the systematic application of engineering principles to software. That covers its design, development, testing, and maintenance. The goal is to deliver systems that are reliable, on time, and within budget. Software engineering draws on computer science for its technical foundations. But it adds something that computer science alone does not require. That something is process. Process is what turns individual programming skill into a repeatable way of delivering working systems. Again and again, to real organizations, at a scale one person could never manage alone. A brilliant programmer can build a program. It takes process to deliver systems reliably.

Placing the Practice

Systems Analysis Inside the Discipline

So where does systems analysis fit? It is one practice inside that larger discipline. Its job is narrow, but essential. Figure out, before anything is built, exactly what a system needs to do. Software engineering as a whole covers the entire journey. It runs from that very first question, all the way to a working, maintained system. Systems analysis owns one particular part of that journey. The part where the problem is still being defined. That makes it early, and it makes it foundational. Everything later is built on what it decides.

Figure 1

4 Roles, One Project

On a real project, systems analysis does not operate alone. It sits between two other roles, which shape what happens before it and after it. Before it comes the business analyst. After it comes the software architect, who then hands off to the development team. Each of these roles passes a specific deliverable to the next. And then there is a fourth role, the project manager. Notice where the project manager sits. Not at the end of the row, but underneath all of it. Project management coordinates scope, schedule, budget, and risk across every stage. It does not own a single step in the sequence. It spans the whole thing. Keep this picture in mind. The arrows between the boxes are where most of the trouble starts.

Who Asks What

Each Role Answers a Different Question

Let's look at each role more closely, starting with the question it answers. The business analyst asks, should we do this project at all? And what business outcome are we actually after? The deliverable is a business case, high-level objectives, and current-state process models. That goes to the systems analyst. The systems analyst asks, exactly what must the system do, for whom, and under what rules? The deliverable is detailed functional and non-functional requirements, along with use cases and data models. That goes to the software architect. The architect asks how the system will be structured, and with what technology, to meet those requirements. Out come architecture diagrams, technology choices, and design constraints, for the development team. Finally, the project manager asks, is the work on schedule, on budget, and within acceptable risk? The project plan, schedule, budget, and risk register go to all roles, continuously. Same project, four different questions, at four different levels of detail.

Where Handoffs Break Down

From an Objective to Something Buildable

Now look at what happens at each handoff. A handoff is a point where information can be lost, not just passed along. Here is an example. A business analyst sets a high-level objective. Reduce customer wait times. That is a good objective. But nobody can build it as written. The systems analyst has to translate it into something specific. For instance, the system must display the estimated wait time within two seconds of a customer joining the queue. Now there is something to design, to build, and to test. That translation, from objective to buildable requirement, is the heart of the systems analyst's job. Notice what the specific version adds. A measurable limit, and a clear trigger for when the clock starts.

The Failure Chain

How a Vague Handoff Becomes the Design

So what happens when that translation goes wrong? Suppose the requirement handed to the architect is vague, or incomplete. The software architect still has to design something. So the architect is left making assumptions to fill the gap. And those assumptions quietly become the design that the whole system is built on. Notice that nobody made a bad decision on purpose. The architect did the reasonable thing with what they were given. But the system now rests on guesses that no one ever confirmed with the business.

Project Management

Why the Project Manager Spans Every Stage

This is also why project management spans every stage, rather than sitting at the end. Its job is to coordinate scope, schedule, budget, and risk, continuously. Picture a project manager who only gets involved once development starts. By then, the requirements have been written, and the architecture has been set. Any handoff problem upstream is already baked into the plan. That project manager has missed the chance to catch the problem while it was still cheap to fix. Recall the cost of change curve. Late involvement means paying for problems at the expensive end of it.

The Subtle Failure

Every Role Competent, the Project Still Struggles

Here is the most counter-intuitive idea in this section. Every individual role can do competent work. And the project can still struggle. How? Because what one role produced was not clearly enough understood by the role that came next. The work was good. The handoff was not. This changes how systems analysis should be judged. It is not enough to write requirements that are correct. They must be clear enough to be picked up and used, by someone who was not in the room when they were written. A requirement only you can interpret is not finished yet. So when you write one, ask yourself a simple question. Could the next person act on this, without coming back to ask what I meant?

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Software engineering is the systematic, process-driven application of engineering principles to building, testing, and maintaining software. Business analysis is the practice of identifying a business problem or opportunity, and building the case for addressing it. It usually happens before a specific system has been chosen. Software architecture is the practice of deciding a system's technical structure, components, and technologies. Those decisions are based on its confirmed requirements. And a handoff is the point at which one role's completed work, becomes the starting input for the next role.

Key Takeaways

What to Carry Forward

To pull this together. Software engineering is the overall discipline. Systems analysis is one practice within it, focused on defining what a system must do, before it is designed. Business analysis, systems analysis, software architecture, and project management each answer a different question. They look at the same project, at different levels of detail. What moves between roles at each handoff matters just as much as the work done within each role. And project management coordinates schedule, budget, and risk continuously. It is not one step in the sequence. It is the thread that runs through all of them.

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 →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take System Analysis and Design with UPI Study

From business problem to working systemSystem Analysis and Design teaches how analysts study a business need and turn it into a system design: requirements, UML and data-flow models, interface and database design, implementation and project management. It is a core course in information systems and IT degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

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 UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks 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 Where Systems Analysis Fits in Software Engineering

How is systems analysis related to software engineering?
Systems analysis is one practice within the broader discipline of software engineering, focused on defining what a system must do before it is designed or built. Software engineering is the systematic, process-driven application of engineering principles to the design, development, testing, and maintenance of software. It covers the whole journey to a working, maintained system, while systems analysis owns the early, foundational stage where the problem is still being defined.
What is the difference between a business analyst, a systems analyst, a software architect, and a project manager?
Each role answers a different question about the same project. The business analyst asks whether the project should happen and what outcome is wanted, producing a business case. The systems analyst defines exactly what the system must do, for whom, and under what rules, producing detailed requirements, use cases, and data models. The architect decides the system's structure and technology. The project manager tracks scope, schedule, budget, and risk across every stage.
What is a handoff in a software project, and why does it matter?
A handoff is the point where one role's completed work becomes the starting input for the next role, and it matters because information can be lost there. If an architect receives a vague requirement, the gaps get filled with assumptions that quietly become the design. For example, the objective reduce customer wait times must be translated into something testable, such as displaying the estimated wait within two seconds of a customer joining the queue.
Why can a software project struggle even when every team member does good work?
A project can struggle because work that is correct may still be unclear to the next role that has to use it. The individual work is good, but the handoff is not. That is why requirements should be judged on clarity as well as correctness: someone who was not in the room should be able to act on them without asking what was meant. Involving project management from the start also helps catch handoff problems early.

About the System Analysis and Design course

How many college credits is System Analysis and Design?
System Analysis and Design (Computer Science 390) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does System Analysis and Design cost and what is included?
$250, paid once, with lifetime access: all 69 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does System Analysis and Design take?
It is self-paced with no deadlines. The 69 lessons total about 9 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

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.

Enroll in System Analysis and Design →Download the syllabusEvery course with PRO →
System Analysis and Design
3 credits · NCCRSEnroll →