软件需求重点

软件需求重点1．涉众：客户、用户（客户的一部分）、需求分析员、开发人员、测试人员、文档编制人员、项目经理、法律人员、生产人员、市场营销、技术支持及其他与产品和客户打交道的人员2．.软件需求的定义：（IEEE的标准术语表中）1)用户为解决某个问题或达到某个目标而需具备的条件或能力。

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

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

3．需求的层次1)业务需求：表示组织或客户高层次的目标。

描述了组织希望达到的目标，用前景和范围文档来记录2)用户需求：用户的目标或者用户要求系统必须完成的任务。

描述了用户能使用系统来做些什么，用用例、场景描述和事件-响应表来表达。

3)功能需求（行为需求）：规定开发人员必须在产品中实现的软件功能，用户利用这些软件功能来完成任务，满足业务需求。

描述了开发人员应该（需要）实现什么，用SRS（软件需求规格说明书）来记录。

4). 非功能性需求：性能指标和质量属性、系统和外部世界的界面、设计和实现的约束；4．软件需求工程分为需求开发和需求管理。

（1）需求开发：获取、分析、编写规约、确认包括的活动：1)确定产品将要面对的各类用户2)从各类用户的代表处收集需求3)了解用户的任务和目标，以及这些任务要实现的业务目标4)分析从用户处得到的信息，将用户的任务目标与功能需求、功能性需求、业务规则、解决方案建议以及其他无关信息区分开来5)将顶层的需求分配到系统构架内定义好的软件组件中6)了解各质量属性的相对重要性7)协商需求的实现优先级8)将收集的用户需求表述为书面的需求规格说明书和模型9)审阅需求文档，以确保在认识上与用户声明的需求相一致，硬挨开发小组接受需求之前解决所有的分歧（2）需求管理：变更控制、版本控制、需求状态跟踪、需求跟踪1)定义需求基线2)审查需求变更请求，评估其可能产生的影响以决定是否批准3)以可控制的方式将准的需求变更融入项目中4)保持项目计划与需求的同步5)估计需求变更的影响，在此基础上协商新的需求约定6)跟踪每项需求，找到与其对应的设计、源代码和测试用例。

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

5.需求相关的常见风险1)用户参与不足：客户不想花大力气进行需求收集，开发人员也不重视用户的参与，有时客户代理方也不能完全理解用户的真正需求，导致不能发现项目需求中的缺陷。

2)用户需求扩展：开发过程中需求不断发展与增加，项目落后计划的进度或者超出预算3)有歧义需求：4)镀金问题5)过于抽象的需求6)忽略某类用户7)不准确的计划6.客户的权利和义务权利：1)要求需求分析员使用客户语言2)要求需求分析员理解用户的业务和目标3)要求需求分析员编写软件需求规格说明（srs）4)听取对需求工作成果的解释5)得到需求分析员和开发人员的尊重6)听取开发人员对于需求及如何实现需求的想法和备用方案7)描述使产品易于使用的特性8)为实现重用而对希求做出调整9)获得对变更成本的真实估算10)得到满足功能和质量需求的系统义务1)为需求人员和开发人员讲解业务2)花时间提供并阐明需求3)对需求的说明必须具体和准确4)及时做出决定5)尊重开发人员对成本和可行性的评估6)为需求设置优先级7)审阅需求文档，评估原型8)将需求变更及时告知开发人员9)遵循开发组织的变更过程10)尊重需求分析员使用的需求工程方法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)掌握应用领域知识。

11.前景：描述了产品用来干什么，它最终是什么样子，关系到整个产品，定义了产品的战略定位和业务目标。

前景（ppt）：描述了产品所涉及的各个方面在一个完美环境中最终所具有的功能。

通过产品前景可以把参与者定位到一个共同和明确的方向上。

范围：确定当前项目要解决产品长远规划中的哪部分，为需求是否属于项目划定了界线，定义了项目的限制，体现于项目定义的需求基线。

只与一个特定的项目或实现产品功能下一次增量的某次迭代项目范围（ppt）：确定当前的项目要解决产品长远规划中哪一部分。

范围同时定义了项目的限制。

对范围的描述确立了正在开发的系统与周围所有事物之间的界限和联系。

12.需求的来源（了解）：1)与潜在用户进行交谈和讨论2)描述现有产品或竞争产品的文档3)系统需求规格说明4)现有系统的问题报告和改进要求5)市场调查的用户问卷调查6)观察用户如何工作7)用户工作的情景分析8)事件和响应12.用户类的理解（P63-P64）13.需求工程的核心任务：需求获取，即确定软件系统涉众的需要及限制条件的过程。

需求获取着重于发现用户需求14.需求获取的常用方法：面谈法（讨论会）在开始需求获取时，邀请一为协调人来负责最初的讨论会，另外记录员要协助协调人记录讨论的内容要点。

