柳阳

越到软件开发后期提出的需求，越是耗费更多的时间才能实现。
虽然不可能在软件开发之初就进行测试，但是可以根据需求开发概念测试用例，并以之反过来检验需求。

需求验证是需求开发的最后一个步骤，需要验证以下内容：
（1）软件需求规格说明的描述是否正确
（2）从系统需求或其他方面获取需求
（3）需求完整、高质量、理解一致
（4）需求可以为后续开发提供足够的基础

需求验证只是针对于那些已经书面化...

      昨天睡觉时换了个方向睡，没睡好，起来的时候喉咙干，有点感冒。抬头看窗外，阴。

      小时候很喜欢阴天，因为如果天气不好的话，妈妈就会早下班，烧很好吃的带鱼。后来工作之后想自己烧来吃，但每次不是烧焦了，就是糊掉，也许只有在阴天里带鱼才是比较听话的吧。大学那段自在的日子里，阴天也曾经是翘课最好的借口，虽然没有带鱼吃，但是可以在床上翻鱼也很惬意，可能正因为这样，才养成...

当客户的期望很高、开发时间短并且资源有限时，优先级必须确定。
当接受一个新的高优先级的需求或者其它变化时，应考虑删除低优先级的需求,或者推迟到下一版本中去实现。
客户和开发者都必须为设定需求的优先级提供信息。
一些低优先级的功能，比如如果影响到系统的结构，就要在项目前期完成。

项目中的不同角色对于优先级的看法是不同的 ... ...

减少用户对产品不满意的风险
原型可以使新产品实在话，为使用实例带来生机，并促进消除期望差异。
原型有很多种，可能只是真实系统的一部分或一个功能，或者根本不是一个可以用的东西。

原型的目的：解决产品早期的不确定性问题
明确并完善需求
探索设计选择方案
发展为最终的产品原型

... ...

非功能性需求：
产品的易用程度如何,执行速度如何,可靠性如何,当发生异常情况时,系统如何处理等。
满足非功能需求往往比满足功能需求更为重要。
质量必须由客户和那些构造测试和维护软件的人员来定义。

虽然质量属性有很多种，但是只要抓住 ... ...

可以弥补文字描述的不全面性。

包括数据流图(DFD)、实体关系图(ERD)、状态转化图(STD)、对话图和类图。

数据流图：适用于事务处理系统或 ... ...

软件开发的最终结果：对于业务需求、用户需求、功能需求达成一致。
项目视图和范围表达了业务需求，
使用实例表达了用户需求，
软件需求规格说明表达了功能和非功能的需求。

规格说明可以用自然语言、图形、数学公式来描述  ... ...

需求获取、分析、编写需求规格说明和验证可以反复进行。
必须透过客户所提出的表面需求理解他们的真正需求。

需求开发方针：
1. 定义项目的视图和范围
2. 确定用户类
3. 在每个用户类中确定适当的代表
4. 确定需求决策者和他们的决策过程
5. 选择你所用的需求获取技术
6. 运用需求获取技术对作为系统一部分的使用实例   ... ...

客户参与是避免期望差异 (expectation gap)的唯一途径。

用户需求的获得需要进行以下工作：
（1）明确项目用户需求的来源。
（2）明确使用该产品的不同类型的用户。
（3）与产品不同用户类的代表进行沟通。
（4）遵从项目的最终决策者的意见。
... ...

属于业务需求，必须在完成之后再开始详细的需求分析。
应该排除那些有碍于项目目标的需求。
项目需要良好的规划和交流途径。

项目视图描述了产品所涉及的各个方面和 ... ...