1、如何对电子商务系统进行需求分析如何对电子商务系统进行需求分析一、需求分析在具体的研究需求分析之前， 我们先了解一下软件工程这个概念。 软件工程分为 三个层次，过程层、方法层、工具层。在最基础的过程层，最重要的就是一组被 称为关键过程区域（KPAs）的框架（KPA的概念在讨论CMM的书中有详细的 概念说明） 。关键过程区域构成了软件项目的管理控制的基础， 并且确立了上下 文各区域的关系， 其中规定了技术方法的采用、 工程产品的， 模型、文档、数据、 报告、表格等，等的产生、里程碑的建立、质量的保证及变化的适当管理。方法 层主要是过程在技术上的实现。 它解决的问题是如何做。 软件工程方法涵盖了一
2、系列的任务：需求分析、设计、编程、测试、维护。同时他还包括了一组基本原 则，控制了每一个的关键过程区域。 工具层就很好理解了， 他对过程层和方法层 提供了自动和半自动的支持。这些辅助工具就称为 CASE。可以看到需求分析的位置，但是事实上需求分析是跨越了软件工程的三个层次 的。这一点是和其他的过程是一样的。 当然我们这里比较重点强调的是在软件工 程的方法层， 同时也涉及到一些过程层的思想， 至于工具层则不再我们的讨论之 列，但是会提到一些很适合在需求分析时应用的工具， 诸如 Word 、Excel 、Visio 等。方法需求分析都包括了哪些方法呢？这里列举出在 需求分析 一书中推荐 的一些方法
3、。1）绘制系统关联图， 这种关联图是用于定义系统与系统外部实体间的界限和接口 的简单模型。同时它也明确了通过接口的信息流和物质流。2）创建用户接口原型， 当开发人员或用户不能确定需求时， 开发一个用户接口原 型一个可能的局部实现这样使得许多概念和可能发生的事更为直观明了。 用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。 注意要找 出需求文档与原型之间所有的冲突之处。3）分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性， 明确与每项需求实现相联系的风险， 包括与其它需求的冲突， 对外界因素的依赖 和技术障碍。4）确定需求的优先级别， 应用分析方法来确定使用实例、
4、 产品特性或单项需求实 现的优先级别。 以优先级为基础确定产品版本将包括哪些特性或哪类需求。 当允 许需求变更时， 在特定的版本中加入每一项变更， 并在那个版本计划中作出需要 的变更。5）为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。 它们能提供不同的信息与关系以有助于找到不正确的、 不一致的、 遗漏的和冗余 的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象 类及交互作用图。6）创建数据字典， 数据字典是对系统用到的所有数据项和结构的定义， 以确保开 发人员使用统一的数据定义。 在需求阶段， 数据字典至少应定义客户数据项以确 保客户与开发小组是使用一
5、致的定义和术语。 分析和设计工具通常包括数据字典 组件。7）使用质量功能调配， （QFD ）是一种高级系统技术，它将产品特性、属性与对 客户的重要性联系起来。 该技术提供了一种分析方法以明确那些是客户最为关注 的特性。 QFD 将需求分为三类：期望需求，即客户或许并未提及，但如若缺少 会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若 未实现也不会受到责备（ Zultner1993;Pardee1996 ）。记住一点， 不要试图在你的项目中把这些方法都用上去， 四个现代化并不是一夜 就可以实现的。 同样，尝试着使用你认为对你很有帮助的方法， 确实收到效果之 后，在考虑继续学
6、习方法。因为上面提到的都是需求分析的大方法，事实号、记 录业务规范、创建需求跟踪能力矩阵、 审查需求文档、 以需求为依据编写测试用 例、编写用户手册、确定合格的标准。二、业务建模很多人都没有意识到业务需求阶段应该做些什么事情， 实际上业务建模是最重要 的一件事情。 不要觉得业务建模这个词很深奥， 让人模不着头脑。 其实所有做过 需求分析的人都做过业务建模，比如你了解企业的运作模式就 ?是一种你脑海中 的业务建模。但是大多数人都没有科学的、系统的、文档化的做过业务建模。业务建模的目的在于： 了解目标组织（将要在其中部署系统的组织）的结构及机制 了解目标组织中当前存在的问题并确定改进的可能性。确保
7、客户、最终用户和开发人员就目标组织达成共识。导出支持目标组织所需的业务需求。 上面的话是不是很抽象呢，其实没有什么复杂的：人和电脑是完全不同的思想 （思 维方式）。所以，原先适合人的业务流程对于计算机来说可不一定合适的，为了 最大限度的利用计算机， 必须要了解原先的业务流程并对此加易改造 （流程自动 化），当然这些动作需要得到用户的许可。有些人认为说只有 ERP 这种大系统才需要对业务流程进行重组，但是实际，不论是部门级的 MIS 系统，还是社会 级的电子商务系统，都需要对业务流程进行改造，所不同的只是改造的程度。业务建模很重要的一点是在分析企业流程的同时分析出基础企业对象（ CommonBu
8、sinessObject ）（这个词我翻译的不好， 如果大家有更好的翻译， 请告诉我）。任何企业都有最基础的一些元素，例如银行的 CBO 就有帐户，制 造业的 CB 对多，订单和产品之间又是一对多，这样一个多对多的关系就拆分成 两个一对多的关系， 而新的订单类也就顺理成章的产生了。 在订单类产生时， 你 可能还会加入一个关联类： 业务员类。 而业务员类又是从员工类继承下来的。 所 以呢，企业的四种 CBO 通过不同的组合，不同的关系，能够形成企业运作的许 许多多的 CBO 。CBO 是做业务建模的基础，在此基础上，通过评估业务状态，说明当前业务， 确定业务流程，改进业务流程的定义，设计业务流程
9、实现，改进角色和职责，研 究流程自动化，开发领域模型等一系列在 RUP 中定义的工作流程实现业务建模 的目标。三、需求获取需求获取 (requirementelicitation) 是需求工程的主体。 对于所建议的软件产品， 获取需求是一个确定和理解不同用户类的需要和限制的过程。 获取用户需求位于 软件需求三个层次的中间一层。 业务需求决定用户需求， 它描述了用户利用系统 需要完成的任务。 从这些任务中， 分析者能获得用于描述系统活动的特定的软件 功能需求， 这些系统活动有助于用户执行他们的任务。 需求获取是在问题及其最 终解决方案之间架设桥梁的第一步。 获取需求的一个必不可少的结果是对项目中
10、 描述的客户需求的普遍理解。 一旦理解了需求， 分析者、 开发者和客户就能探索 出描述这些需求的多种解决方案。 参与需求获取者只有在他们理解了问题之后才 能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把 需求获取集中在用户任务上而不是集中在用户接口上有助于防止开发组由 于草率处理设计问题而造成的失误。 需求获取、 分析、编写需求规格说明和验证 并不遵循线性的顺序， 这些活动是相互隔开、 增量和反复的。当你和客户合作时， 你就将会问一些问题，并且取得他们所提供的信息(需求获取)。同时，你将处 理这些信息以理解它们， 并把它们分成不同的类别， 要交流的方面。 需求获取只 有通
11、过有效的客户开发者的合作才能成功。 分析者必须建立一个对问题进行彻 底探讨的环境， 而这些问题与产品有关。 为了方便清晰地进行交流， 就要列出重 要的小组， 而不是假想所有的参与者都持有相同的看法。 对需求问题的全面考察 需要一种技术， 利用这种技术不但考虑了问题的功能需求方面， 还可讨论项目的 非功能需求。确定用户已经理解： 对于某些功能的讨论并不意味着即将在产品中 实现它。对于想到的需求必须集中处理并设定优先级 ?，以避免一个不能带来任 何益处的无限大的项目。 需求获取是一个需要高度合作的活动， 而并不是客户所 说的需求的简单誊本。 作为一个分析者， 你必须透过客户所提出的表面需求理解 他
12、们的真正需求。询问一个可扩充( open-ended )的问题有助于你更好地理解 用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。 调查用户任务 可能遇到的变更， 或者用户需要使用系统其它可能的方式。 想像你自己在学习用 户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发 和利用。还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映， 用户是如何想的？询问问题时，以“还有什么能” ?时，将会, 发”生当什么”“你有没有曾经想过” , “有没有人曾经”为记开下头每。一个需求的来源， 这样向下跟踪直到发现特定的客户。需求讨论会上必须要使用笔记本电脑，
13、 还要指定一个打字熟练的人把所有的讨论 记录下来， 记录的同时还要做一定的整理。 如果不这样做， 那么你结束会议的时 候就会发现， 所有的讨论只剩下一个模糊的印象， 需求对你来说仍然是一件遥远 的事情。在座谈讨论之后，记下所讨论的条目 (item) ，并请参与讨论的用户评论 并更正。及早并经常进行座谈讨论是需求获取成功的一个关键途径， 因为只有提 供需求的人才能确定是否真正获取需求。 进行深入收集和分析以消除任何冲突或 不一致性。尽量把客户所持的假设解释清楚， 特别是那些发生冲突的部分。 从字里行间去理 解以明确客户没有表达清楚但又想加入的特性或特征。 Gause 和 Weinberg1989
14、 ）提出使用“上下文无关问题”这是一个高层次的问题，它可以获取 业务问题和可能的解决方案的全部信息。 客户对这些问题的回答诸如“产品要求 怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些 回答可以更直接地认识问题，而这是封闭（ close-end ）问题所不能做到的。需求获取利用了所有可用的信息来源， 这些信息描述了问题域或在软件解决方案 中合理的特性。 一个研究表明： 比起不成功的项目， 一个成功的项目在开发者和 客户之间采用了更多的交流方式（ KielandCarmel1995 ）。与单个客户或潜在 的用户组一起座谈，对于业务软件包或信息管理系统（ MIS ）的应用来说
15、是一种 传统的需求来源。直接聘请用户进行获取需求的过程是为项目获得支持和买入 （ buy-in ）的一种方式。尽量理解用户用于表述他们需求的思维过程。 充分研究用户执行任务时作出决策 的过程，并提取出潜在的逻辑关系。 流程图和决策树是描述这些逻辑决策途径的 好方法。在需求获取的过程中， 你可能会发现对项目范围的定义存在误差， 不是太大就是 太小。如果范围太大， 你将要收集比真正需要更多的需求， 以传递足够的业务和 客户的值， 此时获取过程将会拖延。 如果项目范围太小， 那么客户将会提出很重 要的但又在当前产品范围之外的需求。 当前的范围太小， 以致不能提供一个令人 满意的产品。 需求的获取将导
16、致修改项目的范围和任务， 但作出这样具有深远影 响的改变，一定要小心谨慎。正如经常所说的，需求主要是关于系统做什么，而 解决方案如何实现是属于设计的范围。这样说虽然很简洁，但似乎过于简单化。 需求的获取应该把重点放在“做什么”上， 但在分析和设计之间还是存在一定的 距离。你可以使用假设“怎么做”来分类并改善你对用户需求的理解。 在需求的 获取过程中， 分析模型、屏幕图形和原型可以使概念表达得更加清楚， 然后提供 一个寻找错误和遗漏的办法。 把你在需求开发阶段所形成的模型和屏幕效果看成 是方便高效交流的概念性建议， 而不应该看成是对设计者选择的一种限制。 需求 获取讨论会中如果参与者过多，就会减
17、慢进度。人数大致控制在 5 到 7 人是最 好的。这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。 相反地，从极少的代表那里收集信息或者只听到呼声最高、 最有舆论影响的用户 的声音，也会造成问题。 这将导致忽视特定用户类的重要的需求， 或者其需求不 能代表绝大多数用户的需要。最 ?好的权衡在于选择一些授权为他们的用户类发 言的产品代表者， 他们也被同组用户类的其它代表所支持。 没有一个简单、 清楚 的信号暗示你什么时候已完成需求获取。 当客户和开发者与他们的同事聊天、 阅 读工业和商业上的文献及在早上沐浴时思考时， 他们都将对潜在产品产生新的构 思。你不可能全面收集需求， 但是
18、下列的提示将会暗示你在需求获取的过程中的 返回点。1.如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总 是按其重要性的顺序来确定使用实例的。2.如果用户提出新的使用实例， 但你可以从其它使用实例的相关功能需求中获得 这些新的使用实例， 这时也许你就完成了收集需求的工作。 这些新的使用实例可 能是你已获取的其它使用实例的可选过程。3.如果用户开始重复原先讨论过的问题， 此时，也许你就完成了收集需求的工作4.如果所提出的新需求比你已确定的需求的优先级都低时， 也许你就完成了收集 需求的工作。5.如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就 完成了收集需求
19、的工作。以上知识大致上讨论需求分析应该如何做， 实际上对于需求分析的方法有很多很 多，已经形成了一定的用例在需求分析中的使用。多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式， 从而获 取需求(McGrawandHarbison1997 )。IvarJacobson (1992 )把这种看法系统地阐述成用例 (用例) 的方法进行需求获取和建模。 虽然用例来源于面向对象 的开发环境， 但是它也能应用在具有许多开发方法的项目中， 因为用户并不关心 你是怎样开发你的件。 而最重要的， 用例的观点和思维过程带给需求开发的改变 比起是否画正式的用例图显得更为重要。 注意用户要利用系统做什么
20、远远强于询 问用户希望系统为他们做什么这一传统方法。 用例的重要功能是用画用例图的功 能来鉴别和划分系统功能。它把系统分成角色( actor )和用例(用例)。角色 (actor) 表示系统用户能扮演的角色( role )。这些用户可能是人，可能是其他的 计算机一些硬件或者甚至是其它软件系统， 唯一的标准是它们必须要在被划分进 用例的系统部分以外。 它们必须能刺激系统部分并接收返回。 用例描述了当角色 给系统特定的刺激时系统的活动。 这些活动被文本描述。 它描述了触发用例的刺 激的本质， 输入和输出到其他活动者， 和转换输入到输出的活动。 用例文本通常 也描述每一个活动在特殊的活动线时可能的错
21、误和系统应采取的补救措施。 这样 说可能会非常复杂，其实一个用例描述了系统和一个角色( actor )的交互顺序。用例被定义成系统执行的一系列动作， 动作执行的结果能被指定角色察觉到。 用 例可以 :用例捕获某些用户可见的需求，实现一个具体的用户目标。用例由角色 激活，并提供确切的值给角色。 用例可大可小， 但它必须是对一个具体的用户目 标实现的完整描述。在 UML 中，用例表示为一个椭圆。角色是指用户在系统中 所扮演的角色。 其图形化的表示是一个小人。 在某些组织中很可能有许多角色实 例(例如有很多个销售员)，但就该系统而言，他们均起着同一种作用，扮演着 相同的角色， 所以用一个角色表示。
22、一个用户也可以扮演多种角色。 例如，交换。 单个角色可与多个用例联系； 反过来， 一个用例可与多个角色联系。 对同一个用 例而言，不同角色有着不同的作用： 他们可以从用例中取值， 也可以参与到用例 中。需要注意的是角色在用例图中是用类似人的图形来表示， 尽管执行的， 但角 色未必是人。 例如，角色也可以是一个外界系统， 该外界系统可能需要从当前系 统中获取信息，与当前系统有进行交互。一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。 因此，一个用 例是相关的用法说明的集合，并且一个说明( scenario )是用例的实例。这种关 系就像是类和对象的关系。在用例中，一个说明被视为事件的普
23、通过程 (normalcourse) ，也叫作主过程，基本过程，普通流，或“满意之 路” (happypath) 在。描述普通过程时列出执行者和系统之间相互交互或对话的 顺序。当这种交互结束时，执行者也达到了预期的目的。在用例中的其它说明可以描述为可选过程 (alternativecoruse) 。可选过程也可促 进成功地完成任务，但它们代表了任务的细节或用于完成任务的途径的变化部 分。在交互序列中， 普通过程可以在一些决策点上分解成可选过程， 然后再重新 汇成一个普通过程。角色类和角色实例。软件产品最终是给一些用户来使用的， 而用户之间的差异是非常大的。 造成差异的原因包括了对计算机的认知程
24、度的不 同，使用习惯的不同，在软件目标组织中所处的地位不同，地理位置不同，业务 熟练程度不同。不同的用户都有自己一系列的功能需求和非功能需求。 对电脑熟练程度不同的人 可能就会有不同的要求， 熟练程度低的用户可能希望有一个友好的界面， 熟练程 度高的用户可能更希望有快捷键或宏的操作以提高工作效率。 考虑到用户的差异 性，将用户分类并研求。 抓住用户代表的需求就大致把握住了用户类的需求。 当 然，需求分析还是需要在用户中做大规模的调查的， 只是要把重点放在用户代表 上。确保和用户直接进行沟通！ 大家有没有玩过传话的游戏， 可能看过。 一群人排成 一列，一句话从排头挨个向后传，到最后，那句话已经是
25、面目全非了。所以，一 定要保证项目组能够直接和用户接触。 对于和用户直接沟通这一点， 一般的针对 特定企业的应用系统当然是不成问题， 可是如果是开发行业软件， 和用户直接沟 通就成为一件几乎是不可能的事情。在这种情况下，一般有几种解决的办法： 做大规模的市场调查， 针对你的目标市场做市场调查， 并根据统计学的理论建立 你的数学模型。 这部分的工作效果最好， 其性质有些象一些游戏公司会发布一些 Demo 版的游戏。是对于一般的企业来说，这项工作费时费力，高昂的成本往 往使大家知难而退。 我的意见是，方法是非常好的， 但是可以软件技术并不熟悉； 第二种是开发过同类软件的软件专家， 这种人在开发同类
26、软件过程中已经积累了 大量的项目经验，并且具有软件开发的知识。 这种方式是获取需求的最好的方式。分析对比同类软件， 微软在开发 Office 、VisualStudio 的时候，也是参照了 Lotus 和 Borland 的成熟产品。这种方式的特点在于成本很低，比较适合和其他的方 式配合使用。但是，要注意自己有没有触犯专利法。有的时候，虽然已经将用户 分类并选出了用户代表。 但是需求的来源众多， 往往会发生需求之间自相矛盾的 事情。需求从四面八方收集来后， 人们难以解决冲突， 澄清模糊之处以及协调不 一致之处。 某些人还要对不可避免要发生的范围问题单独作出决定。 在项目的早 期阶段，你必须决定
27、谁是需求问题的决策者。 如果不清楚谁有权并且有责任来作 出决策，或者授权的个人不愿意或不能作出决策， 那么决策者的角色将自然而然 地落在开发者身上。 这是一个非常糟糕的选择， 因为开发者通常没有足够多的信 息和观点来作出业务上的决策。在软件项目中， 谁将对需求作出决策的问题并没有统一的正确答案。 分析员有时 听从呼声高的或来自最高层人物的最大的需求。 即便使用用户代表这一手段， 必 须解决来自不同用户类的相冲突的需求。 通常，应尽可能由处于公司底层的人作 出决策，因为他们与题密切相关，并能得到关于这些问题的广泛信息。如果不同的用户类有不一致的需求， 那么必须决策出满足哪一类用户的需求更为 重要
28、。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关 系如何，将有助于你决定哪一个用户类所占份额最大。用例图适于表达交互，之所以上面使用了电信系统，是因为用例最早来自于 Ericsson 的交换机系统。当时，还是 Ericsson 雇员的 Jacobson 初步建立了用 例图的概念，并于 1994 年提出了 OOSE 方法，其最大特点是面向用例 ( Use-Case )，并在用例的描述中引入了外部角色的概念。用例的概念是精确 描述需求的重要武器， 比较适合支持商业工程和需求分析。 随着用例的发展， 用 例被大量的用于对功能进行描述。每个用例代表了系统与外部 ACTOR 的交互 可
29、以采取顺序图来表达用例的具体操作程序。 ACTOR 用于确定系统的边界。ACTOR 、用例可以从不同的层次来描述信息。采用该原则的原因有：1.需求并不是在项目一开始就很明确，往往是随着项目的推进，逐渐细化。2.人的认知往往具有层次的特性。从粗到细、从一般到特殊。采用不同的层次来 描述，适于认知的过程。 使用用例开发系统的一般过程。 在开发过程的初始阶段， 可以根据具体的项目特点， 制订开发各个视图之间的关联原则， 指导规范。 在开 发的过程中，视图的组织原则应不断进行维护、更新。识别 ACTOR 来识别系统与外界交互的实体。 ACTOR 具有特定领域的特征，例 如：交换机（采集系统）、 97
30、信息系统等。在系统层次的 ACTOR 确定了系统 的边界。识别用例。同ACTOR 一样，用例具有不同层次。对较为概括的 USECASE,需 要细化。注：系统开发需要一定的规则来确定，如何来分解用例；可能基于原有 系统的经验，或是参考现有资料。当用例细化到可以被理解的层次。 需要基于用例进行下一步的开发。 如前面提到 的，用例主要用来描述交互。因此，存在交互的实体和交互的细节。交互的实体 采用类图来描述；而交互的细节，采用顺序图来描述。当系统复杂到一定层次时， 类图和顺序图可能不能足以描述其复杂程度。 在该情 况下，需要使用状态图来辅助阐述。状态图和顺序图之间使用事件联结在一起。它们之间的一致性
31、问题，目前 UML 和 ROSE 没有提供解决方案。相对折衷的方 法是使用事件的命名规范强制一致性。可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。 用例是从 用户的角度看待系统， 而不是基于程序员的角度。 这样的话， 用例驱动的系统能 够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。 用户和程序员间通过用例沟通， 避免了牛头马嘴的尴尬局面。 从前，系统开发者 总是用于开发的流程。 当系统的开发过程都是基于用例的， 用用例获取需求， 用 用例设计，用用例编码，用用例测试的时候。这个开发过程就是用例驱动的。用 例和用例文档软件需求一书中提到了几种方法来确定用例
32、： 首先明确执行者和他们的角色， 然后确定业务过程， 在这一过程中每一个参与者 都在为确定用例而努力。 确定系统所能反映的外部事件， 然后把这些事件与参与 的执行者和特定的用例联系起来。 能需求，这些功能需求可以使用户完成其任务， 也可以把它们描述成非功能需求， 这些非功能需求描述了系统的限制和用户对质 量的期望。 虽然最初的屏幕构思有助于描述你对需求的理解， 但是你必须细化用 户界面设计。建立用例文档。 在每一次的需求获取之后， 都会生成很多未整理的 需求，你必须将它们组织成用例文档。 使用诸如模板的技术能够提高你的速度和 需求的复用性。 一个用例文档可以使用表格来组织， 主要的要素包括了用例标识 号、用例名称、父用例标志号、创建者、创建时间、审核者、修订记录、角色、 说、先决条件、请求结果、优先级、普通过程、可选过程、例外、非功能需求、 假设、注释和问题。 虽然列举出了这么多的属性， 但是实际中使用的属性这要看 你的团体而定，看项目的大小而定。 把大量的时间花在用例的描述上是没有意义 的。用户需要的是一个软件系统，并不是一大堆的用例说明
