Software Engineering: Processes and Methods Assignment -
Overview - The purpose of this assignment is to provide a student with the opportunity to gain some insights into systems analysis responsibilities within a SCRUM team. The starting point is an imaginary case study (see below) and students will need to personalise this case study to their particular situation. In their second assignment, students will join with other class peers in small groups to work further on their case study and perform some more complex analysis tasks.
Learning Outcomes Assessed - The following course learning outcomes are assessed by completing this assessment:
- explain how models are used to assist in analysing and modifying existing business systems;
- identify appropriate models for given scenarios;
- develop various models using a professional CASE tool;
- produce Design models using Structured (Traditional) Approach;
- perform Object Oriented Analysis and Design to construct various object models used to communicate the scope and requirements of the project; and
- write integrated reports, using appropriate models, providing detailed analysis of given textual scenarios
Assessment Details -
Background
The case study scenario given is the starting point for this assignment. It is expected that each student will use their imagination to add more detail to the situation to make it their own unique project. It is expected that a student will submit their own individual work for this assignment.
Students are expected to read the case study as a starter and then from this, imagine what specific type of club (and its name) that they would like to profile. They should conduct some research of their own about clubs and their requirements. They can choose any kind of club (e.g. sporting, craft, music, and dance) as long as it fits in with the partial specifications given in the case study. It is expected that no two students' assignments will be the same, so they must make sure that their club has unique characteristics such as name and logo. Though it is expected that some of their user stories will be similar to others', it is also expected that each student will have at least one unique user story in their project that differs from those of their classmates.
Case Study -
You have been employed as an analyst for a small startup company specialising in web based database systems using php/mysql. Your colleague has visited a potential client for a briefing on a new project. Details are unclear at this stage, however you have been asked to prepare an initial scope document as a starting point. Your boss intends to develop a budget based on the information in your document and then discuss the initial product backlog with the club representative stakeholders at the next SCRUM meeting. You haven't time to wait for more details, so you have been asked to make assumptions where necessary. These can be explored with the client at the next meeting.
Your colleague met with the Secretary of a local community club and gathered the following information: The club has over 1000 members, with 25 new registrations within the past year. Members whose most recent purchase of club merchandise was made over a year ago are assigned a membership status of 'Inactive'. If there has not been a registration paid in the past year, the membership status is 'Lapsed'. Other customers may have a membership status of 'Current' or 'Loyal'. A 'Loyal' customer is defined as one who has paid registration in the past year and who makes at least $30 worth of purchases in each of three consecutive months. A 'Loyal' customer is entitled to 15% discount on all future purchases. If a 'Loyal' customer's purchases fall below $100 over twelve months their status reverts to 'Current'. The treasurer would like to be able to print reports that list all members and their current membership status.
Currently, the business uses a paper based system to keep track of customers' addresses, telephone numbers - home, work and mobile. It is hoped in the future that the new system will be able to have customers access it remotely to update their personal details after validating themselves using their membership number and a password.
Another function of the system is to record the available club merchandise items. Each item will have a status e.g. 'in stock', 'on order', 'out of stock'. There will be an on line ordering system, so customers can order items online by logging in and filling out an online order form. The business would like facilities to enable customers to pay online.
The club would also like to engage external businesses to help with fundraising activities by purchasing advertising on the club web page and/or newsletter. It is suggested that potential sponsors and businesses who would like to take part will be able to sign up and access this page to make their contributions as well.
Another function of the system is to display monthly newsletters and regular fixtures for club competitions.
Your colleague forgot to ask whether there were different levels of system access for committee members, although you expect this may be the case. It may be that different roles have special access to different parts of the system, following successful login.
Assessable Tasks/Requirements -
Students need to create a draft product backlog for the project described above. The document must include a title page with student name as author, as well as project name, client name, date and a version control table stating this as draft 1. The draft backlog document should be presented clearly and as a professional document. It must include user stories to explain the features required by potential users. Also, a prioritisation of the user stories is important to start discussions at the first SCRUM meeting. The submitted product backlog document should contain the following:
Part 1 (part of a Project Charter)
A name and logo for the club must be provided. At least 2 paragraphs must be provided that describe the objectives and vision of the club and how the new proposed system will be used to improve processes in the club.
Part 2
A list of definitions for keywords related to the club and system should be provided. The major stakeholders that may be involved in this project as well as an outline of all key user types/roles should be described.
Part 3
Two different potential users of the proposed system should be identified and for each user role, a description of the user profile and an example high level scenario of how they would use the new system (give step by step details as separate user stories in part 5) should be provided.
Part 4
A paragraph titled 'scope and constraints' which contains a description of at least four (4) high level broad objectives of the project should be included. At least one (1) item that will not be included in the scope of the proposed project (e.g. onsite testing, conversion of old data into new system, training, onsite installation) must also be identified.
Part 5
A detailed, prioritised list of user stories describing part of the new system, should be provided. This may form the basis for development in sprint cycle 1. For each requirement, a unique REQUIREMENT ID (use numbers and/or letters) should be shown and this should be accompanied by a priority value and clearly written user story. In particular, the focus should be on the online purchasing of merchandise, the fees for invoicing and collection, or treasurer's reports as allocated by the tutor.
Two categories of requirements - functional requirements and non-functional requirements must be represented in the user stories.
There must be at least seven (7) very specific functional user stories. There should be no summarising: for example, 'print reports'. Instead there should be details on each report separately as a separate individually itemised user stories. The user stories should be in the format: As a , I want so that
There must also be at least three (3) non-functional requirements represented as user stories for the system. These may relate to performance, behaviour, quality, look and feel etc.
Part 6
A sketch of the high level draft concept of the user interface for that part of the system anticipated being developed in sprint cycle 1 (described in part 5) should be provided. At this stage, the design is concerned with what content would be on each screen, and how it would be presented rather than a detailed layout. It should be clearly stated what components will be used e.g. menus, buttons or input fields. At least one screen should contain input fields that require automatic validation. The validation requirements for the screen/s should also be provided. A sketch and detailed description of at least 3 screens should be provided.