The kickoff session for a Systems Analysis and Design course, built to run without the student's textbook or syllabus. It teaches the subject against one running case study - a campus course-registration system - covering what an analyst actually produces, the system boundary, the five SDLC phases and their deliverables, waterfall versus agile, functional versus non-functional requirements and how to make a vague wish testable, use cases with alternate flows, data flow diagrams from context through level 0 with the black-hole and flowchart traps, and an entity relationship diagram including the associative entity that resolves a many-to-many. It closes with an eight-step recipe for attacking any assignment in the course. Three open diagnostic slides double as a course intake - textbook, methodology, notation, final project - so the session also plans the ones after it.
Subject: Systems Analysis & Design · 72 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
Session 1
Course orientation, the SDLC, and the four models you will draw all term
Objectives
You came in without the textbook, so this session builds its own material. By the end of it you will be able to:
Dennis, Wixom & Roth - Systems Analysis and Design (SDLC phases, requirements, use cases, process and data models) Ch. 1
Warm-up
No wrong answers here - this is a map of where you are, not a quiz.
Discussion prompt
Think about any app you have used that clearly went wrong - a registration portal that let you sign up for a class you had no business taking, a form that lost your work. What do you think happened before a single line of that code was written?
Hint: Almost every famous software failure is a failure of ANALYSIS, not of programming.
Answer:
Whatever the bug looked like on screen, the decision that caused it was usually made months earlier, by someone deciding what the system was supposed to do.
That decision is the job you are taking this course to learn.
Missing information
This deck teaches the subject. It cannot teach your syllabus, so let us fill that in together right now.
Discussion prompt
Take these one at a time and answer what you can - guesses are fine, and 'I do not know' is a useful answer too.
Hint: Anything you cannot answer today becomes a five-minute email to your instructor tonight.
Answer:
Whatever you answer, we build session 2 around it. Today is the roadmap.
Section
Part 1
Concept
A systems analyst studies a business problem and produces a specification of a system that solves it - precise enough for someone else to build.
systems analysis — Breaking an existing situation into its parts to understand what is really required. Analysis asks WHAT.
systems design — Assembling those parts into a plan for a new system. Design asks HOW.
Notice the job title says analyst, not programmer. The deliverable is a document, not a build.
Dennis, Wixom & Roth - Systems Analysis and Design (SDLC phases, requirements, use cases, process and data models) Ch. 1
Definition probe
The single most common confusion in this course. The line is WHAT versus HOW.
Sort into buckets
Which side of the line does each statement fall on?
Intuition
Users speak in goals and frustrations. Developers need unambiguous instructions. Almost nobody is fluent in both.
The registrar says 'students keep signing up for classes they are not ready for'. That is a complaint, not a specification.
Your job is to turn it into something a developer can build and a tester can check - without losing what the registrar actually meant.
Counterexample
Good analogies have edges. Push on this one.
Discussion prompt
A translator is supposed to be faithful - never add, never subtract. Where does that stop being the right description of an analyst's job?
Hint: What happens when two users ask for opposite things?
Answer:
A translator relays; an analyst arbitrates. Users routinely want contradictory things - the registrar wants strict prerequisite enforcement, the dean wants flexibility for graduating seniors.
You cannot faithfully relay both. You surface the conflict, get a decision from whoever owns it, and record who decided.
An analyst also has to supply what nobody said: the error cases. Users describe the happy path almost every time.
Concept
In this course, a system is people, processes, data, and technology working toward a purpose. Software is one of four parts.
This is why 'just add a feature' so often fails: the feature lands, the process around it does not change, and people route around it.
Real world
You have been an external entity in a registration system for years.
Discussion prompt
Walk through registering for a class at your school. Where does the software stop and a HUMAN process take over?
Hint: Think about holds, overrides, waitlists, and what happens when something goes wrong.
Answer:
Almost everyone finds the same seams: an advisor's signature, a departmental override, a hold that only a person can lift, a waitlist someone manages by hand.
Every one of those seams is a place the ANALYSIS decided the software would stop. That was a choice, and often the most consequential one in the project.
Concept
Figure (svg): A dashed boundary line with the registration system inside it and payroll, admissions and the campus card system outside it, showing what is in scope and what is merely interfaced with.
Before any diagram, you decide what is inside the system you are specifying and what is merely something it talks to.
Get this wrong and every later model is wrong with it - you will find yourself specifying the billing system by accident.
Anything outside the boundary appears in your models only as an external entity or an actor - a source or destination of data, never something you design.
Anomaly
A real (lightly edited) line from a student project charter.
Predict first
'The registration system will handle course sign-up, tuition payment processing, and dorm assignments.' What is wrong with it?
Correct: It is three systems wearing one name, so the boundary is undefined
Why: Course sign-up, payments, and housing have different users, different data, different rules and different owners. Bundling them means no model of the system can be drawn consistently, and no one can tell when the project is finished. The fix is to name one system, and list the other two as external entities it exchanges data with.
Trap
Kickoff meeting. The registrar describes the prerequisite problem.
Analyst says: 'We will add a validation function on the enroll button'
Why: Twenty seconds in and a technical mechanism has already been chosen.
The meeting becomes about the button
Why: Everyone now debates the mechanism, and nobody asks the questions that were left.
Never surfaced: what counts as meeting a prerequisite? Does a C-minus pass? What about a transfer credit, or a concurrent enrollment?
Same meeting, same complaint.
Analyst says: 'Tell me about the last student this happened to'
Why: A concrete case exposes the rules that an abstract question never will.
Follow up: who currently catches these, and how?
Why: The existing manual process IS the requirement, and it is already written down somewhere.
Now the rules surface: C or better, transfer credits count if evaluated, concurrent enrollment needs advisor approval. THEN you design the check.
Error analysis
Three lines from a requirements document. Every one has something wrong with it.
Annotate
The test for a requirement: could a tester write a pass-or-fail test from this sentence alone, without asking you anything?
Section
Part 2
Concept
The Systems Development Life Cycle is the spine of this entire course. Every technique you learn belongs to one of its phases.
Whatever your textbook is, it is some refinement of this. Kendall splits it into seven phases, Dennis into four - the content is the same.
Dennis, Wixom & Roth - Systems Analysis and Design (SDLC phases, requirements, use cases, process and data models) Ch. 1
Picture it
Before the detail, the shape. Notice the arrow on the right.
Figure (svg): Five SDLC phases stacked vertically - Planning, Analysis, Design, Implementation, Maintenance - each joined to the next by an arrow, with a feedback arrow curving from Maintenance back to Planning.
It is a cycle, not a line. Maintenance produces change requests, and a change request starts a new pass at planning. Most systems you will ever work on are already in phase 5.
Ranking
Shuffled. Rebuild the sequence from memory.
Put in order
Why: Planning, Analysis, Design, Implementation, Maintenance. The order is not arbitrary: each phase consumes the deliverable of the one before it. Design cannot start until analysis has said what the thing must do, and implementation cannot start until design has said how. Some version of this ordering is the single most common question on a first exam in this course.
Concept
A phase is not finished when time runs out. It is finished when it has produced the document the next phase needs.
| phase | the question it answers | what it hands over |
|---|---|---|
| Planning | Should we do this at all? | System request, feasibility study, project plan |
| Analysis | What must the system do? | Requirements definition, use cases, process and data models |
| Design | How will it do it? | Architecture, interface design, database and program design |
| Implementation | Does it work, and is it in use? | Built and tested system, converted data, trained users |
| Maintenance | What has changed since? | Change requests, patches, updated documentation |
Your assignments this term are almost all Analysis-phase deliverables. That middle row is the course.
Comparison
Same table, three cells removed. Recall beats re-reading.
Comparison matrix
| phase | question | deliverable |
|---|---|---|
| Planning | Should we do this at all? | system request and feasibility study |
| Analysis | what must the system do? | requirements, use cases, process and data models |
| Design | How will it do it? | architecture, interface, database and program design |
| Implementation | Does it work and is it in use? | tested system, converted data, trained users |
If you can reproduce this table from memory, you can answer most of a typical first exam.
Intuition
Each phase is cheaper than the next. A misunderstanding caught in analysis costs a conversation; the same misunderstanding caught after release costs a release.
This is the entire economic argument for spending weeks on documents before anyone writes code.
Picture it
Roughly what it costs to fix ONE defect, depending on when you catch it.
Figure (svg): Horizontal bars showing the relative cost of fixing one defect: 1 in requirements, 5 in design, 10 in coding, 20 in testing, 100 after release.
The prerequisite rule nobody asked about in week 1 becomes, in production, a hundred students enrolled in courses they cannot pass - plus refunds, plus transcripts, plus a very bad meeting.
Anomaly
A project manager announces the plan.
Predict first
'We are behind, so we will start coding now and gather requirements as we go.' What actually happens?
Correct: Code gets written against guesses, and the rework costs more than the analysis would have
Why: Skipping analysis does not remove the analysis - it moves it after the code, where every wrong guess is now embedded in something that has to be rewritten. This is exactly the cost curve on the last slide, walked in the wrong direction. Note the last distractor: agile does not skip requirements, it gathers them in smaller batches, which is a different thing entirely.
Trap
A team wants to look productive in week 2.
Write a 40-page requirements document nobody reads
Why: Volume is mistaken for rigor. The document exists to be submitted, not used.
Copy the user's words in verbatim, including 'user friendly'
Why: Transcription is not analysis - the ambiguity is passed straight through to the developer.
Result: a document that is long, on time, and useless.
Same two weeks, used differently.
Write 12 use cases with numbered steps and named alternate flows
Why: Every line is something a developer can build and a tester can check.
Take the list back to the registrar and read the alternate flows aloud
Why: Reading error cases back is where forgotten rules surface - it is the cheapest defect detection that exists.
Result: a shorter document that changes what gets built.
Break the constraint
Real projects run out of time. This question gets asked in interviews, and on this course's exams.
Discussion prompt
You have four weeks of analysis budgeted and you are told you now have two. What do you cut, and what do you refuse to cut?
Hint: Rank by what is expensive to fix later, not by what is quick to do now.
Answer:
Defensible cuts: the number of stakeholders interviewed, the depth of DFD leveling, prototypes of secondary screens, and documenting workflows that are staying as they are.
Do not cut: the system boundary, the main flow of the highest-value use cases, the alternate flows on anything involving money or eligibility, or the data model. Those are the ones that are expensive to get wrong.
Say the trade-off out loud and get it accepted in writing. An accepted risk is a decision; an unspoken one is a failure waiting to be blamed on you.
Section
Part 3
Concept
Each phase finishes and is signed off before the next begins. The full requirements are agreed before design starts.
Most textbook diagram work - DFDs, ERDs, full requirement specs - comes from this tradition.
Concept
Run the whole cycle in two-week slices, delivering something usable each time and letting the next slice be informed by feedback on the last.
Trade off
Fill the gaps. This comparison shows up on nearly every syllabus in this course.
Comparison matrix
| waterfall | agile | |
|---|---|---|
| requirements are fixed | up front, before design | continuously, each iteration |
| user sees working software | near the end | every iteration |
| main artifact | the requirements specification | working increment plus a backlog |
| handles late change | expensively, via change control | as normal business |
| best when | requirements are stable and stakes are high | requirements are uncertain and feedback is available |
Neither is correct in general. The exam answer is always 'it depends on how stable the requirements are'.
Two truths and a lie
Three statements about agile. Two are myths that this course will grade you down for repeating.
Eliminate the wrong options
Only one of these is defensible. Rule out the other two.
Survives elimination: b
Why: Agile changes the SIZE and TIMING of the analysis batch, not whether analysis happens. Every method has to answer 'what must this do' before it can answer 'how'. The two myths both come from confusing 'less paperwork' with 'less thinking', and both cost marks on exams.
Matching
The right answer depends entirely on the situation. Match each project to the approach that fits it.
Match the pairs
Why: The two waterfall cases share a trait: the requirements exist BEFORE the project does, in regulation or in law, and the cost of a defect is catastrophic or legally binding. The two agile cases share the opposite trait: the requirement genuinely does not exist yet and can only be discovered by putting something in front of a user. That is the whole decision rule.
Socratic
This one you answer, not me - and the answer changes what we do in session 2.
Discussion prompt
Look at your syllabus or your assignment list. Do you see DFDs, ERDs and a requirements specification, or do you see user stories, sprints, and a product backlog?
Hint: The table of contents of the textbook answers this in about thirty seconds.
Answer:
Diagrams and a spec means a structured/waterfall course. We will spend our sessions on notation accuracy - DFD balancing, ERD cardinality, use case format - because that is what gets graded.
Stories, sprints and a backlog means an agile course. We will spend our sessions on writing stories with good acceptance criteria, and on estimation.
Both is the most common answer in a survey course. Then the deciding factor is whichever one the final project uses.
Section
Part 4
Concept
functional requirement — Something the system must DO. A behavior: an input, a rule, an output.
non-functional requirement — A quality the system must HAVE while it does it - speed, availability, security, usability, legal compliance.
Quick test: a functional requirement usually reads 'the system shall' plus a verb. A non-functional one usually reads 'the system shall be' plus an adjective - and then has to be given a number.
ISO/IEC/IEEE 29148 - Requirements engineering (what makes a requirement verifiable)
Sorting
Six requirements from the case study. Two buckets.
Sort into buckets
Functional or non-functional?
Item e is the one people miss: sending an email is a behavior. 'Within 5 minutes' is a constraint on that behavior, but the requirement is still functional.
Intuition
If you cannot describe the test that proves the requirement was met, you have not written a requirement yet.
'The system shall be secure' - what is the test? There is not one. 'The system shall lock an account after 5 failed sign-in attempts' - the test writes itself.
This one rule fixes about eighty percent of student requirements documents.
Concept
Five techniques you will be asked to name, and the situation each one is actually for.
| technique | best for | watch out for |
|---|---|---|
| Interview | Depth, and the reasons behind a rule | People describe the process they SHOULD follow, not the one they do |
| Observation | The real process, including the workarounds | People behave differently when watched |
| Document analysis | Existing forms, reports and policy - rules already written down | Documents describe the old system, including its mistakes |
| Questionnaire | Many users, shallow questions, quantifiable answers | You only learn answers to questions you already knew to ask |
| JAD session | Resolving conflict between stakeholders in one room | Expensive, and needs a facilitator who is not you |
The exam question is usually 'which technique would you use and why'. The 'why' is the second column.
Kendall & Kendall - Systems Analysis and Design (elicitation techniques, DFD leveling and balancing) Ch. 4
Translation
The left column is what stakeholders actually say. The right is what you have to write down.
Match the pairs
Why: Notice what every rewrite added: a number, a threshold, or a condition. 'Fast' became 2 seconds at the 95th percentile under peak load. 'Not ready' became a named grade threshold. 'In the loop' became a notification with a time bound. That added detail did not come from you inventing it - each one is a question you had to go back and ask, which is exactly why analysis takes weeks.
Worked example
The registrar says: 'Every term we get a hundred students in classes they have no business being in, and by the time we catch it, it is week four and they have already paid.'
Separate the complaint from the causes
Why: One sentence is hiding three separate failures: students enroll when ineligible, nobody catches it early, and money has already moved.
Write the prevention requirement
Why: FR-1: The system shall reject an enrollment request when any listed prerequisite has not been completed with a grade of C or better.
Write the escape hatch, because a hard rule always needs one
Why: FR-2: When a prerequisite check fails, the system shall offer the student the option to submit an override request to their assigned advisor.
Write the detection requirement - the 'by week four' part
Why: FR-3: The system shall produce a weekly exception report listing every active enrollment whose prerequisite check was overridden or bypassed.
Figure (svg): A numbered flow showing the main path of the register-for-a-section use case - search, display, select, verify, record, charge, confirm - with three alternate branches leaving the verify step.
Verify: read each requirement back and name the test
Why: FR-1: enroll a student missing a prereq and confirm the rejection. FR-2: confirm the override option appears on that rejection. FR-3: override one enrollment and confirm it appears on the weekly report. All three pass or fail with no argument - that is the standard.
Comparison
Same three requirements plus one more. Classify them, and name the test.
Comparison matrix
| requirement | type | how you would test it |
|---|---|---|
| FR-1 reject enrollment below a C prerequisite | functional | enroll a student missing the prereq and confirm the rejection |
| FR-3 weekly exception report of overrides | functional | override one enrollment, confirm it appears on the report |
| The report shall generate in under 60 seconds | non-functional | time the report against a full term of data |
| Only the registrar role may bypass a prerequisite | non-functional (security) | attempt the bypass as a student and as an advisor |
Trap
Writing the prerequisite rule.
R7: The system will handle prerequisites correctly
Why: It cannot be tested, so it cannot be failed - which means it cannot be built either.
The developer decides what 'correctly' means
Why: Now the most important business rule in the system was set by whoever had the ticket that day.
Six months later the registrar says 'that is not what I meant' - and she is right, but there is nothing to point at.
Same rule, written so it can fail.
FR-1: reject enrollment when a listed prerequisite is not completed with a grade of C or better
Why: Names the trigger, the condition, and the outcome. A tester can write the test without asking you anything.
FR-1a: transfer credits evaluated as equivalent shall satisfy the prerequisite
Why: The edge case is written down instead of being discovered in production.
Now 'that is not what I meant' becomes a change request against a specific line, which is a conversation instead of a crisis.
Section
Part 5
Concept
actor — Anyone or anything OUTSIDE the system boundary that interacts with it - a role, not a person. 'Student', not 'Maria'. Another system can be an actor too.
use case — One complete goal an actor achieves using the system, named in verb-noun form: 'Register for a section'.
The test for a use case: when it finishes, is the actor's goal actually met? 'Log in' fails that test - nobody's goal is to log in.
Picture it
This is the notation your course will ask for. Four things to notice.
Figure (svg): A use case diagram: a Student actor on the left and an Advisor actor on the right, connected by lines to four ovals inside a labelled Registration System boundary box.
Actors are outside the box; use cases are inside it; a line means 'this actor participates in that use case'; and the box itself is the system boundary from Part 1.
Elimination
Four of these fail the actor test. Rule them out.
Eliminate the wrong options
Which one is a legitimate actor on the registration system's use case diagram?
Survives elimination: c
Why: The billing system is outside the boundary, it exchanges data with the system being specified, and it is a role rather than an individual - so it qualifies on all three counts. This is a standard exam question, and the four wrong answers are the four standard mistakes: something inside the boundary, a named individual, a UI element, and an internal process.
Worked example
A use case description is a numbered list with a header. Here is the format your course almost certainly wants.
| field | value |
|---|---|
| Use case name | Register for a Section |
| Primary actor | Student |
| Other actors | Advisor (alternate flow), Billing System |
| Precondition | Student is admitted, has no registration hold, and the registration window is open |
| Postcondition | An enrollment record exists and the section seat count has decreased by one |
Write the main flow as numbered steps, alternating actor and system
Why: Step 1 is always the actor doing something. The system never starts a use case by itself.
Then write the alternate flows - this is where the real work is
Why: 4a. Prerequisite not met: system offers to submit an override request to the advisor. 4b. Section full: system offers the waitlist. 4c. Time conflict: system names the conflicting section and stops.
Figure (svg): A numbered flow showing the main path of the register-for-a-section use case - search, display, select, verify, record, charge, confirm - with three alternate branches leaving the verify step.
Verify: check the postcondition against the steps
Why: The postcondition promised an enrollment record and a decremented seat count. Step 5 delivers both, so the main flow is complete. If a postcondition is not produced by any step, the use case is missing a step - this check catches it every time.
Reverse engineer
Here is the same main flow with one step deleted. The postcondition no longer holds.
Fill in the blanks
1. Student searches the catalog
2. System displays matching sections
3. Student selects a section
4. System verifies prerequisites, time conflicts, seat availability and holds
5. System creates the enrollment record and decrements the seat count
6. System sends the charge to Billing
7. System displays a confirmation
Why: Without step 4 the system happily enrolls a student in a full section they are not eligible for - which is the exact complaint the registrar raised in Part 4. Every alternate flow in this use case branches off step 4, so deleting it also deletes 4a, 4b and 4c. When a use case looks suspiciously short, look for a missing validation step.
Trap
Main flow, first attempt.
1. Student clicks the blue Register tab in the top navigation
Why: The use case is now describing a screen that has not been designed yet - that is Design, in the middle of Analysis.
2. Student types CS in the Subject dropdown and clicks Go
Why: Every one of these steps breaks the moment a designer moves a control.
Six months of maintenance on a document that describes a UI mockup nobody kept.
Same flow, written at the level of the goal.
1. Student searches the catalog for a term and subject
Why: True whether the interface is a web form, a phone app, a kiosk, or a phone call to a clerk.
2. System displays matching sections with open seat counts
Why: Names WHAT information passes, not how it is laid out. The designer now has freedom, and a constraint.
This is the single most common correction on use case assignments: you are describing intent, not clicks.
Section
Part 6
Concept
A data flow diagram shows how data MOVES through a system and what transforms it. There is no time, no sequence, and no decision logic in a DFD - that is a flowchart, and it is a different diagram.
| symbol | means | naming rule |
|---|---|---|
| Rounded box or circle | Process - it transforms data | Verb plus noun: 'Check eligibility'. Numbered. |
| Two parallel lines | Data store - data at rest | Noun, usually an entity name: STUDENT. Labelled D1, D2 and so on. |
| Square | External entity - source or sink outside the boundary | Noun, a role or system: Student, Billing System |
| Arrow | Data flow - the data itself, in motion | Noun describing the DATA, not the action: 'course request', never 'send' |
Gane-Sarson uses rounded rectangles; Yourdon-DeMarco uses circles. Same four ideas - use whichever your instructor drew on the board.
Gane & Sarson - Structured Systems Analysis: Tools and Techniques (the four DFD symbols)
Picture it
Level zero of every DFD set: the entire system drawn as ONE process, numbered 0.
Figure (svg): A context diagram: one circle labelled Registration System in the centre, with Student, Advisor and Billing System as external entity boxes, joined by labelled data-flow arrows.
Its whole job is to fix the boundary and name every flow crossing it. Draw this before anything else, and every later diagram has to agree with it.
Worked example
Now open that single process up. Same boundary, same external flows - more detail inside.
Find the verbs in your use cases - those are your processes
Why: Search, verify, record, charge. Four verbs, four numbered processes.
Find the nouns the system has to remember - those are your data stores
Why: Students, sections, enrollments. Three stores, labelled D1, D2, D3.
Figure (svg): A level 0 data flow diagram exploding the registration system into four numbered processes - search catalog, check eligibility, record enrollment, post charges - reading and writing three data stores labelled STUDENT, SECTION and ENROLLMENT.
Keep every flow that crossed the boundary on the context diagram
Why: Course request still enters, confirmation still leaves, the tuition charge still goes to Billing. Adding detail inside must never change the outside.
Verify: balance the diagram against its parent
Why: Count the flows crossing the boundary here: course request in, confirmation out, override request out, override decision in, tuition charge out. Five - the same five as the context diagram, with the same names. That match is called BALANCING, and an unbalanced DFD is an automatic markdown on most assignments.
Fill the middle
One arrow on the level 0 diagram lost its label. Data flows are named for the DATA, never for the action.
Fill in the blanks
Process 2.0 Check eligibility reads from D1 STUDENT. The arrow from D1 into 2.0 should be labelled student record (or: hold status and completed courses) - not 'get student' and not 'check'.
Why: A flow label answers 'what is travelling down this arrow', so it is always a noun phrase. 'Get student' describes the process's behavior, which is already captured in the process name, and labelling an arrow with a verb is the single most common DFD error on student work. If you can put 'a' or 'the' in front of your label and it still reads properly, it is a noun phrase.
Anomaly
You are reviewing a classmate's DFD. Process 3.0 Record enrollment takes an eligible request in, and nothing comes out.
Predict first
What is this error called, and why does it matter?
Correct: A black hole - data goes in and never comes out, so the process cannot be doing anything useful
Why: The three classic DFD process errors have names your instructor will use: a BLACK HOLE has input but no output, a MIRACLE has output with no input, and a GRAY HOLE has outputs that could not possibly be produced from its inputs. The fourth option is the tempting one - but writing to a data store IS an output flow and has to be drawn, so even a pure-storage process has an arrow leaving it.
Trap
Drawing the eligibility check.
Draw a diamond for 'prerequisite met?' with yes and no branches
Why: There are no diamonds in a DFD. Decision symbols belong to flowcharts.
Add arrows labelled 'then', 'next', and 'if approved'
Why: Those are sequence and control, and a DFD carries neither - it shows what data moves, not when or in what order.
The diagram now answers a question nobody asked, and fails the one it was drawn for.
Same logic, expressed the DFD way.
Draw process 2.0 Check eligibility with one input and two output flows
Why: The decision lives INSIDE the process. The diagram shows only what data comes out of it.
Label the outputs 'eligible request' and 'rejection notice'
Why: Both branches are visible as data, which is exactly what a DFD is for. Where the branching logic gets specified - a decision table, or the use case's alternate flows - is a different document.
Rule of thumb: if your DFD tells you WHEN something happens, you have drawn a flowchart.
Edge cases
Every model has a domain where it earns its keep, and a place where it becomes busywork.
Discussion prompt
You keep exploding processes into more detailed levels - 1.0 becomes 1.1, 1.2, 1.3, and those explode again. When should you stop?
Hint: Ask what decision the next level of detail would change.
Answer:
The usual rule: stop when a process is small enough that one page of description - a decision table, structured English, a short paragraph - fully specifies it. That is called a primitive process, and in practice most systems bottom out at level 2 or 3.
Stop earlier if the extra level is not changing anyone's decision. A DFD exists to be read by a human who has to build or approve something. If nobody reads level 4, level 4 is a document you maintain for no one.
And DFDs are structurally silent about timing, concurrency, user experience, and error recovery. When those are the risky parts of your system, a DFD is the wrong tool no matter how many levels you draw.
Section
Part 7
Concept
entity — Something the system must remember information about, and there are many of them: STUDENT, SECTION, COURSE.
attribute — One fact about an entity: a student's name, a section's capacity. Attributes belong to exactly one entity.
relationship — A meaningful association between entities, read as a sentence: a STUDENT enrolls in a SECTION.
Cardinality is the count on each end - one-to-one, one-to-many, or many-to-many. Getting cardinality right is most of the grade on an ERD assignment.
Discrimination
The classic first-ERD confusion. An entity has many instances and several facts about it; an attribute is a single fact.
Sort into buckets
Sort each item.
Picture it
Four entities. Look at the one in the middle before reading on.
Figure (svg): An entity relationship diagram with four boxes - STUDENT, COURSE, SECTION and ENROLLMENT - where ENROLLMENT sits between STUDENT and SECTION to resolve the many-to-many relationship.
STUDENT and SECTION have a many-to-many relationship - a student takes many sections, a section holds many students. ENROLLMENT is the associative entity that resolves it, and it is the only place a grade can possibly live.
Worked example
You do not invent an ERD. You extract it from the use case you already wrote.
Underline every noun in the main flow
Why: Student, catalog, term, subject, section, seat count, enrollment record, tuition charge, schedule.
Throw out the ones that are attributes or outputs, not things to remember
Why: Seat count is an attribute of Section. Schedule is a report generated from enrollments, not a stored thing. Catalog is the collection of courses, not an entity in its own right.
Keep the survivors and name the relationships as sentences
Why: A STUDENT enrolls in many SECTIONs. A SECTION is an offering of one COURSE. A COURSE has many SECTIONs across terms.
Resolve every many-to-many with an associative entity
Why: Student-to-Section is many-to-many, so ENROLLMENT sits between them, carrying student_id, section_id, status and grade.
Figure (svg): An entity relationship diagram with four boxes - STUDENT, COURSE, SECTION and ENROLLMENT - where ENROLLMENT sits between STUDENT and SECTION to resolve the many-to-many relationship.
Verify: check that every attribute has exactly one home
Why: Where does 'grade' go? Not on STUDENT - a student has many grades. Not on SECTION - a section has many. It belongs to the pairing of one student and one section, which is precisely ENROLLMENT. If an attribute has no obvious home, you are missing an entity, and this check finds it.
Trap
First ERD attempt.
Draw STUDENT and SECTION with a many-to-many line between them
Why: Allowed on a conceptual diagram, but it cannot be implemented as drawn.
Try to store the grade
Why: There is nowhere to put it. Grade is not a fact about a student, and not a fact about a section.
The model has to be redrawn - and if this is caught after the database is built, so does the database.
Same two entities, resolved.
Insert ENROLLMENT between them, one-to-many from each side
Why: Every many-to-many relationship becomes two one-to-many relationships around a new entity.
Give ENROLLMENT the attributes that belong to the PAIRING
Why: Grade, status, enrollment date. These were homeless before, which was the clue the entity was missing.
Rule: a many-to-many relationship on a diagram is a junction entity you have not drawn yet.
Section
Part 8
Picture it
Everything in this course is one of these three views, or a refinement of one.
Figure (svg): Three model types in a row - use cases, data flow diagrams and an entity relationship diagram - each labelled with the question it answers, above a caption saying they describe the same system.
They are cross-checks on each other: the nouns in your use case steps become your ERD entities, and the verbs become your DFD processes. If your ERD has an entity no use case mentions, one of the two is wrong.
Pattern
When you are handed a case study and told to 'analyze the system', do these eight things in this order.
Steps 5 and 6 are the whole trick: your use cases already contain your DFD and your ERD. You are extracting, not inventing.
Ranking
Shuffled. Put the eight steps back in the order you would actually do them.
Put in order
Why: Boundary, actors, use cases, alternate flows, then the two extractions - verbs to processes, nouns to entities - then resolve the many-to-manys, then cross-check. The order matters because each step consumes the output of the one before it: you cannot pull verbs out of use cases you have not written, and you cannot cross-check models that do not exist yet. It is the SDLC's own logic, applied to a single assignment.
Check
Answer it in your head before clicking.
Check your understanding
Which of these is a NON-functional requirement for the registration system?
Answer: B
Why: Availability is a quality the system must HAVE while it does its job, not something it DOES - you cannot demonstrate 99.9 percent uptime by clicking through the system once. The other three all describe behaviors with a trigger and an outcome, which makes them functional.
Check
One classmate's diagram, one specific fault.
Check your understanding
A process on a level 0 DFD is labelled '3.0 Record enrollment'. It has one incoming flow, 'eligible request', and one outgoing flow, 'confirmation'. It touches no data store. What is the problem?
Answer: C
Why: The use case's postcondition said an enrollment record must exist afterwards. A process that never writes to a data store cannot create a record, so the DFD and the use case contradict each other - and that cross-check between models is exactly what step 8 of the recipe is for. The fix is a flow from 3.0 into D3 ENROLLMENT.
Connect it up
One sketch, and it is the thing worth keeping from today.
Draw it
Draw four boxes - SDLC, requirements, use cases, DFD/ERD - and write on each connecting line what one hands to the next. Then add one line back from the models to requirements, and label it.
The line back matters most: drawing the models always uncovers requirements nobody stated. That is not a sign you did the analysis wrong - it is what the analysis was FOR.
Exit ticket
One question, and it decides what we do next time.
Predict first
Which of these would help you most in session 2?
Correct: Walk through my actual syllabus and build a study plan against it
Why: Whichever you pick is the right answer for you - but if you are unsure, start with the syllabus. Today's deck taught the subject generically; the fastest gains come from mapping it onto what your instructor actually grades. Bring the syllabus, the textbook title, and the first assignment, and session 2 builds the plan around them.
Recap
Coming in you had no material. Going out you have a vocabulary, a life cycle, three models, and a recipe.
| if you are stuck on... | go back to... |
|---|---|
| what to write down at all | the eight-step recipe in Part 8 |
| a vague requirement | name the test that would prove it - Part 4 |
| a use case that feels wrong | check it describes goals, not clicks - Part 5 |
| an unbalanced DFD | count the flows crossing the boundary against the context diagram - Part 6 |
| nowhere to put an attribute | you are missing an entity - Part 7 |
Dennis, Wixom & Roth - Systems Analysis and Design (SDLC phases, requirements, use cases, process and data models) Ch. 1-6
Want this taught 1-on-1? Alexander tutors Systems Analysis & Design — $55/session, free consultation.