代做data编程、代写Python/Java程序语言

日期：2024-05-04 01:27

University of Technology Sydney, FEIT – Assessment 1 Page 1

Assessment 1 – Part 1: Requirements Analysis

Due date: Friday April 05, 2024, by 11:59 PM

Weight: 15 out of total assessment 1 weight 70

Project: Case-study requirements analysis and software design

Collaboration: Group of three. Group and individually assessed.

1- Project Brief

A local university wants to develop a new interactive system. The university wants to allow

students to self-enrol into a semester subjects. The students would need to register in the new

application before they can access the system and enrol in subjects. A student can enrol in subjects

between 1 and 4. The enrolment is only for one semester at the time. Hence, choice of multiple

semester enrolment is outside the application scope.

Students must register first (using valid email and password). A student must enter their name,

email, and password into the registration form. On sign up, a unique student ID will be auto

generated for each student. The student unique ID is between 1 and 999999. If the size of the

generated ID is not 6-digits, then the ID should be pre-fixed with zeroes to complete 6-digits size

(e.g., 002340 is a valid ID. 2345 is not a valid ID). Registered students’ data should be saved into a

file data store “students.data”.

Students’ emails should have the extension “@university.com”. The students’ emails and the

password should be validated against existing patterns, for example:

Student email: firstname.lastname@university.com is a valid email.

Student email: firstname.lastname@university is not a valid email.

Student password is considered valid if it matches the following pattern:

- Starts with upper-case character.

- Minimum 5 letters

- Followed by 3 of more digits.

Registered students can then login into the application and perform the following operations: (i)

enrol into a subject, (ii) remove a subject from enrolment list, (iii) show current enrolment list, (iv)

change their password. Students enrolling into subject do not need to select a subject to enrol into

(to simplify the application). Once a student selects the enrol command a new subject will be

added to their enrolment list. The enrolment system will keep track of the subjects in the student’s

list and will notify the student if the subject count exceeds 4.

Subjects should be available for students on enrolment. When a student selects the enrolment

command/action, a new subject will be added to their enrolment list (given the list has less than 4

subjects). A subject is identified by a unique 3-digits auto-generated ID (1 <= ID <= 999).

On enrolment, a random subject mark (between 25 and 100) will be autogenerated and allocated

for the subject. Then the subject grade will be auto calculated based on the mark. Refer to UTS

grading system (mark < 50 à Z; 50 <= mark < 65 à P; 65 <= mark < 75 à C; 75 <= mark < 85

à D; mark >= 85 à HD).

University of Technology Sydney, FEIT – Assessment 1 Page 2

Registered students and their enrolment data should be saved into a file data store “students.data”.

The data store file “students.data” should also be available to Admins to perform students’

management operations with the students’ data.

Admins are existing university staff (do not require registration). Admins have their own subsystem within the new application to perform student management operations. Admins can view all

registered students. Admins can organize and view students by grade. Admins can partition and

view students based on PASS/FAIL categories (using the students grades and marks). Admins can

remove a student or clear the entire students.data file store.

The university is requesting a CLI application students and admins actions. The university is also

requesting a GUI component (at smaller scale).

The university CLI interactive system is called “CLIUniApp”. The system should offer access to

two interactive sub-system menus for students and admins. CLIUniApp stores students’ data into a

local file “students.data”. All CLIUniApp CRUD operations should be operated with the storage

file “students.data”.

The case study GUI software implementation is a challenge task of Part 2. The GUI application is

called “GUIUniApp”. The GUI application is a prototype designed only for students to simplify

the implementation. GUIUniApp should allow students to login into the system. The login window

is the GUI main window. Once a student logs in correctly they can enrol into subjects (4 subjects

maximum). Every time a student is enrolled in a subject, the subject is added to the subject menu

enrolment list. Handle possible exceptions for empty login fields and for enrolment in more than 4

subjects.

In the GUI application, assume that the students are already registered (create and add few student

accounts to the application for testing). In GUIUniApp, the rules for student enrolment into a

subject are the same rules as CLIUniApp. There is no need to store students’ data into a file when

using GUIUniApp.

You team is expected to develop the application in two parts, Part 1 and Part2, then demonstrate

the result to the stakeholders in Part 3.

In Part 1, your team is expected to complete and deliver a comprehensive software requirements

analysis report which include: (i) Transform the requirements into user-stories and map the userstories to a requirements table (or backlog); (ii) Create a UML use-case diagram and explain in

details the goals, actors, cases their relationships in the diagram; (iii) Create a UML class-diagram

