软件项目管理课程之第4讲：软件需求管理

讲授内容

项目案例
软件需求管理的基本概念
软件需求开发
软件需求管理

项目案例

案例背景：小王作为软件项目负责人，带领团队开展需求调查工作，但在需求分析和后续开发过程中出现了一系列问题。
问题表现：
- 项目规模庞大，需求分析小组不知如何开展工作，对需求分析的复杂性和难度估计不足。
- 需求分析小组不能有效工作，不知哪些属于用户需求，哪些不是，不知怎样获取用户需求，如何分析清楚。
- 不知按照怎样的规范书写软件需求规格说明书，得到的软件需求质量不高，存在说不清、遗漏、矛盾、啰嗦等问题。
- 需求评审不严格，导致遗漏了许多需求，获取的用户需求不一致、描述不清晰和准确。
- 用户没有参加需求评审，许多软件需求未得到用户认可，最终开发出的软件不能满足用户要求，用户拒绝接收软件并拒绝付款。
- 在软件开发阶段，由于软件需求的不准确性、不一致性和二义性，软件设计人员需通过用户再次确认需求。
- 在开发过程中，用户的需求仍在改变，这些改变的需求未得到有效管理和控制，未能及时反馈给软件开发小组，导致未能在待开发的软件中得到体现。
- 由于需求未能有效管理，在最终项目验收过程中出现问题，实际开发的软件未能完全反映用户的需求，导致用户不满意，项目延期。
案例启示：需求分析极为重要且困难复杂，用户需求经常性变更正常，为保证软件需求质量，必须对需求分析的人、过程和产品进行有效管理，需求管理不善将导致严重后果。

软件需求管理的基本概念

什么是软件需求：
- 软件需求是用户对目标软件系统在功能、性能、设计约束等方面的期望和要求，是用户希望软件能做的事情和完成的功能。
- 软件需求关注用户的期望、要求和需要，不是解决方案，需区分what和how。
- 软件需求主要指功能、性能、设计约束、时间进度等，不包括重量、软件大小等。
- 并非所有用户的期望和要求都是软件需求，用户需求必须中肯、有意义。
- 软件需求解决目标系统“做什么”的问题，而非“如何做”的问题，是连接用户和软件开发团队的桥梁。
软件需求的分类：
- 业务需求：组织或客户高层次的目标，来自项目投资人、购买产品的客户、实际用户、市场营销部门或产品策划部门，描述组织开发系统的理由和目标，使用愿景和范围文档记录。
- 用户需求：描述用户目标和任务，通过用例、场景描述和事件-响应表表达。
- 功能需求：规定软件系统开发人员必须实现的功能，描述开发人员需要实现的内容。
- 非功能性需求：包括质量属性（可靠性、可维护性、安全性、易操作性等）、系统需求（系统运行环境、开发环境等）、业务规则等。
软件需求的重要性：
- 软件开发的基础和前提，明确需求后才能开展系统设计和编码。
- 制定软件开发计划的基础，知道需求才能确定工作量，进而制定计划。
- 软件系统验收的标准，明确需求才能进行验收。
获取软件需求的复杂性和面临的问题：
- 系统复杂和庞大，难以全面获取需求。
- 需求可能存在片面、不完全、模糊、不准确、不一致、歧义等问题。
- 需求变更时，难以及时通知相关人员。
- 需求变动可能带来波动性和放大性问题。
解决方法和手段：
- 技术层面：运用需求分析方法、技术和工具，如数据流、面向对象、抽象、建模、多视点、原型、UML、Rose、Word、Excel、RequisitePro等。
- 管理层面：对需求分析中的人、活动和产品进行管理，形成需求工程研究领域。

软件需求开发

什么是软件需求开发：需求开发是从用户处获得需求并形成与用户需求相一致的、可供阅读的软件需求规格说明书的过程。
软件需求开发的任务：通过对应用问题及其环境的理解和分析，准确、一致和完全地刻画用户需求，并达成一致，形成软件需求规格说明书（SRS）。
软件需求开发的目标：
- 全面性：没有遗漏。
- 一致性：没有矛盾。
- 准确性：说清楚。
- 认同：共同、相互认可。
- 文档化：书面文档。
软件需求开发的过程：
1. 需求获取：从用户处收集、获取软件需求，帮助用户发现潜在的软件需求。技术手段包括Q&A列表邮件提问、电话会议访谈、用户调研、需求专题讨论会、头脑风暴、参观交流、实践等。需求获取的注意事项包括识别真正的用户、正确理解用户需求尤其是隐含需求、具备较强的忍耐力和清晰思维、说服和教育用户。
2. 需求分析与建模：提炼、分析和审查已收集到的用户需求，建立一个概念模型，发现并纠正不一致、不准确和不全面的软件需求，形成准确的用户需求描述。主要活动包括绘制系统关联图、创建用户接口原型、分析需求可行性、确定需求的优先级别、为需求建立模型（如UML）、建立数据字典、使用质量功能调配等。需求建模方法包括用例分析方法、原型分析方法和结构化分析方法。
3. 文档化软件需求：根据软件需求初步描述和软件需求模型，撰写软件需求规格说明书（SRS）。SRS的编制是为了使用户和软件开发者对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS的原则包括从现实中分离功能、采用一定的规格说明语言、包括系统运行环境的说明、容许不完备性并允许扩充。
4. 软件需求验证：由多方对软件需求规格说明书进行评审，分析需求的正确性、完整性以及可行性等，确保需求说明准确、无二义性并完整地表达系统功能以及必要的质量特性。验证活动包括审查需求文档、以需求为依据编写测试用例、编写用户手册、确定合格的标准、最后的签字。参与验证评审的人员包括项目经理、用户方代表、需求分析小组、软件设计小组、软件测试小组、软件质量保证小组等。

