SE 273 Project Deliverables

A list of deliverables for this course and the expected contents for each. See also the discussion of general requirements for all deliverables.

Problem Description

One to three paragraphs describing the problem to be solved. Include the following: Be careful: the problem needs to be big enough to keep you busy for the semester, but not so big that you can't complete it. Include features that go beyond the very basics, but make sure the basics are covered and you don't have more features than you could reasonably expect to implement. If you're not sure, feel free to label some features as items to add "if there is sufficient time".

Requirements Specification

A list of detailed requirements. Each requirement must be numbered. Use "shall" to indicate what the system may do. Make sure requirements are concise, well-written, and testable. If there is any discussion related to a requirement, such as choices that are yet to be made or justification for choices that have been made, clearly separate this discussion from the requirement itself. Include both functional and non-functional requirements.

Be sure to group your requirements in some reasonable way. For instance, you might have a section of requirements for inputs and outputs, one for game rules, and a third for additional processing requirements. You can label the requirements in each section to simplify maintenance; for example "IOR-1", "IOR-2", etc. for input/output requirements, "GR-1" and so on for game rule requirements, and "REQ-1" and so on for the remaining requirements. Organizing your requirements in this way will simplify discussions.

You should almost always include a definitions section which gives definitions for any term that might be misunderstood or unfamiliar to a stakeholder.

Use-case Model

This includes a use case diagram, a sentence or two describing each use case, and at least 2 significant scenarios for each use case. Treat 2 as the minimum number of scenarios; many will need more. Make sure the primary features of each use case are covered by at least one scenario. Number or name the scenarios and organize them by use case. If there are a lot of use cases, consider combining those which involve the same actors as long as you can still name the use case without using "and". For example, if you have use cases to create, update, and delete items in a list, consider combining these into a larger "maintain list" use case. All actor names must be noun phrases and all use case names must be verb phrases.

When writing use scenarios, it's important to remember that these essentially become system requirements. If a scenario is too vague, it will be impossible to tell if a system which satisfies that scenario actually does what the user wants. For example, "Read account information from the keyboard and generate a report" is not an appropriate scenario because it says nothing about what information is entered or what information will be on the report. Be detailed! On the other hand, don't be too detailed: it's not appropriate to specify menu items and mouse clicks in (most?) scenarios. Use phrases like "the analyst selects the type of report," "the manager starts the add account command," or "the user cancels the operation."

Scenarios are to be written as a list of steps. Be sure to make it clear which scenarios go with which use cases.

A frequent issue with use case diagrams created by Rational Rose is that the default association between an actor and use case is "navigable", that is, includes an arrow at one end. This is not correct. One way to fix this is to edit each line and uncheck the "navigable" item. A simpler way is to

  1. open the model,
  2. right click on the tool bar to the left of the diagram and select Customize...
  3. click on "Creates an association relation" in the left window,
  4. click on the Add-> button, and
  5. close the tool bar customization window.
This gives you an undirected association you can place on your diagram.

Note that working on the use-case model is likely to result in changes to both the vision document and detailed requirements.

Domain-Level Class Diagram

All class diagrams are to be developed using Rational Rose. Working on the class diagrams-especially domain-level diagrams-should result in refining the requirements.

The domain-level class diagram is to include the following:

You can also list (simple) attributes for the classes and operations if you know them. However, these are not required for a domain-level diagram in SE 273.

Detailed Class Diagram

Detailed class diagrams add the following to domain-level class diagrams: Again, these are in addition to the domain-level items such as the domain classes, associations, and multiplicities.

Prototypes

Generally, you will be asked to deliver a user interface prototype. This must include the user-interface portion of the main screen and major sub-screens, with indications of what minor sub-screens (such as login prompts) would do. Fields on forms do not need to do anything useful, but you should fill fields in with sample data that would help illustrate how the user would use the system. Buttons and menu items that result in displaying screens should at least display the screen even though they don't do processing that would be necessary in the final system. Do not worry about any error checking unless that is a key element of your interface.

Test Plan

The test plan documents what will be tested in the system without giving detailed inputs and outputs. Test plans should answer such issues as Developing a test plan early helps ensure the system is designed to be testable.

See here for further details on the format of test plans.

You should specify automated tests where possible. If you rely on a user to hand-execute a test, then it will probably only be run once at the end of the project when it's too late to make significant fixes. Specify tests which can be automated so they can be re-run continually to ensure changes do not break existing code. Tests which involve GUI components should be broken into two parts: an automated part which tests the functionality of the system including border conditions and the like and a manual portion which tests that the GUI components are connected to the appropriate non-GUI components.

Test Procedures

Detailed procedures for testing your system. For each procedure, document Tests can be grouped; for example, you might group a series of procedures with the same setup.

See here for further details on the format of test procedures.

Implementation Plan

You should be able to divide your project into groups of classes that will be implemented either by one person or (if the group chooses) by a pair of people. An implementation plan specifies two things: who will work on which classes, and when those classes (or major functionality in those classes) will be completed. Note if class B depends on functionality in class A, you will probably want to complete A before B. Write a table giving milestone dates and what portion of the project will be done by which student by that date. For example:
StudentImplemented
  Oct. 31Nov. 15Nov. 30Dec. 15
Carol Section, LocationSection.conflicts full Section testsFull Schedule tests
Terry MeetingTime, MeetingPageReader Schedule WeekSchedule form
Anne utilities Main form (all GUI elts) Schedule.display Schedule.print
Note these dates are made up; you'll need different dates for your version. A real implementation plan would probably list far more classes and pieces of classes.

General Requirements