软件需求

软件需求重点

1．需求的层次

1) 业务需求：表示组织或客户高层次的目标。描述了组织希望达到的目标，用前景和范围文档来 记录

2) 用户需求：用户的目标或者用户要求系统必须完成的任务。描述了用户能使用系统来做些什么， 用用例、场景描述和事件-响应表来表达。

3) 功能需求（行为需求）：规定开发人员必须在产品中实现的软件功能，用户利用这些软件功能来 完成任务，满足业务需求。描述了开发人员应该（需要）实现什么，用SRS（软件需求规格说明书）来记录。

4). 非功能性需求：性能指标和质量属性、系统和外部世界的界面、设计和实现的约束；

2、糟糕需求的由来：

1) 用户参与不足： 2) 用户需求扩展： 3) 有歧义的需求： 4) 镀金问题

5) 过于抽象的需求 6) 忽略某类用户 7) 不准确的计划

3、优秀需求的特点：

（1）需求陈述的特点：1.完整性 2.正确性 3.可行性 4.必要性 5.有优先次序

1 / 15

6.无歧义 7.可验证性

（2）需求规格说明的特点：1.完整性 2.一致性 3.可修改性 4.可跟踪性

4.客户的权利和义务

权利：

1) 要求需求分析员使用客户语言

2) 要求需求分析员理解用户的业务和目标

3) 要求需求分析员编写软件需求规格说明（srs）

4) 听取对需求工作成果的解释

5) 得到需求分析员和开发人员的尊重

6) 听取开发人员对于需求及如何实现需求的想法和备用方案

7) 描述使产品易于使用的特性

8) 为实现重用而对需求做出调整

9) 获得对变更成本的真实估算

2 / 15

10) 得到满足功能和质量需求的系统

义务 ：

1) 为需求人员和开发人员讲解业务

2) 花时间提供并阐明需求

3) 对需求的说明必须具体和准确

4) 及时做出决定

5) 尊重开发人员对成本和可行性的评估

6) 为需求设置优先级

7) 审阅需求文档，评估原型

8) 将需求变更及时告知开发人员

9) 遵循开发组织的变更过程

10) 尊重需求分析员使用的需求工程方法

5签字的含义：

3 / 15

签字作为项目的一个里程碑，是建立需求协议的基线，即某一时刻需求的瞬态图。

6.前景和范围

前景：将所有涉众统一到一个方向上。描述了产品用来干什么，它最终是什么样子，关系到整个产品，定义了产品的战略定位和业务目标。

范围：确定当前项目要解决产品长远规划中的哪部分，为需求是否属于项目划定了界线，定义了项目的限制，体现于开发团队对项目定义的需求基线。只与一个特定 的项目或实现产品功能下一次增量的某次迭代相关 。

项目范围（ppt）：确定当前的项目要解决产品长远规划中哪一部分。范围同时定义了项目的限制。对范围的描述确立了正在开发的系统与周围所有事物之间的界限和联系。

7、前景与范围文档

详见P53.

前景与范围文档用于将业务需求收集整理到一个文档中，为后续的开发工作打好基础。

模板：P54.

涉众：指积极参与项目、受项目结果影响，或者能够影响项目结果的个人、团体或组织。

项目优先级：考虑5个方面：特性、质量、成本、进度和人员。

4 / 15

8、关联图 P59.

9、需求的来源：

1) 与潜在用户进行交谈和讨论 2) 描述现有产品或竞争产品的文档 3) 系统需求规格说明

4) 现有系统的问题报告和改进要求 5) 市场调查和用户问卷调查 6) 观察用户如何工作 7) 用户工作的情景分析 8) 事件和响应

10.寻找用户代表

用户代表应当自始至终参与项目的整个开发过程，而不是仅参与最初的需求阶段。

11、用户代言人应避免的陷阱

（1）一个合格的用户代言人根据授权做出的决定却被经理推翻。

（2）用户代言人如果忘了自己应代表其他客户，而只表达出自己的需求，那么他的工作肯定做不好。

（3）用户代言人如果缺乏对新系统的充分了解，就可能在重要问题上听从需求分析员的决定。

（4）资深用户可能因为自己没有时间而推荐缺少经验的用户担任代言人。

5 / 15

（5）谨防用户试图代表他们不属于的用户代表发表意见。

12、将用户的意见归类

（1）业务需求 （2）用例或场景 （3）业务规则 （4）功能性需求 （5）质量属性

