1. 需求分析
1.1 明确需求
需求分析就是需求分析师对用户期望的软件行为进行表述，并进⼀步⽤对象或实体的状态、属性和行为来定义需求。具体可分为以下四类：
- 功能要求：根据要求的活动描述要求的行为
- 质量要求或非功能要求：描述软件必须具备的一些质量特征
- 设计约束：设计决策，例如平台或接口组件的选择过程约束：对软件的约束可用于构建系统的技术或资源
- 过程约束：对软件的约束可用于构建系统的技术或资源
交互式多媒体图书平台的需求如下：
- 交互式多媒体图书平台包括读者端和作者端；
- 作者可以编排图书的目录结构、章节内容，章节内容中包括图片、视频、文字、和集成第三方软件边学边练，能定义常见练习题比如问答题、选择题；作者编辑时可以预览读者端的效果，手机效果、Web和桌面软件效果，作者可以限制只在某一种或几种终端上使用。
- 读者端可以通过手机、浏览器或桌面软件使用交互式多媒体图书，可以搜索图书，查看图书目录，根据作者设定可以顺序解锁阅读，或随意跳跃阅读，或部分章节内部必须顺序阅读。
- 软件能集成或调用第三方软件，比如阅读过程中能直接调出vscode或linux shell等第三方软件进行实际操作，并对操作做基本正误判断，然后回到图书继续阅读。调出第三方软件应该通过统一的插件模型调用，第三方软件与图书之间的相互转换要自动流畅完成，不需要读者操作。
- 读者端的手机App、Web或桌面软件使用统一的代码实现，优先考虑前后端为js+nodejs+mongodb；作者端独立部署，只有在作者发布图书时才将数据导入到读者端系统，以避免作者端的操作对读者端系统的影响。
- 以上需求的不足可以适当补充和调整。
对上面的所有需求进行分类并补充入下列子标题所示。
1.2 功能需求(Functional Requirement)
- 交互式多媒体图书平台包括读者端和作者端
- 作者可以编排图书的目录结构、章节内容，章节内容中包括图片、视频、文字、和集成第三方软件边学边练，能定义常见练习题比如问答题、选择题
- 作者编辑时可以预览读者端的效果，手机效果、Web和桌面软件效果
- 作者可以限制只在某一种或几种终端上使用
- 读者端可以通过手机、浏览器或桌面软件使用交互式多媒体图书，可以搜索图书，查看图书目录，根据作者设定可以顺序解锁阅读，或随意跳跃阅读，或部分章节内部必须顺序阅读
- 软件能集成或调用第三方软件，比如阅读过程中能直接调出vscode或linux shell等第三方软件进行实际操作，并对操作做基本正误判断，然后回到图书继续阅读
1.3 质量需求(Quality Requirement)
正确性（Correctness）：系统满足用户目标的程度，即在预定环境下能正确地完成预期功能的程度
健壮性（Robustness）：在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程度
效率（Efficiency）：调用第三方软件相应时间不超过1s
可用性（Usability）：第三方软件与图书之间的相互转换要自动流畅完成，不需要读者操作
可理解性（Comprehensibility）：配置用户使用手册，系统界面简洁易用，第三方软件与图书之间的相互转换要自动流畅完成，不需要读者操作
可维修性（Maintainability）：诊断和改正在运行现场发现的错误所需要的工作量的大小
可再用性（Reusability）：调出第三方软件应该通过统一的插件模型调用
1.4 设计约束(Design Constraint)
- 读者端的手机App、Web或桌面软件使用统一的代码实现
- 优先考虑前后端为js+nodejs+mongodb
- 作者端独立部署，只有在作者发布图书时才将数据导入到读者端系统，以避免作者端的操作对读者端系统的影响
1.5 过程约束(Process Constraint)
使用迭代增量式开发过程模型，每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代。每一次迭代都包括了需求分析、设计、实现与测试。测试和开发并行，再通过客户的反馈来细化需求，并开始新一轮的迭代。（下图参考自百度百科。）
