INFOSYS 220 Business Systems Analysis
The Complete Exam Bible · S2 2026INFOSYS 220 Overview
- 15 points
- University of Auckland
- Semester 2 2026
- Level 2
- Final exam
Follow a decision from need to operation
INFOSYS 220 treats systems analysis as disciplined change, not as a collection of diagrams. A useful analysis begins with a business need and the stakeholders who experience it.
- Lifecycle spine Planning justifies the change, analysis defines what is needed, design specifies how it will work, and implementation delivers and supports it.
- Traceability Strong work links need, stakeholder, requirement, model, prototype and test evidence instead of presenting disconnected artefacts.
- Group progression The one per cent proposal must be approved by the published deadline before the final group deliverable can be submitted.
What you get in the full INFOSYS 220 Exam Bible
- 11 chapters, 48 pages — every examinable topic, week by week
- 30 original practice questions, each with a model answer in the Final Exam format
- 11 worked examples, solved the way INFOSYS 220 marks
- 11 computed figures, redrawn from the course’s own numbers
- Exam-morning plan for the Final Exam (30%) — what to revise last, where marks are lost
Free on this page: assessment table, chapter map, one worked example, key terms, FAQ. The rest is in the full exam bible.
How INFOSYS 220 is assessed
| Component | Weight | Format |
|---|---|---|
| Lab participation, Labs 1 to 9 | 5% | Applied work across the lifecycle in scheduled labs |
| Five online quizzes | 5% | Ten questions, twenty minutes and three attempts on each captured quiz page |
| Assignment 1: Business Case Development for a Request for Proposal Using Generative AI | 10% | Individual business case and critical reflection submitted as two PDF files |
| Assignment 2: Requirement Modelling | 15% | Individual requirements package, UML model, use case document and activity diagram |
| Group Assignment Proposal | 1% | Approval is required by 1 October before the final group deliverable may be submitted |
| Group Assignment Final Deliverable | 29% | Group prototypes, architecture, documentation, reflection and progress evidence |
| Group project presentation | 5% | Week 11 solution presentation, assessed individually according to the schedule |
| Final Exam | 30% | Exam format, duration, materials rule and exact date are not published in the captured source |
| Team Review Moderation | 0% | Optional moderation input for the group project mark |
The nine displayed rows total 100%. The group proposal is a progression gate, not a separately stated course hurdle: without approval by 1 October, members cannot submit the final deliverable and forfeit the full group assignment. Early proposal bonus marks are outside the base total. Confirm operational details on Canvas.
Assessment structure
What other students are asking about INFOSYS 220
- Where can I find lecture notes or study guides for INFOSYS 220 at auckland?
- The INFOSYS 220 study guide in AskSia Library covers Business Systems Analysis in 11 chapters, with the assessment table, a chapter-by-chapter topic map, key terms and a worked example, free to read on this page.
- Is there a final exam in INFOSYS 220, and how much is it worth?
- Yes. In the offering this AskSia Library guide is built from, Final Exam carries 30% of the INFOSYS 220 mark; the full split is Lab participation, Labs 1 to 9 5%, Five online quizzes 5%, Assignment 1: Business Case Development for a Request for Proposal Using Generative AI 10%, Assignment 2: Requirement Modelling 15%, Group Assignment Proposal 1%.
- What does INFOSYS 220 cover on business cases and feasibility?
- In AskSia Library's INFOSYS 220 guide, the Business Cases and Feasibility chapter explains business need, measurable value, stakeholders, constraints and feasibility evidence.
- What does INFOSYS 220 cover on elicitation and prioritisation?
- In AskSia Library's INFOSYS 220 guide, the Elicitation and Prioritisation chapter explains requirements types, evidence gathering, MoSCoW, validation and traceability.
- What does INFOSYS 220 cover on uml requirements and use cases?
- In AskSia Library's INFOSYS 220 guide, the UML Requirements and Use Cases chapter explains user stories, actors, scope boundaries, use case relationships and scenario flows.
Current INFOSYS 220 dates
| Date | Item | Control |
|---|---|---|
| 16 August 2026, 23:59 | Assignment 1 | Published Semester 2 schedule deadline. |
| 30 August 2026, 23:59 | Assignment 2 | The schedule and Canvas say Sunday; the PDF weekday label conflicts. |
| 27 September 2026, 23:59 | Group Assignment Proposal | Published standard proposal deadline. |
| 1 October 2026, 23:59 | Proposal approval | Approval required to proceed to the final group deliverable. |
| 22 or 23 October 2026, 23:59 | Group Assignment Final Deliverable | Deadline depends on the Thursday or Friday lab group. |
| 29 October 2026 | Examination week begins | The exact final exam sitting is not captured. |
Dates are as published in the Semester 2, 2026 course schedule, Canvas assignment pages and group assignment specification. Confirm exact deadlines and submission settings in the live LMS.
What INFOSYS 220 covers
Eleven chapters follow the systems development lifecycle from business need and feasibility through requirements, modelling, design, construction, delivery and continuing support.
Systems Analysis and the SDLC
business analysis, system components, lifecycle phases, stakeholders and valueAnalyse 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.
- Business analysis as change directed toward stakeholder value
- People, processes, data, hardware and software as system components
- Planning, analysis, design and implementation questions
- Systems analyst skills and change agent responsibilities
- Lifecycle outputs and approval decisions
- Feedback and traceability across phases
Business Cases and Feasibility
business need, measurable value, stakeholders, constraints and feasibility evidenceMake the reason to act testable
A business case gives decision makers a disciplined basis for authorising investigation or investment.
- Business need versus proposed solution
- Stakeholders, requirements, value and constraints in a business case
- Tangible and intangible value with measurable indicators
- Technical, economic and organisational feasibility
- Alternatives, assumptions and risks of action or inaction
- Evidence led recommendations for approval decisions
Elicitation and Prioritisation
requirements types, evidence gathering, MoSCoW, validation and traceabilityGather evidence about work and value
Elicitation draws out information that may be incomplete, tacit or disputed.
- Interviews, questionnaires, observation and document analysis
- Business, user, functional, nonfunctional and transition requirements
- Clear, complete, correct and consistent requirement quality
- MoSCoW and evidence based priority criteria
- Validation against need and value
- Verification, agreement and backward or forward traceability
UML Requirements and Use Cases
user stories, actors, scope boundaries, use case relationships and scenario flowsModel goals inside a clear boundary
A use case model shows the solution boundary, external actor roles, goal oriented system functions and their relationships. It does not show screen order, process timing or data flow.
- User stories with role, goal and value
- INVEST quality characteristics
- Actors as external roles and the system boundary
- Goal sized use cases and associations
- Include, extend and generalisation relationships
- Normal, alternative and exception scenario flows
Activity Diagrams and Process Analysis
guarded flows, parallel work, process improvement and balanced data flow modelsMake behaviour and conditions visible
An activity diagram models procedural flow through actions, transitions, decisions and parallel work. The course rule uses one initial state and permits multiple final states.
- Actions, transitions, initial and final states
- Decision guards, merges, forks and joins
- Normal, alternative and exception routes from use case documents
- Current and future process analysis
- External entities, processes, stores and flows in a data flow diagram
- Decomposition, balancing, syntax and semantic checks
Design Strategies and Project Kickoff
make or buy decisions, prototypes, proposal quality and team coordinationChoose acquisition strategy from evidence
A design strategy determines how capability will be obtained.
- Custom build, package, service and outsourcing options
- Requirement fit, capability, cost and strategic alignment
- Vendor, licensing, integration, security and lock in risk
- Low and high fidelity prototype purposes
- Proposal approval as a project progression gate
- Roles, Trello evidence, decision ownership and team coordination
Interface Design and Prototyping
user centred design, navigation, feedback, accessibility and interactive evidenceDesign for a user's task and context
An interface is the point where a user pursues a goal through the system.
- User goals, contexts and task centred interface decisions
- Visibility, consistency, feedback, prevention and recovery
- Navigation structure and user orientation
- Mobile constraints and responsive interaction choices
- Low and high fidelity prototype questions
- Accessibility and documented evidence from feedback
Architecture and Data Modelling
application layers, infrastructure, data structures, integration and design tradeoffsAllocate responsibilities across the solution
Architecture translates requirements into major components and their connections.
- Presentation, application and data responsibilities
- Centralised and distributed architecture tradeoffs
- Components, interfaces, deployment and integration boundaries
- Entities, attributes, identifiers and relationships
- Cardinality, keys and data integrity
- Privacy, access, retention and migration consequences
Construction and Testing
traceable builds, test levels, defect evidence, regression and acceptanceBuild from controlled design evidence
Construction turns approved requirements and design decisions into working components.
- Controlled construction from requirements and design
- Versioning, review, configuration and reproducible builds
- Unit, integration, system and acceptance test purposes
- Test conditions, setup, action and expected result
- Boundary, negative and exception tests
- Defect triage, regression and requirement traceability
Agile Delivery and Security
iterative feedback, backlog decisions, safeguards and shared delivery responsibilityUse iteration to shorten the evidence loop
Agile delivery organises work into small increments, frequent review and adaptive planning.
- Iterations, increments and short feedback cycles
- Ordered backlogs and transparent priority decisions
- Completion standards, reviews and retrospectives
- Predictive and adaptive delivery tradeoffs
- Confidentiality, integrity and availability
- Threats, safeguards, secure evidence and shared ownership
Migration, Operations and Maintenance
readiness, conversion evidence, training, operational ownership and continuing supportMake readiness an evidence decision
Implementation does not end when construction passes a test. The organisation must prepare data, users, procedures, infrastructure, support and ownership for live service.
- Data mapping, cleansing, rehearsal and validation
- Training by role and operational procedure
- Technical, business and support readiness evidence
- Release risk, recovery and accountable approval
- Operational ownership, monitoring and incident response
- Corrective, adaptive, perfective and preventive maintenance reasoning
The business case explains why action is justified, what value is expected, which constraints matter and whether the proposal is feasible. Requirements then translate the need into capabilities and qualities that can be checked. Models expose scope, interaction, process and data relationships. Design decisions turn those models into architecture, interfaces and prototypes.
Construction and testing create evidence that the proposed solution works, while migration, training, operations and maintenance keep value alive after launch.
Build traceability across artefacts
The course rewards connections. A requirement should trace backward to a need and forward to a use case, activity flow, design element and test.
A stakeholder claim needs evidence from an interview, observation, questionnaire or document rather than intuition. A prototype screen should implement a numbered function and show the route a user follows. A test should name the condition and expected result that prove a requirement.
This chain also makes change analysis possible: when one requirement moves, the analyst can identify affected processes, interfaces, data, tests and stakeholders.
Reason with fit, not slogans
Most methods in the course involve tradeoffs. Interviews allow clarification but require time and skilled facilitation. Questionnaires reach many people but may hide ambiguity.
A package or service can reduce delivery risk but introduce licensing, integration and vendor constraints. A custom build can fit distinctive work but demands capability and continuing support. Agile feedback can expose misunderstanding early, yet iteration does not remove the need for architecture, security, documentation or governance.
A strong answer identifies the decision, selects criteria, compares evidence and explains why the recommendation fits the context.
Use assessment facts carefully
The published base weights total one hundred per cent. The proposal and final deliverable are separate rows because proposal approval controls eligibility for the later group submission. Bonus proposal marks sit outside the base total.
The final exam is worth thirty per cent, but the captured exam page supplies no duration, section structure, question format, materials rule or exact sitting date. Prepare from the taught concepts and current Canvas announcements without inventing a format.
Worked example · free
Trace a service delay from need to test
- 2Separate the underlying need from a proposed feature.
- 2Write a measurable requirement and name the actor goal.
- 2Connect the use case to a testable outcome.
- 2Explain how the chain supports change analysis.
Key terms
- Business Need
- A problem or opportunity that explains why organisational change should be considered.
- Business Value
- The benefit stakeholders expect from a change, expressed in a form that can be evaluated.
- Stakeholder
- A person or group affected by a change or able to influence its outcome.
- Feasibility
- Evidence about whether a proposal is viable within technical, economic and organisational constraints.
- Functional Requirement
- A capability, process or information service that the solution must provide.
- Nonfunctional Requirement
- A measurable quality or constraint governing how well or under what conditions a solution operates.
- Transition Requirement
- A temporary capability or condition needed to move from the current state to the future state.
- Traceability
- The maintained links from need through requirements, designs, solution components and tests.
- User Story
- A concise statement of a stakeholder role, desired goal and resulting value.
- Use Case
- A goal oriented interaction between an actor and the system across one or more scenarios.
- Activity Diagram
- A UML model of actions, decisions, guarded routes and parallel flows within behaviour.
- Data Flow Diagram
- A logical model showing processes, external entities, stores and the data moving among them.
- Prototype
- A draft representation used to explore, communicate and evaluate a proposed design.
- Regression Test
- A repeated test checking that a change has not broken behaviour that previously worked.
- Product Backlog
- An ordered and revisable list of work considered for iterative delivery.
- Operational Handover
- The transfer of a delivered system, knowledge and accountability into continuing service ownership.
INFOSYS 220 FAQ
How is the course assessed?
The published base assessment has labs, quizzes, two individual assignments, a one per cent group proposal, a twenty nine per cent group deliverable, a five per cent presentation and a thirty per cent final exam. Team Review Moderation has no standalone weight. The base rows total one hundred per cent.
Why is proposal approval important?
The proposal is more than an ordinary one per cent submission. The group specification states that approval is required by 1 October. Without approval, members are ineligible to submit the final group deliverable and forfeit the full thirty per cent group assignment. That exact consequence is more useful than calling it a generic hurdle.
What is known about the final exam?
The captured schedule confirms a final exam worth thirty per cent and places examination week from 29 October. The captured exam shell adds no usable detail. Its duration, sections, question types, permitted materials and exact sitting date therefore remain unknown and should be checked in current Canvas announcements.
How do business needs differ from requirements?
A business need is the reason to change, such as excessive delay or lost value. A requirement states a capability or quality the approved solution must provide. Starting with a feature often hides the need and prevents comparison with alternatives. Write the problem first, then the measurable response.
What makes a model useful?
A model is useful when its boundary and purpose are explicit, its notation is correct, and its elements trace to requirements and stakeholder evidence. More symbols do not guarantee quality. A readable model should answer a particular question and stay consistent with the related text, prototype and test evidence.
How should I revise across eleven topics?
Use one small service case and carry it through the lifecycle. Write its need, stakeholders and feasibility case, elicit and prioritise requirements, build use case and activity models, sketch the interface and architecture, then add tests, a backlog decision and a handover checklist. This exposes broken links quickly.
Where should changing details be confirmed?
Use the current Canvas course for submission settings, room or delivery instructions, exact dates, proposal approval status and final exam conditions. This guide preserves what the captured Semester 2, 2026 sources support, but it does not replace later announcements or personalised arrangements.
Questions students ask in each INFOSYS 220 chapter
- 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. Chapter 01 · Systems Analysis and the SDLC
- Why not begin with the requested feature?
- A feature is one possible response, while the need explains the outcome that matters. Beginning with the feature can hide cheaper or safer alternatives and make success impossible to judge independently. A sound case preserves the need, then compares options against evidence and constraints. Chapter 02 · Business Cases and Feasibility
- Which elicitation technique is best?
- No technique is universally best. Choose according to the evidence needed, stakeholder availability, sensitivity, scale and ambiguity. Combining methods is often stronger: observation can reveal actual work, while an interview explains why it happens and document analysis checks the governing rule. Chapter 03 · Elicitation and Prioritisation
- Can an internal database be an actor?
- Usually not when it is part of the solution being modelled. Actors sit outside the boundary and interact with the system. A genuinely external information service may be an actor, but internal components belong to design or architecture views rather than the use case model. Chapter 04 · UML Requirements and Use Cases
- Can an activity diagram have several starts?
- The course direction is exactly one initial state. Several final states are allowed when routes end differently. A diagram with multiple starts loses a single entry point and makes it unclear how the represented activity begins. Chapter 05 · Activity Diagrams and Process Analysis
- Is buying always faster than building?
- Not necessarily. A package may reduce coding time but configuration, procurement, data migration, integration, security review and process change still take effort. Speed should be tested against the actual requirements and organisational controls rather than assumed from the product category. Chapter 06 · Design Strategies and Project Kickoff
- Should a prototype look finished?
- Only when visual and interaction detail is the question being tested. Early structural questions are often better served by low fidelity work because alternatives are faster and less costly to change. A polished surface can discourage critique and create false confidence about production readiness. Chapter 07 · Interface Design and Prototyping
- Why use architectural layers?
- Layers make responsibilities and interfaces easier to reason about. They can reduce coupling and support different deployment or change decisions. They are not automatically beneficial; excessive separation can add complexity, latency and operational overhead without solving a requirement. Chapter 08 · Architecture and Data Modelling
- Does passing unit testing mean the system works?
- No. Unit tests can show that isolated logic behaves as expected, but interfaces, configuration, infrastructure and complete user journeys can still fail. Integration, system and acceptance evidence answer different questions and remain necessary according to the risk. Chapter 09 · Construction and Testing
- Does Agile mean no planning or documentation?
- No. Adaptive delivery changes the timing and detail of planning, but teams still need goals, priorities, architecture, risk controls and useful records. Documentation should support decisions, continuity, compliance and operation rather than exist only as ceremony. Chapter 10 · Agile Delivery and Security
- Why can a tested system still be unready?
- Product tests may not prove migrated data quality, staff capability, monitoring, support coverage, infrastructure capacity or recovery. Readiness brings those evidence streams into one decision. A technically acceptable product can still create unacceptable operational risk. Chapter 11 · Migration, Operations and Maintenance
How to study for the exam
Revise INFOSYS 220 as a traceable decision chain. Choose a compact service problem and keep the same case across every chapter. Begin with a need statement that does not prescribe a feature. Identify stakeholders and measures of value, then record feasibility evidence and constraints. Create functional, nonfunctional and transition requirements, assign priorities and draw backward and forward trace links.
Convert the actor goals into a use case model and one detailed scenario, then draw an activity flow with explicit guards and complete endings. Use those artefacts to justify a prototype, architecture and data choice. Add test cases that state setup, action and expected result. Finally, create a migration and support checklist with named owners. After each pass, change one requirement and list every affected artefact.
This change exercise is more revealing than rereading because it tests whether the connections are real. Keep a separate error log for notation mistakes, vague measures, unsupported stakeholder assumptions and solutions disguised as needs. Before an assessment, compare your work with the current specification and Canvas instructions.
For the final exam, practise short decision paragraphs that name the issue, apply the relevant model, cite case evidence, compare alternatives and conclude. Do not predict an unpublished exam format; prepare flexible explanations, model checks and case applications instead.
Your AI Information Technology tutor for INFOSYS 220
Stuck on a hard INFOSYS 220 question? Sia is AskSia’s AI Information Technology tutor — ask any INFOSYS 220 Business Systems Analysis question and get a clear, step-by-step explanation grounded in how the course is actually taught and assessed. Read this whole study guide free, then take your hardest questions to Sia.