CSC 480
Homework 3: Implementation design

Due Feb. 28

For this assignment, you'll convert your requirements document into an implementation design, or software blueprint. Now you're thinking about how to achieve the various requirements identified in the previous step. This may include code for parts of the system, but must include at least the following:

• Any changes to, or more-detailed versions of, the requirements, that you've developed in the intervening two weeks

• Data dictionary: for each important piece of information in the program,

  • its name
  • its data type (which may be built-in types in the implementation language, or abstract data types you're going to define)
  • any legality constraints (e.g. "can be no larger than 99") or default values
  • where it "lives" (in a particular table of a database, as a (static) class field, as a (non-static) object field, local to some function, ...)
  • if it's being imported from an existing legacy system,
    • where it comes from
    • conversion rules if any
  I'm not asking you to document every single variable in the program before you've written any code to speak of, but at this point you should be able to identify a number of pieces of information that will definitely be needed.

• Modular structure: for each major module of the project (which may be a class, or a collection of closely-related classes, or a Web page, or something else appropriate to the language(s) you're working in),

  • a one-sentence "vision statement" saying what this module is for
  • what pieces of information from the Data Dictionary this module depends on or modifies
  • what other modules this module depends on
  • for each important operation or service this module provides,
    • name of operation
    • is it triggered directly by a user action, or by another module, or both?
    • any non-functional constraints on the operation (e.g. particular kinds of users who shouldn't be allowed to invoke it, or response-time requirements)
    • pseudocode if appropriate (typically for complex decision structures)

• Database schema, if you're using a database

• Proposed sequence of versions, with what requirements you plan to implement in what order. This should be more-or-less consistent with the priorities, while recognizing that sometimes a high-priority feature depends on what you originally thought was a low-priority feature so the latter should probably be implemented and tested first.

(Much of this came from the book Planning Smarter, by Tyson Gill, Prentice Hall 2002, ISBN 0-13-065414-0. There are as many other approaches as software architects, I'm not picky about exactly how this is organized, and you may find some parts of this inapplicable to your project. When in doubt, ask me.)