Object Oriented Analysis - 700039
Object Oriented Analysis - 700039
Workshop 5 Marked
NOTE:
The weekly project meeting is to be conducted at the beginning of the workshop. To receive the full marks for the participation in this workshop, you MUST ATTEND the project meeting and complete the tasks: 1 - 4 during the workshop. Further, your teacher must be satisfied with the quality of the work you have produced. Complete the meeting minutes using the template given on Appendix B. Once you complete the workshop, please create a zipped folder of all your work and upload it in the assessment area on vUWS.
Read this worksheet to understand the set workshop work for this week. You must prepare an initial draft of the following:
i) Meeting minutes
ii) Draft of FOUR Use Case Documentations
iii) Draft of TWO Use Case Diagrams
iv) FOUR Activity Diagrams
Task 1 [Group work]: Project Meeting
The group meeting is expected to be completed within the first 30 mins of the workshop session. Document your meeting minutes using the template given in Appendix A
Task 3 [Individual Task]: Actors
Revisit the list of actors that you have identified for your package during workshop 4 and make sure you have listed all three types of actors where appropriate.
Task 2 [Individual Task]: Use Case Documentation
This is an individual task. However, students are encouraged to discuss their identified use cases with other group members.
Identify at least FOUR (4) use cases from your assigned package and document at least ONE (1) use case using the template given in Appendix B.
Discuss in group the Use Case Documentation that you prepared to finalise the first draft of the use Case documentation.
Each student must document at least FOUR (4) uses cases for their assigned Package as a preparation for Iteration 2.
Task 4 [Individual Task]: Use Case Diagram
This is an individual task. However, students are encouraged to discuss their use case diagram with other group members.
Put together the actors that you finalised in Task 2 and the use cases that you have identified in Task 3 into use case diagrams in your CASE tool.
Ensure that the use cases in your use case diagrams have meaningful name and include an action word such as Register Patient.
Add detailed notes to your use case diagram for providing additional explanations.
Ensure that you have used both <<include>> and <<extends>> relationships in your use case diagrams where appropriate.
Discuss in group to get the initial draft of the use case diagram for you package.
Since actors and use cases can repeat themselves in various diagrams, it is expected that there will be at least TWO (2) use cases per package. This means a total of at least EIGHT (8) use cases for a group of 4 members.
Students are expected to prepare TWO (2) diagrams for their assigned package as a preparation for Iteration 2.
Task 5 [Individual Task & Group Task]: Activity Diagram
This is an individual task. However, students are encouraged to discuss their identified use cases with other group members.
Choose one use case from the use case diagram from Task 3 and draw an activity diagram aligning the basic flow of the documentation.
Add notes to the Activity Diagrams to further explain the diagrams.
Show parallel activities using Fork where appropriate.
Discuss in group to get the initial draft of the activity diagram from each of the FOUR (4) Use cases.
Draw FOUR (4) Activity Diagrams for your use cases. Usually one activity diagram will be drawn for one use case. (Hence, FOUR (4) activity diagrams corresponding to 4 different use cases).
Appendix A - Meeting Minutes Template
Minutes of the Project Team Meeting of dd/mm/yyyyMeeting No: 2Held at: ______________________
Chairperson:________________
Team members in attendance: ________________________
Minutes taken by:____________________
Agenda items discussed:
Identify 2-3 agenda items as per workshop tasks. e.g: assign the packages to the group;Can also use a generic one from week 3 onwards: progress of completing/revising previous workshop work/homework
Action Plan:
ItemDescription Who When Initial
Appendix B
Template for Use Case Documentation
Use Case Thumbnail: Package: Actors: Use Case Description: Pre-Condition: Post-Condition:
Basic Flow: Alternate Flow: User Interface Specifications:
Author and
History
Object Oriented Analysis Project Report
Activ@24 Health Club System2024.1
Submitted By
Group Name: <<Your Group Name>>
Student No. Name Package
Please note that you must always adhere to this template format.
INSTRUCTIONS TO STUDENTS:
FOR YOUR FINAL PROJECT REPORT
USE THIS DOCUMENT AS A STARTING POINT TO FORMAT YOUR REPORT
YOU MUST MODIFY/IMPROVE ON THIS DOCUMENT FORMAT PROVIDED TO IMPROVE YOUR OVERALL PROJECT PRESENTATION
THE PROBLEM STATEMENT FOR YOUR CASE STUDY IS INCLUDED IN THIS DOCUMENT. YOU MAY FURTHER MODIFY THE PROBLEM STATEMENT TO SUIT YOUR OWN UNDERSTANDING OF THE CASE STUDY
THE HEADINGS GIVEN IN THIS PROJECT REPORT CORRESPONDS TO MOST OF THE PROJECT WORK REQUIREMENTS GIVEN AT THE END OF EACH CHAPTER OF THE APRCTICAL OBJECT-ORIENTED ANALYSIS BOOK. THESE HEADINGS WILL ENSURE YOU HAVE NOT MISSED ANY MAJOR DELIVERABLES.
HOWEVER, YOU ARE WELCOME TO ADD/MODIFY THE HEADINGS IN THIS REPORT
ENSURE YOU COMPLETE THE COVER PAGE CORRECTLY WITH YOUR GROUP NAME; GROUP MEMBER NAMES; ALSO CHANGE THE FOOTER WITH YOUR GROUP NAME AND DETAILS.
SPELL-CHECK YOUR REPORT THOROUGHLY
ENSURE YOUR REPORT DOES NOT CONTAIN ANY THEORY THIS IS A APRCTICAL PROJECT REPORT SO NO THEORY (SUCH AS WHAT ARE OBJECTS) SHOULD APPEAR ANYWHERE ON THE REPORT
DELETE THIS INSTRUCTION PAGE AND OTHER HIGHLIGHTED INSTRUCTIONS IN THIS REPORT AFTER YOU HAVE READ THEM
Table of Contents
TOC
TOC o "1-3" h z u 1Executive Summary PAGEREF _Toc150162802 h 52Introduction PAGEREF _Toc150162803 h 52.1Purpose of the document PAGEREF _Toc150162804 h 52.2Scope PAGEREF _Toc150162805 h 52.3Dictionary of Terms, Definitions and Acronyms PAGEREF _Toc150162806 h 52.4References PAGEREF _Toc150162807 h 52.5Overview PAGEREF _Toc150162808 h 63Project Overview PAGEREF _Toc150162809 h 73.1Project Purpose, Scope, and Objectives PAGEREF _Toc150162810 h 73.2Project Assumptions and Constraints PAGEREF _Toc150162811 h 73.3Project Deliverables PAGEREF _Toc150162812 h 73.4Evolution of the Project Plan PAGEREF _Toc150162813 h 84Management Process PAGEREF _Toc150162814 h 94.1Effort Estimate by Iterations PAGEREF _Toc150162815 h 94.2Project Plan PAGEREF _Toc150162816 h 114.2.1Phase Plan PAGEREF _Toc150162817 h 114.2.2Iteration Objectives PAGEREF _Toc150162818 h 114.2.3Project Schedule PAGEREF _Toc150162819 h 115Case Study for Project Work PAGEREF _Toc150162820 h 146Critical Requirements Analysis (CRA) PAGEREF _Toc150162821 h 207Package Diagrams PAGEREF _Toc150162822 h 208Actor Hierarchy Diagram, Actor List and Documentation PAGEREF _Toc150162823 h 209Use Case Documentation PAGEREF _Toc150162825 h 2110Use Case Diagrams PAGEREF _Toc150162826 h 2111Activity Diagrams PAGEREF _Toc150162827 h 2212Class Diagrams PAGEREF _Toc150162828 h 2213Sequence Diagrams PAGEREF _Toc150162829 h 2214Interaction Overview Diagrams PAGEREF _Toc150162830 h 2215State Machine Diagrams PAGEREF _Toc150162831 h 2316Functional Prototypes (and User Interfaces) PAGEREF _Toc150162832 h 2316.1UI Flow Diagram PAGEREF _Toc150162833 h 2316.2Screen Specifications PAGEREF _Toc150162834 h 2317Operational (Non-Functional) Requirements PAGEREF _Toc150162835 h 2617.1Performance PAGEREF _Toc150162836 h 2617.2Volume PAGEREF _Toc150162837 h 2617.3Scalability PAGEREF _Toc150162838 h 2617.4Security PAGEREF _Toc150162839 h 2618Environmental Considerations PAGEREF _Toc150162840 h 2619Test Plan PAGEREF _Toc150162841 h 2719.1Test Strategy PAGEREF _Toc150162842 h 2719.2Test Objectives PAGEREF _Toc150162843 h 2719.3Test Assumptions PAGEREF _Toc150162844 h 2719.4Scope and Levels of Testing PAGEREF _Toc150162845 h 2819.5Test Designs PAGEREF _Toc150162846 h 2819.6Test Cases PAGEREF _Toc150162847 h 29Appendix PAGEREF _Toc150162848 h 3019.7Project Minutes of Meetings PAGEREF _Toc150162849 h 3020References PAGEREF _Toc150162850 h 30
History of Document Revision
Version Released On Description of Major Revision Person Responsible
1.0 Executive Summary[The Executive Summary should not be a part of the body of the report itself. The executive summary should very concisely summarise the whole report between 100 to 150 words.]
Introduction [The introduction of the report should provide an overview of the entire document. The overview should be between 150 to 250 words.]
Purpose of the document[Specify the purpose of this report. The text below is provided as an example.]
e.g.: The purpose of the report is to document the requirements of the project that provide a basis for the next RUP iterations in the project. It describes the critical performance area and prioritise the requirements. This can be used to validate the resource estimation for the rest of the iterations and basis for the rest of the phases of the RUP project.]
Scope
[A brief description of the scope of this report; what Project(s) it is associated with and anything else that is affected or influenced by this document. The text below is provided as an example.
This report includes deliverables completed for the given case study project using the given project template. The details of the individual iterations will be described in the Iteration Plans.]
Dictionary of Terms, Definitions and Acronyms[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret this document. This information may be provided by reference to the projects Glossary.]
Term / Acronym Definition
UML Unified Modelling Language
References
[This subsection provides a complete list of all documents referenced elsewhere in the Software Development Plan. Identify each document by title, report number if applicable, date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.
For the Software Development Plan, the list of referenced artefacts includes:
RUP
Iteration Plans
Development Case
Vision
Glossary
Any other supporting plans or documentation.]
Document Title Date Published Source
Project Specification for Iteration 1 To Be Published Moodle
Project Specification for Iteration 2 To Be Published
Project Specification for Iteration 3 To Be Published .
Roles Specification Document
Project Plan for Iteration 1 .
Project Plan for Iteration 2
Project Plan for Iteration 3 .
Meeting Minutes
Impediment Log .
Quality Assurance
.
.
.
Overview
[This subsection describes what the rest of the document contains and explains how the document is organized.]
Project OverviewProject Purpose, Scope, and Objectives[A brief description of the purpose and objectives of this project that you are undertaking as a group and a brief description of what deliverables the project is expected to deliver and clarify what the project will (and will not) deliver, to avoid future shifts in the level of ambition.]
Project Assumptions and Constraints[A list of assumptions that this plan is based and any constraints, for example. budget, staff, equipment, schedule, that apply to the project.]
Project Deliverables[A list of the artefacts to be created during the project, including target delivery dates.]
Iteration 1:
Item No Deliverable Delivery Date
1 Project Introduction 2 Project Plan and Summary of Meeting Minutes 3 Critical Requirement Analysis 4 Package Diagram 5 Actor List 6 First Set of Actor Documentations 7 First Set of Use Case Documentations 8 First Set of Use Case Diagrams 9 First Set of Activity Diagrams Iteration 2:
Item No Deliverable Delivery Date
1 Executive Summary 2 Introduction and Scope 3 Project Management Documents 4 Major Business Function Area & Package Diagram 5 Second Set of Actor Documentations 6 Second Set of Use Case Documentations 7 Second Set of Use Case Diagrams 8 Second Set of Activity Diagrams 9 A Set of Class Diagrams 10 A Set of Sequence Diagrams 11 A Set of Interaction Overview Diagrams 12 A Set of State Machine Diagrams 13 Revised Project Plan and Meeting Minutes 14 Documentation of Group Work and Quality Assurance Iteration 3:
Item No Deliverable Delivery Date
1 Quality Assurance 2 Prototypes 3 Operational Requirements 4 Environmental Considerations 5 Project Management Documents Evolution of the Project Plan[A table of proposed versions of the Software Development Plan. Include initial project plan and two revisions]
Version Released On Description of Project Plan
0.1 Initial Project Plan
1.0 Finalised Project Plan for Iteration 1
2.0 Finalised Project Plan for Iteration 2
3.0 Finalised Project Plan for Iteration 3
Management ProcessEffort Estimate by Iterations[The table below is provided as an example. Your estimate should be bases on deliverables and initial judgement based on given sample case study artefacts.]
Item No Item Name Person hours* % of Total Effort
Iteration 1: (Due in Week 6) 1 Introduction to project
2 Project plan and summary of meeting minutes summarising the work completed so far in the project
3 Critical Requirement Analysis (CRA)
4 Package diagram and identifying who is working on each package
5 Actor list, Actor hierarchy diagram and in-progress actor documentation (minimum 4 actors and 1 actor documentation progress per package).
6 Use case diagrams and in-progress use case documentation (1 use case diagrams per package and 1 in-progress use case documentation per package).
7 Activity diagrams (one activity diagram for each package) and work completed.
8 Presentation slides and preparation
Iteration 2: (Due in Week 9) 9 Executive Summary
10 Introduction, Scope
11 Project management documents including project plan, minutes, etc.as specified in the project template
12 Critical Requirement Analysis (CRA) & Package Diagram
13 Actor List and Documentation (minimum 3 Actors per package)
14 Use case documentation (minimum 4 use case per package 16 use cases for 4 packages).
15 Comprehensive use case documentation including use case thumbnail, use case description, stereotype and package, actors, pre-conditions, post-conditions, use case relationships, basic flow (or normal course of events), alternative flow, exceptions, user interface specification, priority, status, author and history, and reference material.
16 Use case diagrams (2 use case diagrams per package. 8 use case diagrams for 4 packages).
17 Activity Diagrams (4 activity diagram for each package 16 diagrams for 4 packages)
19 Class diagram (around 4 to 6 class diagrams for 4 packages including around 5 attributes and 5 operations for each class)
20 Sequence diagrams (2 diagrams per package, 8 diagrams for 4 packages.)
21 Interaction overview diagrams (1 diagram per package, 4 diagrams for 4 packages)
22 State machine diagrams (1 diagrams per package, 4 diagrams for 4 packages)
23 Revised project plan and meeting minutes
24 documentation-combining group work and quality control
Iteration 3: (Due in Week 11) 25 Quality assurance (1 Test design, 1 Test plan and minimum 3 Test cases per package)
26 Prototypes (functional prototypes using mock-up screens two functional prototypes and one UI flow diagram per package)
27 Operational requirements and environmental consideration
28 Project management documents including project plan, minutes,
29 The deliverable is a report based on the given project template. (should include work from iteration 1 & 2 as well. However, it is expected that artefacts in iteration 1 & 2 will be updated later during the project. So, only final versions of those artefacts need to be included in the report.)
Total Estimated Effort 100%
Project PlanPhase Plan[Include the following:
Work Breakdown Structure (WBS)
a timeline or Gantt chart showing the allocation of time to the project phases or iterations.
identify major milestones with their achievement criteria.
Define any important release points and demos.]
Iteration Objectives[List the objectives to be accomplished for each of the iterations. Relate to the phases and activities in RUP]
Project Schedule[Diagrams or tables showing target dates for completion of iterations and phases, release points, demos, and other milestones.]
Item No Item Name Item Description (Remaining Work) Who When
Iteration 1: (Due in Week 6) 1 Introduction to project To be drafted Week 4
2 Project plan and summary of meeting minutes summarising the work completed so far in the project To be drafted Week3
3 Critical Requirement Analysis (CRA) 16/07/2021 Week 3
4 Package diagram and identifying who is working on each package 16/07/2021 Week 3
5 Actor list, Actor hierarchy diagram and in-progress actor documentation (minimum 4 actors and 1 actor documentation progress per package). Week 4
6 Use case diagrams and in-progress use case documentation (1 use case diagrams per package and 1 in-progress use case documentation per package). Week 5
7 Activity diagrams (one activity diagram for each package) and work completed. Week 5
8 Presentation slides and preparation Week 5
Iteration 2: (Due in Week 9) 9 Executive Summary Week 7
10 Introduction, Scope Week 7
11 Project management documents including project plan, minutes, etc.as specified in the project template Week 2-9
12 Critical Requirement Analysis (CRA) & Package Diagram Week 3
13 Actor List and Documentation (minimum 3 Actors per package) Week 4
14 Use case documentation (minimum 4 use case per package 16 use cases for 4 packages). Week 5
15 Comprehensive use case documentation including use case thumbnail, use case description, stereotype and package, actors, pre-conditions, post-conditions, use case relationships, basic flow (or normal course of events), alternative flow, exceptions, user interface specification, priority, status, author and history, and reference material. Week 5
16 Use case diagrams (2 use case diagrams per package. 8 use case diagrams for 4 packages). Week 5
17 Activity Diagrams (4 activity diagram for each package 16 diagrams for 4 packages) Week 5
18 Class diagram (around 4 to 6 class diagrams for 4 packages including around 5 attributes and 5 operations for each class) Week 8
19 Sequence diagrams (2 diagrams per package, 8 diagrams for 4 packages.) Week 9
20 Interaction overview diagrams (1 diagram per package, 4 diagrams for 4 packages) Week 9
21 State machine diagrams (1 diagrams per package, 4 diagrams for 4 packages) Week 9
23 Revised project plan and meeting minutes Week 8
24 documentation-combining group work and quality control Week 9
Iteration 3: (Due in Week 11) 25 Quality assurance (1 Test design, 1 Test plan and minimum 3 Test cases per package) Week 11
26 Prototypes (functional prototypes using mock-up screens two functional prototypes and one UI flow diagram per package) Week 10
27 Operational requirements and environmental consideration Week 11
28 Project management documents including project plan, minutes Week 10-11
29 The deliverable is a report based on the given project template. (should include work from iteration 1 & 2 as well. However, it is expected that artefacts in iteration 1 & 2 will be updated later during the project. So, only final versions of those artefacts need to be included in the report.) Week 10-11
Case Study for Project Work
FOLLOWING IS A HYPOTHETICAL PROBLEM STATEMENT FOR Activ@24 Health Club System (AHCS) A HYPOTHETICAL Health Club.
THIS PROBLEM STATEMENT IS PURPOSEFULLY KEPT INCOMPLETE REQUIRING YOU TO CONDUCT DETAILED ANALYSIS AND DOCUMENTATION TO COMPLETE THEM
YOU ARE WELCOME TO MODIFY THIS PROBLEM STATEMENT TO SUIT THE PARTICULAR NEEDS OF THE COMPANY.
Activ@24 Health Club (AHC) is a family-owned health club in Western Sydney that aspires to change lives by promoting healthy living. The owners, Josh and Jen Diaz, are committed to providing safe, affordable, and high-quality physical activities that can inspire people to live healthier lives. Jen Diaz, a sustainability champion, is passionate about using sports and physical activities as a powerful tool to achieve the Sustainable Development Goals (SDGs) outlined in the United Nations 2030 Agenda for Sustainability. By targeting "Goal 3: Ensure healthy lives and promote well-being for all at all ages," she aims to spread the message that a healthy lifestyle can bring about a positive change in people's lives.
The company currently employs around 20 casual staff and 5 permanent staff including 2 admin persons to answer the phone, handle payments and paperwork. The AHC gross income in 2023 was $3.6 Million. Presently, the business has a simple informative website, 5 desktops and 3 networked printers. All devices are connected using a small Local Area Network (LAN). The data is currently stored as static files in the individual computers.
The current business is expanding, and the owners wish to open 2 new branches around Western Sydney. Their Business Consultant advised them to systemise the business using Information and Communication Technology. Hence, the owners are keen for an e-business solution with a robust and scalable platform. The requirement for the new e-business solution, however, needs to be understood, analysed, and documented. To achieve this purpose, they have hired a specialist consulting firm made up of consultants (YOUR GROUP), who can use Information and Communication Technologies to accelerate progress towards every single one of the 17 United Nations Sustainable Development Goals (SDGs).
The brief requirement of this project is to develop an Internet-based software solution that will handle all aspects of the business for the Activ@24 Health Club, such as member management, staff management, equipment management, fitness class management, fitness goal management etc. The consulting group is required to document all the requirements for the Activ@24 Health club system. This system is to be documented using Unified Modelling Language (UML version 2.0).
Here is the list of detailed requirements:
Recommendations for Member Management
The receptionist who is responsible for managing the club membership system must have the capability to add new members to the club, along with updating the account details of existing members. They should verify that all information provided is accurate and complete. This includes the member's name, address, phone number, email, and payment details. (new members+existing members--> potential members)
Members who have recently joined the club should have the ability to book a personal trainer for a free session to create an individualized fitness profile. This session should enable the trainer to understand the members' fitness goals, health status, and any medical conditions that need to be considered when designing their personalized fitness plan. Members should also have the option to provide any additional information they think might be necessary.
Staff who are responsible for managing the club membership system must remove expired memberships promptly. They should ensure that members with expired memberships are not allowed access to the club facilities or services until their membership is renewed.
The receptionist must process member payments in a timely and efficient manner. They should ensure that all payments are processed correctly and that members receive a confirmation receipt for their payment. (Payments: Banking system)
Club membership is flexible, and members are entitled to request to freeze their accounts for a specific period. During this period, members should not be charged membership fees. Members should also have the right to apply to reinstate their frozen accounts when they are ready to resume their membership.
Finally, the receptionist must be able to send SMS messages to all or selected groups of members without delay. These messages could be regarding important updates, promotions, events, or any other relevant information. Members should have the option to opt out of such messages at any time.
Recommendations for Equipment Management
The fitness club's staff should possess the capability to add pertinent details regarding newly acquired equipment procured for the facility. This would serve to maintain an accurate inventory of all fitness equipment, thereby ensuring an effective management system within the club. Additionally, staff should possess the authority to remove information regarding defective fitness equipment that is no longer in use, to prevent any discrepancies in the inventory of the fitness equipment.
At the fitness club, the staff follows the National Code of Practice for the Health and Fitness Industry to provide a safe and healthy environment for all members. They update their equipment, maintain cleanliness and hygiene, and provide training to help members achieve their fitness goals safely.
If a piece of fitness equipment requires repair, the staff should be able to book a request for the same. This will enable the maintenance team to attend to the equipment promptly and efficiently, ensuring that it is back in working order at the earliest convenience.
It is essential to maintain a repair log for all fitness equipment, as this would enable the staff to keep track of recurring issues or common faults that may arise. The log would also aid the maintenance team in determining when a piece of equipment has undergone multiple repairs and is approaching the end of its lifespan.
Furthermore, the staff should hold the authority to establish supplier accounts for all newly acquired fitness equipment suppliers. This would streamline the process of purchasing new equipment and guarantee that the club is acquiring the best possible price. If the supplier is no longer associated with the club, the staff should possess the authorization to remove the account.
Finally, fitness equipment suppliers should be granted access to view the stock level for their products. This would enable them to manage their inventory levels efficiently and guarantee that their products are always available for purchase by the club.
Recommendations for Staff Management
The HR staff of a club should have the ability to add new staff details to the system. This includes entering personal information, employment history, job responsibilities, and other relevant data. Additionally, they should be able to update the details of existing staff members, such as job titles, contact information, and salary information.
Furthermore, the HR staff should have the ability to remove staff details from the system for employees who are no longer working at the club. This includes deleting personal and employment information, as well as any other data that is no longer necessary or relevant.
On the other hand, staff members should be able to update their availability status. This includes indicating when they are available to work or when they are not, which helps with scheduling and shift planning.
Additionally, staff members should be able to submit time sheets for their work hours. This includes logging their start and end times, as well as any breaks they took during their shift.
Moreover, staff members should be able to apply for leave through the system. This includes indicating the type of leave they are requesting, such as sick leave or vacation leave, and the dates they will be absent.
Furthermore, the system should allow staff members to book training sessions or workshops. This includes selecting the course they want to attend, the date and time of the session, and any other relevant information.
Lastly, staff members should be able to check their leave balances through the system. This includes viewing the number of days they have remaining for each type of leave, such as sick leave, vacation leave, or personal leave.
Recommendations for Fitness Class Management
The fitness center's staff members should have the ability to create a new fitness class and add it to the schedule with all necessary details such as the class name, description, duration, location, and the trainer assigned to that class.
The fitness center's staff members should also be able to update the details of any existing fitness class whenever required.
Furthermore, the fitness center's staff members should be able to remove a class from the system if it is no longer offered by the gym.
On the other hand, gym members should be able to book a fitness class by selecting the desired class from the schedule and booking it for a specific date and time. They should also be allowed to cancel their booking if they are no longer able to attend the class.
In addition to that, the fitness center's staff should have the ability to create a roster for the trainers who are assigned to teach the fitness classes. The roster should include all trainers' details and their assigned classes, and it should be updated whenever there is a change in the schedule.
Lastly, the staff should be able to run a report that identifies the members who have missed their booked fitness classes, so that they can follow up with them and ensure they are getting the most out of their gym membership.
Recommendations for Fitness Goal Management
The fitness program should provide members with the ability to set their individual fitness goals based on their personal preferences and needs such as losing weight, building muscle, or improving overall fitness.
Members should also be able to book a personal trainer for a consultation session to get professional advice on the different physical activities required to achieve their fitness goals.
Furthermore, members should be able to remove a fitness goal from the system when it is no longer relevant or update it to suit their current needs. This ensures that the fitness program is tailored to the individual needs of each member.
To keep track of their progress, members should be able to create a fitness journal. The journal should allow members to record their physical activities regularly, including the exercises they performed, the duration of the activity, and the intensity level. Members should also be able to manage the journal with updates or delete it from the system if needed.
Additionally, members should be able to book the appropriate fitness equipment for achieving their individual fitness goals. This functionality should be easy to use, and members should be able to check the availability of equipment and book it online.
Both the member and the personal trainer should be able to browse the fitness journal to monitor the member's goal progression. This enables the personal trainer to provide appropriate advice and support to the member as they work towards their fitness goals.
Finally, members should be able to view their Goal Charts to visualize their progress and rewards. The Goal Charts should display the member's progress towards achieving their fitness goals, including the milestones they have achieved and the remaining tasks. Members should also be able to see the rewards they will receive upon achieving their goals, providing motivation for them to continue working towards their fitness objectives.
Recommendation for Healthy Meal Planning
To support healthy weight loss, a member should have the ability to set a dietary goal that follows the SMART (Specific, Measurable, Attainable, Realistic, and Timeframe) framework. This will help ensure that the goal is realistic and achievable, as well as provide a clear roadmap for progress.
To help plan their meals, a member should be able to create and manage a weekly meal plan that includes the three main meals (breakfast, lunch, and dinner) and snacks (morning, afternoon, and evening). This will help them stay on track with their dietary goals while also ensuring that they are getting the nutrients they need to maintain good health.
To make grocery shopping easier, a member should be able to access a grocery list planner that is related to their weekly meal plan. This will help them stay organized and make sure they have all the ingredients they need for their meals.
To keep things interesting and challenging, a member should be able to create and manage a weekly planner that is related to a monthly challenge. This will help them stay motivated and engaged with their dietary goals, as well as provide a sense of accomplishment as they progress through the challenge.
If a member decides to use a suggested meal or recipe from the Activ@24 Health Recipe Hub, they should be able to search for recipes and access them when needed. This will help them find new and interesting recipes that fit their dietary goals and preferences.
If a member wants to view the calorie count of a meal or recipe, it should be available. Additionally, the member should be able to add the calorie count for their own or family recipes. This will help them stay on track with their dietary goals and make informed choices about what they eat.
Finally, to help ensure they stay properly hydrated, a member should be able to receive notifications and reminders to drink water in a way that suits their preferences. This will help them track their daily water intake and maintain good health.
End of Problem Statement
Please note that you must adhere to this problem statement. However, you are welcome to add to this problem statement if you have addressed all the requirements given in the problem statement.
Critical Requirements Analysis (CRA) - Business Objective, Critical Performance Areas (CPAs) or Major Business Functions(Based on CRA, include the Business Objective, CPAs (level 1 and level 2) and Priorities)
Package Diagrams(Three-layered architecture. Prioritise them, show dependencies and notes)
Actor Hierarchy Diagram, Actor List and DocumentationPackage Name
Actor: A01-Actor Thumbnail A01-.
Actor Type & Stereotype Actor Description Actor Relationships Interface Specifications Author & History Reference Material Use Case DocumentationPackage Name
Thumbnail UC01-UsecaseName
Description Stereotype Actors A01-ActorName, A02-ActorName
Pre-Conditions Post-Conditions Relationships Basic Flow
Alternate Flow A1. .
Exceptions Constraints User Interface Specifications Metrics Complex Priority High Status Major
Author/History Reference Material Use Case DiagramsPackage Name 1
Use case Diagram 1
Use case Diagram 2
Package Name 2
Use case Diagram 1
Use case Diagram 2
Activity DiagramsPackage Name 1
Activity Diagram 1 (Need to correspond to a use case documented in the previous section)
Activity Diagram 2 (Need to correspond to a use case documented in the previous section)
Activity Diagram 3 (Need to correspond to a use case documented in the previous section)
Activity Diagram 4 (Need to correspond to a use case documented in the previous section)
Package Name 2.
Class DiagramsPackage Name 1
Class Diagram 1
Class Diagram 2
Package Name 2
Class Diagram 1
Class Diagram 2
..
Sequence DiagramsPackage Name 1
Sequence Diagram 1
Sequence Diagram 2
Package Name 2
Sequence Diagram 1
Sequence Diagram 2
..
Interaction Overview DiagramsPackage Name 1
Interaction Overview Diagram
Package Name 2
Interaction Overview Diagram
..
State Machine DiagramsPackage Name 1
State Machine Diagram
Package Name 2
State Machine Diagram
Functional Prototypes (and User Interfaces)Package Name 1
Functional Prototype 1
Functional Prototype 2
Package Name 2
Functional Prototype 1
Functional Prototype 2
UI Flow DiagramPackage Name 1
UI Flow Diagram
Package Name 2
UI Flow Diagram
Screen SpecificationsOnly the layout of the screens is important from a requirements/usability viewpoint. The screens themselves need not be designed during this stage. The following screen headings are examples only students are required to create their own screen names and layouts and specify them here.
Operational (Non-Functional) Requirements
PerformanceE.g. From the HMS Case study: The system shall give responses in 1 second after entering the patients information for verification.
The system shall show list of available doctors in 2 seconds after entering patient ID and details to book a consultation.
The system shall display the outstanding bill in 5 seconds after entering the patient login details.
VolumeAnticipated volume requirements should be specified as far as possible at the start. You may need to think about Storage capacity, Bandwidth requirements, User capacity, and room for use authorization and authentication.
ScalabilitySample Scalability Requirements for HMS. The system may have been designed for 1000 hits per day and may be scalable to 5000 hits per day; The present database capacity is around 4 TB with multimedia content.; The application server may need to be upgraded on a yearly basis to cope with the market competition and subsequent scalability.
SecuritySample Security Requirement for HMS: Patient records must adhere to privacy policies, Basic level of access to end users to perform functions like booking consultation for registered patients, Utilize encryption technologies and secure communications protocols to protect confidential data, Implement multi-factor authentication for users to access the system.
Environmental Considerations[Sample: The development will take place on Inspiron 24 5000 workstations and Inspiron 17 5000 Laptops, under Windows 10 & Windows Server 2016.]
Following is a list of the software to be used:
Analytical & Design Tools:
XAMPP by Apache friends. XAMPP software package contains Apache distributions for Apache server, MariaDB, PHP, and Perl.
Or
Implementation Tools:
Microsoft Visual Studio 2017
Eclipse SimRel 201809, Windows 64 bit
Following is a list of the languages to be used, but not limited to:
JavaScript ECMAScript 2018 / June 2018
C# 7.3 or Java 10
ASP.NET
HTML, CSSTest PlanTest StrategyThe test strategy should include the methodology to be used, the resources needed, the types of tests to be performed, the environment in which the tests will be conducted, and the schedule of when the tests will be performed. The test strategy should also identify any risks associated with the software and how those risks will be addressed.
Test Objectives[The objective of the test is to verify that the functionality of . works according to the specifications.
The test will execute and verify the test scripts, identify, fix, and retest all high and medium severity defects per the entrance criteria, prioritize lower severity defects for future fixing via ...
The final product of the test is twofold:
A production-ready software.
A set of stable test scripts that can be reused for Functional and UAT test execution.]
Test Assumptions[Key Assumptions: Sample
Production like data required and be available in the system prior to start of Functional Testing
In each testing phase, Cycle 3 will be initiated if the defect rate is high in Cycle 2.
General
All the defects would come along with a snapshot JPEG format.
The Test Team will be provided with access to Test environment via VPN connectivity.
The Test Team assumes all necessary inputs required during Test design and execution will be supported by Development/BUSINESS ANALYSTs appropriately.
Test case design activities will be performed by QA Group
Test environment and preparation activities will be owned by Dev Team
Dev team will provide Defect fix plans based on the Defect meetings during each cycle to plan. The same will be informed to Test team prior to start of Defect fix cycles.
BUSINESS ANALYST will review and sign-off all Test cases prepared by Test Team prior to start of Test execution.
The defects will be tracked through HP ALM only. Any defect fixes planned will be shared with Test Team prior to applying the fixes on the Test environment.
Project Manager/BUSINESS ANALYST will review and sign-off all test deliverables.
The project will provide test planning, test design and test execution support.
Test team will manage the testing effort with close coordination with Project PM/BUSINESS ANALYST
Project team has the knowledge and experience necessary, or has received adequate training in the system, the project, and the testing processes.
There is no environment downtime during test due to outages or defect fixes.
The system will be treated as a black box; if the information shows correctly online and, in the reports, it will be assumed that the database is working properly.
Cycle 3 will be initiated if there are more defects in Cycle 2.]
Scope and Levels of Testing[Unit Testing
Integration Testing
System Testing
Acceptance Testing]
Test DesignsTest Designs can be created based on the understanding of the package and its dependencies.
<< Typical Format of a test design:
Name - name should reflect the nature of the test design.
Module - indicates details of the subsystem, package, or any other module within the target system. It contains a brief description of the type of package being tested, the preparation required for the package and the various categories of test case needed.
Dependency - indicates the other test designs on which this test design depends. This is helpful when creating test cycles, incorporating the test design.
List of test cases - this is a list of test cases that make up the test design.>>
Test Cases<<USE THIS AS A TEST CASE TEMPLATE. MODIFY AS NEEDED>>
Identification: TC01-Patient Registration test Case
Purpose: To check if patient registration works successfully.
Prerequisites: System should be up and running
All required fields for patient registration are available.
Administrative Details:Name of the person who carried out the test.
Input
Actions Expected Output Actual Output
Appendix Project Minutes of Meetings<<IF PROJECT TEAMS ARE HAVING INTRA-GROUP ISSUES, THEY SHOULD ALSO BE RECORDED HERE. PLEASE NOTE: IT IS NOT THE RESPONSIBILITY OF THE LECTURER/TUTOR TO FULLY SOLVE PERSONALITY PROBLEMS WITHIN THE GROUPS. ALTHOUGH SOME HELP/SUGGESTIONS WILL BE PROVIDED>>
[Add all the project meetings completed throughout the project.]
[You can fill the following table or include the meeting minutes]
Meeting No Date Held at Chairperson Attendance Duration Agenda Items Discussed
1 03-08-2022 6 Hassal St + Zoom Group formation.
Group SWOT analysis
1.
1.
1.
References[INSERT YOUR REFERENCE HERE.]
United Nations, Communications materials - For Non-UN Entities: SDG Logo, Including Colour Wheel for Web and Print, https://www.un.org/sustainabledevelopment/news/communications-material/, retrieved 02-03-2024, 2016
United Nations, Communications materials - SDG Poster and Individual Goals for Web And Print, https://www.un.org/sustainabledevelopment/news/communications-material/, retrieved 02-03-2024, 2016
United Nations, The Sustainable Development Agenda, Sustainable Development Goals, https://www.un.org/sustainabledevelopment/development-agenda/ , retrieved 02-03-2024, 2024Fowler, Martins UML Distilled, 3rd Edition, is a good readable book and should be referred to in addition to the course material, Addison-Wesley, 2003
Unhelkar, B., Process Quality Assurance for UML-based Projects, contains detailed discussion on the process aspect of quality. Chapter 1 for UML-based models, Chapter 3 for relevant process components, and Chapter 6 for testing are quite relevant.
Booch, G., et al, 1999, The UML User Guide, 1999, Addison-Wesley, is a substantial text and should be occasionally referred to, when students (especially teams) are looking for additional and in-depth material on a particular topic.
Booch, G. et al., Object-Oriented Analysis and Design with Applications, 3rd edition, 2007, Addison-Wesley, ISBN: 020189551X
Rational Software, Rational Unified Process: Best APRctices for Software development Teams https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestAPRctices_TP026B.pdf
