The follow-up to the orientation session, going down into three things that survey introduced and could not finish, all on the same campus course-registration case study. It derives normalisation from the insert, update and delete anomalies and takes a flat registration table to third normal form step by step, showing that the entity relationship diagram from session 1 follows by rule rather than by taste. It then fills in what a data flow diagram deliberately leaves out - process specifications in structured English, decision tables with their two to the n completeness check, and when to use a decision tree instead. It closes with the design half of the life cycle: logical against physical design, five named interface principles, the four testing levels, and the four conversion strategies plotted against risk and cost with a template for justifying a choice.
Subject: Systems Analysis & Design · 60 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
Systems Analysis and Design - Session 2
Normalisation, what goes inside a process, and the design half of the life cycle
Objectives
Session 1 was wide on purpose: the whole life cycle, requirements, use cases, data flow diagrams and a first data model, all against the campus registration case study. Today goes down instead of across, into the three things that survey introduced and could not finish.
Kendall and Kendall, Systems Analysis and Design — process specification and design chapters process specification and design — The chapters this session tracks.
Warm-up
Session 1 ended with three open questions about your course. Let us close them if we can.
Discussion prompt
Since last session, have you found out which textbook and notation your course uses, and is there an assignment or deliverable due that we should aim today's second half at?
Hint: Even a syllabus page or an assignment brief changes what we should prioritise.
Answer:
If you have them, we will re-order this session around the deliverable, because working on the real artefact always beats working on my case study.
If you do not yet, that is fine. Everything today runs on the registration case study from session 1, so nothing depends on materials you do not have, and we can map it onto your course's notation later.
Picture it
The same five phases from session 1. Today we move down two of them.
Figure (svg): The five life cycle phases stacked vertically, with analysis marked as the previous session, design highlighted as most of today, and implementation as the last part of today.
The line between analysis and design is worth watching. Analysis says what the system must do. Design says how it will do it. Crossing that line early is the trap session 1 called jumping to the solution.
Section
Why the data model from session 1 had that shape
Concept
Session 1 built an entity relationship diagram with separate entities and a junction table, and took that shape mostly on trust. Here is where the shape comes from.
Imagine the registration system storing everything in a single flat table with one row per enrolment, holding the student, the course, the instructor and the grade all together.
| StudentID | StudentName | CourseID | CourseTitle | InstructorName | Grade |
|---|---|---|---|---|---|
| S101 | Rivera | CS210 | Data Structures | Okonkwo | A |
| S102 | Chen | CS210 | Data Structures | Okonkwo | B |
| S101 | Rivera | MK300 | Marketing | Alvarez | A |
It looks convenient and it is a trap. The course title and the instructor name are repeated on every enrolment row, and that repetition is the source of everything that goes wrong next.
Picture it
These have names, and the names appear on exams.
Figure (svg): Three panels describing the insert, update and delete anomalies caused by storing repeated data in a single flat table.
Normalisation is not tidiness. It is the systematic removal of the conditions that produce these three anomalies.
Definition probe
Each of these is a real consequence of that flat table. Sort them.
Sort into buckets
Sort each situation by which anomaly it is.
Concept
Each normal form removes one specific kind of dependency, and each assumes the previous one is already satisfied.
| form | the rule | what it removes |
|---|---|---|
| first | every cell holds one value, and there are no repeating groups | lists crammed into one field |
| second | no non-key column depends on only part of a composite key | partial dependencies |
| third | no non-key column depends on another non-key column | transitive dependencies |
A useful shorthand, and the one most instructors want repeated back: every non-key attribute must depend on the key, the whole key, and nothing but the key.
E. F. Codd, A Relational Model of Data for Large Shared Data Banks (the origin of normalisation) 1970 — The paper this all comes from.
Notation
That one sentence encodes all three forms. Take it apart clause by clause.
Annotate
On: \( \text{depend on } \underbrace{\text{the key}}_{1\text{NF}}, \; \underbrace{\text{the whole key}}_{2\text{NF}}, \; \underbrace{\text{and nothing but the key}}_{3\text{NF}} \)
If a table has a single-column key, second normal form is automatic. It is only composite keys that can carry a partial dependency, which narrows where you have to look.
Worked example
Take the flat table to third normal form, one dependency at a time, saying what is removed at each step.
Check first normal form and identify the key.
Why: Every cell already holds a single value, so first normal form holds. A row is uniquely identified by the student together with the course, so the key is composite: StudentID plus CourseID.
Look for partial dependencies against that composite key.
Why: StudentName depends only on StudentID, and CourseTitle and InstructorName depend only on CourseID. Each depends on part of the key rather than all of it, which violates second normal form.
Split off each partially dependent group into its own table.
Why: Student attributes go to a STUDENT table keyed by StudentID, course attributes to a COURSE table keyed by CourseID, and what remains is the enrolment fact itself: the two identifiers and the grade.
Now look inside COURSE for transitive dependencies.
Why: InstructorName does not really depend on CourseID. It depends on the instructor, who happens to be identified by the course. That is a dependency of one non-key attribute on another, which violates third normal form.
Split the instructor out and leave a foreign key behind.
Why: INSTRUCTOR gets its own table keyed by InstructorID, and COURSE keeps InstructorID as a foreign key. The instructor's name is now stored exactly once in the whole database.
Figure (svg): The single flat registration table shown above four separate tables it decomposes into: STUDENT, COURSE, INSTRUCTOR and ENROLLMENT, with primary and foreign keys marked.
Verify: re-check each anomaly against the new design.
Why: A new course can be inserted with no enrolments, because COURSE stands alone. An instructor rename touches exactly one row in INSTRUCTOR. Dropping the last enrolment removes an ENROLLMENT row and leaves the COURSE untouched. All three anomalies are gone, which is how you know the decomposition was the right one rather than merely a different one.
Trap
Students take many courses and courses hold many students. That is a many-to-many relationship, so draw it directly between STUDENT and COURSE and move on.
Adding a table in the middle just adds complexity for no benefit.
A many-to-many relationship cannot be stored directly in a relational database. There is nowhere to put the foreign key: putting a CourseID in STUDENT allows one course per student, and putting a StudentID in COURSE allows one student per course. Both are wrong.
The junction table, ENROLLMENT here, is where the relationship physically lives. Its key is the pair of foreign keys together.
There is a second reason it is mandatory, and it is the one that shows up in assignments. Attributes belonging to the relationship rather than to either entity have nowhere else to go. The grade is not a property of the student and not a property of the course; it is a property of that student in that course.
Whenever you find an attribute you cannot place in either entity, you have found evidence that the relationship itself is an entity. Session 1 called this the missing junction entity, and normalisation is why it cannot be skipped.
Error analysis
A submitted answer. First and second normal form are satisfied; one violation remains.
Annotate
On: \( \text{COURSE}(\underline{\text{CourseID}}, \text{CourseTitle}, \text{InstructorID}, \text{InstructorName}, \text{InstructorOffice}) \)
The tell is a group of attributes that all travel together and all describe something other than the table's subject. Two or more attributes sharing a prefix is a strong hint.
Edge cases
There are higher normal forms, and production systems sometimes go the other way on purpose.
Discussion prompt
Third normal form is usually where courses stop. Why might a working system deliberately store data in a less normalised form?
Hint: What does splitting one table into four cost you at query time?
Answer:
Every split turns a single table read into a join. A heavily normalised design can require joining half a dozen tables to answer one screen's worth of questions, and joins cost time.
So reporting and analytics systems often store deliberately denormalised copies, accepting the redundancy in exchange for speed. The anomalies are tolerable there because the copy is rebuilt from the normalised source rather than edited directly.
The rule of thumb worth carrying: normalise the system of record, and denormalise copies made for reading. For coursework, normalise, because the assignment is testing whether you can find the dependencies.
Pattern
A procedure you can run on any table an assignment gives you.
Step three is where the real work is. Most wrong answers come from asserting a dependency rather than checking it, so write each one out as a short sentence: this attribute is determined by that one.
Check
Solve it on paper before you click.
Check your understanding
A table has the composite key OrderID plus ProductID, and contains the columns Quantity, ProductName and ProductPrice. Which normal form does it violate first?
Answer: B
Why: ProductName and ProductPrice are determined by ProductID alone, which is half of the composite key. That is a partial dependency, so second normal form is violated. Quantity is the only column that genuinely needs both parts of the key, since it is the quantity of that product on that order.
Concept
Normalisation is stated in terms of keys, so the vocabulary has to be exact before the rules mean anything.
Candidate key — Any column or combination of columns that uniquely identifies a row. A table can have several.
Primary key — The candidate key actually chosen to identify rows. Exactly one per table, and it can never be empty.
Foreign key — A column holding the primary key of another table. This is the only mechanism a relational database has for connecting tables.
In the normalised registration model, ENROLLMENT has a composite primary key made of two foreign keys. That combination is the standard signature of a junction table, and recognising it on sight is worth doing.
Matching
From the four normalised tables built in the worked example.
Match the pairs
Why: The same column plays different roles in different tables, which is the point. StudentID identifies rows in STUDENT and points at them from ENROLLMENT. A unique email could identify a student but was not selected, which makes it a candidate key rather than the primary one, and identifiers are usually preferred because they never change.
Counterexample
ENROLLMENT has a two-part key, so a student might conclude junction tables always work that way.
Discussion prompt
Could a junction table legitimately have a single-column primary key instead, and what would change?
Hint: What if the same student can enrol in the same course in two different terms?
Answer:
Yes. If the same pair can legitimately occur more than once, the pair no longer identifies a row and the key must be extended or replaced. Adding TermID gives a three-part key; adding a surrogate EnrolmentID gives a single-column one.
The choice is a real design decision. The composite key enforces the uniqueness rule automatically, while a surrogate key is simpler to reference but needs a separate uniqueness constraint to enforce the same rule.
The general lesson: the key comes from what one row means, which is why the normalisation recipe starts by writing that sentence down rather than by looking at the columns.
Faded example
State the dependency that third normal form is objecting to in the half-normalised COURSE table.
Fill in the blanks
\textInstructorID \to InstructorName \to ___
Why: Reading the arrows as determines: the course determines its instructor's identifier, and that identifier determines the instructor's name. Because the name is reached through a non-key attribute rather than directly from the key, the dependency is transitive and the name belongs in a table of its own.
Socratic
Students often report that normalising makes the design look more complicated, not less.
Discussion prompt
You started with one table a person could read at a glance and finished with four plus a set of foreign keys. In what sense is that simpler?
Hint: Simpler for whom, and simpler to do what?
Answer:
It is not simpler to read. It is simpler to change, and changing is what a system spends its life doing. Every fact now has exactly one home, so every update touches exactly one place.
The complexity did not appear during normalisation. It was already there, hidden as duplication, and normalisation only made it visible as structure. Duplication is complexity that has not been named yet.
This is the same argument session 1 made about finding requirement errors early. The cost is paid now, in a diagram, rather than later, in a live system full of contradictory instructor names.
Section
Session 1 drew the bubbles; this fills them in
Concept
A data flow diagram shows that a process transforms its inputs into its outputs. It deliberately does not show how, which is why it stays readable at a glance.
Somewhere, though, the how has to be written down, or a developer cannot build it. That document is the process specification, and it attaches to the lowest-level processes only.
Process specification — A precise statement of the logic inside one primitive process: how its inputs become its outputs, in a form unambiguous enough to code from.
Only primitive processes get one. A process that decomposes into a lower diagram is described by that diagram instead, which keeps every piece of logic in exactly one place.
Discrimination
Three notations, and the choice is driven by the shape of the logic rather than by preference.
Sort into buckets
Sort each piece of process logic by the notation that fits it best.
Concept
Structured English is ordinary English restricted to a small vocabulary of control structures, so it reads naturally and translates directly into code.
The discipline is in the vocabulary. Words like appropriately, as needed and if necessary are exactly the vague-requirement problem from session 1 reappearing one level down.
Worked example
Write the specification for the DFD process that decides what happens when a student requests a section.
List the inputs and outputs first, taken from the arrows on the diagram.
Why: The specification must consume exactly what the diagram says it consumes and produce exactly what it produces. A mismatch between the two is a marked error and it is easy to avoid by starting here.
State the conditions in the vocabulary of the data dictionary.
Why: There are three: whether the prerequisite is satisfied, whether a seat is available, and whether the account carries a hold. Naming them exactly as the dictionary does keeps the whole document consistent.
Write the logic in structured English.
Why: Indentation carries the nesting, and every branch ends with an explicit action so no path is left undefined.
| structured English |
|---|
| IF account hold exists |
| reject request and issue hold notice |
| ELSE |
| IF prerequisite not satisfied |
| reject request and issue prerequisite notice |
| ELSE |
| IF seat available |
| create enrolment record |
| ELSE |
| add to waiting list |
| ENDIF |
| ENDIF |
| ENDIF |
Figure (svg): The structured English for the enrolment process drawn with indentation guides showing the nesting of the three conditions and its four leaf outcomes.
Verify: trace every path and confirm each ends in a defined outcome.
Why: There are four leaves: hold notice, prerequisite notice, enrolment created, and waiting list. Every combination of the three conditions reaches exactly one of them, and none falls through without an action. A path with no action is the most common defect in a submitted specification.
Concept
A decision table lays out every combination of conditions as a column, so completeness stops being a matter of opinion.
The number of columns is fixed before you write anything: two to the power of the number of yes-or-no conditions.
\[ \text{rules} = 2^{\,n} \qquad \text{for } n \text{ independent yes-or-no conditions} \]
Three conditions give eight columns. If your table has seven, a combination is missing. If it has nine, one is duplicated. That is why these are marked strictly: the count is checkable without understanding the domain at all.
Worked example
The same three conditions, now as a table, so completeness can be proved rather than asserted.
Count the rules before drawing anything.
Why: Three yes-or-no conditions give two to the third power, which is eight rules. Knowing the target first is what makes the omission impossible to miss.
\[ 2^3 = 8 \text{ rules} \]
Enumerate the combinations in a fixed pattern rather than at random.
Why: Alternating the last condition every column, the middle one every two and the first every four guarantees every combination appears exactly once, and makes a missing column visible as a broken pattern.
| condition | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|---|---|---|---|---|---|---|---|---|
| account hold | Y | Y | Y | Y | N | N | N | N |
| prerequisite met | Y | Y | N | N | Y | Y | N | N |
| seat available | Y | N | Y | N | Y | N | Y | N |
| enrol | - | - | - | - | X | - | - | - |
| waiting list | - | - | - | - | - | X | - | - |
| reject: hold | X | X | X | X | - | - | - | - |
| reject: prerequisite | - | - | - | - | - | - | X | X |
Check that every rule selects exactly one action.
Why: Reading down each column there must be exactly one mark. A column with none is an unhandled case; a column with two is a contradiction the developer would have to resolve by guessing.
Look for rules that can be collapsed.
Why: The first four columns all reject for a hold regardless of the other two conditions, so they can be merged into a single rule with dashes for the irrelevant conditions. That is a simplification, not a shortcut, and it is only legal once the full table has been checked.
Figure (svg): The eight-rule decision table drawn as a grid with three condition rows and four action rows, showing exactly one mark in every column.
Verify: confirm the table and the structured English agree.
Why: The structured English produced four outcomes, and the table produces the same four across its eight rules. Building both and cross-checking them is the strongest verification available here, and disagreement always means one of the two is wrong.
Fill the middle
A process has four independent yes-or-no conditions.
Fill in the blanks
\text4 = 2^16} = ___
Why: Each condition doubles the number of combinations, so four yes-or-no conditions give sixteen rules. This is also the number that tells you when a decision table has stopped being the right tool: past about four conditions the table gets unwieldy and the logic is usually better decomposed into more than one process.
Two truths and a lie
Four statements about process specifications. One is correct.
Eliminate the wrong options
Rule out the three that contradict how specifications work, and keep the survivor.
Survives elimination: s2
Why: The specification and the diagram are two views of one process and must agree exactly. A specification that quietly uses data the diagram never delivers is the most common consistency error across these documents, and it is the first thing a marker checks because it can be checked mechanically.
Concept
Structured English insisted on using only names from the data dictionary. That document is worth describing, because it is what stops three diagrams from quietly disagreeing.
Data dictionary — A central record of every data element and data store in the system: its name, meaning, type, length, allowed values and where it is used.
Its job is single definition. The term seat available must mean the same thing in the data flow diagram, the process specification, the data model and the interface, and the dictionary is where that meaning is fixed once.
When a marker checks consistency between your models, the dictionary is what they check against. Two diagrams using slightly different names for the same element is the defect it exists to prevent.
Error analysis
Submitted structured English for a fee-calculation process. The logic is fine; it still fails review.
Annotate
On: \( \text{IF student is eligible, apply the appropriate discount as needed} \)
Test any specification by asking whether a developer who knows nothing about the domain could implement it without asking a question. If not, the missing words are the specification's real content.
Ranking
The order in which they can actually be produced, since each depends on the one before it.
Put in order
Why: You cannot draw a boundary without knowing what is required, cannot decompose a boundary you have not drawn, cannot specify processes that do not yet exist on a diagram, and should not choose data types before the logical model is settled. Every arrow forward in this list is a dependency, which is why working out of order produces documents that contradict each other.
Anomaly
A student submits a process specification for a process that appears on the context diagram.
Predict first
What is wrong, structurally?
Correct: The context diagram has exactly one process representing the whole system, which is never primitive
Why: The single process on a context diagram is the entire system, and it always decomposes into the level 0 diagram. Since specifications belong only to primitive processes, one written at this level is describing something that is explained by a diagram instead, which means the logic now exists in two places and will drift apart.
Section
What changes once you cross the line
Concept
Design splits into two stages, and mixing them is the single most common structural problem in submitted coursework.
Logical design — What the system must do and what data it holds, independent of any technology. It survives a change of platform.
Physical design — How it will actually be built: the database product, the table types, the screens, the hardware, the language.
Everything from session 1 and from Part 1 today is logical. An entity relationship diagram is logical; the table definitions with data types and indexes are physical. A data flow diagram is logical; the module structure is physical.
Definition probe
Sort each decision. The test is whether changing the technology would change the answer.
Sort into buckets
Sort each design decision by which stage it belongs to.
Concept
Interface design is graded in most versions of this course, and it is graded against named principles rather than taste.
For the registration case, recognition over recall is the one with the biggest payoff: a course picker with search beats a field expecting the student to know that Data Structures is CS210.
Real world
Think about the registration system your own institution uses.
Discussion prompt
Name one place where it violates one of those five principles, and say which principle and what the fix would be.
Hint: Error messages you have seen more than once are a good place to look.
Answer:
The common answers: a timetable clash reported only after submitting the whole form, which is error prevention failing when the clash could have been detected as the section was chosen.
Another frequent one: needing the course code rather than being able to search by title, which is recall where recognition would do.
A third: no confirmation on dropping a course, which is forgiveness missing on an action that is genuinely hard to reverse once a section fills.
The exercise matters because naming the principle is what turns an opinion into a design critique, and that is the difference the marking scheme is looking for.
Concept
Implementation testing is layered, and each layer catches a different class of defect. Naming them in order is a standard exam question.
| level | what is tested | who typically runs it |
|---|---|---|
| unit | one module in isolation | the developer who wrote it |
| integration | modules working together across their interfaces | the development team |
| system | the complete system against its requirements | a test team |
| acceptance | whether the users agree it does what they asked for | the users themselves |
Notice that acceptance testing checks the requirements from session 1. A requirement written so vaguely that it cannot fail is a requirement acceptance testing cannot use, which is why that trap mattered.
Ranking
From narrowest scope to widest.
Put in order
Why: Each level widens the scope and moves the tester further from the code. Running them in this order means a defect is caught by the cheapest test that can catch it, which is the same economic argument session 1 made for finding requirement errors early rather than late.
Concept
Physical design has to choose a shape for the system, and the choice constrains everything afterwards.
| architecture | where the work happens | typical reason to choose it |
|---|---|---|
| centralised | one server does everything | simplicity, small user base, tight control |
| client-server | split between client and server | the standard for business systems |
| three-tier | presentation, logic and data separated | each layer can change or scale on its own |
| cloud-hosted | infrastructure rented rather than owned | elastic demand, no data centre to run |
For a campus registration system the deciding fact is usually demand shape: near-zero for most of the year and enormous for two days each term. That argues strongly for something that can scale on demand.
Elimination
Four defences of a three-tier architecture for the registration system. Only one is an argument.
Eliminate the wrong options
Rule out the three that assert rather than justify, and keep the real argument.
Survives elimination: j2
Why: Only the second names a specific property of this system, explains the consequence, and connects it to the architecture. That is the shape every design justification should take: here is the constraint, here is what it implies, here is the choice that follows.
Comparison
Fill the missing cells. The test remains whether changing the technology changes the answer.
Comparison matrix
| Artefact | Stage | Survives a change of platform |
|---|---|---|
| entity relationship diagram | logical | yes |
| table definitions with data types | physical | no |
| data flow diagram | logical | yes |
| screen layouts | physical | no |
The third column is the test itself. If an artefact would have to be rewritten because you switched database or language, it was physical all along.
Explain it to yourself
Keeping two documents where one would do looks like extra work.
Discussion prompt
What concretely goes wrong when logical and physical design are written as one document?
Hint: Think about what happens when the platform decision changes late.
Answer:
The business rules become inseparable from the technology choices. When the platform changes, you cannot tell which parts of the document still hold, so the whole thing is rewritten and rules get lost in the process.
It also lets technology decisions leak backwards into analysis. A rule stated as the field is 9 characters has silently replaced the real rule, which was about what a student identifier is, and the real rule is now written nowhere.
Keeping them apart means the logical model is the durable asset. Systems get rebuilt on new platforms every decade or so, and a good logical model survives every one of those rebuilds.
Trap
The users care about the screens, so start there. Design the interface first, then build whatever database is needed to fill it in.
Screens designed before the data model encode assumptions about what data exists and how it relates, and those assumptions are usually wrong in exactly the ways normalisation would have caught.
A screen showing a course with one instructor name quietly assumes a course has exactly one instructor. If the institution allows co-teaching, that assumption is now embedded in a design nobody will revisit until it fails.
The order that works is logical data model, then process logic, then interface. The interface is the last thing designed because it is the layer that changes most often and depends on everything else.
This does not mean ignoring users until the end. Prototyping screens early to elicit requirements is good practice. The trap is letting a prototype become the design without the data model ever being checked against it.
Section
Four strategies, and how to defend a choice
Concept
Once the system is built and tested, it has to replace whatever came before. There are four standard ways, and assignments ask you to choose one and justify it.
| strategy | how it works | main risk |
|---|---|---|
| direct cutover | old system off, new system on, one date | no fallback if the new system fails |
| parallel | both run together and results are compared | double the workload while it lasts |
| phased | one module or function at a time | temporary interfaces between old and new |
| pilot | one site or group first, then the rest | the pilot group may not be representative |
There is no correct answer in the abstract. The mark is for matching the strategy to the risk the situation actually carries, and saying so explicitly.
Picture it
The four strategies plotted where they actually sit.
Figure (svg): A plot of the four conversion strategies against cost on the horizontal axis and risk on the vertical, with direct cutover high risk and low cost, parallel low risk and high cost, and phased and pilot in between.
Every one of these is defensible somewhere. What is not defensible is choosing one without saying which risk you were buying down and what you paid for it.
Matching
Each of these has one clearly best answer.
Match the pairs
Why: Payroll cannot tolerate a failed cutover, so the cost of running both systems is worth paying. Multiple campuses give a natural pilot boundary. A tiny low-risk tool does not justify the overhead of anything more careful. A system with genuinely separable functions is the textbook case for phasing, because each phase is a smaller bet than the whole.
Trade off
Fill the missing cells. The marks are in the justification, not the choice.
Comparison matrix
| Strategy | Buys down | Pays with |
|---|---|---|
| direct cutover | almost nothing | accepted risk, in exchange for lowest cost |
| parallel | the risk of the new system being wrong | double running costs and staff effort |
| phased | the size of any single failure | temporary interfaces between old and new |
| pilot | the risk of a fault reaching everyone at once | a longer overall transition |
Write your justification in exactly this shape: the risk I am most worried about is X, this strategy reduces it, and the price is Y which is acceptable because Z. That sentence is worth more marks than the choice itself.
Check
Solve it on paper before you click.
Check your understanding
A hospital is replacing its patient records system. Losing or corrupting records would be catastrophic and the budget is generous. Which conversion strategy is most defensible?
Answer: B
Why: The risk being bought down is catastrophic data loss, and parallel conversion is the only strategy that keeps a complete working fallback throughout. Its cost is double running, and the stated generous budget is exactly what makes that price acceptable, which is the justification the question is testing.
Concept
Three things happen alongside the cutover and all three appear in marking schemes, usually as the part students forget.
Data conversion is where the schedule usually slips. Cleaning old data is discovered rather than planned, because nobody knows how bad it is until they try to load it.
Estimation
A phased conversion runs over three months, one module per month.
Predict first
When should users be trained on the third module?
Correct: Shortly before that module goes live
Why: Training decays quickly when it is not used. Delivered at project start it is forgotten before it is needed; delivered after go-live it arrives after the mistakes have already been made. Just before the module goes live is the only timing where the knowledge is fresh and immediately exercised, which is why phased conversion schedules training in phases too.
Sorting
A go-live plan is graded on completeness. Sort what belongs in it.
Sort into buckets
Sort each item by whether it belongs in the conversion plan.
Pattern
A structure that will fit most assignments in this course, and keeps the logical and physical split visible.
Marks are usually lost between sections rather than inside them. Every physical decision should point back at the logical item it implements, and every logical item should be implemented somewhere.
Explain it
A classmate's design document has a good normalised model and a good set of screen layouts, and it scores poorly.
Discussion prompt
What is the most likely structural criticism, given how these documents are marked?
Hint: Two good sections is not the same as a coherent document.
Answer:
Almost certainly that nothing connects them. The screens are not traceable to the data model, so there is no way to check whether every screen is supported by the data or every entity is reachable by a user.
The usual specific findings are a screen displaying a field the model does not store, and an entity nothing in the interface can create or edit. Both are found by walking the two sections against each other, which is exactly what a marker does.
The fix is a traceability pass rather than more content: for each screen list the entities it touches, and for each entity list where it is created, read, updated and deleted. Gaps in that grid are the defects.
Connect it up
One page connecting session 1 and today, which is also a revision sheet.
Draw it
Draw the five life cycle phases down the left. Beside analysis, list the artefacts from session 1: requirements, use cases, data flow diagram, entity relationship diagram. Beside design, list today's: normalised tables, process specifications, decision tables, logical and physical design, interface principles. Beside implementation, list the testing levels and the four conversion strategies. Then draw arrows showing which analysis artefact each design artefact came from, and mark any arrow you cannot justify.
The arrows you cannot justify are the gaps. Bring them next session and we will close them against your actual course materials.
Exit ticket
The idea that ties Part 1 to everything else.
Predict first
Why does normalisation matter to a systems analyst rather than only to a database developer?
Correct: It removes update, insert and delete anomalies, so the data model can represent the business rules truthfully
Why: Normalisation is an analysis activity because the anomalies are business problems rather than technical ones. A design that cannot record a new course until somebody enrols is failing to represent how the institution actually works, and that is exactly the kind of gap an analyst exists to catch. Faster queries are usually the opposite of what normalisation gives you, since it adds joins.
Recap
Six things, on top of everything from session 1.
| if the assignment asks for | reach for |
|---|---|
| a data model from a flat table | normalise to third normal form |
| the logic inside a process | structured English, or a decision table if conditions combine |
| proof that all cases are handled | a decision table with two to the n rules |
| a design document | split logical from physical before writing |
| a go-live plan | a conversion strategy plus an explicit risk justification |
The thread through both sessions: every model is a promise that can be checked. A requirement that cannot fail, a decision table with a missing column and a table with an update anomaly are all the same defect wearing different clothes.
Valacich and George, Modern Systems Analysis and Design — implementation and conversion implementation and conversion — Where to read further on Part 4.
Want this taught 1-on-1? Alexander tutors Systems Analysis & Design — $55/session, free consultation.