Team 5 Table of Contents Purpose/ Executive Summary
Domain Analysis
Project Purpose
Roles and Deliverables
Project Plan
Hardware and Software References Definition of Terms Functional Requirements
Good Bullet points – should make it into a brief discursive paragraph and give an overview of the document – can use bullet points for the sections. Very good opening paragraph, Excellent table that compares good and bad features. Should do same table for the rest of the systems. Some good research work here, be consistent in the way it is presented. Good overview of what you want to achieve and the calibre of your team. Use Case diagram – should be labelled and numbered and have supporting text to explain it. Name the people in the roles. Deliverables – team structure, contract and peer percentages are all internal processes of your team – not what the customer needs to know or ever gets to see. Team website is not a deliverable for the project – it is your marketing – so for other customers. 8 days for peer percentages? How long will coding take? Where is testing? Plan needs some more thought. Good Good. Number all references and then refer to them in the text by the number. Technical terms should be included here too. 8.1 Diagram is very poor and is not using standard notation, not labelled, numbered or explained. Requirements should have some detail – put in a table, number each one e.g. FR1, because it will need to be referred to in the design document. Explain each requirement not just a few
Amy
Helen/Chris
Me
Amy
Nathan
Alex Me Helen/Chris
Non-Functional Requirements Assumptions
Constraints / Dependencies
words. Should state “The system will…..” Some good ones – again a logical numbering scheme e.g NFR1. Other considerations – most risks are internal to the project and are actually the concern of the project team. Should state risks to schedule, delivery etc. in terms of “We guarantee, we cannot guarantee, we will aim to deliver on time, we have a policy to avoid loss of data…. Etc.
Me Chris Lianos