Assessment 1 - 15% · Jimmy Huang's Blog

作业2025 年 3 月 10 日至 3 月 28 日

Assessment 1 - 15%

本页目录· 17 条

每学期Client’s Requirement应该都会换，考察内容应该大差不差
中文版个人笔记
Client’s Requirement
患者注册与登录
管理员登录
登出
Feature 1：注册与登录（概要）
Feature 2：预约排班与预约（Scheduling & Booking）
Feature 3：患者资料与预约管理（Profile & Appointment Management）
Feature 4：状态仪表盘（报表）
Feature 5：行政管理（Administrative Management）
技术与非功能需求
Assessment 1
Task 1：分析需求，创建用户故事与验收标准（报告）
Task 2：制作数字原型 & 第5周展示
Moodle 提交（文件与命名）
Marking Rubric

每学期Client’s Requirement应该都会换，考察内容应该大差不差

中文版个人笔记

Client’s Requirement

患者注册与登录

仅允许使用 Monash 学生/教职工邮箱注册（如 [email protected] / [email protected]）。
账户字段：唯一邮箱、密码（≥8 位，至少 1 个大写字母 + 1 个数字）、名/姓、出生日期（dd/mm/yyyy）、性别（可选项：Male/Female/Other/Prefer not to say）、澳洲手机号、地址（可选）。
登录：仅支持邮箱+密码（无用户名选项）；当前角色有患者与管理员；不支持访客。

管理员登录

登出

所有用户可随时登出且不丢数据；登出需确保会话结束前安全保存数据。

Feature 1：注册与登录（概要）

覆盖注册、登录、管理员登录、登出四部分（见上）。

Feature 2：预约排班与预约（Scheduling & Booking）

可见排班列表：展示诊所名、GP 名、日期、时间、时长、可用性、就诊原因、状态、诊所郊区（Suburb）；支持按日期/GP/诊所郊区筛选。
预约：可按可用时段或偏好 GP进行预约。
确认与通知：成功预约后向患者确认，包含预约详情、就诊原因、GP 名、诊所地址；预约截止时间为开始前 2 小时。
易用性：预约流程应步骤最少。
冲突检测：防止双重预约/时间重叠。

Feature 3：患者资料与预约管理（Profile & Appointment Management）

编辑资料：可更新姓名/邮箱/电话；保存后需发送确认通知。
查看将来预约：列表至少含 GP 名、日期时间、诊所郊区；点开可看全部细节。
取消预约：
- 免费取消窗口：预约前 24 小时；
- 晚取消（24 小时内）：可能有惩罚（如限制未来预约）；
- 成功取消后需通知患者并回收可用性。
查看历史预约：可查看过往预约详情；每条包含 GP 名、日期、时间、诊所郊区、状态（到诊/患者取消/诊所取消）。
站内信中心（Inbox Centre）：若预约被修改（日期/时间/GP/诊所郊区等），需要清晰说明变更内容并通知患者。

Feature 4：状态仪表盘（报表）

按 GP 的接诊量报告：可选日期范围（日/周/月/自定义）；每位 GP 的条目含 GP 名、诊所郊区、接诊总人数、按预约类型的细分（如普通问诊/转诊/疫苗等）。
按诊所的接诊量报告：可选诊所与日期范围（文档中 “dy” 处疑似 “daily” 的笔误）；包含 诊所名、接诊总人数、各 GP 处理的预约数、按预约类型细分、以及高峰时段分析。
按就诊原因的预约分布：可按日期范围分析；给出总预约数与各原因的百分比分布（如常规体检、疫苗、转诊、慢病管理、心理健康咨询、其他）。
导出：所有报告支持导出 CSV 或文本。

Feature 5：行政管理（Administrative Management）

诊所与 GP 管理：管理员可创建/更新/删除诊所与 GP；
- GP 字段：姓名、邮箱、所属诊所（可多）、专长、可用性（休息日）；
- 可更新诊所信息：诊所名、郊区、可用服务、营业时间；
- 可调整时段与可用性。
容量与可用性管理：可设置/更新每位 GP 的预约名额；可按诊所郊区查看可用性；预约时长可为 15/25/40/60 分钟。
管理员取消预约：可在预约开始前取消，并通知患者。

技术与非功能需求

