TDDC32 Design and implementation of a software module in Java

Analysis and Design Document

What should the analysis and design document contain?

For smaller projects, like the one in this course one document is OK. Next come suggestions on what your analysis and design document should contain.

• On the first side you should have the project name as the main headline. Then you should have a heading that identifies the document as an "Analysis and Design Document" and further the version number of the document, the names and emails of the project members, date of the last modification. First page ends here.

• A summary that presents the purpose of the document, the context of the project, and the main parts of the document. Should be around 2 paragraphs in length.

• Table of contents.

• Document conventions. What the different symbols, text formats, or reserved words in your document mean.

• Class diagrams

  One or several class diagrams that give an overview of the classes composing the system, and the relationships among them. (See lab 3 for suggestions on UML tools.)

• Class descriptions

  Give a short description for each class. A CRC-type information together with a small description of the purpose of the class should be enough.

• Use case diagrams

  Provide a more detailed use case description of your system as it resulted from the design work. Describe step by step how the different functions offered by the system are realised by your classes. Start from the use cases that you delivered with the requirements specification.

• Interaction diagrams

  Provide interaction diagrams for non-trivial use cases. For a particular use case, you may choose to represent it with either a sequence diagram or a collaboration/communication diagram. Motivate your choice in one sentence.

• State and activity diagrams

  Interaction diagrams do not give an in-depth representation of the behaviour. Thus you should use state and activity diagrams to model more complicated behaviour. Use state diagrams when the state of some objects are important. Use activity diagrams if a certain work flow is more important (e.g. synchronisation). You should have at least one state diagram and one activity diagram in your documentation.

• Test planning

  Plan how you can test the requirements in your requirements specification. Tests can be of two types, unit tests, referring to tests of objects or small units, and integration tests where the system is put together and tested. Think also about how to test the modules you have to implement individually. What do you have to test manually? Give a short description of how you can test every requirement in your requirements specification.

Page responsible: Tommy Färnqvist
Last updated: 2013-01-30