精品软件需求分析模型Word下载.docx

精品软件需求分析模型Word下载.docx

《精品软件需求分析模型Word下载.docx》由会员分享，可在线阅读，更多相关《精品软件需求分析模型Word下载.docx（8页珍藏版）》请在冰豆网上搜索。

（l）需求定义过程中的具体细节尚无定论，特别是在需求定义过程中，一般先要从“用户之声"

引出用户需求的定义，然后再从用户需求定义导出系统需求定义，而什么是“用户”、什么是“用户需求”、“用户需求”如何定义好、如何从用户需求的好定义有质量地导出系统需求定义等一系列回避不了的问题都没有很好的答案；

（2）软件产品，特别是管理信息系统这类软件产品，在需求定义过程中其应用环境一直在动态变化着，因此用户的需求也动态地随之变化;

（3）要适应需求变化,在需求定义质量中必须考虑可扩展性、可修改性，否则就会因修改需求定义的困难而影响此后一系列的开发活动容易而导致开发成本的明显增加、开发时间的明显延长；

（4）通常的需求定义过程中，由于把所谓的功能性需求与性能需求分开考虑,而实际上对每一项功能性需求都必然有对性能的要求，二者不可分离，因此对需求定义的完整性考虑都有欠缺;

（5）在需求定义过程中,涉众的含义和彼此之间的关系并不简单，涉众至少包含了客户、顾客、用户、法规方面的专家、软件开发商等，因此做好用户需求定义除了技术问题外，涉众之间的协调也非常重要;

（7）需求定义的标准化程度不高,特别是需求定义的标准表达形式;

（8）在需求定义的过程中缺乏质量控制手段.

基于以上几点,本文介绍的需求分析过程模型的基本思想为:

（l）需求分析过程中应注重涉众.MIS本身的特殊性决定了其需求分析过程中涉众的重要性，而以往的方法都没有注意这一点.应注意MIS开发中所涉及的不同涉众在需求分析中所起的不同作用，例如明确客户需求与用户需求之间的区别与联系；

（2）需求分析过程中结构化方法的应用。

在需求定义过程中引入结构化的方法，从而保证需求定义传递中的规范性，进一步保证需求定义的质量,并且利于建立用户需求与系统需求之间的对应关系;

（3）在需求定义过程中应当把功能性需求与性能性需求结合起来考虑，两者是互相影响的,将其孤立开来往往导致开发过程中的需求变动；

（4）注意定义形式的标准化，（5）注意需求定义过程中的质量控制，从而减少事后变更。

特别是MIS的开发中,有时信息系统的引入会引起企业本身的业务流程变动，因此要注意分析过程中的质量控制;

（6）注意最终需求文档的标准化。

软件工程的层次为需求分析模型的层次提供了理论基础，给予建立模型的基本思想，建立模型。

如图:

该模型具有三层体系结构层次，自下而上分别为质量保证层、过程层、方法层。

需求分析的最终目的是得到符合其度量指标的需求定义，质量保证层是该思想的体现，借鉴成熟的质量管理方法，并结合前文所归纳的度量指标，该层为需求分析过程提供了质量控制的指标及方法。

过程层是模型中的基础层，它是将相关的需求分析技术包含在其中，有效地进行需求分析的一套方法模型.过程定义了一组能使分析技术有效发挥作用的关键过程区域的框架.该过程区域构成了需求分析过程控制的基础，并且确立了上下各区域之间的关系。

其中规定的内容包括:

采用何种技术方法、产品（模型、文档、数据、报告、表格等）的产生、质量的保证及管理的不断完善。

方法层提供了需求分析在具体技术上应“如何做"

的方法。

1.质量保证层

质量保证层应包括两方面内容，一是度量需求定义的指标,二是一套结构化的根据指标对需求定义进行度量方法。

质量保证层是整个需求分析过程中参照的标准和基础，如果没有该层,那么所得出的需求定义将因为缺乏质量控制而毫无意义。

a.度量需求定义的指标，度量需求定义的优良性的指标为正确性、一致睦、清晰性、完整性、可测试性、可跟踪性等，现在我们来讨论这些指标对用户需求定义的意义。

正确性的主要内容分成两个层次：

第一层是指每条用户需求的定义都

正确反映了用户的要求，第二层是在第一层基础上的完整性和一致性要求，即用户的所有要求都有定义且不能相互矛盾。

正确性还有形式上的要求，例如采用UML工具来分析和定义需求时,分析和定义必须符合UML的规定。

