产品精准需求过程模型.doc

附录A Volere需求过程模型 本需求过程模型由一系列具有层次结构的过程组成。要了解某一个过程的细节，请查看具有相同编号的过程图解或过程说明。例如，在下面的“Vo1ere过程模型汇总”中，有一个名为“项目启动”的过程(编号1)。图解1将展示该过程的细节。在本附录的“需求过程中用到的术语”部分有对本模型中用到的术语的解释。 图解9-0 Volere过程模型汇总 图解1 项目启动图解1.1准备项目启动会议 这是一个通用过程模型，用于提取、明确和复审需求。该模型将重点放在内容上。过程间的依赖关系通过接口来定义。该模型并不暗示任何顺序，它是一个异步执行的网络。这些过程的任意组合可以在任何时间发生。 该模型的目的是提供一个需求过程，让您可以根据自己的环境进行剪裁。剪裁该模型的目的是使它与您自己的环境吻合，具体做法是通过将该模型重新分割以增加适合您的环境的检查点(复审、里程碑)以及明确负责执行这些过程的人。您也会将过程间的接口按照适合自己工作方式的格式打包。ProcessContinuum环境提供了一个该模型的自动化形式。该环境由PlatinumTechnologies提供，公司的网站是wwwplatinumcom定义项目启动目标(过程说明111) 定义启动阶段将得到的可提交产物。检查项目意图并决定启动阶段是否应该得到： 系统目标：这总是应该得到的。 工作上下文范围模型：也许存在一个已有的模型可以说明该项目的出发点，否则启动阶段必须提供一个新的上下文范围模型。 明确的风险承担者：总是需要的。 预期开发者：检查顾客所需的产品的类型。运用以前项目的经验来决定该项目所需的技术。预期开发者是最可能参加这个项目工作的人员清单。 系统事件：在某程度上，这总是要由启动阶段提交的。 事件用况模型：这在启动阶段得到，以证明项目的可行性。当项目很大，而且不存在占主导地位的事务时，在项目启动阶段就提供用况模型的作用是很小的。然而， 当项目有少量关键事务，初步的用况事件模型对决定产品能不能构造是很有帮助的。 系统术语表：在初始阶段应该得到初步的术语表，除非组织中已使用了定义良好的标准术语表。例如，一些行业有相关术语的国家标准或国际标准。 场景模型：这与事件用况模型的情况相同。计划物质l-的安排(过程说明112) 该过程的工作是确定物质上的安排，以达到启动阶段的目标。 根据该类型项目的需要，从潜在的风险承担者中确定参加者，包括所有可能在项目中有风险的人。最好将可能的风险承担者包括在内，而不是排斥在外。如果他们发现在产品中没有真正的利益，他们自然会发现有更好的事要做并离开您的风险承担者小组。 请认真准备会议设施和场所。记住会有不少人出席会议。如果您希望留住他们，就应该保证有足够的设施让他们觉得时间花得值得。确保您已确定了： 启动会议的地点； 如何到达会议地点； 会议组织者的名字和联系方法； 日期和时间； 项目启动所需的时间天数或小时数； 参加者名单与参加者沟通(过程说明113) 保证所有的参加者都知道项目启动会议的地点和将持续的时间。给每个参加者发送一份会议日程以确保他们在到会之前就理解期望他们做些什么。重要的是您留给参加者的印象，即他们参加项目启动对产品的价值，为什么他们做这件事，以及该产品对您所在组织的价值。在每份邀请函中附一份参加者名单。每个参加者必须回应并承诺到会，您需要确保他们为了完成该任务有备而来。图解1.2 召开启动会议确定产品目标(过程说明121) 该项任务是问“我们需要这个系统做什么?”但不讨论我们如何才能构造该系统。系统目标是一份清楚的、无二义性的并可测量的说明，精确指出了您的客户在项目结束时需要得到什么样的产品。 这应该是一份简短的说明，一句话或至多两句话，或许在下面加一些圆点来突出重点。 这项任务的实际意图是问“该项目可行吗?”如果不能得到所有风险承担者一致同意的系统目标表述，那么该项目就不会得到任何有价值的东西。类似地，您对目标的描述必须让您在达到该目标时能清楚地知道。如果您描述了用于测量目标的标准，那么这些标准必须有很强的约束力，同时很清楚。 不能得到一个产品目标的合适说明就意味着您应该认真考虑放弃或延迟该项目，直到您的风险承担者能达成一致。 每个目标说明都必须包含下列内容： 目标的简短描述(请尽量用一句话描述)。 目标后面的根本原因问为什么客户有此目标?客户的业务优势是什么以及他如何度量成功? 测试的通过标准，您将使用这些标准来判断目标是否达到。确定工作上下文范围(过程说明1。22) 上下文范围是需求的起始点。上下文范围图将您为了达到系统目标所要研究的部分隔离出来。上下文范围图展示了您的项目与其他人、组织和技术之间的接口。您的项目与哪些东西有关?期望系统完成什么?这里是达成初始一致意见的好地方。上下文范围很少做到应该的那样大它应该包括整个应用领域。您应该小心，不要把上下文范围设得过小，或是只分析期望的计算机系统的上下文范围。用户常常这样描述他们想要的系统，即他们认为一台计算机可以做的事情。因此，如果接受这种对计算机系统的描述，您就会失去其他一些将过程自动化或改进过程的机会。您的上下文范围描述应该包括业务过程在内，这些业务过程与理解您的项目的实质问题有关。某些业务过程由您的最终用户执行(条件是他们帮助您理解应用领域)，这些业务过程应该在您的详细上下文范围研究范围之内。进行“第一刀”风险分析(过程说明123)这是关于构建期望的产品的主要风险的评估。团队需要问的问题是： “如果构建该产品，我们面对的主要风险是什么?” “如果风险真的发生，会出现怎样的情况?” 例如，设想产品是一个新的假日旅行者订房系统，与这类系统相关的主要风险可能是： “如果我们没准备好假日旺季会发生什么情况?” “系统是给旅行代理用的。如果我们构建的系统学习使用的周期太长会发生什么情况?” “该系统必须与航线系统接口。如果在我们的系统构建好之前航线系统发生变化会发生什么情况?” 在说明风险时，一定要保持无情的诚实。在启动会议上，某些风险可能像是针对某些人的批评。如有必要，可以考虑采用匿名的方式提出风险。 风险是那些您能想象到的最坏的情况。建议检查的风险包括： 我们提交该产品的时间进度表是否不切实际? 如果我们不能按时得到该产品，会发生什么情况? 我们是否对该产品抱有不切实际的期望? 我们是否具备构建该产品所需的人力和技术? 需要哪些新技能? 我们以前构建过这类产品吗? 其他一些项目在我们实施时出现了什么问题? 我们实施或在别处实施时，这类系统曾经出现过什么问题? 我们过去哪些方面做得很糟? 对于该项目有哪些外部影响?例如，是否有一些法律正在建议改变，将影响到该产品?在产品提交之前公司会重组吗? 该产品需要什么新技术? 我们是否依赖于由外部提交的一些产品? 对于该项目需要的一些其他产品，我们是否做出了不切实际的假设? 对该项目我们是否有一个正确的管理结构? 该项目是否存在“镀金”的危险?请记住，在这个阶段对风险保持诚实会极大地增加产品构建成功的机会。确定风险承担者(过程说明124) 确定所有在正在构建的产品中被授予利益的人，他们是风险承担者。风险承担者参与需求收集阶段的工作，并决定他们想要构建的产品。 您要找出将受到该产品影响的人，或参与产品开发的人。尽管风险承担者名单不必大到包括所有构建相关的人员，但也不应将在产品中有真正利益的人排除在外。这样做在以后会产生影响，可能会破坏您的项目。 风险承担者必须明确列出每个人的名字，不要接受“来自会计室的某人”这样的描述。下面是一份可能的风险清单者的核对清单： 客户负责为开发付钱的人； 顾客购买该产品的人或组织： 用户(这阶段还是潜在的)将在工作中使用该产品的人或组织： 负责人负责项目鉴定和健康发展； 市场部门： 开发者负责开发该产品的人或组织； 领域专家主题相关知识的来源： 技术专家在主题相关的产品非功能性需求方面有专业经验的人或组织，这些非功能需求包括机器、法律、操作环境等等(更多的内容请参见Volere需求模板)： 测试者负责测试需求的品质的人。 对每个风险承担者，需要弄清楚： 风险承担者的名字； 风险承担者的特长(如会计、定价、制造等)； 预期该风险承担者需要为项目付出的时间(很难在项目启动阶段就了解这一点。但是考虑一下您是否有一些天数周数方面的暗示，以及参与的频繁程度也是很有好处的)。分解工作(过程说明125) 将上下文范围分解为业务事件。 术语“事件”用在这里的意思是指对您研究的工作产生影响的业务事件。您需要研究这些事件，以便获得足够的知识宋决定产品的最佳范围。 先从系统外开始看，寻找那些会引发与相邻系统通信的事件和您的工作的上下文范围。例如，当一个客户下了一份订单要向您的系统请求一些服务时，这就是一个事件。 系统并不是这些事件的发起者，但必须响应这些事件，所以如果来自于外界的任何信号到达，您的系统就必须做出反应，那么它就是事件。请记住这些是业务事件，而不是指单个的界面事件。界面事件是用户点击一个按钮产生的。考虑“无事件(Nonevent)”(过程说明126) “无事件”是指如果一个事件没有发生情况会如何。例如，假设您有一个基本事件是“顾客为货物付款”。“无事件”就是如果顾客未付款情况会如何。是否有其他的事件发生，诸如追 踪信誉不佳的付款者? 检查每个业务事件并问一个问题：是否存在相关的一个或更多的“无事件”?将发现的新事件加入到您的业务事件列表中去。将新的数据流加入到您的工作上下文范围图中。确定系统术语（过程说明1.2.7）为数据项以及其他开发者和用户用到的东西建立大家认可的名字。从上下文范围图开始，写下围绕上下文范围的数据流描述。这样做的意图是就系统使用的每个数据项的常用术语达成一致。这项任务的结果是得到一份大家认可的术语和定义清单。定义项目限制条件(过程说明128)定义要求的限制条件，该产品必须在满足这些限制条件的情况下得到。从关于问题应该如何解决的意见中寻找真正的限制条件，明确下来： 解决方案限制条件要求使用的技术： 最后期限任何已知的最后期限： 财务预算： 当前系统限制条件。 每个限制条件都应该是可测试的。换言之，您是如何知道是否己满足该限制条件? 对每个项目限制条件问一个问题：“为什么它是一个限制条件?”这将有助于您区分真正的项目限制条件和看上去像是限制条件的解决方案。 更多的编写限制条件的指导请参看Volere需求模板。确定感兴趣的领域(过程说明1.2.9)产品的目标是我们的出发点，由它确定哪些主题对我们研究的领域来说是重要的。对每项产品目标说明问一个问题：“这个目标是否提到或暗示了主题相关的领域，需要我们去研究以便构造该产品?”例如，假设一个目标是为公众提供轨道交通。于是我们可以说，我们要研究轨道交通以及公众问题领域。一个感兴趣的问题是：这些领域与我们要构造的产品之间有多大程度的关系?当我们设置奸该问题的上下文范围时就可以关注该问题。图解1.3 项目启动阶段总结编写项目启动报告(过程说明1.3.1)编写一份报告，描述通过项目启动会议达成了哪些东西。该报告应该包括： 工作上下文范围图解和关于要研究的工作边界的主要决定及其原因； 风险承担者清单列出启动阶段确定的所有风险承担者。同时也列出那些被排除在风险承担者之外的人，并说明原因； 开发者清单列出项目工作所需的所有人员： 首要事件或用况清单。列出到目前为止确定的所有事件用况。该清单并不完整，但可作为首次对工作量估计的依据； 到目前为止已被大家接受的系统术语表； 主要风险。这是要引起管理层注意的； 完成该项目需要的工作量的初始估计； 建议进行下去或终止。同时说明不要进行下去的原因，以及哪些条件改变后(如果有的话)，项目可以进行。请记住需求框架(Requirements Skeleton)是构建需求规格说明书的第一步。换言之，您在需求框架中写的所有东西都将用于构建需求规格说明书的过程。复查启动阶段成果(过程说明1.3.2)查看需求框架，把已收集到的内容与需求模板进行比较。确定作为一个框架，它是否有足够内容以完成需求规格说明书。该模板是您要编写的需求规格说明书的一个指南。这样做的意图并不是在本阶段得到一份完整的需求规格说明书，而是希望知道在给定时间内，能不能得到需求规格说明书。项目目标与启动会议计划是否相符?换言之，启动会议提交的产物是否足以开始收集正确需求的任务?是否存在突出的问题?为所有突出问题编制一个清单。如果提交的产物不够完整，那些突出问题就作为跟进启动会议(follow-upblastoffmeeting)的输入。这个过程作出是否要让项目继续下去的决定。继续终止的决定是一项必须有清醒认识的任务。该问题可能在启动会议期间被询问数次。Jim Highsmith和Lynne Nix在“Feasibility AnalysisMission lmpossible”(Software Development杂志，1996年7月)一文中提供了下面的检查清单，明确何时您不应该让项目进行下去：1主要政策问题在启动会议上没有得到解决。2关键风险承担者将不参加启动会议(因此可能不参加该项目)。3风险(产生负面影响的可能性)太高(技术的、经济的、组织的)。4投资回报率不够吸引人，特别是回报的利益不可测量时。5内部员工对该项目的经验和培训不够。6需求不清楚，或在启动阶段就频频变化。7风险和回报率不成比例。高风险通常要有高回报才有价值。8客户(在一个涉及多学科的项目中)不能就问题或目标到底是什么达成一致。9没有主管经理愿意成为项目的负责人。10实现计划看上去太浮于表面。 对系统目标应该存在可测量的说明： 顾客必须感到满意，认为该产品是值得的； 开发者必须感到满意，认为他们能够构造该产品： 双方对构建产品的估计都感到满意； 最终用户必须感到满意，认为该产品将带来好处。如果事情在这个阶段看起来没什么希望，现在就放弃该项目比进行几年后再放弃要经济得多。请记住项目启动阶段的首要目标是确定项目是否可行。跟进启动会议(过程说明133)这是一个小型启动会议，操作方式与前面的会议一样，但特别关注那些突出的需求问题。除非这些问题得到解答，否则继续该项目的风险就太大了。请记住，您是在试图达到启动阶段的目标，而不是要知道关于系统的所有事情。作出初步估计(过程说明134)对构建该产品所需的工作量作出首次估计。在这个阶段作出的估计不必非常精确，但必须实事求是。它可以基于一些简单的度量标准，诸如系统必须响应的事件的数目，或组成系统的用况数目。事件用况为您提供了一个可管理的大块(chunk)，可以作为工作量估计的基础。估计实现一个事件的平均工作量，然后根据这个数据来估计在您的工作上下文范围内的所有事件的工作量。根据对数据了解多少，您可能可以得到一个初步的系统功能点计数。计数的类型和计数的边界范围(项目上下文范围)已经确定，大致的数据和事务功能也是已知的。也可以将数据的复杂度作为度量标准，来估计工作量。大致说来，就是系统将用到的数据实体的数量。这种估计方法要求知道实施一个数据实体的平均代价是多少。尽管这不是十分精确的估计，但它提供了一个起点。请记住，如果这是您第一次使用我们推荐的开发方法，以前关于每个功能点(或其他)所需的工作量的历史数据可以融合进来，这样可以降低新过程的学习难度。图解2 知识网罗图解2.1 学习工作复查当前状况(过程说明2.1.1)当您复查当前状况时，请记住您并不是在试图指定该系统，而只是建立用户当前所面对的状况。很可能用户描述业务的方式中包括了他们用来完成工作的机制，但是这些机制却并不是新系统的需求：你必须透过这些机制，发现用户系统的底层策略。不管当前系统的口碑有多么差，它都不会是毫无价值的。它可能有很多功能，对业务做出了积极的贡献。这当然就意味着当前系统的某些部分必须被包含在任何将来的系统中。您可能利用新技术以不同的方式实现它们，但它们背后的业务策略将几乎保持不变。因此对当前系统的复查的目的是，确保您在引入任何新的改进之前理解了当前的状况。当前状况模型可被用作业务过程再工程的输入。做用户的学徒(过程说明2.1.2)这一点是基于师傅和学徒的想法。系统分析师成为用户的学徒，与用户坐在一起，通过观察和问问题来学习该工作。不太可能做到许多用户都能以足够详细的方式解释清楚他们在做什么，让分析师能捕获所有的需求。但是，当人们正在做某事时，总是很善于解释他们正在做什么。如果用户正在他日常的位置上做他的工作，他就能提供一份动态的意见和建议，这样能提供一些细节，不这样做的话很可能漏掉这些细节。可能仅当用户在工作时，他才能精确地描述他的任务，告诉您他为什么在做这些事， 这种师徒关系消除了对一般化谈话的需要。如果我们离开工作，我们倾向于用一些抽象术语来描述工作，并描述一般性的情况。一方面，抽象是有用的；但另一方面，它并没有承载每次都能解决问题的足够细节(当用户向您展示特殊情况下采用的迂回解决方法时，您可以看到这种效果)。通过坐在用户旁边，学徒得到了一份动态的意见和建议，看到了所有的情况，以及每种情况下用户是如何采取行动的。最后，学徒学会了该任务，通过在用户的监视下真正地做该项工作来证实这一点。在以下情况中使用这种方式： 当用户不善于抽象时； 当用户没有时间与您交谈时。确定本质需求(过程说明213)目标是发现底层的系统的本质问题，而不是偶然地重新引入一项已知的技术或因已知的技术而存在的需求。开发者也在寻找人们使用的技能，以及他们在工作时是如何看待自己的。他们使用哪些概念化的东西和隐喻(metaphor)?抽象的方法是：用非技术的眼光来看应用程序。例如，一个位于伦敦的银行有20种不同的金融产品，每个产品是一种不同的方式(表面看来是这样)，用于保证出口商能收到境外货物的货款。产品形式多样，从信用证、担保的外国银行借贷，到保证金等。用户处理每种产品的方法初看起来是不一样的。然而，当开发者研究了实际工作并查看了目前使用的技术后，一个共同的本质浮现出来。最后的结果是，我们可以得到一个核心实现，然后处理每个不同产品的不同情况。在某些情况下，不同的窗口仅仅需要改动屏幕上的一些标题而已。需求头脑风暴(过程说明2.1.4)头脑风暴是一种产生想法的方法，这里的意图是得到关于新产品的尽量多的需求。不要太注意头脑风暴过程得到的想法是否都可用，我们的意图首先是得到尽可能多的想法。接下来，您会除去那些太昂贵、不切实际和不可能的想法。进行头脑风暴有一些简单的原则： 头脑风暴的参加者应该尽可能地具有广泛的不同学科背景，经验也各不相同。这种背景的融合给整个会话过程带来更多创新思想。 停止(至少是推迟)判断、评估和批评。在需求产生时，只是简单记录下来。不做评判、评估和批评的做法最容易在参与头脑风暴的人中建立起创造性和有活力的气氛。 产生大量的想法。得到尽可能多的想法，数量最终将反映为质量。 尝试得到尽可能多的想法，这些想法可能是反传统的、独特的、疯狂的和出格的。 想法越出格，就越可能具有创造性，也越可能变成一个真正有用的需求。 让新想法基于老想法。就是说，在一个想法上面构造另一个想法。 写下每一个想法，不作检查和删节。“如果不写下来，想法消失得比水蒸发得还要快。”(A1exOsbome，头脑风暴的发明人)。 如果您感觉受到了阻碍，可以从字典中随机取出一个词，作为开始思考的“种子”。 这个词作为产生想法的过程的一个起点。 在头脑风暴之后，结果将得到评估，其中一些最好的需求可以通过较为传统的方法来进一步明确。用户访谈(过程说明2.1.5) 用户访谈是需求收集的传统方法。然而，仅使用这种方法可能并不是最有效率的。我们强烈建议不要把访谈作为唯一的需求收集方法，而是将它与其他方法一起使用，有时其他方法能产生更好的效果。 需求调查工程师可以事先设计出调查问卷。尽管这为接下来的访谈提供了某种结构，但我们发现用户需要有很强的动机才会在见到需求工程师之前就认真填写调查问卷。我们建议您向用户(或其他要访谈的对象)发送一份议程表，包括您希望讨论的议题，这样至少给用户在手头准备一些材料的机会，或把主题方面的专家请到现场。 用户在访谈过程中不应该完全是被动的。您在访谈过程中与用户对话时，我们强烈敦促您建立模型事件响应、用况、场景等等。这可以立即给您和您的用户以反馈，允许您测试您听到的东西的准确性。你应该允许他们的个人习惯表示法，可以以后再纠正。 您也可以在观察工作完成的过程中对用户进行访谈。这样做的好处是，您可以直接就正在做的任务提问，这也给了用户一个较好的机会来描述该任务。人们不善于描述他们的工作，但当他们正在做时，常常比较善于告诉您他们正在做什么。 当用户向您描述一些事情时，特别是像需求这种概念化和较难的事情，他们通常很难做到精确描述。他们也会用抽象的术语来描述，而且很难精确地确定他们的意思。您可以使用阶梯法来帮助克服这一问题。阶梯法的观点是：根据您想了解什么，可以将他们说的东西在概念上向上推或向下推。顺着阶梯向下意味着你将听到的东西解构，以发现隐藏在陈述后面的事实， 然后进一步解构以得到更低层的事实。您也可能需要沿阶梯向上，即将对话转向更高的抽象层。 例如，您可能被要求开发一个系统，它能够快速响应顾客的需要。顺着阶梯向下的意思是， 您必须问(JJ陕速”的意义或测量方法。“当顾客的电话还没挂断时”就是一种测量方法，而更 低一层的事实是“您必须在一秒钟内找到顾客的记录”。通过顺着抽象的阶梯向下，您得到了一个确定的答案。 沿着阶梯向上也是有用的，它导致了结果和评判标准。例如，“系统应该快速响应，这样顾客不会等得不耐烦。”请思考访谈的抽象层次，多尝试一下其他抽象层次。这样做常常能有所发现。文档考古学(过程说明216) 文档考古学就是通过查看组织内使用的文档和文件来确定基础的过程，这些过程即需求。 这种方法不应该作为一种需求收集技术，而应该作为一种避免更密集的访谈的手段和建模工作的基础。 文档考古学工作从收集所有文档、报告、表格、文件(实际上是所有用来记录和传递信息的东西)的样本开始。正常的电话通话不应被排除在外。 查看文档(为简单起见，术语“文档”用宋代指上面所有的东西)，寻找名词，或“东西”。 这些可能是表格的列标题、表格中命名的矩形框，或只是文档里部分数据的名称。 对每个名词，问以下问题： 此物的目的是什么? 谁用它?为什么用它?用它做什么? 系统都利用它来做些什么? 如果我有A物，就一定要有B物，并且一定不能有C物吗? 此物会有一个值吗?例如，它有一个数字或代码或数量吗? 如果是这样的话，它属于哪些东西组成的集合? (数据建模的热心者会立即意识到需要找到拥有该属性的实体。) 此物的用途是什么? 文档中是否包含了一组重复的事物? 如果是这样的话，这些事物的集合称为什么? 我能找到事物之间的联系吗? 什么过程建立了它们之间的联系? 每件事物附加的规则是什么?换言之，哪部分业务策略涉及该事物? 什么过程确保了这些规则会被遵守? 什么文档带给用户最多问题?这些问题本身不会揭示所有的系统需求。然而，它们会给您充足的材料以及进一步调查的方向。我们也建议您把文档考古学作为数据建模方法的一部分。通过数据建模提出的问题总是非常富有启发性。制作需求录像带(过程说明2.1.7) 录像带可以用于协助开发软件。用户和开发者参与研讨会和头脑风暴，过程被制成录像带。访谈和现场观察到的事实也被制成录像带。录像带首要目的是记录过程，其次是确认过程。另外，录像带还可以给那些没机会与用户面对面的开发者看。 录像带可以作为访谈和用户工作现场的观察的联系。用户有他们自己的完成任务的方式。他们对自己所使用的信息有自己的分类方法，以及解决问题的方法。从他们所处的情况看来，这些方法很起作用。因此，通过录像来捕捉用户的工作，您就捕捉到了他们完成工作的方法和他们的考虑，而不是把您自己的期望和喜好强加于他们。录像带的使用可以更结构化，每次一个用况或事件。选择一个用况，要求用户按活动中遇到的典型场景走一遍。当他们工作时，用户描述一些特殊情况，他们用到的附加信息，异常情况等等。耸肩、做苦相和手势通常在笔录方式中都会略去，而录像会忠实记录下来，以便将来回放和分析。召开用况研讨会(过程说明218) 研讨会在合适的顾客用户与需求调研团队之间进行。研讨会的第一部分是得到场景，这 需要用户顾客提供信息，要点是从头到尾讨论一个用况事件并从用户那里得到本质的东西， 即当事件发生时必须进行的工作。您将试图确定一系列用户可识别的步骤，在该事件发生时完成工作。您要求用户确认改进改变您写下的那些步骤。由此得到的用况场景是该用况的一个很粗的需求草案。在用况研讨会之后，需求工程师回到自己的办公室，从用况场景中导出并明确单个的需求。构建事件模型(过程说明2.1.9) 您将关注系统的功能性部分。根据构成整个系统的业务事件将它进行分解。我们将使用术语“事件”来标识这种分解，作为一种方便的方式来关注系统的每项功能。 将系统按事件分解的目的是以一种一致的和可交流的方式将系统进行切分。事件分解就像是一把特别的刀，将系统切成逻辑上的、相互间联系最小的块。但是，除了简洁性之外，它还提供了一些好处： 事件间的联系非常小，因此您可以对各部分单独研究，不必陷入到系统的所有细节中去； 事件可以很容易地根据功能点进行度量，或使用其他度量方法。因此它易于基于实际的度量进行工作量估计； 管理者可以使用事件分解来监视进展。 对需求过程的主要好处是，事件让您能够分离系统的行为，以一种用户熟悉的方式来处理系统的功能。 发现事件： 工作上下文范围(work context)是识别事件的最佳地方。所有把系统和外界联系起来的数据流在某种程度上都是事件的一部分。从寻找相邻系统开始，相邻系统与待开发的系统通信。每个联系这些系统的分离的业务数据流都是一个潜在的事件，其中的一些只是简单的数据流，要求系统存储：其他一些将是与相邻系统的复杂的交互过程，一直持续到这一部分业务完成。 有一些从系统流出的数据，起因是一个暂时的事件。根据这一点来识别更多的事件。最后，您必须考虑到与系统相关的所有数据流。这些数据流要么触发某个事件，要么是某个事件的结果。有些事件同时有进出的数据流。当您列出了所有的事件，请考虑每个事件的功能。可能需要对某些事件进行建模，目的是能将需求看得更清楚。但是，在这一阶段，您应该避免陷于详细的建模工作。我们建议，场景模型可以作为一个工具，它对每个功能给出足够的描述，让您能编写它的功能性需求。构建场景模型(过程说明2110) 场景是一些确定的故事，说明用户操作目标系统的可能的方式。构建场景的目的是说明用户对某个特定事件的看法，并用于澄清一项需求的含意。场景可以使用多种媒介来构建。最简单的场景可能是纯文本，但更多的可能是图片或图解。 实际上您可以使用任何用户觉得满意的格式和媒介。图解2.2 确定产品范围研究相邻系统(过程说明2.2.1)针对每个业务事件： 如果您在学习工作的过程中已经建立了事件响应模型，那么使用该模型来研究相邻系统和事件处理： 否则 根据您对该事件的了解以及事件的复杂程度，勾画一个事件响应模型可能会有帮助。 * 寻找业务机会，即产品如何在项目限制条件下达成产品目标 * 对每个与相邻系统联系的输入、输出数据流和处理过程，考虑系统的限制条件和工作上下文范围，并问以下问题： 为了提供或利用该接口，相邻系统需要做些什么? 我们对相邻系统的研究是否足够识别出业务机会? 是否有一些由相邻系统完成的工作可以由本产品完成? 是否有一些由处理过程完成的过程可以由本产品完成? 是否存在一些机会，可以帮助人们更好地完成工作? 相邻系统最渴望的、期望的和考虑过的是哪些东西?定义用况边界(过程说明2.2.2) * 为业务事件确定用况 * 针对每个业务事件： 考虑业务机会； 复审工作知识。 * 决定产品和参与者(actor)之间的边界 * 针对每个用况(一个业务事件可能有多个用况)： 确定参与者的名称； 确定用况名称； 定义用况边界数据； 通过将该用况加入用况图，记录下产品上下文范围； 确保您跟踪了与该用况相关的业务事件名称。 * 如果用况数超过15-20个，用况图会变得过于复杂，这时需要画一个分层的用况图 *图解2.3 进行事件勘察收集业务事件知识(过程说明2.3.1) 这项活动是观察所有的工作知识，这些知识存在于每个业务事件中。使用事件边界作为收集所有工作知识和知识来源的指导。这项活动的成果是学习详细的工作的起点。 针对每个业务事件： 查找任何可能包含与该事件相关的工作知识的文档； 查找报告、表格、规范、用户手册、组织图表、可行性研究、产品文档、市场广告等任何可能包含深藏起来的需求的文档； 列出工作知识的来源名称： 在工作上下文范围边界之内的人： 相邻系统： 在工作上下文范围边界之外的人； 一个可能具有该事件知识的团体名称： 是否存在一些领域模型包含了该事件的知识? 是否存在一些可重用的需求包含了该事件的知识?选择合适的网罗技术(过程说明2.3.2) 为了选择最合适的业务事件网罗技术，您需要考虑以下问题： 可能的知识来源是什么? 您在寻找哪一类型的需求：业务策略结构、存储数据、人机界面、基本活动? 您能直接与人交谈吗? 这种知识是有意识的、无意识的还是从没想到过的? 以下是一些网罗技术的优点： 复查当前状况： 善于揭示无意识的需求： 有助于增加新的需求或对现有系统作维护性改动： 作为业务过程再工程的基础。 做用户的学徒： 有助于揭示无意识的需求和有意识的需求； 如果用户因“太忙”而无法交谈，这种方法很有用。 确定根本需求： 有助于将需求和解决方案分离； 是理解系统的真正目标的一个好办法： 有助于揭示无意识的需求，同时提供见解，触发从没想到过的需求。 用户访谈： 发现有意识的需求的奸办法。 头脑风暴： 有助于发现从没想到过的需求。当发明了新产品，而潜在用户的情况不太清楚时，这很有用。 用况研讨会： 让用户参与解释模糊、复杂、困难的事件； 善于揭示有意识的和无意识的需求。 文档考古学： 用于信息来源己被文档化的情况。 构建事件模型： 如果业务事件的边界较模糊，那么通过建立一些详细的模型进行调查。制作需求录像带 当用户时间有限时很有用。可以在以后让一组人来研究、分析和使用。 在上下文范围模糊时有帮助。询问澄清问题(过程说明2.4) 复查需求问题和系统限制条件问题。使用需求模板作为辅助。 您能确定需求类型吗? 是否存在这类需求的度量实例? 哪个风险承担者最有可能提供这些问题的答案? 问这个问题最好的媒介方式是什么? 您的问题应该包括了已知需求的所有东西。图解3 编写需求确定潜在需求(过程说明3.1) 设置上下文范围并针对逻辑的、互联的部分工作，得到的成果并不能发现全部的需求。许多单个的需求是通过对知识的网罗来发现的。 本过程分析潜在需求，这些需求是通过网罗发现的。 针对每项潜在需求： 在产品必须执行的操作后面，用这样的格式写下一段描述：该产品应该 用一个唯一的号码标识该需求； 复查产品上下文范围，看看是否能确定与该需求有关的用况： 记录下该需求的来源(最好是人的姓名)； 记录下该需求的根本原因，问一个问题：为什么该需求对业务来说是重要的?确定功能性需求(过程说明3.2) 针对产品上下文范围中的每个用况： *当用况很大，或艮复杂，或不熟悉时，直接从用况跳到需求是困难的。在这种情况下，用况的步骤提供了迈向需求的垫脚石。* 从参与者的视角，列出所有步骤的清单，这些步骤是产品为了完成用况定义的工作必须执行的。 针对每个用况步骤： *通过将每个用况步骤分解为可测试的一句话说明来发现功能性需求。问一下为了完成这一步工作，产品必须做些什么。下面是一些有帮助的问题：* 该产品必须接收怎样的数据? 该产品必须产生怎样的数据? 产品必须记录怎样的数据? 产品必须做怎样的检查? 产品必须做怎样的判断? 产品必须做怎样的计算? 上述的每个问题都可能产生一些功能需求。 针对每项需求： 在产品必须执行的操作后面，用这样的格式写下一段描述：该产品应该 用一个唯一的号码标识该需求； 附上该需求的用况号； 记录下该需求的来源(最好是人的姓名)； 记录下该需求的根本原因。问一个问题：为什么该需求对业务来说是重要的?确定组合需求(过程说明3.3) 一项组合需求指的是，某项需求没有自己的可测试的验收标准。换言之，它是一组其他的单独可测试的需求的“小结”。 对于讨论互助组需求的组合效果，组合需求是一种有用的方式。有时候，项组合意味着存在模糊或不确定的地方。 组合需求常常被称为“高层次需求”。 对每个用况有一个高层次需求是很有用的，这样您可以在用况这一层对需求进行总结，同 时又保持组成该用况的可测试需求之间的联系。当您确定一个组合需求时，请确保这样做有足够的理由，而不只是把这种泛泛而谈作为一种逃避的方法。将需求规范化(过程说明3.4) 请参考与需求模板打包在一起的需求项框架。 针对每项需求，用该需求项框架作为指导，确定需求项框架上提到的每一项。对每种类型需求更详细的建议和例子，请参考需求模板。将系统限制条件规范化(过程说明3.5) 请参考与需求模板打包在一起的需求项框架。 针对产品目标和项目限制条件，用该需求项框架作为指导，确定需求项框架上提到的每一项。 对其他类型的系统限制条件(客户、顾客、用户)，请参考需求模板。对每种类型系统限制条件的更详细的建议和例子，请参考需求模板。确定非功能性需求(过程说明3.6) 您可以使用功能性需求作为帮助发现非功能性需求的触发器，可以使用以下的方法： 针对每个用况： 针对每个功能性需求： 针对需求模板中列出的每种类型的非功能性需求： 是否存在一个或多个非功能性需求支持该功能性需求?您也可以采用站在更高层次的方法，通过比较用况与每种类型的非功能性需求来寻找非功能性需求。编写功能性验收标准(过程说明37) 本过程的目标是根据一项需求，运用工作知识，得到功能性需求的需求验收标准。本过程是寻找无二义性的标准，这样可以把所有对需求的解决方案归为两类：满足需求或不满足需求。 模板包含了许多如何确定需求度量方法的例子。 针对每项需求： 功能性需求的验收标准明确了如何判断产品是否成功完成了要求的动作。 假定您已经定义了一些术语(参看需求模板的第5节)，并用这些术语描述了需求及其目的关系，那么您的验收标准将采用以下方式： 指定取得的数据将与指定输入的数据相符： 指定检查过的数据将与指定的检查规则相符； 计算的结果将与指定的算法相符； 指定记录的数据将与指定取得的数据相符。换言之，如果您的术语已经有了无二义性的定义，它将作为功能性需求验收标准定义的一部分。编写非功能性验收标准(过程说明3.8) 本过程的目标是根据一项需求，运用工作知识，得到非功能性需求的需求验收标准。 本过程是寻找无二义性的标准，这样可以把所有对需求的解决方案归为两类：满足需求或不满足需求。 模板包含了许多如何确定需求度量方法的例子。 判断您正在处理哪种类型的需求模板对此有所帮助。 它真是一项需求吗?需求常常被错误地表述为解决方案。如果是这种情况，那么您需要询问风险承担者真正的需求是什么。真正的需求应该独立于您可能的解决方案。 如果需求是以某种您可以触摸到、看到、闻到、听到或尝到的方式提出的，那么就比较容易发现一个客观的度量标准。 如果一个名词不是您可以触摸到、看到、闻到、听到或尝到的东西，那它就是一个名词化的词。当一个动词用于描述一个正在执行的过程时，就变成了一个名词，这样名词化词就产生了。例如，我们可以说“维护”是一个名词化词。 假设您遇到这样一项需求：维护必须可靠。维护是一个名词化词，您可以通过界定它的意义来阐明它。将名词化词还原成动词，并问一下：谁将什么名词化了?他们如何做到这一点?这个技巧有助于您确定需求的真正意义，从而能定义一个合适的验收标准。 某些需求是模糊的名词化词，因为没人知道它们的意义或意图究竟是什么。确定顾客价值(过程说明3.9)要求顾客从两个视角来看需求，以此来确定顾客价值： 顾客满意度。“如果我给您的解决方案满足了需求的验收标准，您会有多高兴(用5分制打分)?” 顾客不满意度。“如果我没能给出满足需求的验收标准的解决方案，您会有多不高兴(用5分制打分)?” 您的目标是理解顾客真正的优先级，并引导顾客说出他真正最重要的事，目的是有一些合理的依据来选择是否需要何时需要实现哪些需求。当您有几组不同的顾客，他们的优先级各不相同时，也运用相同的过程。您的目标是记录下不同的优先级，然后可以做合理的选择与折衷。确定依赖关系和矛盾之处(过程说明3.10) 不论何时，如果您发现一项需求与另一项有矛盾之处，则应该将该矛盾之处记录下来。 存在矛盾之处预示着您需要某种类型的谈判。 解决矛盾的第一步是确定矛盾的存在，并分别从提供矛盾的需求的人的角度来考虑问题。在这个阶段，您可能不会发现所有的矛盾。在以后，当您复查需求规格说明书时，您会对矛盾之处做更正式的检查。 图解4 质量关复查需求验收标准(过程说明4.1) 需求验收标准的目标是建立可交流的限制条件，让项目所涉及的人员能够有充分的理解，以便测试每个解决方案。 请寻求测试人员的帮助，以完成此过程。 是否规范化的需求和规范化的限制条件拥有一个需求验收标准，并做到： 需求验收标准提供了一个无二义性的方式，能测试任何最终解决方案，证明其要么满足，要么不满足需求验收标准? 有些需求比另一些要容易量化。功能性需求是所有需求中最容易量化的，因为它们被界定在一个紧凑的上下文范围中，我们对这些需求的量