Systems Home | Introduction | Needs Assessment | Requirements Specification | Requirements Analysis | Preliminary Design | Detailed Design | Implementation | Testing

Systems Development: Requirements, Design, Implementation, Testing

Preliminary Design

What is Design? Good Design? Bad Design

We have finally completed our requirements phase and are starting the design phase. Note we split this phase into two sub-phases: preliminary and detailed design.

Design answers the "how" question, namely "How will the system meet its specified requirements?" We know (or should know) what the system must do. Now we worry about how to do it.

Even small projects typically separate the upper and lower level design into different phases. The first phase, preliminary design, is concerned with the overall system architecture. Software subsystems tend to use object oriented principles. Thus we need to determine:

• What objects compose each subsystem.
• How objects interact with each other to carry out transactions.

Thus we concentrate on class and sequence diagrams during preliminary design.

This is our opportunity to set the whole tone of the system, too. In the preliminary sub-phase, we have the opportunity to re-arrange objects and associated responsibilities to impact how easy (or difficult) it will be to add new functions, repair defective functions, or remove unwanted functions from the system over time. So it's not enough to have a design: we need a good design to help us evolve the system over time.

And remember: the better our design, the more people want to use the system. The more people use the system, the more they want to change it. And the more they change it, the more successful the system is!

Process Activities

In our requirements analysis sub-phase, we resolved conflicts among the requirements themselves. We decomposed the system into subsystems, determined data flows among subsystems, and generated use cases (or transaction scenarios). After establishing the top-level interfaces and responsbilities, we can assign functions to objects and analyze transactions:

• Develop Class Diagrams: In an object oriented design, attributes (or data) and methods (or functions) are assigned to classes which become objects. We need to diagram the relation of classes to each other and identify their roles and responsibilities.

• Draw Sequence Diagrams: Use case transactions are at the system level, perhaps among subsystems. But we implement transactions by calling object methods and passing parameter data. We use sequence diagrams to evaluate the dependencies, events, and interfaces of our system's transactions.

• Build Project Trace Matrix: Since requirements answer the "what" question and design answers the "how" question, we need to document which design elements correspond to which transactions. For each design element, we need to document its associated requirement identifier.

Exercise

We mentioned earlier incorrect or missing requirements cause 50% of all system errors. We will start to see ripple effects of these latent (unseen) errors as we engage in design. Pay particular attention to the assignment tasks. Do the work requested well, but do not perform extra, needless work.

• Armenian
• English

For demonstration purposes, here is sample design document. Some, but not all, parts are examples of preliminary design activities:

• English

Study Guides

Use the following study guides to focus concepts from the readings:

• Armenian
• English

Lecture Slides

Here are copies of the lecture slides presented during class:

• Armenian
• English

Readings

As before, each of the listed links will open in a new browser window:

Systems Home | Introduction | Needs Assessment | Requirements Specification | Requirements Analysis | Preliminary Design | Detailed Design | Implementation | Testing