Why the Life Cycle Is Iterative: Feedback Loops, Phase Revisits, and Continuous Refinement

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

Why the Life Cycle Is Iterative: Feedback Loops, Phase Revisits, and Continuous Refinement

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

← The Five Core Phases of the Systems Analysis and Design Life CycleNext lesson: The Systems Analyst: What They Do and Why It Matters →

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

Feedback loops, phase revisits, and continuous refinement.

  • Explain why a strictly linear life cycle breaks down on a real project
  • Define requirements volatility and its common causes
  • Explain a feedback loop and how it differs from a restart
  • Apply continuous refinement across all 5 phases

Transcript

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

Systems Analysis and the Analyst's Role

Why the Life Cycle Is Iterative

The last section drew the life cycle as five phases in a neat row. This section explains why real projects almost never follow that row just once. We will see where a strictly linear model breaks down. We will name the force that breaks it, which is called requirements volatility. Then we will look at the mechanism that handles it, the feedback loop. We will separate revisiting a phase from restarting a project. And we will end with the principle that ties it all together, continuous refinement.

The Linear Picture

Useful, but Incomplete

Start with the picture you already have. The five-phase view makes the life cycle look like a straight line. Planning finishes, and analysis begins. Analysis finishes, and design begins. And so on, through maintenance. That picture is genuinely useful. It shows clearly what each phase is responsible for. But it hides something every practicing analyst learns quickly. Almost no real project moves through the five phases only once, and in only one direction. The straight line is a map of responsibilities. It is not a map of how projects actually move.

A Scenario

A Business Rule Nobody Captured

Here is a scenario that makes the problem concrete. A team gets its requirements approved. It builds a complete design from them. Then, during implementation, it discovers that a business rule was never captured. Now read that situation strictly linearly. There is no path back. The design phase is done, and the requirements document is already signed. But in practice, the team has no real choice. It has to go back and correct the requirements, and the design, before implementation can proceed correctly. The linear diagram never showed that path. The project needs it anyway. So the question becomes, how does a life cycle go backward in a controlled way?

A Predictable Force

Requirements Volatility

The force behind scenarios like that has a name. Requirements volatility. It is the tendency of requirements to change, or to become better understood, after they have already been documented and approved. It is important to be clear about what volatility is not. It is not the same as poor discipline. And it is not the same as scope creep. It is a predictable feature of any project that involves people. It comes with an evolving business, and with technology choices made under uncertainty. If you expect requirements to never move, you are planning for a project that does not exist. The real question is not whether requirements will change. It is how the project will absorb the change.

Where Change Comes From

5 Common Causes of Volatility

Volatility has several common causes. The first is stakeholder learning. Users often cannot fully evaluate a requirement until they see it, in a model, a mockup, or a working feature. The second is business change. A reorganization, a new competitor, or a new pricing strategy can change what the system needs to support. The third is regulatory change. A new compliance rule can appear after requirements were already signed off. The fourth is discovered edge cases. Testing or early use surfaces scenarios that the original requirements did not anticipate. And the fifth is technical constraints. A chosen platform or integration turns out not to support a requirement exactly as first specified. Notice that none of these five is anyone's fault. They are simply what happens when real projects meet the real world.

The Mechanism

Feedback Loops

If volatility is normal, the life cycle needs a normal way to absorb it. Otherwise, a model with no room for a changed requirement treats every change as a failure. And it will constantly be forced outside its own rules. The mechanism that absorbs change is the feedback loop. A feedback loop is a controlled path. It carries a finding from a later phase back to an earlier phase. That way, the earlier phase's deliverable can be corrected before the project moves forward again. The key word is controlled. A feedback loop is deliberately narrow. It sends back only the specific piece of work that needs correction. Not the whole project. Everything that was approved and is still valid stays exactly where it is.

Figure 1.3

Loops Point Back to a Specific Phase

