|Fact finding||deployment, DFDs, scenarios, data samples,...|
|Problem Solving||DFDs, Activity diagrams, Cost-Benefit tables|
|Data Base Design||DFDs, ERDs, data samples, Data Ditionary|
|Human-Computer Interfaces||activity diagrams, storyboards, HTML, CSS, ..., Samples|
|SDS All of the above + Business case: CPM and Cost-Benefit, prototypes|
|Software Development||DFDs, ERDs, stories, use cases, SQL, logic, mathematics, code|
|Installation & Training||Use Case diagram, scenarios, stories, procedures,|
|Operation & Maintenance||All of the above|
A Use case diagram shows who is involved in the system and what they want to do with it. It does not show any data flows. It does not show any data stores. It does show what people want todo with a system/program/app.
DFDs are good tools for analysing systems and early designs. Use cases are good requirements tools and completing the design.
Normalization will correct any mistaken primary keys... you will end up with a table with a primary key and no dependent data... and throw it out.
Required rules are properties that you have to make true, and are probably false right now.
. . . . . . . . . ( end of section Questions Asked in 2011) <<Contents | End>>
Notes -- Analysis [ a1.html ] [ a2.html ] [ a3.html ] [ a4.html ] [ a5.html ] -- Choices [ c1.html ] [ c2.html ] [ c3.html ] -- Data [ d1.html ] [ d2.html ] [ d3.html ] [ d4.html ] -- Rules [ r1.html ] [ r2.html ] [ r3.html ]
Projects [ project1.html ] [ project2.html ] [ project3.html ] [ project4.html ] [ project5.html ] [ projects.html ]
Field Trips [ F1.html ] [ F2.html ] [ F3.html ]
[ about.html ] [ index.html ] [ schedule.html ] [ syllabus.html ] [ readings.html ] [ review.html ] [ glossary.html ] [ contact.html ] [ grading/ ]