15.如何获取遗漏的需求：1)将高层次的需求分解得足够细，让用户真正的需求显露出来，避免使用不精确和模糊的词语2)务必让所有的用户类都提出他们的意见，确保每个用例都至少有一个确定的执行者3)跟踪系统需求、用例、事件—响应表以及业务规则，直至其详细的功能性需求，确保需求分析员推导出了所有必需的功能4)检查边界值，查找被遗漏的需求5)用多种方法表达需求信息6)包括复杂的布尔逻辑的需求集常常是不完整的。

用判定表或判定树来表达复杂逻辑就能保证覆盖所有可能情况。

精确的找遗漏需求的方法：CRUDL矩阵（创建、读取、修改、删除、列表）表格的最左边一列列出用例，其他列代表数据实体。

观察5个字母是否有哪一个在同一列的所有单元格中没有出现，可能就存在需求的遗漏（结合P85的例子）15. 用例法：需求分析员用使用场景来获取需求。

场景是对系统的单个使用用例的描述，这种以场景为中心的方法归纳为用例法16. 用例的本质：用例就是由使用者(actor)驱动的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。

在RUP中，一个用例就是一个需求单元，分析单元，设计单元，开发单元，测试单元，甚至部署单元。

17. 用例描述的基本内容（会画用例图）：1)惟一的标识2)一个用例名（动宾形式）3)用自然语言书写的简短的文字描述4)一组前置条件5)后置条件6)一组带编号的步骤，描述系统与角色之间的一系列会话步骤与交互18. 如何确定用例：1)明确有哪些角色，然后确定这些角色各自参与了哪些业务规则（常用）2)确定哪些外部事件是系统必须响应的，将他们与参与的角色和特定用例关联起来3)用特定场景描述业务过程，将这些场景归纳为用例，并确定每项用例涉及哪些角色4)从已有的功能性需求推导出可能的用例19. 业务规则的定义：业务规则是对业务的某个方面进行定义或约束的语句。

用于声明业务结构，或者控制、影响业务的行为。

业务规则分类：（会判断，注意例子）1)事实：对业务的真实描述，常描述重要业务术语间的关联，是关于数据实体及其属性的不可改变的真实情况2)约束：限制了系统和它的用户可以执行哪些操作，必须、可以、不可以、只有、最多等词语可以描述一项约束3)动作触发规则：在特定条件下触发某个动作的规则，可能由人手工执行或这条规则引出对某项功能性需求的定义，使软件在指定条件为真时表现出正确的行为。

如果……则（发生某事-动作）暗示这是一条动作触发规则4)计算：定义使用特定数学公式或者算法进行计算的业务规则5)推论：根据某个条件的真实性得出某些新事实的规则。

常用如果/则句式表达，与动作触发类规则的区别在于推论的“则”子句表达的是一个事实或者一条信息，而非动作6)术语（ppt）20. 需求规格说明书包括的内容：1)引言：目标、文档约定、读者对象和阅读建议、项目范围、参考资料2)总体描述：产品前景、产品特性、用户类及其特征、运行环境、设计和实现上的约束、用户文档、假设和依赖3)系统特性：描述和优先级、激励/响应序列、功能性需求4)外部接口需求：用户界面、硬件接口、软件接口、通信接口5)其他非功能性需求：性能需求、防护性需求、安全性需求、软件质量属性6)其他需求7)附录：术语表、分析模型（数据流图、类图、状态转换图、E-R图）、待确定问题的清单21．需求视图包括：功能性需求清单和表格、图形分析模型、用户界面原型、测试用例、判定树和判定表等22．需求阶段建立目标，建模的好处？（了解）23．结构化分析和面向对象分析的区别：▪结构化分折(Structured Analysis, SA)方法▪一种单纯的由顶向下逐步求精的功能分解方法。

分析员首先用上下文图表(称为数据流图DFD)表示系统的所有输入／输出，然后反复对系统求精，每次求精都表示成一更详细的DFD从而建立关于系统的一个DFD层次。

为保存DFD中的这些信息，使用数据字典来存取相关的定义、结构及目的。

▪面向对象（Object Oriented, OO）方法▪把分析建立在系统对象以及对象间交互的基础之上，使得我们能以3个最基本的方法框架——对象及其属性、分类结构和集合结构来定义和沟通需求。

面向对象的问题分析模型从3个侧面进行描述，即对象模型(对象的静态结构)、动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)。

二者之间的区别（—）结构化方法首先关心的是功能，强调以模块为中心，采用模块化、自顶向下、逐步求精设计过程，系统是实现模块功能的函数和过程的集合，结构清晰、可读性好，的确实提高软件开发质量的一种有效手段。

每个模块有可能保持较强的独立性，但它往往与数据库结构想独立。

如果数据库复杂，模块独立性很难保证。

结构化设计从系统的功能入手，按照工程标准和严格规范将系统分解为如干功能模块。

然而，由于用户的需求和软、硬件技术的不断发展变化，作为系统基本成分的功能模块很容易受到影响，局部修改甚至会引起系统的根本性变化。

开发过程前期人手快而后期频繁改动的现象比较常见。

结构化方法，系统是过程的集合过程与数据实体交互，过程接受输入并产生输出。