SENG2130 PSB 2023T1

School of Electrical Engineering & Computing SENG2130-Systems analysis and design

Introduction

Group Project 2: Requirements Modelling (30%) Due: See deadline of submission in Canvas FileName: labDay_labRoom_labTime_teamName

Group Assessment Only

File Name: SENG2130_A1_TeamName File Type: Word / PDF

Starstruck! Space Flight Management System

Starstruck! is a business that provides space tourism services to the public. Customers can book a quick flight to take them into space for a couple of hours and back, or a longer flight that completes a full orbit of the Earth before returning. Optionally, customers can choose a flight to take them to the moon and back, which takes about a week in total. Each flight has a capacity limit (usually 7 people), and customers who want their travel, or travel for their group, to be exclusive (i.e. not shared with another customer) will need to pay more as a result. Each booking is taken by administration staff and reviewed by the business manager who may approve or deny it.

Space flight is not always possible on any given day of the year. Flights are scheduled by the business manager months in advance as multiple factors, such as local weather, flight load, mission control availability, the orbital position of certain planetary bodies (such as the moon) and satellites, among other factors, may prevent a rocket launch from occurring. Additionally, safety checks occur constantly during preparation and countdown. At any point, if a problem is detected, depending on the severity, the launch may be aborted automatically or manually. During a period of 5 minutes before launch to 30 seconds after the second stage of the rocket fires, a launch may be aborted using the launch escape system, which will result in the capsule with the customers ejecting from the rocket and splashing down in the ocean. Customers with an aborted flight may lose out financially altogether, or, if they have paid extra for booking insurance, they may be offered a new date or given a partial or full refund, depending on the level of insurance purchased. Each use of the abort system is recorded in an audit log as well as the relevant flight log for safety monitoring purposes.

During re-entry, all remaining parts of the rocket are jettisoned and burn up in the atmosphere. The exception to this is the capsule, where customers and crew are located. This module will splashdown in the ocean somewhere in a pre-defined area known as the landing ellipse and will be picked-up by a specially equipped recovery ship or aircraft carrier, where customers and crew will receive a medical check, before being flown back to a conventional airport. These details, including the return airport, are specified in the booking.

While in space, the capsule exposes a large dome window that allows customers to see outside into space and take photos using the on-board telescope and cameras which can then be purchased for additional cost when the customer returns to Earth. For longer trips, customers may choose food and drink during booking (this is required for moon tours), which will be prepared and stored on-board prior to launch for use as

Page 1 of 6

SENG2130 PSB 2023T1

needed. While customers may request whatever they wish, some food is not safe for spaceflight, and will be rejected by the kitchen staff, forcing the customer to choose again. Luxury food items will incur additional cost.

The spacecraft must maintain a constant connection to mission control; the on-board system will report current status, problems, allow voice and video communication which can be recorded and relayed live to friends and family of the customers on-board, and allow mission control to override the system if required. Any use of the override feature is recorded in the audit log as well as the individual flight log. Live system data is also stored in the flight log for later analysis. All elements of the flight are tracked, from the amount of fuel in each stage of the rocket, to the flight crew on-board, as it is essential that the correct total weight of the spacecraft can be determined at any given time. For this reason, everything (including fuel) and everyone entering the spacecraft before launch must be weighed before entering, and this must be recorded by mission control.

Given the high price of space tourism, with costs reaching the millions per seat, cash payments are not accepted (counting that much money would take far too long). Instead, customers pay primarily by bank cheque, direct deposit, an approved cryptocurrency, or in some cases, credit card. All payments must be cleared before a booking can be confirmed. In the case of a group booking a 10% discount can be given per person in the group. Pricing also varies by lead time, that is, a booking a year in advance will be cheaper than booking a month in advance, with the exact cost calculated at the time of the booking.

For safety reasons, the business also tracks crew information, including their qualifications and when they expire, training completed, as well as their medical records. On-site medical staff are responsible for conducting medical assessments of flight crew as well as customers, and they may deny anyone from going into space on medical grounds, this is recorded in a log for future reference. Medical checks must be performed both before and after each flight, and any medical problems detected with customers are communicated to their registered GP, details of which are recorded in the booking.

Objective of the system

The main objective is to develop a new online management system.

1. The business manager needs all information at their fingertips to make decisions.

2. Safety is a critical aspect of this business and must be considered in every scenario.

3. The business manager requires financial reports each month, the system should store these as well

for audit purposes.

4. While the system will be online, it must also be secure, and personal information must be kept

private, such that only staff with a genuine need-to-know will be able to access private records.

5. The system must operate in real-time, i.e. able to receive and report on live flight data as it comes in

without delays.

Tasks

(Assume that customers interact only with staff and are therefore not considered as an actor.)

This is a continuation of Group Project 1, which you have already gathered and documented system requirements, business rules and constructed an initial model of the system in UML. Specially, you have

Page 2 of 6

SENG2130 PSB 2023T1

developed a use case diagram, activity diagrams and map out a domain class diagram for the domain which you have elicited requirements.

In this Group Project 2, you are required to submit a Report in Word or PDF format, covering the following:

1. Report cover sheet containing the

a. Team Name

b. List of Team members (first and last name and student numbers)

2. Introduction to the report (2.5 Marks)

a. What is in the report?

b. Who is the intended audience of this report?

c. What are the objectives of this report?

d. How does each element of this report contribute to achieving the report objectives?

