Book4-需求获取概述
1. 引言
- 需求获取是进行需求收集的一个活动,它从人员、资料和环境中得到系统开发所选用的相关信息。
2. 需求获取的常见困难(非平凡性)
- 默认背景:用户/客户与开发团队分离
- 用户和开发人员的背景不同,立场不同
- 知识理解的困难:开发人员尽力去研究应用的背景,理解组织的状况,形成一个能够和用户进行有效沟通的粗略的知识框架
- 默认(Tacit)知识现象:利用有效的获取方法与技巧(角色扮演、观察等)来发现并获取默认知识,多数情况找对计算机比较了解的用户是错误的行为。
- 普通用户缺乏概括性、综合性的表述能力
- 普通用户的知识结构就相对局限于一些具体的业务细节:善于表达具体业务的细节问题
- 专家用户的知识结构因其渊博性而具有概括性和广泛性:能够回答概括性和综合性的问题
- 开发人员在与用户接触之前就先行确定获取的内容主题,然后设计具体的应用环境和场景条件,由用户根据细节业务的执行来描述问题、表达期望。
- 用户存在认知困境
- 潜在(Latency)知识:拥有一种方法但是自己却不知道,需要利用各种有效的需求获取方法和技巧
- 民族志方法,分析用户环境和行为,挖掘潜在知识。
- 在有限理解的基础上设计初始原型。
- 主动"创造"需求,实质仍然是原型法。
- 潜在(Latency)知识:拥有一种方法但是自己却不知道,需要利用各种有效的需求获取方法和技巧
- 用户越俎代庖
- 用户提出的不是需求,而是解决方案:注意保持业务领域和解决方案的区分界限,比如原问题是提高容灾能力,提出的要求是双机热备(解决方案)
- 用户固执的坚持某些特征和功能:分析用户的深层目的,找到隐藏在背后的需求
- 缺乏用户参与
- 用户数量太多,选择困难
- 用户认识不足,不愿参与:认为软件产品是付费之后等结果即可。
- 用户情绪抵制,消极参与:新系统侵害他们,或者看不到对他们的尊重。
- 没有明确的用户(市场驱动)
- 对系统的用户以及用户的替代源等相关涉众进行分析
- 用户画像(Persona)
3. 需求获取的活动过程
3.1. 需求获取的子活动
- 研究应用背景,建立初始的知识框架
- 根据获取的需要,采用必要的获取方法和技巧
- 先行确定获取的内容和主题,设定场景
- 分析用户的高(深)层目标,理解用户的意图
- 进行涉众分析,针对涉众的特点开展工作
3.2. 需求获取的活动过程
- 收集和应用相关的背景资料 → \rightarrow → 了解应用和组织的大概状况,建立初始的知识框架 → \rightarrow → 结合背景资源分析涉众的高层次问题,了解涉众对这些高层次问题的解决期望,总结出系统的业务需求
- 复杂的获取活动中,其实质步骤如下:
- 确定待获取信息的内容
- 确定待获取信息的来源
- 确定应采用的获取方法
- 执行获取
- 记录成果
4. 需求获取活动的要点
4.1. 获取的内容
- 在项目的范围之内
- 所有为用户创建解决系统必须的信息
- 需求(草稿):是系统期望达到的目标,通常体现为用户的观点、看法、目标或者问题
- 问题域特性:需要注意的是不要忽略系统的环境和约束
- 环境与约束:主要来源于涉众的描述和对应用环境的观察
- 获取的内容不是一次得到的,而是逐步积累的
4.2. 获取信息的来源
- 涉众
- 用户:最主要的
- 客户
- 领域专家
- 市场人员、销售人员等其他用户替代源
- 硬数据
- 登记表格、单据、报表等定量文档
- 备忘录、日志等定性文档
- 相关产品
- 原有系统
- 竞争产品
- 协作产品(和解系统存在接口的其他软件系统)
- 重要文档
- 原有系统的规格说明
- 竞争产品的规格说明
- 协作产品的规格说明
- 客户的需求文档(委托开发的规格说明、招标书)
- 相关技术标准和法规
- 相关法律、法规及规章制度
- 行业规范、行业标准、领域参考模型
- 归纳获取源主要有以下两类:
- 人脑内知识
- 人脑外知识
4.3. 获取信息的方法
- 传统方法:问卷调查、面谈、硬数据分析、文档检查、需求剥离等
- 集体获取方法:头脑风暴(Brainstorming)、专题讨论会(Workshop)、JAD(Joint Application Development,联合需求开发)、JRP(Joint Requirements Planning,联合需求计划)等
- 原型与模型驱动:尤其适用于模糊和不确定性较大的情况。
- 模型驱动方法:模型定义了要手机的信息类型,模型建立和完善的过程就是需求获取的方法
- 面向目标的方法
- 面向场景的方法
- 基于用例的方法
- 认知方法:任务分析(Task Analysis)、协议分析(Protocol Analysis)等 – 对领域知识严谨而细致的抽取
- 基于上下文的方法:观察、民族志(Ethnography)和话语分析(Conversation Analysis) - 深入到用户之中,对其进行观察(第三者)
4.4. 获取信息的过程
4.4.1. 注意事项
- 在整体上制定组织方案:确定系统的边界,(最好)建立上下文图或系统用例图
- 维护项目的前景和范围
- 引导和控制获取过程
- 适当修改不准确的前景和范围
- 接受需求的不稳定性:世界是随时变化的,用户随世界而变化,需接受
- 控制探索性工作(例如模拟和原型):有延期和超支的风险,可考虑额外立项或增量式开发
4.4.2. 防止需求遗漏
- 务必让所有的涉众都表达出自己的意见。
- 不要以抽象和模糊的需求作为结束。对抽象和模糊的需求,要进行细化,让真正的需求显露出来。
- 使用多种方法表达需求信息。利用不同的分析技术为相同的需求进行建模,通过分析不同的关注点,考察需求是否完整。
- 注意检查边界值(程度)和布尔逻辑(好与坏,行与不行)。
4.4.3. 结束获取活动的判断条件
- 用户想不出更多的用例;
- 用户想出的新用例都是导出用例(通过其他用例的结合可以推导出该用例);
- 用户只是在重复已经讨论过的问题;
- 新提出的特性、需求等都在项目范围之外;
- 新提出的需求优先级都很低;
- 用户提出的新功能都属于后继版本,而非当前版本
4.5. 获取的结果
- 肯定会产生获取笔录(Elicitation Notes)
- 用户需求、问题域知识和约束
- 可能具有组织差、冗余、遗漏、自相矛盾等诸多问题
- 可以包括文字记录、录音、摄像等各种形式
- 可能会产生两份定义明确的正式文档(与需求分析结合)
- 项目前景和范围文档
- 用例文档
5. 需求获取的实践调查情况
5.1. 实践中的需求获取活动主要关注的几个问题:
- 项目目标:项目成功的十大影响因素之一[Standish Group],目标模型和面向目标方法。
- 项目范围:包含完备的功能,功能是必要的;最佳成本效益比;有效控制。
- 用户参与
- 交流问题
- 获取方法的使用
![]() | ![]() |
---|
5.2. 项目范围的常见错误
- 项目的边界定义不清晰,或者根本就没有定义项目的边界;
- 定义的项目边界错误,使得最终的需求不完备或者冗余;
- 没有控制已建立的项目边界,使得项目范围失控:尤其是因为时间压力而抛弃需求的问题和开发人员"镀金"的问题非常普遍
5.3. 用户参与不足
- 没有能够有效地选择参与项目的用户:理想的用户是最不可能的用户
- 认识不足
- 开发者:用户不懂/不感兴趣/没有时间
- 用户:意识不到其主体作用(直接给我产品!)
- 用户抵制:影响了部分群体的利益或价值观/拒绝变化/冲突
- 没有明确的用户:互联网企业/思维:庞大用户群(流量)+新生事物(创新),利用用户的替代源
- 管理上的障碍:请有权威员工参与:需求获取会占用本身的工作时间
![]() | ![]() |
---|
5.4. 交流问题
- 最大的问题就是理解偏差
- 常用的交流方式:非正式的电话交谈、正式的电话交谈(例如客户热线或者远程电话会议)、邮件、web反馈表、文档以及一些面对面的交流(例如JAD会议、原型等)
- 私人联系和非正式交流更受欢迎
- 交流途径的数量要适中(4-7)
- 面对面的交流方式是最有效,也是最受欢迎的
- 直接交流途径优于间接交流途径
5.5. 获取方法的使用
- 没有在实践当中得到充分的应用:没有选择正确的获取方法
- 五个方面的获取方法选择依据(用户是否有能力准确全面地表达对系统的要求)
- 需求的目的(细化的SRS或整体需求方案):为已存的系统建立规格说明,还是为一个项目建立需求方案。
- 知识的类型(静态/动态,抽象/详细)
- 知识内化的特性要求(新知识、潜在知识、场景知识、惯性知识、明显知识)
- 可观察的现象
- 约束(是否需要开会、准备/采集/获得需求的时间限制、工程师/涉众的数量、涉众支持程度、前导技术要求)