the hands of god的博客
本文关键词：掌握需求过程，由笔耕文化传播整理发布。
【活动】Python创意编程活动开始啦！！！ CSDN日报20170424 ——《技术方向的选择》 程序员4月书讯：Angular来了！
掌握需求过程
标签：
本文章已收录于：
分类：
掌握需求过程
后篇
第十章 功能需求功能需求是产品为了支持工作而必须做的事情，它们的表述应该尽可能独立于实现需求的技术。作为业务分析师不要尝试打造技术方案，而是要指定技术解决方案必须做的事，如何实现结果是设计师的事情。场景中包含3-10个步骤给出合理的细节程度，又不会让非技术的利益相关者感觉太复杂。控制需求描述的细节程度或粒度，在需求描述中添加理由，在许多情况下，这是需求的关键部分。不论需求最终如何实现，写下描述和理由显然会引导发现真正的需求。
在编写需求时，不只要注意一词多义，如果产品的上下文不清楚，也会引起二义性。需求的层次结构，工作上下文范围是最高层次的需求说明，它分解为下一个层次即业务事件，业务事件下一层由产品用例组成，每个产品用例又被分解为一些产品用例步骤，最底层的需求包括原子需求，每项原子需求都可以追踪到高层的用例步骤。有场景、用户故事（作为[角色]，我想要[功能]，这样就能[使用该功能的理由]）、业务过程模型等多种方法来描述产品的功能。
功能需求描述了产品的处理动作，即为了支持业务而必须做的事，功能需求是产品功能描述，它应该是完整的，并尽量避免二义性。
非功能需求描述产品将失去做到什么程度。把功能需求看成是使产品工作的需求，把非功能需求看成是为工作增加某些特征的需求。非功能需求描述了特征或功能完成的方式。非功能需求类型包括感官、易用性和人性化、执行、操作、可维护行性和支持、安全、文化和政策、法律等。
需求类型有助于发现需求的工具，可以将需求类型看作一份检查清单，将来会为每项需求加上验收标准，并使它可测试。我们可以通过用博客记录需求、用例、模板、原型、客户等来发现非功能需求。非功能需求也许看起来有些模糊，需要在写验收标准时，写下测量指标，，量化每项需求的含义。
第十二章 验收标准和理由验收意味着解决方案准确地实现了需求所要求做的事情，或具备需求所要求的属性。需求本身必须是可测量的，需求的测量指标就是验收标准，它量化了需求的行为、执行方式以及一些其他品质。
验收标准既不是测试，也不是对测试的设计，而是测试提交的产品时必须采用的测试基准。它是构建测试用例的输入信息，测试者通过测试用例来确保产品的每项需求都符合它的验收标准。验收标准是产品要执行的、无二义性的测试基准。通过检查需求描述和理由，确定哪种量化方式最能体现用户需求的意图，从而导出验收标准。
质量关是检查每项需求并确保它合适的活动，对需求活动提供清晰、完整和无二义性的描述，说明要构建什么，所有的需求都必须经过质量关的确认。当规范的潜在需求到达质量关时，它应该足够完整，以便能进行测试，决定是否纳入规格说明书。被拒绝的需求退回给提出者，要求澄清、修改或取消。质量关防止不受欢迎、不想要的需求进入规格说明。
拒绝的需求：
质量关守关人的任务就是确保验收标准是合理的需求测量指标，即可以对照需求来测试产品。验收标准使用数据来表达需求，但数字本身必须不是主观确定的，要基于事实依据。验收标准可以采用事先定义的标准。安全需求可能也会采用标准作为验收标准，要么是特定行业的安全标准，要么是组织结构自己的安全标准。验收标准采用数字还是引用标准，取决于需求的类型，执行需求和可用性需求通常采用数字，而观感、安全和文化等需求大多采用标准。高价值的需求要沟通和谈判，低价值的需求要放弃。在“伙伴结对”中，需求分析师相互测试得到的需求。如果两个分析师懂得客观地对待彼此的工作，这种策略最有效。质量关对潜在的需求进行测试，评估标准如下：
通过防止不正确的需求进入规格说明书，质量关降低了开发成本。因为尽早消除错误是开发产品最快、最省钱的方式。
第十四章 需求与迭代开发一些开发技术如SCRUM、Crystal Clear、极限编程、看板等，这些技术的目的是迭代式地交付能工作的产品，迭代式地构建产品。分析业务需求是一项持续的活动，收集新的业务要求并对它们进行探讨、评估和排列优先级。大多数迭代过程通过用户故事来沟通，一组用户故事代表了下一个发行版需要的功能。用户故事是一种方式，它大致相当于产品用例（PUC）场景中的一个步骤，用户故事起源于极限编程，但现在已经被大多数迭代方法所接受。用户故事的常见形式是：最为[角色]，我想要[功能]，以便能实现[理由]。故事写下来，被加到开发列表中，为它们排列优先级，根据架构和开发的要求，当然还有业务的要求。这种优先级排列是连续的。
用户故事确定了产品要为用户做的事情，但它也必须关注业务用例所确定的业务问题，因此，BUC作为故事的起点，每个BUC通常导出一个或多个故事。BUC提供了业务指导，这样用户故事会支持业务，而不只是确定用户界面。好故事带来卓越的产品。
扩展用户故事设计一些领域专家的输入信息：业务、易用性、安全性、观感等非功能需求。业务是项目中最关键的部分，业务知识很重要。因为业务分析师既不属于业务，也不属于开发团队，所以业务分析师是业务知识的有用来源。技术知识体现为开发者、系统架构师、测试员、外部供应商等角色的某种组合。业务专家关注业务的运营以及他们的日常工作，技术专家投身于解决方案和追踪最新技术，他们的工作是完成项目和解决问题。
有了业务分析师和其他人给出的输入信息和解释，开发者写下最能满足业务要求的故事。开发者对开发列表中的用户故事排列优先级，针对选出的故事，扩展并决定产品下一个发行版要实现的原子需求。
在一个组织结构中，项目常常构建相同或类似的产品。需求复用指利用为其他项目写下的需求。有一下几种来源：规格说明书的复用库、相同领域的需求规格说明或来自其他人的经验。成功的复用始于一种组织文化，这种文化有意识地鼓励复用，而不是重新发明。启动会议的提交产物为确定可复用的知识提供了关注点，否则这些知识也许不能发现。如果每个人都按一致的方式来组织需求和使用术语，那么所有的需求就更容易被将来的项目路复用。
非正式的、有关经验的需求复用：当我们向同事问问题时，我们希望从他人的经验中学习，这样不必从头开始努力。一旦知道了工作的上下文范围，就可以寻找针对全部或部分这一上下文的需求规格说明，将它们作为潜在可复用需求的来源。采用训练有素的过程来编写需求规格说明书有一项好处：得到的需求更容易被将来的项目复用。
编写需求不是一项单独的活动，而是在网罗和发现需求时完成的。将潜在需求变成书面需求，它必须包含清晰、完整、可测试的要求，说明必须构建什么。将半成形的相反变成准确的、可沟通的需求表述。项目通常组合使用电子表格、字处理程序、需求管理工具、建模工具以及老式卡片来管理知识模型中展现的信息。
原子需求的属性：
有许多不同的自动化需求工具，工具清单参见
编写需求规格说明不是一项随意的活动，业务事件、业务用例、产品用例、模板和需求框架使之成为一个有序的过程，而且它们也随着度量完成程度，更重要的是，指出哪些地方需要完善。需求知识管理是管理需求知识的文档系统的一种抽象视图，它为追踪一部分知识对其他知识的影响提供了基础。正确地编写需求是很重要的，一组好的需求能得到数倍的回报：构建工作更精确，维护成本更低，完成的产品更准确地反映了顾客的需要和想法。
质量关已测试并接受了单项的需求，它们被允许进入规格说明，现在需要评估规格说明是否完整。这种复查可以迭代进行，最好每次针对一个产品用例的需求。复查的过程是迭代式的，寻找问题或遗漏、修正问题。有一种相当有效的规格说明复查方式，它是一个正式的过程，成为审查。审查过程开始时，由一名协调人确定要审查的材料和审查者，审查者收到被审查的文档的概要，用一天的时间来研究这些材料，审查会议利用以前发现的问题的检查清单来分析文档。如果发现新错误，就会更新清单。审查工具是非常有效的工具，确保了需求的正确性和完整性。为了进行复查，不必产生更多的文档，只要更好地利用已有的信息。复查过程如下：
排列需求优先级，可以将需求分组，并将它们作为一个单元来排列优先级。影响优先级的因素：
常见的需求优先级登记是“高”、“中”、“低”等，优先级可以预防某些冲突的发生。冲突的产生可能是因为不同的利益相关者提出了不同的需求，或者利益相关者提出的需求与客户对需求的想法不一致。这对于大多数的需求收集工作来说都是正确的，它表明需要建立某种冲突解决机制。作为业务分析师，要将冲突的需求隔离出来，单独与每个利益相关者沟通接触。
规格说明书用到的所有术语，都必须在数字字典部分得到明确定义。如果每个词都有达成共识的定义，而且一致地使用术语，那么整个规格说明书的意思就是一致的和无二义性的。
风险评估不是正在的需求，而是项目问题。作为需求分析师，不必独自进行风险分析，如果组织机构足够大，员工中应该有人接受过风险评估方面的培训。业务分析师在风险评估中的角色，是考虑需求是否包含某种风险，可能影响项目的成功。
项目驱动
- 项目驱动
- 客户、顾客和其他利益相关者
- 产品用户
项目限制条件
- 强制的限制条件
- 相关事实和假定
功能需求
- 工作的范围
- 业务数据模型和数据字典
- 产品的范围
度量所需的工作量
复查是为了评估需求规格说明的正确性、完整性和质量。复查才有机会测量构建产品的好处、成本和风险，从而评估是否值得继续开发该产品。
掌握需求过程为分析方面提供了一个众人期盼的“前传”。
顶 0 踩 0
我的同类文章
参考知识库
更多资料请参考：
猜你在找
关闭
查看评论
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
个人资料
lipeishenshen
积分：260
文章搜索
文章分类
文章存档
阅读排行
评论排行
推荐文章
最新评论
qingteng826: 学习了
本文关键词：掌握需求过程，由笔耕文化传播整理发布。
本文编号：329088
本文链接：https://www.wllwen.com/wenshubaike/mishujinen/329088.html
