CM0656 Case Project

Module Title:	Case Project
Module Number:	CM0656
Coursework Title:	Formative Assessment
Semester 1
NORTHUMBRIA UNIVERSITY Faculty of Engineering & Environment

ToR, Requirements Specification & Design Documents

FORMATIVE ASSESSMENT

Each group must provide the assessors with ONE document, plus appendices, containing the documentation indicated below for the entire group. This should comprise of the documentation for the group element with separate, attached, appendices containing documents for each of the individual elements. Please ensure the appropriate names are on all pages of submitted work.

The group should first draw up a code of conduct which states the agreed responsibilities and commitment expected from all group members. This is to provide a foundation for the management of the project and should be considered an important part of the documentation. You are expected to discuss and agree your code of conduct with your supervisor in the second week of teaching. The group should then go on to produce the terms of reference and design documentation for all required areas of the system, including interface design templates and navigation structures etc. as further detailed below. The documentation should show consistent standards between individual group members to demonstrate that the group have communicated about quality assurance and adherence to documentation standards. Each group member should produce the specification and design for their area of responsibility.

This exercise must be completed to enable you to complete Assignments 1 and 2. If you do not complete this exercise you will not know what you are planning to build or how you are planning to build it – and more importantly you cannot demonstrate to the tutors that you can accomplish the task agreed, in the manner agreed within the time constraints. Feedback will be provided on a weekly basis on any completed work in supervision sessions. Additionally, written feedback will be provided upon the documents you hand in. No marks will be awarded for Terms of Reference/requirements/design but an indication of success achieved will be given on the feedback sheet. Failure to submit this documentation will mean the maximum mark achievable for this module is 40%

The group’s second task is to choose what system they wish to build. Groups have a choice of the following:

  1. To build a system for the scenario supplied in the following brief. This is the default route and the route you must follow unless an alternative is agreed with your supervisor during or before the second week of teaching (week commencing 29th September).
  2. To build a system for the general requirements given below but for a case study of the group’s choice.

In this case the group must supply a one page outline of the proposed scenario to their project supervisor in the scheduled group meeting of week 2 (week commencing 30th September). In this case your supervisor will then determine if the case study you are proposing is acceptable, we reserve the right to direct you to complete the scenario indicated in the brief or to provide us with further information. In this case you must include indication of sign off from your supervisor in your terms of reference.

  1. To build a system of the group’s choice. In this case the group must identify the case study in approximately one side of A4 together with a second side of A4 which clearly indicates the group and individual functional areas. For each area prioritised high level requirements must be identified. Each individual area should be primarily independent to prevent undue dependencies between functional areas. The system produced must be demonstrable using university hardware. Note: each individual area must have three “MUST DO” requirements, one “SHOULD” requirement and one low priority “COULD” requirement. The intention is the ‘could’ requirement is more technically challenging. The group must supply a two page outline of the proposed case study and project to their supervisor in the scheduled group meeting during week 2 (week commencing 30th September). In this case your supervisor will then determine if the proposal, case study and system you are proposing is acceptable, we reserve the right to direct you to complete the scenario indicated in the brief or to provide us with further information. The system proposed and the elements within it should be of similar complexity to those provided below. So we may, for example, insist the complexity of your proposal is increased or decreased to ensure parity of challenge. In this case you must include indication of sign off from your supervisor in your terms of reference.

SCENARIO

The application to be developed has both group and individual parts as follows:

Ima Megastar has just become very famous having won the ‘X Voice Factor’ TV talent show. Having become so famous so quickly the fans are very keen to have a web application to express their feelings and share their thoughts and experiences with like-minded people.

Ima is also very keen to do some good for the community and regularly auctions items used in the stage show so fans can own something important to them while the money raised goes to charities around the world. Competitions are also run so those who have less ability to bid for items can win something – therefore keeping fans very happy.

You have been asked to create this application, in a style suitable for a megastar whose fans range from 10 years old to 95 and ensure it is easy to maintain and considers accessibility and security appropriately.

Group element:

  • Log in/out users, security considerations and accessibility

Individual elements:

  1. Administration:

An interactive application which:

  1. Must allow the registration of junior and adult members (it is anticipated there will be junior and senior members plus administrators)
  2. Must enable membership to be confirmed to applicants,
  3. Must allow the ability to add/delete/amend members’ details
  4. Should allow user management activities (e.g. banning users/password management etc)
  5. Could allow a variety of users/usage statistical reports (possibly in graphical presentation) to be displayed.
  6. Auction

Ima wants to raise funds by running auctions online so every senior member has a chance to bid

The auction:

  1. Must enable only administration to upload articles for auction and only senior members to bid.
  2. Must notify members of their bid and also when another member has outbid them
  3. Must be time limited i.e. an ending date/time to the auction can be set.
  4. Should have a buy it now functionality which, when used, ends the auction.
  5. Could enable bids to be withdrawn (with all appropriate notifications to members and calculations).
  6. Gallery

The fans often take photographs at ‘meet Ima events’ which are very popular and at which many photographs are taken. So these photographs can be shared a gallery is desired - this should be an application which:

  1. Must allow members to upload pictures from an event.
  2. Must enable only registered users to view uploaded pictures
  3. Must enable separate galleries for different events
  4. Should enable a search function by event title or date of function.
  5. Could include a comment/discussion facility and necessary image and content moderation (reporting abuse, preventing inappropriate language etc.)
  1. Discussion board

Ima is keen to obtain feedback from the fans and to get their opinions and to allow them to discuss their thoughts. For this a discussion board is required.

An interactive application which:

  1. Must allow only members to post messages.
  2. Must allow admin to create threads (topics) for discussion.
  3. Must allow responses by members (giving username and date of post).
  4. Should allow reporting of inappropriate messages to admin.
  5. Could ensure that inappropriate language is subject to automatic moderation.
  6. Competitions

Ima is very keen to let her younger fans have a chance to win items so a competition will be run regularly to ensure younger fans get a chance to win without having to spend money. This means a system which allows the management of competition entries is required (winners are drawn at random and notified separately)

This is an interactive application which:

  1. Must allow only junior members to enter,
  2. Must be able to modify questions to be answered for different competitions
  3. Must provide confirmation of entry with date and time of when winners will be notified, the competition must close to entries two days before this.
  4. Should allow the member who entered to cancel their entry and re-enter up to the close of the competition.
  5. Could restrict competition entry to age ranges: 10 – 13, 13 – 16. 16 – 18 depending on difficulty of questions

Ima’s Sample Competition questions

  1. What is her biggest hit single to date ____________
  2. What was Ima’s hair colour on her Rainbow video (drop down list with options provided)
  3. Should Ima sing a duet with Michael George on Strictly Come Singing?

Definitely agree

Agree

Neither agree nor disagree

Disagree

Strongly disagree

DELIVERABLES

Documentation to be submitted must include:

GROUP CODE OF CONDUCT

This should state the agreed responsibilities and commitment expected from all group members and should be considered as a binding agreement on each individual member. This is intended to focus on the professionalism required to complete such a project in order to maximise the likelihood of a successful outcome.

CASE STUDY AND HIGH LEVEL REQUIREMENTS

If your group is opting to use their own case study or case study plus requirements then the following documentation MUST be provided (failure to do so will result in a maximum module mark of 40%)

  1. A side of A4 indicating the scenario
  2. A side of A4 indicating the required functionality (if required)
  3. Indication that your supervisor has approved the choice of case study/requirements.

ALL GROUPS MUST PROVIDE THE FOLLOWING DOCUMENTATION.

GROUP DOCUMENTATION

  1. Terms of Reference which sets out the group’s specific intention, the aims, scope and general treatment of the project, the key skills and allocation of tasks and roles within the team and a plan of activities and their deadlines. This document should be the result of collaboration with all group members.

The Terms of Reference should contain the following information:

- Project Objectives – objectives which specifically address how the project will be completed.

  • Roles, allocation of tasks and mapping of skills – identify skills needed and how they will be mapped to individuals/roles and consider skills gap analysis to show where skills may need to be developed. Also show how main tasks will be allocated.

- Agreed deliverables – describe the deliverables which will be produced at each stage of the project.

- Resources list – detail the hardware, software, languages used, including versions if applicable, plus any associated standards.

  • Testing procedures/strategy – explain what you intend to do to ensure that the project is managed professionally and that the final product is of good quality.
  • Risk analysis - determining the probability and impact of a risk to the completion of the case project.
  • Project plan – The group should produce a Gantt chart to show how each project task has been scheduled. The chart should include milestones and task dependencies