（6）外部接口需求 （7）约束 （8）数据定义 （9）解决思路

13、需求获取中的注意事项 P83

14.如何获取遗漏的需求：

1) 将高层次的需求分解得足够细，让用户真正的需求显露出来，避免使用不精确和模糊的词语

2) 务必让所有的用户类都提出他们的意见，确保每个用例都至少有一个确定的执行者

3) 跟踪系统需求、用例、事件—响应表以及业务规则，直至其详细的功能性需求，确保需求分析员推导出了所有必需的功能

4) 检查边界值，查找被遗漏的需求

5) 用多种方法表达需求信息

6) 包括复杂的布尔逻辑（与、或、非）的需求集常常是不完整的。用判定表或判定树

6 / 15

来表达复杂逻辑就能保证覆盖所有可能情况。

精确的找遗漏需求的方法：CRUDL矩阵（创建、读取、修改、删除、列表）

表格的最左边一列列出用例，其他列代表数据实体。观察5个字母是否有哪一个在同一列的所有单元格中没有出现，可能就存在需求的遗漏（结合P85的例子）

15、如何判断需求获取是否已完成

（1）用户想不出更多的用例

（2）若用户提出新的用例，而你已经从其他用例中推导出这一用例的相关功能性需求

（3）用户只是重复他们在以前的讨论中已经提到过的问题

（4）被提出的新特性、用户需求或功能性需求都在范围之外

（5）被提出的新需求优先级都很低

（6）用户提出的新功能都是可以“在产品生命周期的某个时刻”加入，而不是“属于我们当前正在讨论的特定产品”。

16、用例的描述（会画用例图）：

1)惟一的标识（UserID）2)一个用例名（动词+对象）3)用自然语言书写的简短的文字描述

7 / 15

4)前置条件5)后置条件6)一组带编号的步骤，系统与角色之间的一系列会话步骤与交互

17、事件响应表 P101

18、编写需求文档的原则、 改进前后的需求事例 P123_128

19、实体关系图（ERD） P137

20、状态转换图

可以简洁、完整、无歧义的表示有限状态机。

包括3种元素：

1.可能的系统状态（矩形框） 2.允许的状态改变或迁移（箭头连接一对矩形框）

3.引起每个状态转换的事件或条件，在每个迁移箭头上用文本标签表示。

实时系统的状态转换图包括一个特殊的状态：“空闲”状态（当系统不再执行其他处理时，都会返回此空闲状态）。

21、对话图 P142 对用户界面进行建模。

22、判定树和判定表 P146—148

8 / 15

判定表：可列出影响系统行为的所有因素的各种取值，并表明对这些因素的每一种组合所期望的系统响应动作。

23、质量属性

对用户重要的属性：

可用性、有效性、灵活性）、完整性、互操作性、可靠性、健壮性、易用性。

对开发人员重要的属性：

可维护性、可移植性、可重用性、可测试性。

24、原型 P162

原型：是所提议的新产品的部分实现或可能的实现。

目的：明确并完善需求、研究设计选择方案、发展为最终产品

建立原型的主要原因：为了产品开发早期阶段不能确定的一些问题，以及发现并解决需求二异性和不完整性

各种类型的原型：P163-168 原型的评估、风险、成功因素：P168-170

25、需求优先级 P172

9 / 15

26、变更需要付出代价：影响分析 P242

27、需求链中的联系链 P247

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

2．.软件需求的定义：（IEEE的标准术语表中）

1) 用户为解决某个问题或达到某个目标而需具备的条件或能力。

2) 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。

3) 上述第一项或第二项中定义的条件或能力的文档表达。

3．软件需求工程分为需求开发和需求管理。

（1）需求开发：获取、分析、编写规约、确认 包括的活动：

1) 确定产品将要面对的各类用户

2) 从各类用户的代表处收集需求

3) 了解用户的任务和目标，以及这些任务要实现的业务目标

10 / 15

4) 分析从用户处得到的信息，将用户的任务目标与功能需求、功能性需求、业务规则、解决方案 建议以及其他无关信息区分开来

5) 将顶层的需求分配到系统构架内定义好的软件组件中

6) 了解各质量属性的相对重要性

7) 协商需求的实现优先级

8) 将收集的用户需求表述为书面的需求规格说明书和模型

