Analyzing Systems Within the Software Engineering Workflow

UPI Study › Courses › Software Engineering › Free lessons › Lesson 1.4 Free with a free account

Analyzing Systems Within the Software Engineering Workflow

Software Engineering · Chapter 1: Foundations of Software Engineering and Process ModelsSection 1.4 · lesson 4 of 1038 min · free with a free account

← Approaches to Software Development: Plan-Driven, Agile, and Hybrid ParadigmsNext lesson: Designing with Objects: The OOAD Approach →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

What analysis does, how it bridges requirements and design, and scope and feasibility.

  • Explain what systems analysis does, and why it exists
  • Explain how analysis connects requirements to design
  • Define scope, and why it must be agreed early
  • Assess technical, economic, operational, and schedule feasibility

Transcript

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

Foundations of Software Engineering and Process Models

Systems Analysis in the Workflow

Before a single screen is designed, or a single line of code is written, someone has to answer a harder question. What, exactly, is this system supposed to do? And is building it even a good idea? That is the job of systems analysis. This section covers what it does, how it links requirements to design, and its two core tasks, defining scope and assessing feasibility.

An Investigation

What Systems Analysis Does

Picture a retail chain that wants to replace its paper-based inventory tracking with software. Store managers are frustrated, corporate wants better numbers, and everyone agrees something needs to change. But that agreement is not a plan. Systems analysis is an investigation that turns the vague agreement into a structured, verified understanding of the problem. It tests the early picture. Is this need real, and shared across the people affected? What does the current process actually do, as opposed to what people say it does? And what constraints, such as budget, time, existing technology, or regulation, will shape any solution? The output is not a design. It is a clear, checked statement of the problem, and the conditions any solution has to satisfy.

Why It Exists

Mistakes Are Cheapest Here

This step exists because skipping it is expensive. Teams that jump straight from we have a problem to building something routinely discover, late and at high cost, that they solved the wrong problem. Or that they missed a constraint that made their design unworkable. Or that they built something nobody asked for. Analysis is the point where those mistakes are still cheap to catch. A conversation and a revised document, rather than a rewrite. Notice what analysis is not. It is not building the thing, and it is not deciding how the thing will be built. It answers what is true about the problem. Keeping that boundary clear stops the work turning into design, before the problem is understood.

The Bridge

From Raw Input to a Usable Picture

Early conversations with stakeholders produce requirements. But in their raw form, requirements arrive messy. Different stakeholders describe the same process differently. Some needs are stated as solutions, such as give us a button that does this, rather than as problems. And important details go unmentioned, because they seem too obvious to say out loud. Systems analysis sits between that raw material and design, and its job is translation. It organizes what stakeholders said, and what direct observation reveals, into a coherent, verified picture. What the system must accomplish, who depends on it, what information it handles, and what already exists that any new solution must work around.

The Relay

Where Analysis Sits

Think of the workflow as a relay. Communication with stakeholders hands off raw, unfiltered input. Analysis catches it, checks it, resolves the contradictions it can, and hands off a structured, agreed statement of the problem. Design picks that statement up, and starts making concrete technical decisions. Construction follows. Each stage depends on the one before it being done well. A design built on unverified, poorly organized requirements tends to inherit every gap and contradiction that analysis was supposed to catch.

Core Task 1

Defining Scope

One of the first things an analyst pins down is scope. Scope is a clear statement of what the system will do, and just as importantly, what it will not do. Without a defined boundary, a project has no way to know when it is finished. Every stakeholder can keep adding just one more thing. Setting scope is rarely purely technical. It means making explicit trade-offs with the people who requested the system. This process will be automated, and that one stays manual for now. This group of users is in the first version, and that group will wait. Uncontrolled growth in expectations, after the boundary was agreed, is one of the most common reasons projects run over time and budget. A documented scope gives the team something concrete to point to when a new request arrives. Either it fits the boundary, or it is a deliberate change, to be evaluated on its own terms.

Core Task 2

Assessing Feasibility

Defining scope answers what the system would do. Feasibility asks a different question. Should this actually be attempted? An idea can be well defined, and still be a bad idea. Feasibility is broken into separate questions, because a system can pass one and fail another. Technical feasibility asks whether it can be built with the tools, skills, and technology realistically available. Economic feasibility asks whether the expected benefits outweigh the cost of building and running it. That includes comparing against the cost of doing nothing. Operational feasibility asks whether the people who are supposed to use it will actually adopt it, and work the way it assumes. And schedule feasibility asks whether it can be delivered within the time frame that matters. So an idea can be technically feasible, and still not be worth pursuing, if the economics, the people, or the timing rule it out.

The Recommendation

Yes, Yes-If, or No

None of these assessments needs to be exact yet. Precision comes later. What matters is enough evidence to give decision-makers an honest picture. Yes, this is worth pursuing. Or yes, but only if these conditions are met. Or sometimes a no, which saves everyone from investing in an idea that was never going to work. Suppose an analyst finds a system technically and economically sound, but it needs a workflow change most staff are unlikely to accept. That is a real red flag. The team should investigate the resistance, consider a modified approach, or revisit the go or no-go decision, rather than proceed as planned.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Systems analysis is the investigative work of turning raw, unverified input into a structured, checked understanding that design can act on. A stakeholder is anyone with a direct interest in a system, including its future users and the people funding it. Scope is an explicit statement of what a system will and will not do, agreed early. And a feasibility study checks whether a proposed system is realistic, across technical, economic, operational, and schedule dimensions.

Key Takeaways

What to Carry Forward

To pull this together. Systems analysis turns a vague agreement that something must change into a checked statement of the problem, before design begins. It bridges messy, sometimes contradictory requirements and design, by organizing and verifying them. Scope sets what the system will and will not do, so the project knows when it is finished. Feasibility is judged separately on technical, economic, operational, and schedule grounds. And the result is an honest recommendation. Yes, yes if, or no.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security 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 Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software 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

Software Engineering 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 Analyzing Systems Within the Software Engineering Workflow

What is systems analysis in software engineering?
Systems analysis is the investigative work that turns a vague agreement that something must change into a structured, verified understanding of the problem. It checks whether the need is real and shared, what the current process actually does, and which constraints, such as budget, time, existing technology or regulation, will shape any solution. Its output is a checked problem statement, not a design.
What is project scope and why should it be agreed early?
Scope is an explicit statement of what a system will do and, just as importantly, what it will not do. Without an agreed boundary, a project cannot know when it is finished, because stakeholders can keep adding one more thing. A documented scope lets the team treat each new request as either inside the boundary or a deliberate change to be evaluated on its own terms.
What are the four types of feasibility in a feasibility study?
The four types are technical, economic, operational and schedule feasibility. Technical asks whether the system can be built with available tools and skills. Economic asks whether benefits outweigh the cost of building and running it, compared with doing nothing. Operational asks whether people will actually adopt it. Schedule asks whether it can be delivered within the time frame that matters.
How does systems analysis connect requirements to design?
Systems analysis sits between raw requirements and design and acts as a translator. Raw requirements arrive messy: stakeholders describe the same process differently, state needs as solutions, and leave out details that seem obvious. Analysis organizes and verifies this input into an agreed statement of the problem, which design then uses to make concrete technical decisions. A design built on unverified requirements inherits their gaps.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) 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 Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 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 Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 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 Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →