Team5interreqfb (1)

  • Uploaded by: Jeffrey Greene
  • 0
  • 0
  • July 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Team5interreqfb (1) as PDF for free.

More details

  • Words: 347
  • Pages: 2
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

Related Documents


More Documents from ""