Student Resources > CMPT 275 > assignment schedule > Deliverable 2

Software Requirements Specification Document: Release 1

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

• Cover page .doc .pdf html
• Revision History
• Table of contents
• Draft Requirements Specification
  • Functional Requirements
  • Non-Functional Requirements
  • Prioritization of Functional Requirements
• Requirements Analysis / System Models
• Appendix 1
  • Agenda and Minutes

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.

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 draft requirements specification consider the functional requirements and the nonfunctional requirements of your system, then prioritize the resulting requirements.

• First list the functional requirements. The functional requirements specify what the system needs to do. You MUST number each functional requirement as discussed in class.
• Next consider the non-functional requirements. Non-functional requirements specify quality requirements (Usability, Reliability, Performance, Supportability) and constraints on the system in areas such as Interface definition, Legal, and Implementation (languages, tools, platforms ...). You MUST number the requirements in the non-functional requirements section using the same scheme as you used for the functional requirements
• Next, prioritization all of your functional requirements. Eventually you will make 4 lists.
  • List 1 will contain the requirements you believe the client feels are the core or critical features of the system (necessary for the system to perform its most critical functions),
  • List 2 will contain the requirements you believe the client feels are the most important of the remaining features of the system (necessary for the system to perform all functions important to the user efficiently)
  • List 3 will contain the remaining requirements you believe the client feels are the needed but less important to the functioning of core features of the system (necessary for the system to perform all functions important to the user efficiently)
  • List 4 will contain the requirements you believe the client feels are the desired features of the system (not necessary to the successful and efficient operation of the core system).
• For deliverable 2 your group will consider only List 3 and List 4. Your group will make lists of requirements it believes belongs on list 3 and on list 4. Each list will be used as a basis for beginning discussions of scope with the client in the requirements review meeting. This list should use the same numbers (for the same requirements) as used in the original list of requirements.

5) For release 1 the Requirements Analysis section will be an empty section. When you prepare release 2 of this document for Deliverable 4 you will add content to this section

6) At least once every two weeks your team should have a formal meeting, your team will also have will have discussion sessions or informal work sessions. For each formal meeting your team holds, your team should prepare an agenda and record minutes. Agendas and minutes of all formal meetings should be archived in your SVN repository. The agenda and minutes section of deliverable 2 should contain the agenda and minutes for your most recent formal team meeting, The most recent formal team meeting is the last formal meeting your team held before the due date of deliverable 2.
7) The electronic copy of your project planning document ( PDF) must be submitted to the submission server. It must also be checked into your subversion repository. Each team member should also check in their own contributions to the document (before incorporation into the document and any necessary edits made during incorporation) to the team's SVN repository.

Marking Scheme - out of 60

We will be looking at:

• Completeness of each section of your document
• Completeness of the lists of requirements
• Does the prioritization make sense. Marks will be deducted if your group has placed requirements in List 3 that are dependent on requirements in list 4 being implemented (or in list 3 and 4 that depend on remaining requirements being implemented)? Marks will also be deducted if you placed requirements in lists 3 or 4 that are obviously central to the operation of the application
• Is the document understandable by and aimed at the correct audience? Do not use technical jargon unfamiliar to the client.
• The document should illustrate WHAT the requirements are as opposed to the HOW those requirements will be implemented. 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 cover page and table of Contents
• 4 marks for revision history
• 36 marks for requirements specification
  • Functional Requirements (26)
  • Non-Functional Requirements (5)
  • Prioritization of Functional Requirements (5)
• agenda of your last formal meeting (5)
• minutes of your last formal meeting (8)
• checking in each team members contributions to the document to the team's subversion repository. Each team member should check in their own contributions to the document (including any revisions to their own or other team members work) to the teams SVN repository (4)
• Up to 5 marks may be deducted for poor spelling and grammar
• Be sure your requirements document (version 1) has been checked in (committed) to your SVN repository before you begin making changes and additions for version 2 (Deliverable 4)