UC IRVINE - ICS 125 PROJECT IN SYSTEM DESIGN
Assignment 4: Design
Due in Class on November 19 with Presentations November 19 and 21
This assignment consists of two parts: 1) an update and modification
to the requirements document (see below) and 2) an in-class
presentation limited to 15 minutes and focused on you software
architecture and related design diagrams and descriptions.
Purpose and Content
The Requirements Document focused on what your system will do.
The design document describes how it will be done, giving the overall
picture of how your system is organized.
The design document should also be an evolving document, or a living
document. You should begin by documenting the conceptual model of
your system. As you continue working, this model will be refined
to include more detail, and some things will change. By the time
you turn in your design document, it should contain a reasonably accurate
description of your final system. You will also be asked to turn
in a final version of the document at the end of the quarter that will
include changes made to the requirements and design during the later stages
The design document will consist of the following sections. Sections
1-4 and 8-13 are updates of what you turned in for the Requirements Document.
The remaining sections, 5-7 and 14, are new to the Design Document.
Use Cases, Scenarios, Mock-up's
(whichever you focused on in Assignment 2)
What style of architecture did you adopt? Provide a reference to a
Shaw and Garlan (in Software architecture: perspectives on an
emerging discipline) have identified the following list of
1.Data Flow Style
Pipes and Filters
2.Call and Return Style
Main Program and Subroutines
Transactional Database Systems
System Architecture Overview
Others find that UML provides a sufficient architecture
specification, but requires more than class diagrams.
This is the place for your "one great diagram" that shows how your
system is built. You might want to use more than one diagram, to show,
e.g., some different abstractions of the design (such as a data flow view,
a layers of abstraction view, an object view, or an OS process view)
What each subsystem means
Major limitations on the current design
Team Specific diagrams
List of Modules within your system
For each module, provide a Module Specification
Definition/Purpose - what it is/does
Narrative/Comment - how it works
What are the interfaces or APIs? E.g., using Java terminology
Data - What state does it keep, what variables?
Access - Who has access to the module/object/data?
How does it fit into the inheritance/with/uses heirarchy?
Constraints - what constraints are there for this object/module?
Cardinality - How many will there be?
See your TA but likely notations include Entity-Relationship (ER)
Diagrams for database projects, UML Sequence Diagrams for
client-server applications, ontologies for knowledge-based projects,
Terms and Authorization
Milestones and Effort
Acceptance Test Plan
To be more specific in the update of your Acceptance Test Plan, create
a script (2-4 pages) of your intended final presentation. The script may
be in the form of an outline or bulleted list. In some cases, it will be
close to your prototype demonstration. It should tell a choherent and convincing
story that will make your client enthusiastic about signing off on your
You may refer to figures in other parts of your document such as use
cases and / or mock-up's.
Unit and Integration Test Plans
Enumerate several key tests for evaluating individual modules and combinations
of modules in your system.
For each test
Purpose of Test
Item(s) being tested
Input specification or specific data being tested
Expected Results or Test Oracle Mechanism
Test environmental needs or special test procedures
David F. Redmiles Home Page
Department of Information and Computer
University of California, Irvine CA 92697-3425