软件设计与开发：从需求到可靠服务

“做一个好用的预约系统”怎样变成开发人员能实现、测试人员能检查的要求？

功能需求描述行为，如查询余位、提交预约；非功能需求描述质量或约束，如响应时间、可访问性、隐私。需求应包含角色、触发、输入、成功结果和异常。模块化分解职责，高内聚表示相关任务集中，低耦合表示依赖尽量清楚且有限。接口是模块之间的约定，含参数、返回、错误、权限与副作用，不只是页面按钮。

结构化方法按功能与数据流逐层分解；面向对象用对象的状态与行为组织，类描述一类对象，封装约束内部状态，继承表达合适的类型关系，多态让同一接口对应不同实现。两者可组合，不能把“用了类”当成设计质量证明。

把“预约成功”写成验收条件：已登录且有空位时提交；并发请求不能超过容量；重复提交返回同一结果或被安全拒绝；无空位返回可理解提示；失败不扣名额。再把界面、预约规则、存储分离，接口明确谁验证何种条件。

先独立作答；卡住时看提示，完成后再对照解析。

一个方案到最后才让用户看，发现方向错了怎么办？

瀑布强调阶段交付，适用于需求和约束较稳定的情况，但变更反馈可能较晚；迭代增量用较小可验证版本持续学习；原型用低成本表示验证不确定性，不能把演示流畅等同于可上线。测试包括单元、集成、系统、验收；黑盒从规格选输入，白盒从内部控制路径考虑覆盖。测试发现缺陷，不证明所有输入都正确。

维护有纠错、适应环境、完善能力和预防问题等动机；版本控制、自动回归、日志和可回滚发布降低变更风险。质量还包括可用性、安全、性能与可维护性。

对允许年龄18至60的输入：等价类有小于18、18—60、大于60、非数字；边界至少17、18、19、59、60、61，另测空输入。需求若允许小数或缺省必须明确。修复后先复现旧失败，再验证修复并跑相关回归。

先独立作答；卡住时看提示，完成后再对照解析。

手机上按“提交”，数据是直接写进远处数据库的吗？

典型应用由客户端界面、服务端业务与数据层构成。客户端通过HTTP等协议请求API，服务端校验身份和输入、执行业务、访问数据库并返回结果。API是程序接口，不必等于可见网页。网络可能超时、重复、断开，因此设计需处理重试与幂等；幂等指重复同一操作不会造成额外效果。

缓存保存可复用结果，降低延迟但可能陈旧；身份认证确认是谁，授权确认允许做什么。客户端隐藏按钮不是服务端权限检查。隐私设计先问数据是否必要，再安排告知、最小访问、保留期限与删除机制。本节解释应用架构，不扩成408网络课程。

画“用户→客户端→API→业务规则→数据库→响应”六步，并标出失败分支。预约请求附稳定请求标识，服务端把去重记录和预约写入作为一致操作，网络重发不会再扣一次名额。

先独立作答；卡住时看提示，完成后再对照解析。