一致性在各个任务需求都是互不相干情况下只要检查性能需求是否一致就能获得,因此在定义用户需求时必须将每项任务与其目标要求紧密地联系在一起，遗憾的是当今两大主流方法——SD和00--都把任务需求和性能需求分隔开来分析，前者放在需求定义阶段而后者放在系统分析阶段进行，无谓地将需求定义一致性的问题复杂化了.清晰性问题与需求定义的表达方式或模型形式有关。

如果用自然语言来表达，那么除了要用Glossary现的术语进行解释外，还必须注意到自然语言在描述需求定义中某些概念之间的关系上的局限、必须注意不加限制（即规定）的自然语言叙述会对涉众的理解一致带来问题;

如果用UML那样的建模语言来表达则也会因其简单、词汇量少、符号使用规定等因素如何适应千变万化的用户需求的丰富内涵而引起定义清晰性问题。

完整性除了在正确中提到的任务需求完整的一层意思外，还有一层意思在一致性中已经提及：

在定义每一项用户需求时不能将任务需求和性能需求分隔开来讨论。

每一项用户需求都有一个带有完成质量要求的任务,任务需求必须受到性能需求（即完成质量要求）的约束、性能需求必须依附于任务需求。

迄今为止，软件开发中的许多乱子皆由此引发。

另

外，我们还必须注意软件的使用环境经常在变化,即用户需求经常在变化，甚至在软件产品开发过程中客户就已不止一次地提出修改或增加用户需求的要求，因此，完整性需要可扩展性和可修改性的补充和支持。

所谓的可扩展性指软件增加功能时，增加新功能会对软件原有部分产生的影响，原有部分受到影响越小则可扩展性越好.所谓的可修改性指用户需求有变化时，定义需要修改的范围大小，修改范围越小则可修改性越好。

在需求定义时增加对可扩展性和可修改性的考虑可以为接下来的系统设计、系统实施创造良好条件,对最终软件产品的可修改性、重用性都有良好影响.需求定义的可测试性表现为可审查性，在下文中我们可以发现用户需求定义的可测试性问题不难解决,如果我们能解决用户需求与系统需求的对应关系，那么，系统需求定义的可测试性问题也不难解决.可跟踪性在需求定义阶段没有大问题，解决用户需求定义与系统需求定义之间的对应性关系,可跟踪性问题就转化为用户需求定义的可跟踪性,从而我们可由下文中要介绍的用户需求定义方法推知，用户需求定义的可跟踪性的关键在于非技术性的工作文档管理。

b。

GQM度量方法

在软件工程中关于需求定义过程中的质量控制的讨论几乎是空白,因此这是一个很值得展开全面而细致的讨论的课题，在这里我们借鉴较为成熟的结构化分析方法-GQM方法。

GQM作为在软件产品开发过程的质量度量评估方法，它可用来分析质量是否能够达到预定的目标。

Basili等提出了目标问题度量（GQM）。

它最早于1984年应用在NASA的Goddard空间飞行中心（GSFC），用来评估一些项目的缺陷，后来逐渐扩展到软件质量管理上面。

GQM从目标和问题来度量软件的质量。

它是三层结构（目标、问题、度量），先确定一组目标，再针对各个目标，提出可能会遇到的问题，来细化这个目标;

最后，针对每一个问题再给出一组测量方法,并用测量出来的数据分析来回答这个问题。

而这数据可能是主观的数据（如可读性文本，用户的满意度）或客观的数据（如员工花在某一任务上的工作时间，文件的大小等等）。

GQM先确定一组目标,一般包括五个要素:

度量的对象、目的、属性、涉众及度量的环境。

GQM作为在软件产品开发过程评估软件质量方面的方法，一种反馈和评估的度量方法，它所度量的是那些可以被量化的信息,并且这些量化信息能够用来分析排尿巩固所建立的质量目标能否达到预期标注。

由于该方法中包含任务、对象、涉众、环境等需求分析的相关因素，并且遵循结构化的分解方法,可以很好的适用于对需求定义的度量评估.质量审查的形式一般有四种:

开发人员自查、开发商的有关责任部门审查、委托审查和第三方审查。

对于需求定义审查工作来说一般不会发生第三方审查的情况，委托方审查只发生在用户需求定义的审查上，此时委托方的作用不但重要而且必要，因为用户需求定义必须完整、正确、一致地反映客户的要求和利益，必须得到客户（代表所有用户）的理解和确认。

审查工作必定从自查开始，审查至多只能对工作质量做出客观的评价，单纯的审查不会改进质量，因此做好需求分析和定义的工作、做好自查的准备工作才是关键,这些工作做好了，自查和开发商的有关责任部门审查就变成了一项例行公事,通过委托方审查也不会有大问题.许多关于需求定义质量审查的管理问题都是由于在质量管理上这种审查属于“事后检验”而不是“事前预防”，还是层次较低的阶段性的质量控制。

