Chapter4

1.需求的含义

• 对来自用户的关于软件系统的期望行为的综合描述，设计系统的对象、状态、约束、功能等。

2.确定需求的过程

• 原始需求获取（来自客户）
• 问题分析
• 规格说明草稿
• 需求核准
• 正式需求文档的输出

3.举例说明获取需求时考虑到优先级的需求分类及相互关系

• 1.绝对满足的需求
• 2.想要但并非必须的需求（用户热切希望但是不是必须的需求）
• 3.可要可不要的需求（技术有可能实现但必须去除的需求）

例子：

• 给定某个日期银行信用卡付账系统必须列出最近的费用，将它们加起来并要求进行支付，这是第一种需求；
• 但是也可能将费用和购买方式分开，以助于想飞这理解购买的模式，这种需求属于第二种；
• 最后，打印账单的字体需求是第三种需求
• 注：当软件项目受到时间或资源限制时，这种做法很有用：如果这样定义系统的成本太高或者开发的时间很长，就可以不再讨论第三种需求，分析师排除还是延期考虑第二种需求

4.如何使需求变得可测试

针对需求确定一种量化的描述方法，避免模糊的表达方式。将各种指代词代替为实体的正式名称。每个名词或款项应该在需求文档中给出唯一的含义。

（尽量以数学或者数学模型刻画需求。需求不是写小说，重名、化名不可以，“这些”、“那些”也不可以）

5.需求文档分类

• 需求定义文档：完整的罗列出用户想让系统做的事情。
• 需求规格说明：用专业术语和记号重述定义，以使设计者可以开始设计。

6.功能性需求和非功能性需求

• 功能性需求：描述系统内部功能或系统与外部环境的交互作用，设计系统输出应对，实体状态变化，输出结果，设计约束与过程约束等。
• 非功能需求：描述软件方案必须具备某些质量特征，如性能、安全性等。

7.需求的特征

正确性、一致性、完整性、无二义性、可行性、相关性、可靠性、可测试性、可跟踪性。

8.在需求原型化方面，什么是抛弃原型？什么是演化型原型？

• 抛弃型：仅用于了解问题，探索可行性，并不打算用来作为将来实际提交系统的一部分，而是用来扔掉。
• 演化型：用于了解问题、并作为将来准备提交系统的一部分

9.了解DFD

• 加工或功能
• 数据流
• 数据输收器、参与者
• 存储

有错误或者遗漏？前往修改