軟件需求期末复习.docVIP

软件需求考试总复习 1、为什么软件需求这么难？ 客户说不清楚需求 需求自身经常变动 分析人员或客户理解有误 2、软件需求的定义 软件需求＝业务知识＋问题列表＋其他因素。 业务知识包括业务事件、业务实体和业务规则；问题列表是用户在工作中遇到的困难与障碍，这也是软件开发中需要解决的问题；其他因素包括了一些设计约束和非功能方面需求。 3、需求的层次 业务需求、用户需求、软件需求 需求层次的产物：业务需求是需求定义的产物，用户需求是需求捕获的产物，软件需求是需求分析与建模的产物。 4、软件需求的三种类型 功能需求：开发人员要实现什么 非功能需求：对产品功能描述的补充 设计约束：限制了开发人员设计和构建系统时的选择范围 5、软件开发的各个阶段，为什么只有需求阶段称为工程？ 需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。 需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。 所以才只有需求成了工程！ 6、需求工程划分为哪两个部分 需求开发、需求管理 7、需求开发包括哪些内容 需求获取、需求分析、需求规约（编写需求规格说明书）和需求验证（确认）。 8、需求管理包括哪些内容 基线管理、变更管理和需求跟踪。 9、如何评价需求的好与坏（优秀需求的特点） 完整性、正确性、可行性、有优先次序、无歧义、可验证性、确定性 10、客户的含义 广义来讲，客户泛指直接或间接得益于产品的个人或组织。 软件的客户包括那些提出软件需求，购买、定义、使用软件产品或选择接受软件功能的项目涉众 11、“签字”的含义 签字是项目的一个里程碑，是建立需求协议的基线。 12、需求定义阶段的任务 确定项目的宏观需求。换句话说，就是定义项目的业务需求，也就是明确项目的目标和范围。 13、需求定义的理念 目标、问题、可选方案、建议方案 14、问题分析5步法 在问题定义上达成共识、理解根本原因（也就是分析问题背后的问题）、确定相关人员和用户、定义解决方案的界限、确定加在解决方案上的约束 15、需求定义的产物 根据项目类型的不同，需求定义的产物大致可以分为POS（Project Overview Specify,项目综述）和Vision(愿景)两大类。 16、需求定义的要素 目标、范围、相关人员与用户、相关事实与假设 17、一个好的目标应满足的原则（SMART） 必须是具体（Specific）的：目标必须能够指导具体的工作 必须是可以度量（Measurable）的：这样才能进行成本/效益分析 必须是可以达到（Attainable）的：否则是没有意义的目标 必须和其他目标具有相关性（Relevant） 必须具有明确的截止期限（Time-based） 18、需求开发过程 需求开发过程是一个迭代的过程，不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。 19、划分主题域(构件图，也即UML中的组件图) 业务事件类型： 外部事件（来自系统外部的事件，也就是系统参与者发起的） 内部事件（系统内部触发的） 20、确定主题域（上下文关系图） 上下文关系图：针对每个主题域来绘制上下文关系图，确定出每个主题域的范围。 上下文关系图绘制要点： 首先用一个矩形表示系统，写上系统的名称，将整个系统看作一个黑盒子。 然后找到该系统的所有客户（处于主题域的外部），考虑他们会发起什么事件，这些事件会引发内部工作人员的什么动作，将这些序列逐一表示出来。 最后再看看系统的每个内部工作人员还有没有一些主动发起的事件。 当上下文关系图绘制出来之后，整个主题域的范围也就框定出来了，但是它还不足以为后续的需求捕获、分析与建模活动提供良好的基础。我们需要将主题域的内容以业务事件列表和报表列表表示出来。 21、需求分析人员的工作 需求分析人员是对项目相关人员的需求进行收集、分析、记录和验证职责的承担者，是用户群体和软件开发团队间进行需求沟通的主要渠道。 定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先