因此，应当在需求分析过程中就循环地应用度量方法,从而达到减少事后的需求变更，这依靠模型的过程层实现。

2.过程层

过程层是整个模型的核心部分，它表述了模型的关键域框架。

方法层是其应用中的细化部分,质量保证层则是其应用中的准则参考。

接下来首先介绍贯穿整个过程层的关键方法—任务分解结构方法,这有助于理解过程层的框架及基础，然后将对过程层模型中的几个关键步骤及模型进行详细的阐述.

a.任务分解结构方法

任务分解结构是一种熟悉工程，全面、系统地分析工程项目的有效方法。

WBS最早是在美国国防部的军用标准中提出来—“WBS是一个以产品为中心的，由硬件、软件、服务和资料组成的族系，该族系谱全面地确定了一个工程项目。

WBS显示和定义了要生产或开发的产品，并将为完成该产品所需进行的各项活动联系起来.”在很多情况下WBS被看作是项目分解结构和为生产某种产品所须进行各项主要任务的综合。

这些主要任务不是产品的一部分，而是为生产该产品所必须执行的任务.另外，为了反映出项目构建和管理的不同观点和方法，还有人认为wBS是综合了组织分解结构和成本分解结构等其他观点的多维度方法从以上可以看出WBS方法具有结构化、操作性强的特点。

WBS构建方法有很多，不同的构建方法决定着整个项目的WBS结构。

Globerson指出可以以产品为导向进行项目分解，也可以以业务流程为导向进行分解,还可以以项目的生命周期、功能、组织为导向等。

b.过程层方法

过程层方法的根据就是任务需求的WBS分析规则。

WBS的结构化方法应用于需求分析过程中，将是个按结构化层次进行需求的分解及反馈的过程，即由上而下分解分析，然后自下而上反馈度量，并且协调不同涉众需求，在这过程中可能会产生对原有业务流程的改进。

用户需求定义过程层的步骤为:

（l）客户的总体业务需求定义，

（2）构建用户的组织关系树,（3）建立业务流程展开模型，（4）建立任务需求的分析网络，完成任务需求的WBS分析，（5）对描述性能需求的指标进行分解，（6）使用方法层的方法，从人一机互动角度出发、结合系统分析中的用例结构考虑,进行需求分析并提取在用户需求中任务需求，（7）建立需求的任务一性能矩阵,规范地、完整地、正确地定义用户需求，（8）自下而上审查和度量用户需求定义,如在审查中发现问题就立即修改。

该过程层方法与业务流程模型、企业模型、工作流模型、WBS等都有几分相似但都不同，原因很简单,因为它们各自要解决的问题都不一样但相互关联。

客户是要使用E即的企业或机构、客户的代表是CEO，用户是个群体而且每个用户只使用ERP的一部分，而且用户之间存在组织关系（指直接的领导与被领导关系）和工作关系（指在业务流程中的上道、下道工作交接关系）,因此过程层方法分成三个部分：

第一部分是用户的组织关系模型，第二部分是业务流程展开模型,第三部分是任务需求分析矩阵模型。

（1）.用户组织关系模型

用户的组织关系模型必定是一棵树，而且我们可以对树上的每个节点进行编码并定义职责.假定作为讨论对象的企业的组织结构分成总部、部门、科室和基层岗位四层，业务流程展开模型将从企业希望待开发E即将覆盖的若干大块的业务（例如销售管理、财务管理、库存管理、生产管理等）开始展开,然后将每块管理业务分解为若干项管理任务,接着将每项管理任务的执行过程先展开为部门间的流程，然后将每个部门中的流程展开为其科室间的子流程，最后将各子流程展开成每个基层岗位上的任务流程。

（2）.业务流程展开模型

在建立业务流程展开模型时必须记住M.Halnlner的关于计算机辅助管理的观点：

计算机辅助管理不是将以前的手工操作的业务流程自动化而是业务流程重组。

因此业务流程展开模型要对实际情况加以提炼，要充分注意到执行同样性质的务时计算机化操作与手工操作在流程上的差别。

（3）.任务需求分析矩阵

任务需求分析矩阵是过程层的核心方法。

任务需求分析矩阵模型要将用户的组织关系模型和业务流程展开模型结合起来成为一个能有效地辅助任务需求的WBS分析规则实施的工具，具体地说,就是要将业务流程展开模型中每块管理业务、每项管理任务、每个部门流程段、每个科室子流程、每个基层岗位的任务的责任者与用户的组织关系模型中的节点对应起来.软件需求分析模型在用户需求分析中的重要作用不言而喻,越是复杂的软件系统，其重要性越明显。

下表为任务需求分析矩阵模型的一个例子.

