软件工程学习笔记《三》需求获取

版权声明：本文为博主原创文章，但部分内容来源自互联网，大家可以随意转载，点赞或留言均可！ https://blog.csdn.net/csdn_kou/article/details/83867429

软件工程学习笔记《目录》

软件工程学习笔记《目录》

需求工程师

当代的需求工程师需要具备的能力

• 分析问题和解决问题的能力
• 人际沟通及交流的能力
• 软件工程师知识和技能
• 应用领域有关知识
• 书面语言组织和表达能力

当代的需求工程师需要努力的方向

• 识别错误假设
• 确保一致性
• 提升依从性
• 减少彼此误解
• 提升支持速度和效率
• 提升客户满意度
• 撰写优质文档

当代的需求工程师需要注意的错误

• 干扰
• 沉默
• 过度规约
• 矛盾
• 含糊
• 向前引用
• 不切实际与一厢情愿

需求的定义

需求是人们要解决的某个问题或达到某种目的的需要，是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。需求将作为系统开发，测试，验收,提交的正是文档依据。

需求目标

对产品及其与环境的交互进行更深入的了解，识别系统需求，设计软件体系结构，建立需求与体系结构组件的关联，在体系结构设计实现过程中进一步识别矛盾冲突，并通过干系人之间的协调磋商解决问题。

需求分析的实质

概念建模——选择常用的建模语言，进行功能建模和信息建模

需求分析的关键

体系结构设计与需求分配

应该涵盖的内容？

• 为什么设计该系统
• 由谁使用
• 要做什么
• 系统要涉及哪些信息
• 对解决方案有什么额外限制
• 如何使用该系统
• 质量需达到什么程度

需求规约（作为较客观的参照）

单个需求项的质量

• 准确
• 正确
• 可行
• 可证

整个需求集合的质量

• 显示
• 精确
• 全面
• 一致

需求分析

产品/过程

• 产品需求
• 过程需求

产品需求

• 功能性需求
• 非功能性需求

需求分类的合理使用

• 关注特殊的需求特征

• 关注需求语义特征

  • 明确指出系统必须支持的行为
  • 排序那些不可接受的系统行为
  • 明确指出系统的最好支持的行为

• 对那些适用范围受限的关注点和横切关注点区别对待

• 需求的分类主要用于为需求的抽取提供启发式的规则

  • 避免忽略某些关键的需求类型
  • 通过已知矛盾的需求类型发现具体需求间的矛盾和冲突

• 业务需求

  • 业务需求又叫业务目标：携程旅行的业务：买飞机票；公司目标：成为认为想买飞机票首先想到的公司

• 用户需求

  • 有时候被称为“用户接口需求”，系统的用户需求指其满足会影响系统的用户接收程度的需求

• 系统需求

  • 系统需求的满足使得系统实现预期的功能，他从用户的角度描述系统做什么，与系统是由什么硬件和软件实现无关。

• 软件设计规约

  • 系统的API需要同时支持C++和Java来让程序员访问系统服务

• 软件需求

  • 软件需求是指关于系统中软件部分的需求，它满足帮助实现系统需求

• 功能性需求

  • 又称“行为需求”，指满足系统需求需要提供的功能

• 质量需求

  • 关于“提供的服务好到何种程度”的问题。订票系统的订票请求响应时间要小于1分钟

• 依从性需求

  • 指要着重描述软件对国家法律，国际公约，社交法则，文化与政治习惯，标准等环境约束的满足要求。两列火车间的最小间距应满足国际铁路运输安全规范中的最坏情况停车距离

• 体系结构设计需求

  • 分布式约束：要求软件系统组件满足目标组织由于地理自然分布导致的对系统设备节点的分布要求，以及数据的分布式存储与处理要求。
    例如：会议调度系统应与分布在世界各地的参会者的邮件服务系统和电子日程管理系统协同工作
  • 安装约束：要求软件系统能够在目标实现环境下正常运行
    例如：会议调度系统应在微软和IOS上

• 设计开发约束

  • 指对软件系统设计过程的约束，包括：开发成本，开发周期，产品特征的变化性，可维护性，可移植性，可重用性等。
    例如，动车控制软件应在两年内投入使用。会议日程安排系统应根据会议类型动态调整

需求之间存在重叠

• 功能性需求与非功能性需求间的划分并非绝对的，可能存在重叠
  • 是一个功能性需求，也是安全性需求

需求获取方式

面谈

问卷

群体诱导

参与调查

文档分析

会议

头脑风暴

需求讨论会

情景分析

概念建模

竞争性需求分析

A/B测试

如何选择需求方案？

如何撰写需求文档？

软件需求规格说明

需求文档的组织形式

规格说明SRS的风格

撰写原则实例