9) 审阅需求文档，以确保在认识上与用户声明的需求相一致，硬挨开发小组接受需求之前解决所 有的分歧

（2） 需求管理：变更控制、版本控制、需求状态跟踪、需求跟踪

1) 定义需求基线

2) 审查需求变更请求，评估其可能产生的影响以决定是否批准

3) 以可控制的方式将准的需求变更融入项目中

4) 保持项目计划与需求的同步

5) 估计需求变更的影响，在此基础上协商新的需求约定

11 / 15

6) 跟踪每项需求，找到与其对应的设计、源代码和测试用例。

7) 在项目开发过程中，始终跟踪需求的状态和变更。

8.需求分析员：

（1）定义：是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。是客户和软件开发团队间进行需求沟通的桥梁。

（2）需求分析员的职责：

1) 定义业务需求 2) 确定项目涉众和用户类别 3) 获取需求 4) 分析需求 5) 编写需求规格说明 6) 为需求建模 7) 主持对需求的验证 8) 引导对需求的优先级划分 9) 管理需求

9.需求分析员必备的技能：

1) 倾听的技巧 2) 交谈和提问的技巧 3) 分析能力 4) 协调能力 5) 观察能力 6) 写作能力 7) 组织能力 8) 建模能力 9) 人际交往能力 10) 创造力

10.需求分析员必备的知识：

1) 对当代需求管理技术的深刻理解。 2) 在各种不同软件开发生命周期环境中应用相关技术的能力。 3) 将需求开发和管理活动贯穿于整个产品生命期中。 4) 掌握应用领域知识。

13.需求工程的核心任务：需求获取，即确定软件系统涉众的需要及限制条件的过程。

12 / 15

需求获取着重于发现用户需求

14.需求获取的常用方法：面谈法（讨论会）

在开始需求获取时，邀请一为协调人来负责最初的讨论会，另外记录员要协助协调人记录讨论的内容要点。

15.用例法：需求分析员用使用场景来获取需求。场景是对系统的单个使用用例的描述，这种以场景为中心的方法归纳为用例法

16.角色：指与系统交互以实现某种目的的人、软件系统或硬件设备。

17. 用例的本质：用例就是由使用者(actor)驱动的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。 在RUP中，一个用例就是一个需求单元，分析单元，设计单元，开发单元，测试单元，甚至部署单元。

18. 如何确定用例：

1) 明确有哪些角色，然后确定这些角色各自参与了哪些业务规则（常用）

2) 确定哪些外部事件是系统必须响应的，将他们与参与的角色和特定用例关联起来 3) 用特定场景描述业务过程，将这些场景归纳为用例，并确定每项用例涉及哪些角色 4) 从已有的功能性需求推导出可能的用例

19. 业务规则的定义：

13 / 15

业务规则是对业务的某个方面进行定义或约束的语句。用于声明业务结构，或者控制、影响业务的行为。

业务规则分类：（会判断，注意例子）

1) 事实：对业务的真实描述，常描述重要业务术语间的关联，是关于数据实体及其属性的不可改变的真实情况

2) 约束：限制了系统或它的用户可以执行哪些操作，必须、可以、不可以、只有、最多等词语可以描述一项约束

3) 动作触发规则：在特定条件下触发某个动作的规则，可能由人手工执行或这条规则引出对某项功能性需求的定义，使软件在指定条件为真时表现出正确的行为。如果„„则（发生某事-动作）暗示这是一条动作触发规则

4) 计算：定义使用特定数学公式或者算法进行计算的业务规则

5) 推论：根据某个条件的真实性得出某些新事实的规则。常用如果/则句式表达，与动作触发类规则的区别在于推论的“则”子句表达的是一个事实或者一条信息，而非动作。

6) 术语

20. 需求规格说明书包括的内容：

1) 引言：目标、文档约定、读者对象和阅读建议、项目范围、参考资料

14 / 15

2) 总体描述：产品前景、产品特性、用户类及其特征、运行环境、设计和实现上的约束、用户文档、假设和依赖

3) 系统特性：描述和优先级、激励/响应序列、功能性需求 4) 外部接口需求：用户界面、硬件接口、软件接口、通信接口

5) 其他非功能性需求：性能需求、防护性需求、安全性需求、软件质量属性 6) 其他需求

7) 附录：术语表、分析模型（数据流图、类图、状态转换图、E-R图）、待确定问题的清单

判定树和判定表等

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

15 / 15