软件需求管理

需求管理的必要性：
- 需求获取的偏差难以避免，客户描述的需求与项目经理、分析员、程序员等的理解可能存在差异。
- 需求具有易变性和难以表述性，需求错误出现的高频性和修复的高昂成本。
需求管理的目标：
1. 使软件需求受控，并建立供软件工程和管理使用的基线。
2. 使软件计划、产品和活动与软件需求保持一致。
需求管理的原则：
- 需求一定要分类管理：目标性、业务需求和操作性。
- 需求必须分优先级：需求过多、需要裁剪。
- 需求必须文档化：记录，避免忽略重要需求。
- 需求一旦变化，就必须对需求变更的影响进行评估。
- 需求管理必须与需求工程的其他活动紧密整合。
需求管理策略：
- 需求一定要与投入有必然的联系。
- 需求变更要经过出资方认可，小的需求变更也要经过正规的需求管理流程。
- 精确的需求与范围定义并不会阻止需求变更。
需求管理活动：
- 需求管理规划：需求识别、变更管理过程、需求跟踪和自动化工具。
- 需求管理是一个对系统需求变更了解和控制的过程，与其他需求工程过程相互关联。
- 变更控制：建议需求变更并分析其影响，做出是否变更的决策。
- 版本控制：确定单个需求和SRS的版本。
- 需求跟踪：定义对于其他需求及系统元素的联系链。
- 需求状态：定义并跟踪需求的状态。
需求变更的原因：
1. 在项目的早期所有的问题不可能被完全定义，软件需求是不完全的，注定了需求需要变更。
2. 随着软件项目的进行，软件开发人员对问题的理解会发生变化，这些变化也要反馈到需求中去。
3. 不同类型的用户的需求可能是冲突的或是矛盾的，最后的系统需求是它们之间的一个妥协，这种妥协的程度在项目进行过程中有可能发生改变，从而导致系统需求的改变。
4. 系统购买者或系统最终用户很少是同一人，有的系统客户对系统提出的一些需求可能和最终用户需求不一致。
需求变更控制基本流程：
1. 客户或开发人员提出变更请求。
2. 项目经理进行初步判断，分流处理。
3. 对于应重视的问题，提交变更控制委员会进行决策。
4. 变更控制委员会分析变更影响，做出接受或不接受的决策。
5. 如果接受，修改SRS、开发计划和其他相关文档。
需求文档版本控制：
- 保证软件项目干系人得到最新版本的需求文档和记录需求的全部历史版本。
- 统一确定需求文档的每一个版本，保证每个成员都能得到当前的需求版本。
- 清楚地将变更写成文档，并及时通知项目开发所涉及的人员。
- 只允许指定的人来更新需求文档。
需求状态：
- 包括需求属性（背景资料和上下文关系、创建时间、涉及的子系统、版本、涉及的产品版本、创建者、批准者、验证方法、状态、优先级、原因、稳定性等）。
- 需求状态的变化过程（提出需求、已建议、已批准、已拒绝、需求分析、已设计、已实现、已验证、已删除、已交付等）。
需求跟踪：
- 目的：建立和维护从用户需求开始到测试之间的一致性与完整性，确保所有实现都以用户需求为基础，而实现的需求也全部覆盖了预期的需求，同时确保所有输出与用户需求的符合性。
- 可追溯性信息：源可追溯性信息、需求可追溯性信息、设计可追溯性信息。
- 需求跟踪的方式：正向跟踪和逆向跟踪。
- 需求跟踪的实现：需求跟踪矩阵。
- 需求跟踪的作用：在需求验证中的作用、有助于需求变更影响分析、便于需求的维护、便于测试时找出问题所在、便于项目跟踪、减小项目的风险、简化了系统的再设计、易于软件重用。
需求管理工具：CaliberRM、DOORS、RTMRational RequisitePro。

案例分析：如何面对项目需求变更？

案例背景：小主的公司遇到两个项目，分别由项目经理A和B负责。项目经理A对客户提出的问题无论大小都给予解决，客户满意但项目进度拖得较长；项目经理B对客户提出的问题大多不予理睬，客户不满意但项目进度控制较好。
问题：
1. 如果你遇到需求变更，你会采用哪种方式？
2. 分析这两种应对需求变更方式的优缺点。
分析：
1. 需求变更对项目的成本、进度、质量都会产生影响，对客户提出的需求变更要求要谨慎对待，既不能一味接受也不能全盘拒绝，要综合分析，合理的需求变更可以接受，过分的要求则要拒绝，且需求变更要严格按照需求变更审核控制流程来进行。
2. 在项目前期尽量把用户的需求了解清楚，注意引导用户的需求到我们的方案中来，与销售部保持良好沟通，避免项目实施后进行变更。
3. 对于用户提出的意见和建议，要系统评估需求变化导致的成本增加和质量改进，最终进行决策，并与用户及时沟通。
分析2：
- 项目经理A的应对方式的优点是客户满意，缺点是对项目进度延期，成本增加，质量没保障。
- 项目经理B的应对方式优点是项目可以按时完成和交付使用，缺点是影响客户关系，对将来的合作产生不利影响。