这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
需求分析的原理和目标
- 在需求阶段，软件工程师的主要关注点在做什么，而不是怎么做。是问题定义阶段。 有哪些用户交互？ 系统处理什么对象？对象之间有什么关系？ 系统必须执行什么功能？（提供什么服务？） 系统展示什么行为？ 定义什么接口？ 有什么约束？
- 需求模型要实现三个目标： 描述客户需要什么？（问题定义，需求确认） 为软件设计奠定基础？（设计和实现） 定义在软件完成后可以被确认的一组需求？（测试和验收）
需求建模：基于场景的方法
使用UML进行需求建模是从场景建模开始的，即从开发用例、活动图和泳道图形式的场景开始。用例（场景模型）是用户最容易理解的。
开发用例
用例一般表示为用例图和用例描述，辅助以活动图
参与者执行的首要任务或功能是什么？
- 参与者需要获取、生成或改变哪些系统信息？
- 参与者是否需要通知系统外部环境的变化？
- 参与者希望从系统中获取何种信息？
- 参与者是否想了解意料之外的变化？
需求建模：基于类的方法
- 类模型定义了：
- 系统操作的对象
- 应用于对象的操作（也称为方法或服务）
- 对象间的关系（某种层级）
- 已定义类之间的协作
- 基于类的分析模型的元素包括：
- 类和对象
- 属性和操作
- 类的职责协作者(CRC)模型
- 协作图
- 包
- 分析类的表现方式
- 外部实体（例如，其他系统、设备、人员），产生或使用基于计算机系统的信息。
- 事物（例如，报告、显示、信件、信号），问题信息域的一部分。
- 偶发事件或事件（例如，所有权发生转移、或完成了机器人的一组移动动作），在系统操作环境内发生。
- 角色（例如：经理、工程师、销售人员），由和系统交互的人员扮演。
- 组织单元（例如，部门、组、团队），和某个应用系统相关。
- 场地（例如：制造车间或码头），建立问题和系统整体功能的上下文环境。
- 结构（例如：传感器、四轮交通工具、计算机），定义了对象的类或与对象相关的类
- 类模型类应满足的特征
- 保留信息。只有记录该潜在类的信息才能保证系统正常工作，它在分析过程中才是有用的。
- 所需服务。潜在类必须具有一组可确认的操作，这组操作能用某种方式改变类的属性值。
- 多个属性。在需求分析过程中，焦点应在于“主”信息；事实上，只有一个属性的类可能在设计中有用，但是在分析活动阶段，最好把它作为另一个类的某个属性。
- 公共属性。可以为潜在类定义一组属性，这些属性适用于类的所有实例。
- 公共操作。可以为潜在类定义一组操作，这些操作适用于类的所有实例。
- 必要需求。在问题空间中出现的外部实体，和任何系统解决方案运行时所必需的生产或消费信息，几乎都被定义为需求模型中的类。
