Assignment 1 Specification
Any changes to due dates or other information relating to the project (or tutorial) will be advised via the topic FLO.
I acknowledge the contribution of all previous lecturers in this topic to the project structure.
Project Overview
During the course of the semester, each project group (even if that’s an project group of one) will develop a Software Requirement Specification for the requested system. The initial input to the requirements for that system will be provided in a Project Broad Statement of Needs. Your group needs to convert such a broad statement into more structured requirements for the system and describe them in written and graphical formats following the IEEE standard (tailored). This will inevitably involve dealing with challenges in documenting requirements for effective communication among stakeholders. Several elicitation techniques will be employed to confirm and/or discover the user requirements for the system. Where advice is needed on how to proceed, you should consult your tutor and lecturer who constitute the customers.
The project is divided into two phases:
- Phase 1 : SRS with high-level use cases (refer to SRS_ template.doc) and analysis models
- Phase 2 : Expanded use case, and level 2 DFD for selected use cases
Details of the document required are included in the phase specifications. These are based on the IEEE guidelines that provide an example structure for such documents. But, as it notes, this example structure is for information purposes only and is not part of the standard. This commonly occurs with standards, as it allows the standard to be tailored to different kinds of projects. The particular structure to be used in this project will be detailed in phase deliverables.
A note about the system
This is a real case of an unfunded project submitted for consideration to the University. I have crossed out those parts of the project which are beyond the scope of the assignment but everything else I have left in for interest or background. In the end, other more pressing projects were funded but it represents a real document. A blog will be set up on FLO to expand on this.
Submission
The completed documents are to be submitted online by the stated deadlines.
Declaration
Each student is to complete an individual contribution declaration and submit it to the individual declaration box online by the relevant phase deadline. Contribution covers both contribution to the content quality of the deliverable and also contribution to the group process that produced that deliverable.
An unsatisfactory, unreadable, incomplete, or frivolous contribution declaration will be taken to indicate an insignificant contribution to group submission and group operation and result in minimal marks being awarded. Each student must be prepared to show evidence to substantiate their claims. Each student will be given credit for the part of the project work, which they carried out, and for their contribution to the operation of the group (as judged by their fellow group members and the tutor).
Phase 1 Specification:
This document details the format and guidelines for phase 1, also known as Assignment 1, of the project.
Phase 1 has the following aims:
- To provide a forum for your group to practise its communication skills in promoting and sharing of ideas, formulating a group response, and submitting a completed group document;
- To enable thinking about what constitutes a software system and how to describe system requirements both as a user and as a developer;
- To investigate the use of several elicitation techniques to confirm and/or discover the user requirements for the system;
- To convert a broad statement of needs into a more structured requirements for the system;
- To document the formulated requirements in a structured format;
- To show main product features with a system context diagram (use case diagram and level 1 data flow diagram);
- To identify user classes (actors), and associated high level use cases;
- To appreciate the challenges in documenting requirements so that they can be effectively communicated to others.
Group Work
Each group will produce one document as the result of this phase. With reference to the Project Broad Statement of Needs, each group will produce a Software Requirements Specification document for the proposed system.
- For groups greater that one person – Every student is expected to participate in the group’s discussions and idea generation on every part (or section) of the document. It is likely that some of the group members’ ideas may be conflicting; the group will therefore need to decide on how best to resolve such matters.
- For groups of one person – you will be required to maintain a reflective log outlining the issues and problems you encountered and how you dealt with them.
Tasks
To produce the required document, the group must initially agree on what will be the standard document format, file naming conventions etc. Much of this should be resolved in the first group meeting.
Each member of the group is expected to take multiple of the following roles during this phase of the project work:
- collator – to put the various parts of the document together, including revised versions of parts. The document should be uniform in its presentation e.g. font and page layout.
- publisher – to put the final document together, to check the overall look and finish of the document.
- drafter – to draft the initial version of each part, to make any necessary modifications to it, and to do the initial proof reading (Reading out loud is always a good check.)
- proof reader – to check the syntax and content of parts, to provide editorial comments. All group members could make comments but this role involves a commitment to make comments and/or corrections.
Note that:
- Simple short sentences tend to make for the most understandable English.
- Fancy formats, colour printing etc do NOT make up for lack of quality in content.
- Any material, directly quoted or paraphrased (restated), from the work of others must have the source acknowledged.
- No part of the document will be very large but parts may vary in size.
- Each member of a team must cooperate to get the team’s report in before the deadline.
- The group should determine a timetable for completing the necessary tasks and review it regularly.
- Should any student for medical or compassionate reasons find that they are unable to make the necessary contribution to the group work, they should immediately
- let the group know, and,
- let the topic coordinator know, in writing via email. Please include group identification. Supporting documentation may be required.
If a group’s document is incomplete at the deadline, it should still be submitted and group members should make clear on their contribution declarations reasons for the lack of completeness. Group members are not expected to do extra work to make up for the failure of a member to deliver, but each group is expected to monitor its own progress and manage issues that arise, and may be asked to provide evidence of such monitoring/management (e.g. entries in the group discussion forum).
Detailed description of the required deliverables
Document Structure: Each group will need to obtain a copy of the Software Requirements Specification Template for this project (SRS_template.doc available on FLO), and use this template to complete their submission. The document should be single-spaced and size 11 fonts.
The document template is moderately self-explanatory. Each section should be completed appropriately within the guidelines and bounds stated above.
- Sections 1 and 2 provide a description of the document and an overview of the system.
- Section 3 is the section for specific functional requirements. Only high-level use cases are required for Phase 1 submission.
- Section 4 – 6 are for external interface, non-functional, and other requirements.
- The Appendix sections are the supporting and reference materials for the document/submission.
- Appendix A: Glossary that define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations
- Appendix B: Use case diagrams (there should be a use-case diagram for each user class defined) and Level 1 data flow diagrams.
- Appendix C: List of the open requirements issues that remain to be resolved, including TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.
- Appendix D: Requirement elicitation report.
- Appendix E: Group weekly project meeting minutes. [If you do this as a group of one person, this is replaced by the reflective log of the issues and problems you encountered.]
Assessment
Phase 1 submission will be marked for each group submission. Each submission will receive a grade, not a mark, for this submission.
An individual student will receive a grade that could be the same as, higher or lower than, the group grade depending on his/her contribution to the group work.
The weighting distribution across the sections of a submitted SRS is outlined as follows:
- Section 1. Introduction [NGP]
- Section 2. Overall Description [NGP]
- Section 3. Specific System Requirements [30%]
- Section 4. External Interface Requirements [20%]
- Section 5. Other Non-functional Requirements [20%]
- Section 6. Other Requirements [NGP]
- Section 7. Reflection [NGP]
- Appendix A: Glossary [NGP]
- Appendix B: Analysis Models [20%]
- Appendix C: Issue list [NGP]
- Appendix D: Elicitation Report [NGP]
- Appendix D Team Meeting Minutes (NGP)
- Presentation and Consistency: [10%]
NGP indicates that the section needs to exist in a proper form but does not contribute towards the marks.
Professor John F. Roddick
March 19, 2020
The post Assignment 1 Specification appeared first on My Assignment Online.