Team 5

Table of Contents Good

Purpose/ Executive Bullet points – should make Amy
Summary it into a brief discursive
paragraph and give an
overview of the document –
can use bullet points for the
sections.
Domain Analysis Very good opening Helen/Chris
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.
Project Purpose Good overview of what you Me
want to achieve and the
calibre of your team. Use
Case diagram – should be
labelled and numbered and
have supporting text to
explain it.
Roles and Deliverables Name the people in the roles. Amy
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.
Project Plan 8 days for peer percentages? Nathan
How long will coding take?
Where is testing? Plan needs
some more thought.
Hardware and Software Good
References Good. Number all references Alex
and then refer to them in the
text by the number.
Definition of Terms Technical terms should be Me
included here too.
Functional Requirements 8.1 Diagram is very poor and Helen/Chris
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
 words. Should state “The
system will…..”
Non-Functional Some good ones – again a Me
Requirements logical numbering scheme
e.g NFR1.
Assumptions Other considerations – most Chris Lianos
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.
Constraints / Dependencies