ISYS1039: ace the component, not just read the notes
Your complete guide to RMIT University's business systems analysis unit. See where the marks are, work real practice questions, and study with an AI tutor that knows ISYS1039.
Sia generates ISYS1039 practice questions, walks through business information systems in context and the requirements discovery process step by step, and quizzes you on the material the component that weights most heavily.
Sharpen your argument
A client says: "We need a system that stops staff booking the same meeting room twice." What is the correct first analysis move?
Notice what the client actually stated: a solution, not a requirement. "Stops staff double-booking" is already a proposed fix, and the underlying need is unstated.
Look for the workarounds. If staff currently double-book because the calendar is slow, or because senior staff informally bump juniors, a uniqueness constraint will not solve the problem — it will push it into email and the system will be bypassed.
Only then model. Options B and C are both correct UML and both premature: they encode a solution to a problem that has not been established. Option D skips analysis entirely, which is the failure mode this course exists to prevent.
The weaker choice: Modelling the stated solution instead of discovering the real requirement. Options B and C feel productive because they produce an artefact, and both would be marked as competent notation attached to a failed analysis. The course assesses whether you understood the problem, not whether you can draw a diagram. watch this!
One component decides 40% of your grade. Continual assessment. This whole page is built around that.
Overview
What ISYS1039 is, and where it sits
ISYS1039 develops and extends, in the words of the course description, your knowledge of the analysis and design process for business information systems by introducing object-oriented techniques using the UML notation for analysis and design, the requirements discovery process taking into account soft systems methodology, and the process of modelling business processes.
The course sits at the join between what a business needs and what a system does. That gap is where most information systems projects fail, and the discipline taught here is making it explicit: eliciting what people actually do, representing it in a notation others can check, and designing a system that answers the real requirement rather than the first one stated.
Assessment is three tasks weighted 40, 20 and 40, with no examination. Two heavy deliverables means no single day decides the course — but equally, no revision period exists in which to recover a weak submission.
Always treat your own course outline and the exam timetable as authoritative.
Difficulty & time commitment
Is ISYS1039 hard, and how much time does it take?
ISYS1039 is manageable if you keep a weekly rhythm and treat the back half as the main event. The pattern is consistent: it starts gently and steepens, and the heaviest assessment is the part that separates grades.
The difficulty curve and the assessment weighting point the same way: the back half is harder and worth more. Front-loading effort there is the highest-return decision in the unit.
Is this unit for you
Who tends to do well, and who tends to struggle
You will likely do well if
- You investigate before you model, and treat a stated solution as a clue rather than a requirement.
- You use UML precisely — a diagram that is nearly right is a diagram that will be read wrongly.
- You can explain a model in plain language to someone who has never seen UML.
- You start both 40% tasks early, since neither can be produced well under time pressure.
You may struggle if
- You draw diagrams before understanding the problem situation.
- You treat UML as decoration around a written answer rather than as the analysis itself.
- You accept the first requirement a stakeholder states without probing what sits behind it.
- You leave a 40% task late; there is no examination to recover on.
- For every model you draw, write one sentence saying what decision it helps someone make. A diagram that answers nothing scores poorly regardless of correctness.
- Practise the same scenario in two notations — a use case and a sequence diagram — and note what each reveals that the other hides.
- Keep a list of the questions that uncover unstated requirements, and use them in every task.
- Have someone outside the course read your diagram. If they cannot follow it, it fails the communication outcome.
Syllabus
The 12 topics, topic by topic
The exam-weight marker on each topic shows where the marks concentrate. The amber topics carry the highest exam weight.
T1 · Business information systems in context
Course descriptionWhat an information system is inside an organisation, and why analysis exists as a discipline.
T2 · The requirements discovery process
Course descriptionEliciting requirements from people who often cannot state them directly.
T3 · Soft systems methodology
Course descriptionHandling problem situations where stakeholders disagree about what the problem even is.
T4 · Modelling business processes
Course descriptionRepresenting how work actually flows before proposing how it should.
T5 · Object-oriented concepts
Course descriptionClasses, objects, encapsulation and inheritance as analysis tools rather than programming ones.
T6 · Use cases and actors
Standard UML canonCapturing system behaviour from the outside, in the user's terms.
T7 · Class and object diagrams
Standard UML canonStructural modelling: what things exist and how they relate.
T8 · Interaction and sequence diagrams
Standard UML canonBehavioural modelling: what happens, in what order, between which objects.
T9 · State and activity modelling
Standard UML canonLifecycle of an object and the flow of an activity.
T10 · From analysis to design
Course descriptionTurning a model of the problem into a specification of a solution.
T11 · Validation and stakeholder review
Course learning outcomesChecking a model against the people whose work it describes.
T12 · Communicating a model to non-technical stakeholders
Course learning outcomesA diagram nobody outside the team can read has not done its job.
How it's assessed
Assessment structure
| Component | Weight | Format & timing |
|---|---|---|
| Assessment Task 1 | 40% | First major assessment task, published by RMIT with its weighting and linked course learning outcomes but without a task title. Across the semester. Continual assessment. |
| Assessment Task 3 | 40% | Third major assessment task. Late semester. Continual assessment. |
| Assessment Task 2 | 20% | Second assessment task. Mid semester. Continual assessment. |
- The three published tasks sum to 100. RMIT publishes no hurdle requirement for this course.
- There is no examination. Two tasks carry 40% each, so the grade is decided by two substantial pieces of analysis and design work rather than by a single sitting. Nothing can be recovered in a revision period, because there is none.
This is a coursework unit. Coursework carries 100% of the grade and the assessment task 1 is the single heaviest piece at 40%, so steady work across the semester decides your result more than any one sitting. Continual assessment.
Final exam timing: No examination in this course. Confirm the exact date and venue on your exam timetable.
How to actually pass it
A weekly rhythm, two checklists, and the traps to avoid
The unit rewards consistency over cramming, and practice over re-reading. Here is the loop that works, then what to have nailed before each exam.
The weekly loop
Before the mid-semester checklist
- Explain what business systems analysis is and where it sits in a project.
- Carry out requirements discovery, including with stakeholders who disagree.
- Apply soft systems methodology to an unstructured problem situation.
- Model a business process as it currently operates.
Before the final heaviest topics
- Produce correct use case, class and sequence diagrams for a given scenario.
- Model object lifecycles and activity flows.
- Move from an analysis model to a design specification.
- Validate a model with stakeholders and communicate it to a non-technical audience.
The mistakes that cost marks
Modelling the proposed solution. A stakeholder's stated fix is not the requirement. Discovering what sits behind it is the assessed skill.
Notation used loosely. UML is precise by design. An arrow of the wrong type changes the meaning of the model, and markers read it as written.
Diagrams without a purpose. Every model should support a decision. Producing all the diagram types you know is not analysing.
Ignoring workarounds. How people currently get around a system is usually where the real requirement is hiding.
Teaching team
Who teaches ISYS1039
The bios below are factual. We do not rate lecturers; any star ratings are submitted by students who have taken ISYS1039.
Teaching team as listed in public course information. AskSia does not rate lecturers; star ratings are submitted by students who have taken ISYS1039.
Formula & concept sheet
The vocabulary and formulas you must own
- Requirements discovery
- The process of establishing what a system must do, from stakeholders who often describe solutions rather than needs.
- Soft systems methodology
- An approach for problem situations where stakeholders disagree about the nature of the problem itself.
- Use case
- A description of system behaviour from an external actor's point of view, in the actor's own terms.
- Actor
- Anyone or anything outside the system that interacts with it.
- Class diagram
- A structural model showing the types of thing in a system and the relationships between them.
- Sequence diagram
- A behavioural model showing the order of interactions between objects over time.
- Activity diagram
- A model of the flow of an activity, including decisions and parallel paths.
- State machine
- A model of an object's lifecycle: the states it can occupy and what moves it between them.
- Encapsulation
- Keeping an object's internal detail private and exposing behaviour through a defined interface.
- Business process model
- A representation of how work actually flows through an organisation.
- Stakeholder validation
- Confirming with the people whose work is modelled that the model is accurate.
- Analysis versus design
- Analysis describes the problem; design specifies the solution. Conflating them is the classic beginner error.
Common acronyms: BA · CLO · OO · SSM · UML.
Where it fits
Prerequisites, related units & why it matters
Required prior study published by RMIT: 002915 Digital Business Design and Innovation. Worth 12 credit points, taught face to face at City Campus by the School of Accounting, Information Systems and Supply Chain.
Your ISYS1039 study toolkit
Study the unit with Sia, not just read about it
Each tool already knows ISYS1039: your syllabus, your texts, and where the marks are. Grouped by how you study, from first contact to exam week.
FAQ
Frequently asked questions
Is ISYS1039 hard?
It rates moderately hard. There is no examination and the notation itself is learnable. What makes it demanding is that analysis work is marked on judgement: two students can produce valid UML and only one has modelled the right thing.
What is the assessment breakdown?
Three assessment tasks weighted 40%, 20% and 40%. RMIT publishes the weightings and linked course learning outcomes but not task titles, so we do not invent names. There is no examination.
What do I need before taking it?
The published required prior study is 002915 Digital Business Design and Innovation.
Who coordinates the course?
The published course coordinator is Dr Mohammad Hossain, School of Accounting, Information Systems and Supply Chain.
Do I need to be able to program?
No. The object-oriented material here is used for analysis and design, not implementation. You model classes and interactions rather than writing code.
What is soft systems methodology?
An approach for problem situations where stakeholders do not agree on what the problem is. the description names it as part of the requirements discovery process, and it is what separates this course from a pure notation subject.
Study ISYS1039 with Sia
Work through business information systems in context, the requirements discovery process, soft systems methodology and the rest of the unit with a tutor that knows it and quizzes you on the topics the assessments weight most heavily.
Start studying with Sia
