需求工程-需求思想+全局视图
2021-05-28 11:29:51 39 举报AI智能生成
需求工程-需求是一项工程，主要包括需求定义（项目立项时应该做）、需求捕获、分析与建模、需求管理，该图以宏观角度对需求工程进行了概述并表明了需求过程中的主要任务 需求定义、需求捕获、分析与建模请查看《需求工程-需求定义》、《需求工程-需求捕获、分析与建模》 欢迎各位大神留言探讨需求相关问题
作者其他创作
大纲/内容
业务驱动的需求思想
针对“组织应用类软件”系统的分析工作，核心在于“业务分析”。
要厘清此类软件系统的需求，必须抛开具体的实现，站在用户的角度审视用户想要解决的问题、想要达成的业务目的。
要厘清此类软件系统的需求，必须抛开具体的实现，站在用户的角度审视用户想要解决的问题、想要达成的业务目的。
需求思想
技术驱动
站在技术视角展开，关注的是“方案级需求”
业务驱动
站在用户视角展开的，关注的是“问题级需求”
常见问题
如果基于一个目的不清晰、实现方案相当明确的需求进行开发，一旦开发成本比较大，就极易出现执行变形，严重的时候甚至还会使客户关系恶化
需求变更/优化
需求分析
需求分析
任务执行指引
客户提出的原始需求是方案级还是问题级需求？
当我们“完美”的满足了客户提出的“方案级需求”时，最终未必会得到完美的反馈。
客户是问题专家，而非解决方案专家，客户提出的方案未必能够完美的解决问题
客户是问题专家，而非解决方案专家，客户提出的方案未必能够完美的解决问题
澄清问题
想要解决谁的问题、什么问题？
用户当前遇到该问题会采用什么样的解决方案？
这个问题是否需要进一步的细化和明确或对模糊概念达成共识？
了解背景
场景（功能）
该需求谁使用？
什么时候使用？
具体怎么做？
术语（数据）
有需要澄清的业务术语吗？
它们的格式是什么?
建议并确定解决方案
要解决这个问题有哪些可行的解决方案？
这些方案的成本是多少？
你觉得哪种最合适（解决问题/成本合适）？
该解决方案对用户而言有什么优缺点？
有其他需求深挖的需求吗？
组织应用类软件系统
需求全景图
需求全景图
价值需求
重要性
1、地位：价值需求是组织应用类软件系统需求的灵魂和方向
2、现况：在需求分析实践中，做的都比较薄弱；
3、问题：2现况使得项目范围更容易蔓延，客户从系统中获取的利益与价值不容易呈现，从而导致客户满意度难以有效的提升
2、现况：在需求分析实践中，做的都比较薄弱；
3、问题：2现况使得项目范围更容易蔓延，客户从系统中获取的利益与价值不容易呈现，从而导致客户满意度难以有效的提升
常见问题
四海皆准的、定性的描述，无法作为“成功标准”来指导系统的开发与实施工作。甚至会出现“因为走的太远，以至于忘记为何而出发”的尴尬境地
忽略干系人识别，导致忽略客户的关注点，陷入客户的阻力点，从而在开发过程中不断受到影响
分析关键
执行好目标分析
产物：《项目目标描述》，场景化定义项目目标
干系人识别
产物：《干系人列表》，列出所有关键干系人
干系人分析
产物：《干系人档案》，针对每个关键干系人整理相应的关注点和阻力点
详细需求
分析关键
子问题域分解（可选）
关键任务
系统分解模型：系统中涉及哪些子问题域
业务接口要求说明：定义各主题域间的业务接口，说明这些接口的用途、实现方、使用方等细节
行为需求（功能主线）
要求：厘清系统中的所有功能是为什么而存在的
主线
业务支持
典型的三类场景
固化、优化业务流程：业务流程是核心
业务延伸到新的通道：本质上是流程的重构，业务流程是核心
将个人能力转化为组织能力：专家场景 是核心
关键任务
业务流程识别：为每个子问题域生成一个《业务流程列表》，列出系统涉及的业务流程
业务流程分析：对各业务流程进行分析和优化，绘制一组《流程图模型》（业务流程列表）
业务功能（场景）识别：识别各流程中系统需支持的业务功能模型（用例模型）
业务功能（场景）分析：描述各业务功能的具体需求（用例描述）
管理支持
主要体现
事前风险避免，通过增加管理流程
事中风险控制，通过“规则”和“审批”
事后总结优化，通过“数据分析”
关键任务
管控点识别与分析：从管理者的视角识别出他们的管理场景及意图，得到《管理点列表》，对每个管控点进行分析，得到所需的业务报表、BI需求、数据仓库、数据挖掘等需求
业务报表分析（针对辅助决策）：对关键任务识别出的业务报表项，从数据项、计算方法、展现格式、统计口径等方面进行具体描述
维护支持
典型的场景
初始化
配置
排错
运营维护
关键任务
识别未来的维护用户
根据不同的维护用户列举出未来维护、运营的相关场景，得到《维护场景列表》
数据需求（数据主线）
关键任务
领域建模：用领域图的形式刻画出问题域中的所有业务实体之间的关系
业务数据分析：对每个业务数据实体进行“业务数据分析”，详细定义数据构成与推演过程
非功能需求
质量要求
常见问题
定性描述：直接写“高可靠、高易用、高灵活......”之类的要求，实际上并没有传递出有效的信息
盲目定量：拍脑袋写量化指标，写出一些客户、需求、研发都无法清晰理解的似是而非的量化要求
全局性描述：诸如“所有查询在7秒以内”之类的全局性描述，以偏概全，缺乏实际有效的落地性，应该将局部与全局分开
分析思路
非功能需求的分析工作最核心的就是逆向思维，从威胁入手
关键任务
标识关键质量要求：逆向、场景化的思考，通过排查核心威胁得出候选关键质量需求并按照风险曝光度进行排序
质量场景分析：基于每种质量类型，识别出业务环境中可能产生的破坏力大、出现概率高的威胁场景，用场景传达具体需求
约束
关键任务
明确项目约束
明确设计约束
0 条评论
下一页
