Contents


    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 use cases for any interesting use cases.

        You should include at least one fully-dressed uses cases for really critical use cases (one that needs to be done first to mitigate risks, for example). This should follow the fully dressed template [ r2.html#Fully Dressed format ]

        Rules

        Define all special "Business" Rules that apply. Omit if none.

        Quality 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>>

    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 [ project0.html ] [ project1.html ] [ project2.html ] [ project3.html ] [ project4.html ] [ project5.html ] [ projects.html ]

    Field Trips [ F1.html ] [ F2.html ] [ F3.html ]

    Metadata [ about.html ] [ index.html ] [ schedule.html ] [ syllabus.html ] [ readings.html ] [ review.html ] [ glossary.html ] [ contact.html ] [ grading/ ]

End