INFOSYS 220 Chap.1 Systems Analysis and the SDLC
Systems Analysis and the SDLC
Analyse change before specifying technology
Systems analysis begins with organisational value. The analyst identifies a need, studies the people and context around it, and recommends a solution that can deliver value. An information system combines people, processes, data, hardware and software, so a technically polished application can still fail if work practices, information or adoption are ignored.
The systems development lifecycle supplies a decision structure: planning asks why the change is justified, analysis asks who needs what and in which context, design decides how the solution will operate, and implementation builds, tests, installs and supports it.
Keep the lifecycle connected
Each phase produces evidence for the next. A business case and feasibility evidence authorise planning.
Requirements and models become a system proposal. Architecture, interface, data and program decisions form the design specification. Construction, testing, conversion, training and support produce an installed service. Feedback can send the team backward when evidence changes. The lifecycle is therefore a chain of accountable decisions rather than a promise that work always proceeds in one direction.
What this chapter covers
- 01
Business analysis as change directed toward stakeholder value
- 02
People, processes, data, hardware and software as system components
- 03
Planning, analysis, design and implementation questions
- 04
Systems analyst skills and change agent responsibilities
- 05
Lifecycle outputs and approval decisions
- 06
Feedback and traceability across phases
Worked example · free
Locate a failure in the lifecycle
- 2Separate the service outcome from the software launch.
- 2Locate the missing decision and affected system components.
- 2Recommend evidence and controlled action.
Key terms
- Business Analysis
- The discipline of enabling change by defining needs and recommending solutions that deliver stakeholder value in context.
- Information System
- An arrangement of people, processes, data, hardware and software that supports organisational work.
- SDLC
- A structured lifecycle for planning, analysing, designing, implementing and supporting an information system.
- Systems Analyst
- A change agent who connects business evidence, stakeholder needs and technology decisions.
- System Proposal
- The analysis phase package that presents requirements, models and a recommendation for approval.
- System Specification
- The design phase description of architecture, interfaces, data and programs needed for construction.
Systems Analysis and the SDLC FAQ
Is the lifecycle always sequential?
No. The phase questions and approval points remain useful even when work iterates. New evidence may send a team back to revise a requirement or design. The important discipline is knowing which decision changed, who authorises it and which later artefacts must be updated.
Why are people part of an information system?
People supply information, perform work, interpret outputs, make decisions and sustain the service. Ignoring them can create a technically functioning application that does not fit real practice. Analysis therefore studies roles, skills, authority, communication and adoption alongside software and infrastructure.
What distinguishes analysis from design?
Analysis defines the problem, users, required capabilities and operating context. Design specifies how the chosen solution will provide those capabilities through interfaces, architecture, data and programs. A design can reveal a weak requirement, but it should not silently replace the need with an unsupported feature.
What should a lifecycle answer contain?
State the current phase question, the evidence available, the missing decision and the affected output. Then recommend a controlled next step and trace its consequences. This is stronger than merely naming a phase because it shows why the phase matters in the case.
Exam move
Create a one page lifecycle ledger with four rows: planning, analysis, design and implementation. Give each row its central question, main activities, output and approval decision. Apply the ledger to a familiar campus service. Write its business need, identify users and other stakeholders, list the five information system components, and decide what evidence would be gathered in each phase.
Then introduce one change, such as a new privacy constraint. Trace which requirement, model, design, test and training item must be reviewed. Practise distinguishing phase labels from reasoning: instead of saying only that an issue belongs to analysis, explain which user, task or requirement was missed and what evidence would resolve it.
Build flashcards for the six analyst skill families and connect each skill to an action in the case. For retrieval practice, cover the phase outputs and reproduce the path from system request through installed system. Finish with two short comparisons: software versus information system, and analysis versus design. If an answer begins with a feature, rewrite it from the organisational need.
This habit prepares the business case and requirements chapters while preventing technology from becoming the unsupported starting point.
Working through Systems Analysis and the SDLC in INFOSYS 220? Sia is AskSia’s AI Information Technology tutor — ask any INFOSYS 220 Systems Analysis and the SDLC question and get a clear, step-by-step explanation grounded in how INFOSYS 220 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.