3. Business Rules (5 Marks)

a. Refine business rules which you have already identified in Group Project 1. You may add on/ update your business rules as you discover more detailed requirements (as you perform iterative modelling). Your final list of business rules cannot be smaller than the requirements for Group Project 1.

b. Explain how each business rule is captured by your team design. This is an important part of testing your design. Remember some business rule may only be captured by human business processes. So is a business rule captured by an interface, by class data or a method etc?

c. Use the following table format for this process

   Business Rule

B1: Customer contact details

System Mapping

Data collected in the customer class and the interface

Organisational Mapping Manager notified if data is not complete by the system

      4. Subsets of Class Diagrams (30 Marks)

a. How many are required?

5/6 depending on the number of Use Case Descriptions developed in Group Project 1.

b. Each team member will revise their Use Case description from Group Project 1 (unless otherwise assigned by your academic) e.g. cannot use the logon use case.

c. Each team member will develop a subset of the Class Diagram for the Use Case Description he/she developed in Group Project 1. It must show all the participating classes which are required to implement the Use Case Description (including the Boundary classes, Controller classes and Entity classes) and appropriate relationships between them.

d. The word “Subset” means that only participating classes which are required to implement the Use Case Description will be included. It also has more information than the earlier Domain Class Diagram which does not show methods of the participating classes.

e. Include all attributes for each class needed in you Use Case Description. You may include access modifiers i.e. private, public and protected if you can identify them (optional).

f. Include all operations/ methods, you may include access modifiers i.e. private, public and

protected if you are able to identify them (optional), You may also include input parameters

and return types for each class if you are able to identify them (optional).

g. Your subset of the class diagram should follow principles of good system and object design

as discussed in lectures and the videos provided. Include any appropriate design patterns e.g. MVC.

Page 3 of 6

SENG2130 PSB 2023T1

5. Sequence Diagrams - (30 Marks)

a. How many are required?

5/6 depending on the number of Use Case Descriptions developed in Group Project 1.

a. Each team member will create a Sequence Diagram for the Use Case Description he/she developed in Group Project 1. It must show the relevant Boundary, Controller and Entity classes from your subset of the Class Diagram (see section 4 above for details).

b. Give a short description for each diagram to briefly explain the interactions among the models to perform the use case.

6. User Interface (10 Marks)

a. How many are required?

5/6 depending on the number of Use Case Descriptions developed in Group Project 1.

b. Each team member will develop a user interface (i.e. screen design) using your use case

description, subset of the class diagram and sequence diagram (section 5) as the basis of

your interface (The logon interface is not to be modelled).

c. You may wish to use the tool from Justinmind.com for the user interface design

development.

d. Each interface must be consistent in appearance and visual style for the team.

e. Consider each user of your interface, considering accessibility and ease of use.

f. The use of a navigation process between each team members interface is important

7. Deployment (5 Marks)

a. What is your team proposing for a deployment strategy? How will you address issues in data migration from the old system to the new system? How will you handle user training? How does your chosen strategy address the potential for system faults and bugs?

b. Will you use a direct, pilot, parallel, or phased deployment? Justify your choice in comparison to the alternatives. What are some potential disadvantages to your choice and how will these be mitigated?

c. Have a look at the 14-2-Deployment.mp4 video link.

d. Give an example (with references) of a real-world situation where a similar strategy was

used to support your argument.

8. Team Management (15 Marks)

a. Meeting notes for at least 5 meetings

b. MS Teams activity report

c. MS Gantt Chart

i. your team will continue to refine your existing chart and show who has done what and the percentage completed for each task

ii. This part of your assessment will be utilised if there is any issue with team management of production and team submission. Makes sure you keep copies of your individual work

9. Conclusion (2.5 Marks)

a. What was completed

b. What was not completed and why

c. How did each section of the report achieve the report objectives?

Page 4 of 6

SENG2130 PSB 2023T1

d. What are your recommendations for the client?

e. https://www.monash.edu/rlo/assignment-samples/engineering/eng-writing-

technicalreports/conclusions-and-recommendations

10. Reference list (including but not limited to, any references used for the introduction and business rules sections in particular)

Total 100 marks Final mark out of 30.

Handing in your work

You are to hand in the assignment electronically using Canvas’s Assignment facility.

When you are ready to submit your code file, log in to Canvas, go to the site for this course, and follow these steps . . .

• Select the Modules folder.

• Click the Group Project 2 link, which will take you to the appropriate upload page.

• Click or drag file as below. Then hit Submit Assignment.

• If you wish to see if the correct file has been uploaded then just click the download icon as below.

• If you want to submit an updated version of the assignment, go back to the Assignment link and click Try Again.

    Page 5 of 6

SENG2130 PSB 2023T1

   Click to download submission

      teamName.zip

• Make sure you’re aware of the deadline: the final marking will be applied only to the most recent

submission, and if it’s submitted late it will be marked as late.

You might be required to demonstrate your program, and to explain aspects of your code, in a subsequent computer lab class. If required, your lecturer will notify you of this process.

Deadline and consequences for late submission

Check due date of submission in Canvas. Work will be penalised 10% for every day or part day by which it is late.

Any request for late submission must follow the formal process for applying for adverse circumstances. Remember to include appropriate documentation with this application. This request may or may not be granted as considered appropriate. Please check your course outline for more information on Adverse Circumstances.

  Page 6 of 6