and explain in details the classes, their properties and their relationships.

In Part 2, your team is expected to develop and implement the university application following Part

1 design. The university application is composed of CLIUniApp and GUIUniApp (challenge task).

The application should be submitted by the due date and demonstrated in Part 3.

Part 3 is the assessment formal showcase. Each team will present their Part 2 working application

based on their collaborative Part 1 design. Team members must equally participate and collaborate

in all assessment parts.

University of Technology Sydney, FEIT – Assessment 1 Page 3

2- User-Story Table (Backlog)

Your team is expected to read thoroughly the customer (university) requirements and transform the

requirements into user-story. The user-story should be simple so that each story is later translated

into a function (or action). Each story will have a unique 3-digits ID. If a group of stories related to

the same features, then the hundreds (number) will match for all those stories. For example:

Consider the Login feature. All the following stories are related to the same Login feature. Hence

their ID should start with the same hundreds number.

Story: match username and password with the ones on file à 101

Story: verify username and password against patterns à 105

Story: show error message if credentials do not match à 106

Story: take student to student sub-menu if credentials are correct à 100

The refined user-stories should be mapped into a requirements table (or backlog). The table is

formatted as follows:

ID User Action Result Function

A unique 3 digits

user story ID.

The person or

entity taking the

action

The action taken

by the user

The result or

outcome of the

action

The action name

3- UML Use-Case Diagram

Your team is expected to develop a comprehensive UML use-case diagram. To successfully

develop the diagram, identify the actors, the goals, the case, and their relationships. Provide

explanation for each actor, goal, case, relationship. Ensure that your diagram is consistent and align

with the provided explanations about all involved entities.

4- UML Class Diagram

Your team is expected to develop a comprehensive UML class diagram. To successfully develop

the diagram, identify the classes, fields, methods, visibility, multiplicity, and their relationships.

Provide explanation for each actor, goal, case, relationship. Ensure that your diagram is consistent

and align with the provided explanations about all involved entities.

5- Marking Scheme

Total assessment Part 1 mark is 15/70. All team members are expected to equally contribute

to the development of the project (all parts).

a. User-Story Table (5 Marks)

University of Technology Sydney, FEIT – Assessment 1 Page 4

Entity Criteria Mark

User stories are specific User stories are decomposed into simple story = action 2

User stories consistency User stories align with the project requirements 2

Backlog correctness User stories are correctly mapped into the backlog 1

b. Use-case Diagram (5 Marks)

Entity Criteria Mark

Entities identification Goals, cases, actors, relationships correctly identified 1

Entities description Entities are correctly explained and reported 1

Actors action Actors initiate accurate cases 1

Case relationships Accurate and consistent cases relationship 1

Labelling Use of correct relationship labelling 1

c. Class Diagram (5 Marks)

Entity Criteria Mark

Class Class properly identified and explained 1

Fields Properly identified. Accurate visibility choice 1

Methods Correct method naming, type, visibility 1

Relationships Consistent class relationships 1

Multiplicity Accurate relationship multiplicities 1

6- Deliverables and Contribution

The assessment requires collaboration and equal amount of contribution between all group

members. The individual student contributions or parts will be collated in a group deliverable for

submission and assessment (group submission but individual assessment). The deliverables of this

assessment task also include a compulsory oral/visual presentation (no PowerPoint slides) of the

individually implemented working software application during the scheduled assignment

assessment or review session (showcase).

The submitted “case study software” CLI or GUI must fully work before marks can be awarded.

CLI (and GUI) applications can be in the same project folder and submitted in the same ZIP file (if

your team chose to complete the GUI challenge task.

7- Assessment Submission

Submit assessment 1 part 1 (single submission only / per group) as a PDF.

Assessment file name: (group<group-number>-Cmp<lab-number>.pdf) to

Canvas/Assignments/Task1/Part1.

Submit your assessment PDF file by the due date: Friday 05/04/2024 by 11:59 PM

University of Technology Sydney, FEIT – Assessment 1 Page 5

8- Special Consideration

Special consideration, for late submission, must be arranged beforehand with the subject coordinator (email: yining.hu@uts.edu.au). Please also see the UTS Special Consideration Process:

www.sau.uts.edu.au/assessment/consideration

9- Late Penalty

See subject outline for late submission penalty unless an extension has been approved by the

subject coordinator.

10- Assessment Misconduct

Please see the subject outline for plagiarism and academic integrity in conjunction with UTS policy

and procedures for the assessment for coursework subjects.