Introduction

A system project comes to a critical point when the complete new system is described in a "System Design Specification". This is the time when management can be told enough about the project to make a "go/no go" decision. The "System Design Specification" provides the data and should win management backing for the work to be done to complete the project. It is the result of all the previous work and combines together the all the artifacts produced. It summarizes the results using many techniques, methods, and tools. You will be preparing one of these and I have designed a template for it that is suitable for this class.
1. SDS::artifact="System Design Specification", has these main headings:
   
   1. Executive Summary
   2. System Components
   3. Requirements
   4. Implementation plans
   5. Operation and Maintenance plan
   
   

   Project 5 Deliverable -- Systems Design Specification

   Diagrams must follow standards covered in this class.

   Executive Summary

   (Two Pages max)

   Front Sheet

   1. Title
   2. Names of People
   3. Vision/Description
   4. Context DFD: a single central process + external contact points only. [ a4.html ]

   . . . . . . . . . ( end of section Front sheet) <<Contents | End>>

   Second Sheet

   1. Time and Cost Estimates Cost/Benefit analysis. Overall development plan.

   . . . . . . . . . ( end of section Second Sheet) <<Contents | End>>

   . . . . . . . . . ( end of section Executive Summary) <<Contents | End>>

   System Components

   Data Flows and Processes

   Level zero fish eye DFD -- shows main programs/components and data interacting with the rest of the world. [ a4.html ]

   You must include level 1 DFD expanding any level 0 process that is too big to be a single program. [ a4.html ]

   You may include a narrative, activity diagram/flowchart, ... describing any complex or interesting process.

   All data (flows and stores) should be named. There must not be a store called "Data Base"!

   Data Base

   The data should be in Third Normal Form. [ d4.html ] All data in DFDs should be defined.

   Entity Relationship diagram -- -- --(ERD)
   [ d3.html ]

   Data Definition

   Data dictionary: For each entity list the attributes/data elements List of attributes (and keys) for each table/entity in the ERD. Name, type, Key?, constraints, defaults,...
   1. OR
      • Use UML class diagram and make attributes,<<PK>>, <<FK>> etc. visible.
      [ d1.html ] [ d2.html ]

      System Architecture

   2. Deployment: nodes, connections, and deployed artifacts. [ a3.html ]
   3. How do the deployed artifacts realize the needed data and processing components?

   Requirements

   Use cases / Functions

   Use case diagram showing all actors and naming all use cases.

   Brief descriptions of two or three most interesting use cases.

   You can include casual or fully-dressed uses cases for any really critical use case (one that needs to be done first to mitigate risks, for example).

   Rules

   Define all special "Business" Rules that apply.

   Non-Functional Constraints on System

   Describe any of the following that apply

   Interfaces with other systems

   Hardware that must be used

   Software that must be used

   Security

   Usability

   See [ d1.html ] for techniques to improve usability.

   Reliability

   Response times

   Processing schedules

   Deadlines for development

   Data Storage limitations

   Security

   other qualities that you think are important

   Implementation Plans

   Check out [ c2.html#Implementation ]

   Plan

   Implementation Schedule with Critical Path Analysis if needed.

   Development plan

   How each artifact is either acquired or created. Don't forget that there are alternatives to writing new software.

   In what sequence are the various use cases to be programmed? Why? How? When? Who?

   Startup

   How to cut over from old to new. Why select this method?

   Initial data

   How to generate the initial data?

   User training

   How much, when, who does it, ...

   Test plans

   Unit, Integration, ...

   Operation and Maintenance Plans

   Optional Appendices

   ???

   . . . . . . . . . ( end of section Project 5 Deliverable -- Systems Design Specification) <<Contents | End>>

   Review Techniques Presented Previously

   Now would be a really good time to start reviewing the techniques, tools, and methods that you might need to complete the project and do well on the final.

   Questions

   Go over the DFD Types

   First there are different notations -- not an important difference.

   Second there are Physical and Logical DFDs. A Physical DFD shows the implementation of the data flows and stores. For example it mentions forms, packets, signals, etc. A Physical DFD may also mention physical details of the processing: "stick stamp on envelope". A logical DFD is more abstract and merely names the data types -- not how they are encoded or manifested.

   Finally there are "context DFDs", "Level 0 DFDs", "Level 1 DFDs", ... A context DFD has one process (typically numbered "0") surrounded by external entities. A level 0 DFD gives details of the processes and data inside the process of the context diagram. A Level 1 DFD takes one process in a level 0 DFD and expands it to show more internal processes and data. Similarly, each level 2 DFD expands a single level 1 DFD process.

   It is easier to understand leveled DFDs if you use (1) Fish-eye diagrams and (2) number the processes. A fish eye diagram shows the details inside a large process symbol with the same number and name. It shows the components that are connected to the expanded process out side. The numbering is: Process 0 is the process in the context diagram, Processes 1,2,3,4,..... are processes in the level-0 DFD of Process 0. Process 1.2 is a process inside process 1 (inside process 0)... 1.2.1.3 is a process in a level 3 process....

   Here is a figure showing how successive levels work:

   

   (Note: I've used numbers rather than names to save space).

   Here is a pair of DFDs describing the way we used to handle bills, checks, and bank statements when the bank returned checks to us

   ---

   

   

   ---

   Notice -- it is not possible to describe the above system (as currently implemented) as a scenario because it is not a sequence of activities. Two people work on different processes at once: an enveloped is being opened, split and stamped while a different bill is having a check written for it. More -- the arrows allow data to pile up. If the person writing check is delayed for some reason the envelope preparation continues and a small pile of prepared bills to be paid stack up in the middle of the table. A single scenario can not do justice to all these different sequences of events. The power of a DFD comes from its high level abstraction: ignoring the sequence of events in time, while controling the sequence of operations on a particular piece of data.

   Later I will show you how I changed the system when the banked stopped sending us the checks with the statement.

   You can also go back to [ a4.html ] for another example of leveled DFDs.

   What works best with end users a DFD or an ERD

   I think a simplified DFD is the place to start. ERD are more useful for technical details needed in design. However, you can use them with some stakeholders to validate them.

   Show how a DFD and ERD fit together

   Each data store in a DFD should be an entity in your ERD. The entities in the ERD define the data in the data bases and the DFD shows which processes access and update it.

   A good place to start a conceptual data model -- an ERD -- is with a list of the data stores in the DFDs. The ideal is for each store to hold a single type of entity and for this entity to have the same name in the ERD. The DFD shows how data moves and is processed. The ERD shows how it is structured.

   Each name of a data store is the name of an entity in the ERD. The ERD will probably have extra "linking" entities and lots of relationships that do not appear on a DFD. Notice that only data stores should appear in the ERD. Processes do not appear on the ERD unless they depend on the existence of a secondary key, index, or operational master so that they can efficiently retrieve a subset of the entities of a given type. A classic example is making it easy to scan a college's database for candidates for a deans list, or for department honor's. This means searching in the Student table for large GPAs. You can instruct most DBMSs to keep an index of Student by GPA and so to make it quick and easy to extract the best stsudents. Indeed such index could also be used to find students who are having problems.

   External entities do not appear on the ERD unless there is a data store that stores information about them.

   There is another subtle link between ERDs and processes. A process will use the links in the ERD to move from entity type to entity type to compute its outputs from its inputs. It may also create and delete instances of relations between entities in the ERD.

   Here is a case study starting from a Physical context DFD and level 0 DFD to a first physical ERD for the way we pay bills in my household after the banks stopped sending us the cancelled checks. This removes a useful data flow. Now we have to keep a memoranda of every check....

   ---

   

   

   

   ---

   Notice -- Even tho' we studied DFDs first and ERDs later, you can (indeed should) develop them in parallel: do some work on the DFDs and map it to the ERD, then work on the ERD and map it back to the DFD.

   Also note: if your ERD entities don't have the same names as your data stores then you will need to document which Entities are in each store.

   What DFD smell is worst

   First worry about errors: black holes (where data disappears), white holes (where data appears from no where), etc..

   The worst smell (to my mind) is a system that sends data out to a user in form that the user must re-input into another process. This wastes user time and introduces a source of error and abuse.

   

   Why do you want to normalize data

   1. Modern databases expect normalized data.
   2. Normalization removes anomalies.
   3. Normalization clarifies and exposes the structure hidden in the physical data.
   4. It produces better designs than intuition alone.

   Why normalize data in stages

   Basically -- because it works and other people will expect you to follow the classic: "The key, the whole key, and nothing but the key" procedure.

   Can you talk more about normalizing UML data bases

   There are three things that need to be done to a UML conceptual model to normalize it:
   
   1. All repeated attributes (marked [*] typically) are extracted into a class linked to the original class.
   2. All n-ary associations (with more than two ends) become classes.
   3. All many-many ( *--------* ) associations become a new class with one-to-many associations.
   4. THINK about one-one ( 1------1 ) associations: are they optional or are they identical?
   
   Here is a figure illustrating the changes:

   

   You can go further within the UML by marking prime keys <<PK>> and foreign keys <<FK>> and following the usual 1NF, 2NF, 3NF sequence. However I find it quicker to do this outside the UML, and to draw the UML diagram later.

   What is a non-functional requirement

   A non-functional requirement is a quality requirment. It constrains how a function is achieved. It defines the qualities of a piece of software.

   Example: the software sorts 3 million records successfully -- we say the software is functional. But if it takes 2 hours to do it and the user needs the sorted data in 2 minutes then the software fails a non-functional requirement.

   What is the difference between a high level functional and a high level non-functional requirement

   High level functional requirements are an imperative command, they have a verb, they pass the "Hey mom! I just _____" test. Examples: update..., delete...., raise the alarm, terminate the process, send EMail, display .... . A functional requirements defines a function of the software. It describes something that must be done. They define the purposes of the system.

   High level nonfunctional requirements are typically adverbs. Examples: Securely, user-friendly, reliably, ... . They apply a constraint to functional requirements. They describe the qualities of the software. The non-functional requirements often determine the architecture.

   You should always analyze high level requirements into low-level details. Functional requirements are probably best refined as use cases and nonfunctional as acceptance tests. Example: "In 99.9% of tests 3M items are sorted in less than 2 minutes", is a partial low-level specification of the high level non-functional requirement: "fast".

   What are use cases

   They are a set of scenarios that describe how a specific user attempts to achieve a specific tangible goal.

   Can you review the strategy behind using use cases

   A use case forces you to work out solutions that fit the user well. You start with the user and their goals and then turn these into scenarios describing how the user attempts to achieve the goals.

   Use cases place requirements in context -- grouped around the users -- what they want to do and how well it needs to be done.

   The detailed formats/templates for use-cases make sure you don't miss any important details that are show-stoppers.

   These scenarios are the basis for designing software to help the user get what they want. They describe the main program directly. In CSCI375 we will learn how they also define the objects and classes needed to support the main program.

   Online Resources

   1. Review the course. I would recommend that you start your review and revision process by opening [ mock.html ] which shows the structure of the final. Then [ finals.html ] which lists question from many previous finals. Finally you can look at [ dictionary.html ] which lists all the headline, defined terms, and formulas in this set of notes. Scan it to find topics that you don't understand, and then click

   . . . . . . . . . ( end of section Online Resources) <<Contents | End>> on them to review them -- good luck!

   Review Questions

   1. Write down one question you would like answered about any technique, topic, method, or tool covered in this class.
   2. List the five main sections of a Systems Design Specification from memory.
   3. Where in a Systems Design Specification do you find: a DFD, an ERD, Use cases, non-functional/quality requirements, Business Rules, deployment diagrams, and activity diagrams?
   4. What things must you worry about when implementing a system?
   5. What things must you worry about when planning the operation of a system?
   6. Write a list of the activities that occur when implementing and operating a computer system (Final Question).
   7. What are the main section found in a typical Systems Design Specification?
   8. Draw a context DFD of making a ham sandwich
   9. Draw a level-0 DFD that refines the previous context DFD.
   10. Draw a level-0 DFD of the flow of data from an existing system to analysis and design artifacts, and into an improved system (about half a dozen data stores and at least ten processes). Here is a high-level view that needs work: [ DFDADI.png ]
   11. List all the techniques covered in this class and complete the following table
       Table

       Name	Purpose	Form (diagram or text)	Includes	Excludes
       scenario	list steps	text	steps, sequence, repetition	choices, parallelism
       ...
       symbolic logic/math	show rules	text	formulas	actions, goals, choices, sequences

       
       (Close Table)
       
   12. Final Question on Implementation
       
       1. Name and describe four(4) changeover processes.
       2. How do the four changeover methods differ in terms of cost and risk? (draw a diagram)
       3. Name one(1) form of changeover process recently used at CSUSB.
       4. In which recent project was it used?
       
       

   . . . . . . . . . ( end of section Review Questions) <<Contents | End>>

. . . . . . . . . ( end of section System Specification and System Design) <<Contents | End>>

Abbreviations