Here are the five phases again, moving forward through their gates. The solid arrows show that forward path, from planning down to maintenance. Now add the feedback loops, drawn as dashed arrows. One loop runs from design back to analysis. Another runs from implementation back to design. And a longer loop runs from maintenance back to analysis. Notice what every loop has in common. It always points back to a specific earlier phase, never to the very beginning of the project. So a missing business rule found in implementation sends the team back to analysis and design, to correct that rule. It does not send the team back to planning. Why not? Because the original justification for the project has not changed.

Two Different Events

Revisiting a Phase vs. Restarting the Project

That leads to a distinction that is easy to blur. Revisiting a phase, and restarting a project, are not the same event. A revisit updates a specific deliverable. For example, it adds one missed rule to the requirements document, and updates the one design element that depends on it. Then that narrow update goes back through the relevant phase gate for approval, before work resumes. A restart is far bigger. It discards the project's existing deliverables, and begins again from planning. That is reserved for situations where the original justification for the project no longer holds. In day-to-day work, most of the rework an analyst encounters is a revisit, not a restart. A restart is rare, and it should be. It throws away approved work.

Two Ways to Get It Wrong

Too Big, or Too Quiet

There are two opposite ways to handle a correction badly. The first is to treat every correction as grounds for a full restart. That wastes all the approved work that is still perfectly valid. The second is to quietly patch every correction, without going back through a gate. That feels efficient. But it risks letting an unapproved change slip into the system, unreviewed. The disciplined path sits in the middle. Send back only what changed, and put it back through the gate. That keeps valid work intact, and it keeps every change visible to the people who approve it.

The Guiding Principle

Continuous Refinement

Put volatility and feedback loops together, and a broader principle appears. The life cycle is not something a team gets right once, and then executes mechanically. It is continuously refined. Each phase gate is a chance to fold in what has been learned so far. And often, so is the work between gates. This principle applies across all five phases, not just analysis and design. In fact, it is the reason the models and methods later in this course exist. They are different, structured ways of applying this same principle of ongoing refinement. When you meet them, ask how each one folds new learning back into the work.

Key Takeaways

What to Carry Forward

Let's pull this together. A strictly linear reading of the life cycle has no built-in way to absorb a change discovered after a gate has passed. Requirements volatility, meaning requirements changing or becoming better understood after approval, is normal. It is not a sign of poor discipline. A feedback loop sends a specific finding back to the earlier phase it affects, without restarting the whole project. A revisit updates a deliverable, and re-passes its gate. A restart discards existing deliverables, and begins again from planning. And continuous refinement is a principle across all five phases, not a technique limited to one 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 Why the Life Cycle Is Iterative: Feedback Loops, Phase Revisits, and Continuous Refinement

What is requirements volatility?
Requirements volatility is the tendency of requirements to change, or become better understood, after they have been documented and approved. It is a normal feature of real projects, not a sign of poor discipline, and it is not the same as scope creep. Common causes include stakeholders learning more once they see a mockup, business change, new regulations, edge cases discovered in testing, and technical limits of a chosen platform.
What is a feedback loop in the systems development life cycle?
A feedback loop is a controlled path that carries a finding from a later phase back to the specific earlier phase it affects, so that phase's deliverable can be corrected before work moves forward. For example, a business rule missed during analysis but discovered in implementation sends the team back to analysis and design for that rule, not back to planning. Approved work that is still valid stays in place.
What is the difference between revisiting a phase and restarting a project?
Revisiting a phase updates one specific deliverable and puts that narrow change back through its gate, while restarting discards the project's existing deliverables and begins again from planning. A revisit might add one missed rule to the requirements and update the design element that depends on it. A restart is reserved for cases where the project's original justification no longer holds, so it should be rare.
Why is a strictly linear life cycle unrealistic for most projects?
A strictly linear life cycle has no built-in way to absorb a change discovered after a gate has passed, yet almost no real project moves through its phases just once in one direction. The linear view is still useful as a map of each phase's responsibilities. In practice, teams rely on continuous refinement, folding new learning back in at every phase, and avoid both needless restarts and quiet, unreviewed patches.

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 →