This Course has been replaced by CSE557

Contents


    System Specification and System Design

      Introduction

      A system project comes to a critical point when the complete new system is described in a "System Design Specification" or SDS. 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 input into management's decisions. In most organizations there will be several competing project proposals, so it should be designed to win management backing for the work to be done to complete the project. It summarizes the results of using many techniques, methods, and tools. It is the result of all the previous work and ideally just combines together all the artifacts produced.

      You will be preparing an SDS for this class I have designed a template (SDS below) that is suitable. It is not dissimilar to those used in practice.

    1. SDS::artifact="System Design Specification", has the following 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

          (Three Pages)

          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. Cost/Benefit analysis. [ c2.html#Cost_benefit_analysis ]
          2. Overall development plan: How long, Who does what when? [ c3.html ]

          . . . . . . . . . ( 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 narratives, activity diagrams/flowcharts, ... describing any complex and/or interesting processes.

          All data (flows and stores) should be named with names from the ERD. 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 with attributes and stereotypes. Use <<PK>>, <<FK>> etc..
          [ 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. [ c3.html#Estimating and Planning ]

          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

        1. Operation
        2. Help/Support
        3. Four types of Maintenance
        4. Back up

        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

        How long in advance should one start planning out a new system

        It depends on the size of the system and how fast you can do it. Also it depends on how fast the problems are changing.

        A small change to a system might be planned in hours and implemented soon after. For example, I change the software that runs my web site every week and typically an iteration takes less than two hours (if all goes well). A colleague spends several days talking about the problems and possible solutions in his compiler and run-time system before he implements them. This often takes a week chasing obscure bugs. Changing the look and feel of my web site to Web 2.0 started in Spring 2009 and is continuing as I write.

        Large changes need more time to plan. The delay increases the risk of failure significantly. The system requirements change as you do the analysis and design.

        My personal thought is that if the system takes longer than a few months to design (before starting to code) then it should be broken down into a series of small changes that can be done in one or two month cycles.

        Do Deployment Diagrams equal Implementation Plans

        No. A deployment diagram tells you what hardware and software is going to be used and where the software will run on the hardware. It doesn't tell you where to start.... An implementation plan states when and how you are going to do things.

        For example. The deployment diagram may show the need for a new web server that runs a LAMP stack. The implementation plan will show that you have to buy this first and then install and test the platform. An alternate plan would be to take a desktop machine from a redundant employee, move it to the server room, rip out Windows Vista and install LAMP.... A third plan, you tap a grant making body to finance a blade with an educational discount... and ask for the cost of the Windows installation back.

        The deployment diagram describes the goal and the implementation plan shows the journey to the goal.

        When do you do bottom level testing and when top level testing

        The correct terms are Bottom up testing and Top down Testing. You will find their definitions in the [ glossary.html ] for this course.

        These days every body works bottom up -- unit tests first, integration tests as higher level modules are developed, acceptance tests of the system last. [ c2.html#Testing ]

        However, you can argue that the popular "Test driven Development" is top-down in the sense that you write main programs to unit test modules before you write the modules.

        What is the differences between ERDs and DFDs

        ERDs are used to analyse and design data. They are static and show: entities, relations, and (sometimes) attributes. They show the structure of data. They do not show processes or anything that is not persistent data.

        DFDs are used to analyse and design systems. They show the dynamics: how data flows through the system from external entities, through processes, in and out of data stores, and out to external entities. DFDs do not show the structure of data. They must have a store called "Data Base"!

        The two kinds of diagram are linked in that the data processed and stored in the DFD should be analysed and designed using an ERD.

        You should, in theory, develop DFDs and ERDs in parallel -- but in practice you decide which to work on by what is most needed: clarify the structure of the data or the processing of the data.

        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:

        Three levels of DFD

        (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


          Context

          Level 0 Data Flows


        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 the ERD.

        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 students. Indeed such an 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....


          Bills Context DFD

          Bills level0 DFD

          Bills ERD 1


        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 who must re-input into another process. This wastes user time and introduces a source of error and abuse.

        A classic bad smell in a DFD

        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:

        Ways to Normalize UML ERD

        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
        NamePurposeForm (diagram or text)IncludesExcludes
        scenariolist stepstextsteps, sequence, repetitionchoices, parallelism
        ...
        symbolic logic/mathshow rulestextformulasactions, 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

  1. TBA::="To Be Announced".
  2. TBD::="To Be Done".

    Links

    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/ ]

End