(you might wish to consider here the time needed to integrate the individual elements into one cohesive system)

  • Professionalism – ground rules/group code of conduct (how you will agree to work as a group, what expectations you may have of fellow group members etc)
  • Ethical consideration, legal aspects, social impact – The group should consider how their system may impact on others (individuals or groups within society for example), whether there are, or may be, ethical concerns with the system you intend to build, and any potential legal problems (or what you might consider SHOULD be legal problems) as a result of the application you are designing.
  1. Group design documentation

This section should consist of any design documentation for shared areas of the system including the interface design templates.

Some examples of design documentation for shared areas are:

  • high and low fidelity prototypes
  • storyboards
  • system navigation maps
  • shared database design
  • shared architecture/high level design
  • test plan for group elements
  • any background research

The group may not need to produce all of the documents in the list above if it is felt they wouldn’t help in specifying the system, and may include any other information diagrams they would like to use.

All members of the group will receive the same feedback based on both the quality of the design of shared areas AND the degree of cohesion the group demonstrates, in terms of the consistency and standardisation between each individual’s design and requirements documents. Credit will be given for demonstrating that group members have agreed standards for their requirements and design documents as a group have followed these standards and demonstrate an understanding of how each person’s area of responsibility links to the others.

As part of this design the group is expected to consider how the system will be made secure. This will clearly require the identification of any security requirements.

INDIVIDUAL DESIGN DOCUMENTATION

  1. Market Research, Requirements Specification and Test Plan

Each group member should produce a requirements specification for their area of responsibility. The individual specifications should be submitted as individual appendices to the TOR ensuring each student’s name is on each page.

  1. Market research findings related to the target users and the context of use – with reference to research findings, explain who you think the target users are, how they will use the system, what functionality the system will provide and your rationale for these decisions. Note: this section should contain references to statistical sources or websites viewed. It should be no more than 3 pages long; this page limit is for text only and does not include graphs, screenshots or diagrams. If graphs, screenshots or diagrams are included, more than 3 pages are permitted. You should also research the social issues which may result from your intended part of the system, for example the potential for abuse/misuse etc could be considered. In this element research should be carried out regarding any social issues which may occur as a result of your part of the application.
  2. Requirements specification should list the precise prioritised functions of the application including scenarios to illustrate and justify each if necessary. An indication of the relative importance of each requirement must be displayed, e.g. requirements numbered in order of importance and labelled as ‘essential’, ‘desirable’, ‘cosmetic’ etc.

The requirements specification should not contain reference to interface elements such as menus, buttons and textboxes. Each requirement should be a concise unambiguous description of an area of functionality, including as much detail as is needed for the requirements specification to be understood if passed on to another developer for implementation.

  1. Test plan. Each group member should produce a test plan for their area of responsibility. This should include what, how and when you are planning to test.
  1. Individual design documentation

This section should consist of any design documentation for each person’s area of responsibility.

The group will be expected to agree the techniques and methodology between themselves, but each group member should then be responsible for producing the design documentation for their area of responsibility.

Some examples of design documentation for individual sections are:

  • diagrams (for UML)
  • high and low fidelity prototypes
  • storyboards
  • system navigation maps
  • entity relationship diagram
  • data dictionary
  • other database design documentation

The list above is merely to provide some examples of what is meant by design documentation. You may not need to produce all of the documents in the list above if you feel you don’t help in specifying the system, and may include any other information diagrams you would like to use. Remember that design documentation should be used as a communication device between the system designer and the developer who will implement the system. With this in mind, ensure you use the techniques which work best to enable an understanding of the system design for another developer. The quality of your design choices will also be assessed here.

CM0656 Case Project

Feedback Sheet

Each group member should produce the requirements specification and design for their designated area of responsibility. The group should produce the terms of reference document and any design documents created for the database, interface and any other shared common areas of the application.

1. Group Terms of Reference

The Terms of Reference will be given a rating, indicated below, depending on the amount of thought given to all the sections of the document and the professionalism of the document.

Rating

Description of Quality

Exceeds expectations

Comprehensively addresses the areas with thought and relevant research. Demonstrates that a professional approach has been taken when specifying the terms of reference. Excellent consideration of the professional, social, legal and ethical issues.

Satisfactory to good

