需求分析概述

1、需求分析概述一需求获取及用例使用需求获取（requirement。1也廿0门）是需求工程的主体。对于所建议的软件产品，获取需求是 一个确定和理解不同用户类的需要和限制的过程。获取用户需求位于软件需求三个层次的中 间一层。业务需求决定用户需求，它描述了用户利用系统需要完成的任务。从这些任务中， 分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们 的任务。需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少 的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就 能探索出描述这些需求的多种解决方案。参与需求获取者只有在

2、他们理解了问题之后才能开 始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在 用户任务上一而不是集中在用户接口上一有助于防止开发组由于草率处理设计问题而造成 的失误。需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、 增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需 求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需 求同可能的软件需求相联系（分析）。然后，你可以使客户信息结构化，并编写成文档和示意 图（说明）。下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。这四个

3、过程贯穿 着需求分析的整个阶段。需求获取可能是软件开发中最困难、最关键、最易出错及最需要 交流的方面。需求获取只有通过有效的客户一开发者的合作才能成功。分析者必须建立一个 对问题进行彻底探讨的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出 重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种 技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用 户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集 中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。需求获取是一个需要高度合作的活动，而并

4、不是客户所说的需求的简单誉本。作为一个 分析者，你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充 （open-ended）的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或 改进他们的工作。调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。 想像你自己在学习用户的工作，你需要完成什么任务?你有什么问题?从这一角度来指导需求 的开发和利用。还有，探讨例外的情况：什么会妨碍用户顺利完成任务?对系统错误情况的反映，用户 是如何想的?询问问题时，以“还有什么能”，”当？时，将会发生什么”“你有没有曾经想 过”，“有没有人曾经”为开头。记下每一个需求的来源，

5、这样向下跟踪直到发现特定的客 户。有些时候，尝试着问一些“愚蠢”的问题也有助于客户打开话匣子。如果你直接要求客 户写出业务是如何实现的，客户十有八九无法完成。但是如果你尝试着问一些实际的问题， 例如：“以我的理解，你们收到订单后，会.”。客户立刻就会指出你的错误，并滔滔不绝的开始谈论业务，而你，就在一边仔细的聆听吧。这一招就叫做“抛砖引玉”。需求讨论会上必须要使用笔记本电脑，还要指定一个打字熟练的人把所有的讨论记录下 来，记录的同时还要做一定的整理。如果不这样做，那么你结束会议的时候就会发现，所有 的讨论只剩下一个模糊的印象，需求对你来说仍然是一件遥远的事情。在座谈讨论之后，记 下所讨论的条目

6、(item)，并请参与讨论的用户评论并更正。及早并经常进行座谈讨论是需求 获取成功的一个关键途径，因为只有提供需求的人才能确定是否真正获取需求。进行深入收 集和分析以消除任何冲突或不一致性。尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。从字里行间去理解以明确客 户没有表达清楚但又想加入的特性或特征。Gause和Weinberg(1989)提出使用“上下文无关 问题”一这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。客户 对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某 人的回答吗? ”这些回答可以更直接地认识问题，而这是封闭(clo

7、se-end)问题所不能做到的。需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理 的特性。一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更 多的交流方式(Kiel and Carmel 1995)。与单个客户或潜在的用户组一起座谈，对于业务软件 包或信息管理系统(MIS)的应用来说是一种传统的需求来源。直接聘请用户进行获取需求的 过程是为项目获得支持和买入(buy-in)的一种方式。尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过程， 并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。在需求获取的

8、过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。 如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获 取过程将会拖延。如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外 的需求。当前的范围太小，以致不能提供一个令人满意的产品。需求的获取将导致修改项目 的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。 这样说虽然很简洁，但似乎过于简单化。需求的获取应该把重点放在“做什么”上，但在分 析和设计之间还是存在一定的距离。你可以使用假设“怎么做”来分类并改

9、善你对用户需求 的理解。在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然 后提供一个寻找错误和遗漏的办法。把你在需求开发阶段所形成的模型和屏幕效果看成是方 便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。需求获取讨论会中如果参与者过多，就会减慢进度。人数大致控制在5到7人是最好的。 这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。相反地，从极少的 代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。这将 导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。最好的权衡 在于选择一些授权为他们的用户类发

10、言的产品代表者，他们也被同组用户类的其它代表所支 持。没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的 同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的 构思。你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总是按 其重要性的顺序来确定使用实例的。如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些 新的使用实例，这时也许你就完成了收集需求的工作。这些新的使用实例可能是你已获取的 其它使用实例的可选过程。如果用户开始重复原先

11、讨论过的问题，此时，也许你就完成了收集需求的工作。如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求 的工作。如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成 了收集需求的工作。以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经 形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。 所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是 成功的。多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求 (McGraw and Harbison 19

12、97)。Ivar Jacobson(1992)把这种看法系统地阐述成用例(用例)的方法 进行需求获取和建模。虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开 发方法的项目中，因为用户并不关心你是怎样开发你的软件。而最重要的，用例的观点和思 维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。注意用户要利用系统做 什么远远强于询问用户希望系统为他们做什么这一传统方法。用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色(actor) 和用例(用例)。角色(actor)表示系统用户能扮演的角色(role)。这些用户可能是人，可能是其 他的计算机一些硬件或者甚至

13、是其它软件系统，唯一的标准是它们必须要在被划分进用例的 系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色给系统特定的刺激 时系统的活动。这些活动被文本描述。它描述了触发用例的刺激的本质，输入和输出到其他 活动者，和转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能 的错误和系统应采取的补救措施。这样说可能会非常复杂，其实一个用例描述了系统和一个角色(actor)的交互顺序。用例 被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。用例可以用例捕获某些用户可见的需求，实现一个具体的用户目标。用例由角色激活，并提供确切的值给角色。用例可大可小，但它必

14、须是对一个具体的用户目标实现的完整描述。在UML中，用例 表示为一个椭圆。角色是指用户在系统中所扮演的角色。其图形化的表示是一个小人。在某些组织中很可 能有许多角色实例(例如有很多个销售员)，但就该系统而言，他们均起着同一种作用，扮演 着相同的角色，所以用一个角色表示。一个用户也可以扮演多种角色。例如，一个高级营销 人员既可以是贸易经理，也可以是普通的营销人员;一个营销人员也可以是售货员。在处理 角色时，应考虑其作用，而不是人或工作名称，这一点是很重要的。我们使用不带箭头的线段将角色与用例连接到一起，表示两者之间交换信息，称之为通 信联系。角色触发用例，并与用例进行信息交换。单个角色可与多个用例联系;反过来，一 个用例可与多个角色联系。对同一个用例而言，不同角色有着不同的作用：他们可以从用例 中取值，也可以参与到用例中。需要注意的是角色在用例图中是用类似人的图形来表示，尽 管执行的，但角色未必是人。例如，角色也可以是一个外界系统，该外界系统可能需要从当 前系统中获取信息，与当前系统有进行交互。一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此，一个用例是相 关的用法说明的集合，并且一个说明(scenario)是用例的实例。这种关系就像是类和对象的关 系。在用例中，一个说明被视为事件的普