交付形态：**文本界面（text-based）**应用。
技术栈：Java 17 或 Python 3.11，遵循 OOP。团队需统一选型。
工具建议：IntelliJ（Java）/PyCharm（Python），也可用 VS Code。
数据存储：不允许使用数据库；所有数据存文本或 CSV。不允许外部库或 API。
进度与展示：第 12 周前完成并做最终演示。
代码仓库：托管于 FIT GitLab，结构清晰并附详细 README；需包含真实感的模拟数据。
质量约束：防止重复预约/排班冲突/重复条目；所有输入必须校验并提供清晰友好的报错。

Assessment 1

Task 1：分析需求，创建用户故事与验收标准（报告）

提交 8 条用户故事（User Stories），并为每条配套验收标准（Acceptance Criteria）。可使用作业区提供的模板。
覆盖面要求：应为整个项目撰写更全面的用户故事库（后续 A1–A3 会持续使用并完善），从中挑选 8 条作为 A1 提交，最好每个核心功能 1–2 条。无需做 MoSCoW 或权重排序，挑最有把握的给导师审阅。
验收标准写法：明确**“完成”条件**（Definition of Done 对应到该用户故事的可验证条件）。

Task 2：制作数字原型 & 第5周展示

原型工具：LucidChart。原型需要突出 UX 与事件流程正确性，并显式采用以下两套可用性原则之一：Norman 六原则或 Shneiderman 八原则；在文档/展示中阐明你的原型如何与所选原则对齐。
展示（第5周）：
- ≤10 分钟，建议用 Google Slides；每位组员必须有贡献。如成员缺席，团队仍可展示，但缺席者得分为 0。
- 展示内容应包括：数字原型与高层流程、与客户需求的对齐；选取 3 条用户故事，展示其验收标准与对应 UI；并说明原型如何符合所选可用性原则；幻灯片中应包含 LucidChart 的可分享链接。

Moodle 提交（文件与命名）

由一名组员集中提交，所有文件PDF 格式：
1）签字的 Assessment cover sheet；
2）报告命名：FIT5136_S1_2025_Appliedxx_TeamX_A1-Task1.pdf；
3）演示稿命名：FIT5136_S1_2025_Appliedxx_TeamX_A1-presentation.pdf。

Marking Rubric

A. 评分构成与权重

部分	子部分	细项	权重
1. 用户故事与验收标准	—	—	50%
1.1 用户故事的结构与术语	—	25%
1.2 符合 INVEST 原则	—	未标明
1.3 验收标准的可行性与对齐	—	25%
2. 原型与展示	—	—	50%
2.1 原型	—	40%
2.1.1 用户体验（事件流）	15%
2.1.2 UI 内容（数据/菜单/布局）	10%
2.1.3 与需求对齐（内容相关性）	15%
2.2 展示	—	10%
2.2.1 幻灯/展示清晰度与质量	3%
2.2.2 演示者对项目的理解	4%
2.2.3 可用性设计原则的应用	3%

B. 各细项的等级标准（摘要）

细项	不及格（0–50）	及格（50–60）	良好（60–70）	优秀（70–80）	卓越（80–100）
1.1 结构与术语	全部不正确	少量正确	部分正确	大多数正确	全部正确
1.2 INVEST	均不符合	少量符合	部分符合	大多数符合	全部准确、合逻辑并遵循 INVEST
1.3 验收标准对齐/可行	多数不对齐，表述含糊不可执行	部分对齐，多数不现实	大多对齐，部分清晰但欠现实	全部对齐，多数现实且给出步骤	全部严密对齐、现实，步骤清晰完整
2.1.1 用户体验（事件流）	流程含糊/无导航	有基础流程但大多含糊	基本主流程，仍有含糊处	流程良好，少量含糊	事件流优秀
2.1.2 UI 内容	与项目无关	有基础样例数据与可理解菜单	一般样例数据与可理解菜单	良好样例数据与易懂菜单	样例数据与菜单无歧义、布局得当不杂乱
2.1.3 与需求对齐	内容与项目无关	少量内容相关	部分内容相关	大多内容相关	全部内容相关
2.2.1 幻灯/展示质量	结构不清，难以理解	小部分结构清晰、兼顾可访问性	部分结构清晰、较易理解	大多结构清晰、易理解	全部结构清晰、可访问性佳、易于理解
2.2.2 演示者理解	理解差	理解够用	理解较高	几乎完全理解，少量小错	完全理解，无错误
2.2.3 可用性原则	未考虑	最少量使用	有一定使用	证据充分但仍可改善	证据充分地应用一套原则