Satisfactorily addresses the areas with thought and relevant research. Demonstrates that a sensible approach has been taken when specifying the terms of reference. Good consideration of the professional, social, legal and ethical issues.

Requires some reworking

Unsatisfactorily addresses the areas without thought and/or relevant research Lacking in thought and relevant research AND/OR lacking a professional approach when specifying the terms of reference in some areas. Poor consideration of the professional, social, legal and ethical issues.

No meaningful attempt

Totally inadequate, lacking thought and relevant research. Indicates an unprofessional approach to specifying the project terms of reference. Consideration of the professional, social, legal and ethical issues is weak or absent.

Exceeds expectations

Satisfactory

Requires some reworking

No meaningful attempt

Code of Conduct

Objectives

Roles/Task Allocation

Mapping of skills

Deliverables

Resource List

Test strategy

Test procedures

Risk Analysis

Professional/ethical/legal/social issues

  1. Group Design Documents and System Documentation Consistency

Rating

Description of quality

Exceeds expectations

- The group’s specifications and designs demonstrate a high degree of cohesion. The group

has obviously liaised fully about what is involved in each area of responsibility AND/OR

- The documents are based on good design decisions AND/OR

- The design documents are complete and have been produced in a professional manner in accordance with appropriate standards.

Another developer would be able to commence implementation based on these designs without

requiring much further information.

Satisfactory to good

- The group’s specifications are reasonably cohesive and demonstrate that they have

communicated to some degree about what is involved in each area of responsibility, but

there is either some overlap or some elements missing AND/OR

- The design documents contain some omissions or mistakes AND/OR

- Some of the design decisions will need to be reconsidered.

Another developer would be able to commence implementation based on these designs,

however they may require further elaboration of some system requirements and design decisions.

Requires some reworking

- The group’s specifications lack cohesion in many areas. The group members do not

appear to have communicated about group quality standards for documentation AND/OR

- The design documents have not been produced according to recognised standards and contain

several major omissions and mistakes AND/OR

- Most design decisions need to be reconsidered.

The documents would not currently be of sufficient use to another developer implementing the

system.

No meaningful attempt

Totally inadequate, lacking thought and relevant research. Indicates an unprofessional approach

to the design

Exceeds expectations

Satisfactory

Requires some reworking

No meaningful attempt

User Interface design

Database design

System design

Group test plans

Thoroughness/ completeness of documentation

Usefulness of documentation

2. Individual Requirements Specification

Rating

Description of quality

Exceeds expectations

A complete, thorough and prioritised list of requirements, which another developer could use to

design and develop the system. Market research is useful and an appropriate test plan given. Excellent discussion of social issues.

Satisfactory to good

Some necessary requirements missing from the requirements list AND/OR

the requirements list requires more detail and explanation if another developer is to understand

how to design and develop the complete system. Market research is lacking in detail and/or test plan is not to required standard. Good discussion of social issues.

Requires some reworking

An inadequate requirements list, with many requirements missing. Market research is weak, test plan poor. Poor discussion of social issues.

No meaningful attempt

Totally inadequate, lacking thought and relevant research. Indicates an unprofessional approach

to specifying the requirements. Market research is of little or no use and test plan poor with little consideration given. Discussion of social issues is weak or absent.

Exceeds expectations

Satisfactory

Requires some reworking

No meaningful attempt

Market research

Requirements specification

Use case model or equivalent analysis

Individual test plans

Discussion of social issues

  1. Individual Design Documents

Rating

Description of quality

Exceeds expectations

- The design documents are complete and have been produced in a professional manner in

accordance with appropriate standards AND/OR

- The documents are based on good design decisions.

Another developer would be able to commence implementation based on these designs

without requiring much further information.

Satisfactory to good

- The design documents contain some omissions or mistakes AND/OR

- Some of the design decisions will need to be reconsidered.

Another developer would be able to commence implementation based on these designs,

however they may require further elaboration of some system requirements and design decisions.

Requires some reworking

- The design documents have not been produced according to recognised standards and

contain several major omissions and mistakes AND/ OR

- Most design decisions need to be reconsidered.

The documents would not currently be of sufficient use to another developer implementing the

system.

No meaningful attempt

Totally inadequate, lacking thought and relevant research. Indicates an unprofessional approach

to the design

Exceeds expectations

Satisfactory

Requires some reworking

No meaningful attempt

User interface design

Database design

System design