- 需求工程优秀实践
找出并使用行业最佳实践，这才是更高效的。最佳实践方法是丰富工具箱，运用不同技术来应对不同的挑战。
需求工程优秀实践
需求开发过程框架
需求工程包括获取、分析、规范说明和验证。但不能只是简单以一种一次性线性顺序来实施这些实践。实际上，这些活动是相互交织、渐进的和迭代式的。
需求开发是一个迭代的过程
一个典型的需求开发流程
需求管理所包含的实践能够帮助理手头上已有的需求。这些实践包括版本管理以及建立基线、变更控制、跟需求状态以及跟踪对其他系统元素的依赖。
优秀实践：需求获取活动
>定义产品愿景和项目范围
愿景和范围文档包含产品的业务需求。愿景描述可以使所有干系人对产品的产出有一致的理解。范围界定了发布或者迭代中哪些功能应该（或不应该）出现。
>识别用户类型及其特征
建立用户角色——也就是一种虚拟人物——来代表特定用户类型。
>为每类用户选出用户代表
为每类用户找出一个能精确传达用户心声的个人——产品用户代表。他提出用户组的需求，并代表用户组做决策。
>安排由典型用户组成的焦点小组
收集他们期望有的产品功能及质量。与产品用户代表不同，焦点小组通常没有决策权
>与用户代表协同发现用户需求
用户需求的表达方式包括用例、用户故事或场景。讨论内容还包括用户与能使其完成各项任务的系统之间的互动关系。
>识别系统事件和反应
列出系统可能经历的外部事件及其对每个事件可能做出的反应。
>举办获取访谈
访谈可以是一对一的，也可以是和一小组干系人。这是一个获取需求的高效方式，可以避免占用干系人过多时间。
>举办并引导需求获取讨论会
通过需求获取研讨会，分析师和客户能够精诚合作，高效地探索用户需求和起草需求文档（Gottesdiever 2002）。
>观察用户如何工作
观察用户如何完成其任务目标，能够了解到一个新应用在这些用户中的潜在用途。
>分发调查问卷
调查问卷这种方式就是调查大量用户群并判断他们有哪些需要。
>分析文档
现有的文档可以揭示系统目前如何运行或者人们期望它如何运行。
>检查现有系统在需求方面的问题报告
从用户那里获取问题报告和改进请求为我们提供了丰富的候选项，我们可以将这些新增需求或改进纳入下一发布或新产品之中。
>重用现有需求
如果客户所要的功能跟现有系统中已经提供的功能类似，就要看需求（以及客户）是否能够变通，允许重用或者改写已有组件。
优秀实践：需求分析
需求分析包括需求的精炼，使所有干系人都能够理解并检查出错误、遗漏以及其他缺陷。分析还包括将概要需求分解成更细、粒度层次更合适的需求,建立原型，评估可行性以及协商优先级。
>为应用环境建模
系统环境关系图是一种简单的分析模型，展示的是新系统如何适应其环境。它定义了开发中的系统与外部实体（例如用户、硬件设置或其他系统）之间的界限以及接口。
>创建用户界面以及技术原型
当开发人员或用户对需求不太确定时，需要创建一个原型：一个部分的、可能的或者初步实现的模型，目的是使概念及各种可能性更真实一些。原型可以让开发人员以及用户对所解决的问题达成共识并有助于验证需求。更多信息请参见第15章。
>分析需求可实现性
业务分析师应当与开发人员协同工作，评估在成本可接受范围内每个需求实现的可能性及其在设定环境下的效果。这样可以让干系人了解实现每个需求可能存在的风险，
>需求按优先级排序
需求按优先级排序可以保证团队首先实现价值最高或者最具有时效性的功能。
>建立数据字典
把与系统相关的、对数据内容和结构的定义存储在数据字典之中。这样能够保证项目中的每个人都使用一致的数据定义。
>为需求建模
图表是一种分析模型，与文本方式的功能需求列表不同，它可以将需求可视化。模型可以揭示出错误的、不一致的、缺失的或是冗余的需求。
>分析系统与外部世界之间的关联
所有的软件系统都通过外部接口与外部世界联通。信息系统有用户界面，并常常与其他软件系统交换数据。
>将需求分配给子系统
一个包含多个子系统的复杂产品，将其需求分派到各个软件、硬件以及人工子系统和组件。
优秀实践：需求规范说明
需求规范说明的精髓就在于用一致的、可存取、可评审的方式记录不同类型的需求，且目标读者都理解这些规则。
>使用需求文档模板
模板所提供的标准结构可以用来记录与需求相关的各类信息。即使不用传统的文档形式存储需求，模板也能提醒你还有各类的需求信息有待发掘和记录。
>明确需求来源
为了让所有干系人了解每个需求存在的合理性，就需要对其进行追根溯源。通过记录需求所影响到的干系人，你可以知道在有变更请求时应该该联系谁。需求来源可以用一个可跟踪的链接标示或者定义一个需求属性来做跟踪。
>每个需求一个唯一标识
制定一个规则，用于给每个需求打上独立的标识。这个规则必须足够健壮，能够禁得住时间的考验，允许对需求增加、删除和变更。标识需求使需求具有可跟踪性，并能记录变更。
>记录业务规则
业务规则包括公司政策、政府法规、标准和算法。要将业务规则从和项目需求中独立出来记录，因为其生存期通常比具体的项目更长。
>记录非功能需求
包括性能、可靠性、易用性、可修改性等。
优秀实践：需求验证
验证能够保证需求的正确性、展示期望的质量特性并满足用户需要。
>测试需求
测试为需求提供了另一个视角。写测试也就是要你考虑如何证明系统是否正确实现预期功能。我们从用户需求中设计测试，就是想记录特定情况下产品的预期行为。
>定义验收标准
让用户自己说出如何判断解决方案是否满足自己的需要以及是否可用。
>模拟需求
用户可以与模拟系统交互来验证需求并做出设计决策，使需求在还没有进行代码实现之前就被赋予生命力。
优秀实践：需求管理
>建立一个需求变更控制流程
变更流程应当定义如何提出、分析和解决需求变更。所有提议的变更都通过这个流程来管理。
>对需求变更进行影响分析
评估提出的每个需求变更并确定它们对项目可能造成的影响。使用需求跟踪矩阵来发现其他可能需要修改的需求、设计元素、源代码以及测试。
>建立基线并控制需求集合版本
基线定义的是大家都认可的一组需求，通常是一个特定发布或迭代内的需求。当需求基线确定后，如果要做变更，就只能通过项目变更控制流程。我们要赋予需求规范说明书的每个版本一个独特的标识，避免将草稿与基线或者旧版本与当前版本搞混。
>维护需求变更的历史记录
每做一次需求变更，就要留下一个历史记录。
>跟踪每个需求的状态
为每个影响产品实现方式的独立需求都建立一个记录。保存每个需求的关键属性，包括状态（例如提出、批准、实施或验证）。这样可以监测在任何时间点处于每个状态的需求个数。随着需求在开发和系统测试中的进行，要对每个需求进行跟踪，从而深刻洞察整体项目状态。
>跟踪需求问题
问题跟踪工具可以帮助我们避免遗漏问题。我们要为每个问题指定专门的负责人，监控需求问题的状态，以此来判断需求的整体状态。
>维护一个需求可跟踪矩阵
把每个功能需求与设计、实现它的代码以及验证它的测试相互联系起来，这样做通常很有价值，甚至不可或缺。
>使用需求管理工具
商业版的需求管理工具可以在数据库中帮助存储各种类型的需求。
优秀实践：知识
>训练业务分析师
不管团队中谁承担业务分析师的任务，都应当参加需求工程方面的培训，无论他们的职位是否是“业务分析师”。
>帮助干系人理解需求
需求培训课要想收到最好的效果学员最好可以横跨很多个项目领域，而不只是局限于业务分析师。参与软件开发的用户应当接受一到两天需求方面的培训，理解术语、关键概念和实践及其对项目成功的重要性。此类信息对开发经理和客户经理也很有用。将不同的干系人召集在一起，为他们准备一堂软件需求课，这也是一种有效的团队建设活动。
>帮助开发人员理解应用领域
为了让开发人员对应用领域有一个基本的认识，我们可以组织一个研讨会介绍客户的业务活动、术语以及待建产品的目标。这有助于减少以后工作中的困惑、误解以及可能的返工。
>制定一个需求工程流程
将组织所遵循的获取、分析、规范、验证以及管理需求的流程记录成文档。为如何完成其中的关键步骤提供指引，使分析师一直得心应手。
>建立词汇表
词汇表，是对应用领域中专业术语的一种汇总，它有助于消除误解。
优秀实践：项目管理
选择一个合适的软件开发生命周期
组织应当根据不同的项目类型以及需求的不确定程度指定多种相应的开发生命周期。将需求活动纳入生命周期。
>规划需求活动
每个项目团队都应该计划如何进行需求开发和管理实践活动。需求获取活动计划可以保证你用最合适的技巧在恰当的项目阶段找到适当的干系人并从他们那里获得信息。
>估算需求工作量
千系人一般都需要知道项目中需求开发阶段需要多长时间以及花在需求开发和管理上的工作量占总工作量的比例。
>基于需求确定项目计划
随着项目范围和需求细节逐渐清晰，以迭代方式制定计划和时间表。
>识别需求决策人
项目团队需要找出决策者并给他授权，最好是在首次做出重大决策之前就做到这一点。
>当需求变化时重新协商项目承诺
项目团队承诺在预定时间及预算内交付特定的需求集合。随着你在项目中加入新的需求，需要重新评估基于现有资源是否仍然能够完成原来的承诺。
>分析、记录以及管理与需求相关的风险
项目风险管理活动的一部分，要识别并记录与需求相关的风险。
>跟踪在需求上花费的工作量
为了能在未来项目中提高对需求所耗资源估算的准确性，要记录团队在需求开发以及管理中所花的工作量。
>借鉴其他项目中关于需求的经验教训
学习型组织会定期组织回顾会，收集以往项目或当前项目早期迭代中的经验教训。
需求工程的优秀实践
- 业务分析师
>在每个软件项目中，都有人在显式或隐式地扮演业务分析师（BA）的角色。
>业务分析师是能够在组织中促成变化的人，他们通过定义需求和向干系人推荐有价值的解决方案来促成这些变化。
>分析师获取和分析他人的观点，将收集到的信息转换为需求规范说明，并与其他干系人沟通和交流这些信息。
>分析师帮助干系人发现他们所描述的需求与实际需要之间的差别。
业务分析师的角色
>业务分析师的首要职责是获取、分析、记录和验证项目干系人的需要。
>业务分析师在收集和传播产品信息时扮演主要角色，而项目经理的主要职责的是沟通项目信息。
不要妄想谁不经过培训和辅导就能自动成为高效的业务分析师，即使他是有天赋的开发人员或知识渊博的用户。
业务分析师的职责
作为业务分析师，可能要执行下面描述的这些典型活动。
>定义业务需求
首要任务是帮助业务或者出资方、产品经理或者市场经理定义项目的业务需求。
>确定项目干系人和用户类别
针对每个用户类别，与业务发起人共同选出合适的代表，争取得到他们的参与，确定其责任。
>获取需求
积极主动的分析师能够熟练使用各类信息收集技巧，帮助用户阐明自己需要哪些系统功能，满足其业务目标。
>分析需求
与干系人协同工作，共同确定对用户需求和功能需求的说明需要具体到什么程度。
>记录需求
分析师在记录需求时需要做到结构清晰，有条理，能够清楚描述将用于解决客户痛点的解决方案。
>沟通需求
作为业务分析师，必须与所有各方高效而充分地进行需求沟通。沟通还涉及与团队持续不断地合作，确保他们能够理解你想要表达的信息。
>主导需求验证
检查需求引发的设计和测试，确保人们对需求的解读是正确的。
>帮助推动需求优先级排序
负责对各类干系人和开发人员进行合作和协商，保证他们做出的需求优先级决策是合理的，与达成业务目标是一致的。
>管理需求
业务分析师全程参与整个软件开发生命周期，因此会帮助创建、检查和执行项目的需求管理计划。对需求基线的变更进行管理。
基本的分析技巧
>倾听技巧
要想成为双向沟通专家，就要学会如何有效倾听。
>访谈和提问技巧
提出的问题必须恰当，才能引出基本的需求信息。如果有经验，就能熟练应用提问艺术，揭示并澄清不确定、有分歧、想当然和隐晦的种种期望。
>才思敏捷
要发现哪些地方是矛盾的、不确定的、模糊的和想当然的，以便在合适的机会对它们进行讨论。
>分析技巧
要有高、低两级抽象思维能力，并且能自由切换。需要严格评估信息，以求协调矛盾，从基本的真实需要中独立出用户“想要的”，并区分提议方案与需求之间的差异。
>系统思考的技巧
必须做到事无巨细，但也要有大局观。业务分析师要参照他所了解的企业整体、业务环境和应用来核查需求，找出矛盾之处及其影响。他需要理解人、过程、技术与系统之间的关系。
>学习技巧
快速吸收新的需求方法或者应用领域内的新知识。能将知识高效转化为实践。处理大量材料并迅速掌握精髓。
>引导技巧
能够引导需求讨论和获取研讨会。引导是带领团队迈向成功的关键步骤。很高超的提问、观察和引导技巧，能够帮助团队建立互信，还能改善业务人员和口员工之间偶尔的紧张关系。
>领导力技巧
拥有各类技巧，以协调项目的干系人之间的关系、解决冲突并做出决策。要创造出一个和谐的环境，促进不同人群之间的互信。
>观察技巧
观察用户的工作过程或者使用当前的应用程序，敏锐的观察者可以捕捉到客户自己都没有察觉到的细枝末节。观察技巧有时能发掘出新的领域，从而揭示出额外的需求。
>沟通技巧
扎实的语言功底，能用书面或者口头形式清晰地表达复杂的概念。
>组织技巧
应对不断变化的信息，并将这些信息碎片构建成一个整体，这就要求他们具备非凡的组织技巧、耐心和不屈不挠的精神，从混沌和混乱中理清头绪。有能力搭建一个信息架构，在项目进展过程中丰富它，使其能为项目提供信息支持。
>建模技巧
需要根据模型所发挥的作用来判断具体模型的适用时机。让其他干系人明白使用这些模型的价值所在以及如何读懂模型。
>人际技巧
要使用对方能听懂的语言。沟通时，态度要随和，表达要清晰一致。
>创造性
能够挖掘出潜在的需求引发客户的思考。以创造性方式满足客户需要，而这些需要甚至连客户自己都没意识到。必须要尽力避免给解决方案“镀金”。
基本的分析知识
业务分析师需要将需求开发和管理活动纳入整个项目周期之中。如果分析师能够充分理解项目管理、开发生命周期、风险管理和质量工程，就能防止需求方面的问题对项目造成破坏。
打造一个协作型的团队
在软件项目中，分析师、开发人员、用户、经理和市场人员之间的关系有时比较紧张。各方都做不到完全的互信或理解他人的需要和难处。但在现实中，软件产品的生产者和消费者的目标是一致的。
分析师引领所有项目参与者达成需求方面的共识，从而在以下几个方面实现双赢。
>客户对产品感到满意。
>开发组织对业务成果感到满意。
>所有团队成员对自己在这项富有挑战但又回报丰厚的项目中的优秀表现而自豪。
发表回复