Student Resources > CMPT 275 > deliverable descriptions > Deliverable 4

Software Requirements Specification Document: Release 2

The second release of your Software Requirements Specification Document must contain each of the following sections:

• Cover page
• Revision History
• Table of contents
• Draft Requirements Specification
  • Functional Requirements
  • Non-Functional Requirements
  • Prioritization of Functional Requirements
• Requirements Analysis / System Models
  • Use Cases, and summary Use Cases
  • Use Case diagram
  • First draft class diagram (no methods or attributes in classes)

Some Helpful Instructions for Document Preparation

1) You MUST use the title page provided as the first page of your Software Requirements Specification Document.

2) Your revision history MUST be on the page following your title page. Be sure to update your revision history. Provide information on which sections have been updated and by whom.

3) Your table of contents MUST include all section and subsection titles, as well as the page numbers on which each section or subsection starts.

4) To prepare your requirements specification, consider the draft requirements developed in deliverable 2. Make any updates or additions necessary to incorporate all feedback received on deliverable 2 and during the client requirements review. 5) If necessary also incorporate changes in prioritization of requirements. You MUST submit your requirements specification (functional, non-functional, and prioritization or requirements) even if there are no changes from revision 1 of the document.

Next perform your requirements analysis.
5) Develop a list of use cases to fully describe the system. Provide a list of all the use cases that make up your system. Each of these use cases should be provided in "summary" form. In this context a use case presented in "summary" form includes the following

• A descriptive name
• A list of requirement numbers of the requirements satisfied by the use case
• The actor that initiates the use case
• A BRIEF description (4-6 sentences or 4-8 brief points) summarizing the steps that a user would take to complete the use case

You have probably prepared much of this list already, make sure to make use of the scenarios you developed when you were preparing for the client requirements review meeting and the comments you received when those scenarios were presented in the meeting and when they were graded.

6) Use the formal use case format discussed in class to write the "create programming activity" use case. This is a complicated use case. You should identify portions of the use case that might be factored out into included or extended use cases (for example create rubric or create programming test). By writing these portions of the "create activity" use case as separate sub use cases that are referred to in the main use case you will create a small group of sub use cases and a main use case that refers to those sub use cases. This will create a set of use cases that make your system much easier to understand and use. Remember , as discussed in class, you need to write the formal use case only for programming activities, you should not consider other types of activities. .

7) Develop a use case diagram based on the full set of use cases. Remember to factor out common parts of multiple use cases using <<include>> and to factor out significant portions of the use cases that are completed only under some circumstances using <<extend>>. Also remember to label every relation between use cases with the requirement numbers of the requirements that that relationship satisfies.

8) Build a class diagram describing the entire system. You do not need to include attributes and methods in your classes. You do not need to include helper classes or interface classes. You do need to show all entity classes and all relationships between those entity classes. When appropriate, each relationship should indicate multiplicity, navigability, name, and type of association (aggregation, composition). Also remember to label every relation between two classes with the requirement numbers of the requirements that that relationship satisfies.

9) The electronic copy of your project software requirements specification document (SRS) must be submitted to the COURSESYS as a PDF document. It must also be checked into your team's subversion repository. Each team member should also check in their own contributions to the document (before incorporation into the document) into the teams SVN repository.

Marking Scheme - out of 75

We will be looking at:

• Completeness and correctness of each section of your document
• Completeness and correctness of diagrams and other representations (all functional requirements are represented)
• Correct usage of UML
• Whether or not the document illustrates the WHAT (requirements) as opposed to the HOW (implementation issues). Marks will be deducted if your document discusses internal design of the system and its implementation.
• Spelling and grammar. Read each other's work. Use a spelling checker. Marks will be deducted for spelling and grammar errors, and for lack of clarity due to questionable or overly complex grammatical structures

Specifically:

• 3 marks for Revision History
• 12 marks for revised (if necessary) version of your Functional Requirements (from Deliverable 2)
• 54 marks for Requirements Analysis
  • Use Cases(14)
  • Use Case diagram (15)
  • Class diagram (25)
• 4 marks for checking in each team members contributions to SVN. Each team member should check in their own contributions to the document
• 2 marks for having each release of your document shown in your revision history correspond to a release of you document in SVN
• Up to 7 marks may be deducted for poor spelling and grammar