Project 3: Design

The second step of the project is to produce a software design (solution) to the problem that was documented in your SRS. Now your perspective shifts from the problem domain (aka application domain) to system-oriented concepts. At the end of this process, you will have defined the overall software architecture of your system (i.e. the major components and their interconnections), identified the major scenarios that your system must handle, and have a good idea of the components you will need to handle each scenario.


Your design document should consist of the following sections:

  • An introduction that describes your overall approach to solving the problem described in your SRS document.
  • A “boxes and arrows” diagram showing the software architecture of your system. What are the major components of your system, how are they connected. What are the major inputs to your system? What are the major outputs?
  • A list of scenarios that your system must handle to cover all of the functionality identified in the SRS. These scenarios should be documented in the form of use cases and you should try to identify both the “success path” and potential “error paths” through each scenario. For the error paths, try to indicate what the system will do in response. Doing this allows you to address fault correction/tolerance issues in your design.
  • A set of activity diagrams and sequence diagrams related to the scenarios that show what objects collaborate to achieve the goals of each scenario. Any objects that appear in these diagrams need to also appear in your class diagram. You do not have to create activity diagrams and sequence diagrams for ALL of your scenarios. Instead choose at least two use cases to document with an activity diagram and then choose interesting activities from those diagrams to document with sequence diagrams.
  • A class diagram that elaborates the concept-based class diagram from your SRS with system-based classes that are required to implement the scenarios specified in your use cases.
  • State diagrams for any classes that have an interesting set of states that govern their behavior. You do NOT need a state diagram for every class in your class diagram. Document only those classes that have interesting (from a design sense) states.
  • Updated FSP specs/ structure diagrams that reflect the new information introduced by the system concepts added during design. Previously, your FSP specs were modeling concurrent behaviors that occurred in the application domain. Now, you may want to augment these specifications with ones that deal with concurrent behaviors that are related to your design.
  • a list of any non-functional concerns you intend to address while implementing the design of your system.

A team is free to use any of the notations / specification techniques covered in class, if needed, in addition to the ones specifically requested above.

Individual Participation

25 points of this assignment is based on an evaluation of your work and participation by your other team members. Once the design has been submitted, each team member should mail Professor Anderson an evaluation of the participation and work performed by the other team members. If all of your team members give you a “thumbs up,” you will receive all 25 points for this portion of the assignment. Otherwise, you will receive a percentage of the 25 points based on the positive/negative reviews that you received.

Note: If team members indicate that a student did nothing for this portion of the project, that student is in danger of losing more than just the 25 points allocated to individual participation.

Points and Due Dates

This assignment is worth up to 150 points, depending on the score you receive for individual participation.

Please submit your design document as a PDF document to the moodle by 11:55 PM on Tuesday, April 15th. (Note: Since some CAETE students are working with in-class students on this project, I am not intending on having a separate due date for CAETE students on this assignment. CAETE students working on their own, please contact me if you'd like to have your due date extended by one week as usual.)

You may also create your design document as a set of HTML pages. If so, you should submit a small text file to the moodle that contains the URL of the "home page" of your design document.

Contact Professor Anderson if you have any questions or concerns about this assignment.

Kenneth M. Anderson, 2008.