在这里可以看到,任务需求分析矩阵分别具有任务结构、组织结构两个维度上的层次，可以说是一个分析的“切面"

随着两个维度的层次不同，可以定位在不同的断面上，获取该层次上的需求描述.

任务结构维度与质量保证层里的度量相对应，这里可以获取对任务的目标、问题、度量标准。

为方法层提供了任务分析要素。

而组织结构维度则在与任务形成对应关系的同时,为质量保证层提供了任务的“对象"

，即实际的执行者，并为下个方法层分析方法提供了结构层次要素。

3.方法层

过程层是整个分析的过程化的描述,而在单个的需求分析中，方法层分析方法则提供了获取需求的具体方法。

该方法包含了四个关键要素，它们既有前后关系，又共同为需求定义描述提供了准则和方法，我们将其称为“四要素分析法”。

方法层“四要素分析法"

如下所示。

（l）涉众要素分析-确定软件需求分析的涉众确定某个层次上不同的参与者，即涉众。

需求中所指的满足用户需要，但是却没有明确该用户的定位,是提出需求的业务客户,还是使用系统的最终用户,或是与软件相关的开发人员？

这一问题的分辨不清，导致了在业务需求提出后,对于需求的分析、定义,没有明确的对象，形成了沟通的不便，更无法谈论需求的质量。

而从管理的角度上看,对于需求的认识，涉众的看法往往是千差万别。

即使对于同一项需求,不同人的看法亦截然不同。

开发某一系统这一业务需求，对于客户-系统投资者而言，是希望对于现有系统或工作流程的改进，期望得到更高的效率与回报率;

对于最终用户-系统使用者而言，则是希望自己使用方便、安全。

而软件开发的交付是与客户-系统投资者之间的关联，因此，需求应是由客户提出的，而其满足的，则首先是客户的需求，也可以是用户的需求,但其前提是由客户提出的。

本文中仍沿用常规的用户需求称法，来表示客户需求.

（2）结构要素分析—定位该需求的结构层次

根据涉众中的用户所处的层次位置，这为进一步向下分解分析，或向上总结核实与协调，提供了一个在结构中的定位。

用户的组织关系模型必定是一棵树，而且我们可以对树上的每个节点进行编码并定义职责（注意:

节点用职责而不是按人定义,如果某人身兼数职，那么组织关系模型中对应的数个节点合在一起才代表该人在企业里的作用；

如果一个有数十个人的工作、职责完全相同，那么在组织关系模型中某一个节点就可能代表了这数十个人）。

在过程层中的任务需求分析网络的基础上得出相应的用户需求在整个结构中所处的节点,并根据一定的标准对其进行编码的标识。

（3）任务要素分析-确定和描述需求

确定该层次初步的具体需求内容，并形成一条需求初步分析的一记录。

该记录应当包括前面2步的详细信息，以及该位置上的需求描述.KarlE.Wiegers提出了软件需求包括三个不同的层次—业务需求、用户需求和功能需求，也包括非功能需求业务需求反映了组织机构或客户对系统、产品高层次的目标要求，阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。

其他任何一说明都应遵循“业务需求”的规定,然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。

用户需求描述了用户使用产品必须要完成的任务，描述的是用户的目标,或用户要求系统必须能完成的任务。

功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求，描述的是开发人员需要实现什么。

需求还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。

它包括产品必须遵从的标准、规范和合约;

外部界面的具体细节;

性能要求;

设计或实现的约束条件及质量属性.需求的分类主要从平面的角度,横向平等地看待所有需求，而需求的层次则从纵向的角度来划分需求,不同层次的需求侧重点不一样，描述方式不同，管理方式也不同.每一项用户需求都有一个带有完成质量要求的任务,任务需求必须受到性能需求（即完成质量要求）的约束、性能需求必须依附于任务需求。

（4）度量要素分析—确定是否满足度量标准

本身要满足需求分析的几条标准（完整性、无二义性等）,并且与其它同层次的需求分析记录整合在一起，形成一个需求描述文档的集合。

这一要素从质量保证层，贯穿过程层，并最终直接指导方法层分析方法的应用，是需求分析的一个质量保证手段.

随着计算机网络的发展，软件应用的的普及，软件需求分析模型将会有更多的用武之地.

参考文献：

SwapnaKishore，RajeshNaik.软件需求与估算.北京：

机械工业出版社，2004

BenjaminL.Kovitz。

实用软件需求。

北京:

机械工业出版社,2005

StandardGlossaryofSoftwareEngineeringTerminology,IEEEComPuterSoeietyPressWashingtonD。

C，1997

赵池龙，杨林，孙伟.实用软件工程（第2版）.北京:

电子工业出版社,2006