怎样做需求分析.docx
《怎样做需求分析.docx》由会员分享，可在线阅读，更多相关《怎样做需求分析.docx（19页珍藏版）》请在冰豆网上搜索。
怎样做需求分析
怎样做需求分析
如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。
建议采用以下步骤形成软件需求：
获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。
下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。
获取用户需求
这是该阶段的一个最重要的任务。
以下为获取用户需求需要执行的活动（如图1所示）。
●了解客户方的所有用户类型以及潜在的类型。
然后，根据他们的要求来确定系统的整体目标和系统的工作范围。
●对用户进行访谈和调研。
交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。
需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。
例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
●需求分析人员对收集到的用户需求做进一步的分析和整理。
下面是几条常见的准则：
⑴对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；
图1获取用户需求的活动
⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；
⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。
●需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。
大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。
需求分析人员在这个任务中需要执行下述活动：
⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；
⑵使需求符合系统的整体目标；
⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。
分析用户需求
在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。
这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。
用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。
分析用户需求需要执行下列活动：
●以图形表示的方式描述系统的整体结构，包括系统的边界与接口；
●通过原型、页面流或其它方式向用户提供可视化的界面，用户可以对需求做出自己的评价；
●系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等；
●以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。
图2DFD示意图
用于需求建模的方法有很多种，最常用的包括数据流图（DFD）、实体关系图（ERD）和用例图（UseCase）三种方式。
DFD作为结构化系统分析与设计的主要方法，已经得到了广泛的应用，DFD尤其适用于MIS系统的表述。
DFD使用四种基本元素来描述系统的行为，过程、实体、数据流和数据存储。
DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是从DFD图中无法判断活动的时序关系。
图2描述的是某个项目的DFD示意图。
ERD方法用于描述系统实体间的对应关系，需求分析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使用ERD描述物理表之间的关系。
需求分析阶段使用ERD来描述现实世界中的对象。
ERD只关注系统中数据间的关系，而缺乏对系统功能的描述。
如果将ERD与DFD两种方法相结合，则可以更准确地描述系统的需求。
在面向对象分析的方法中通常使用UseCase来获取软件的需求。
UseCase通过描述“系统”和“活动者”之间的交互来描述系统的行为。
通过分解系统目标，UseCase描述活动者为了实现这些目标而执行的所有步骤。
UseCase方法最主要的优点，在于它是用户导向的，用户可以根据自己所对应的UseCase来不断细化自己的需求。
此外，使用UseCase还可以方便地得到系统功能的测试用例。
=============================================
上一期，我们介绍了需求分析五个步骤中的前两个步骤（获取用户需求、分析用户需求），本期将继续介绍后三个步骤（编写需求文档、评审需求文档、管理需求），并与大家讨论相关实践问题。
1、编写需求文档
需求文档可以使用自然语言或形式化语言来描述，还可以添加图形的表述方式和模型表征的方式。
需求文档应该包括用户的所有需求（功能性需求和非功能性需求）。
2、评审需求文档
需求文档完成后，需要经过正式评审，以便作为下一阶段工作的基础。
一般的评审分为用户评审和同行评审两类。
用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。
而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。
3、管理需求
图1需求变更流程
需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。
如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。
所以需求管理要保证需求分析各个活动都得到了充分的执行。
对于需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。
需求变更流程和需求跟踪矩阵分别如图1和图2所示。
图2需求跟踪矩阵
常见问题及建议
Q、客户与最终用户的区别是什么？
A、可以借助图3来说明它们之间的区别。
图3需求获取渠道示意图
软件需求来自系统工程与客户两个方面，其中客户是主要的需求提供者（系统工程需求也来自于客户）。
客户需要搜集其最终用户的需求并考虑自身的需求，然后再提供给开发方。
假如客户并未去认真搜集最终用户的需求，开发方便需要做到这一点，因为系统最终要满足最终用户的需求。
Q、如何进行用户访谈？
A、首先，一定要事先确定访谈的目的和提纲。
其次，因为用户往往并不知道应该提供哪些方面的需求，所以需要开发人员引导。
Q、用户访谈内容是什么？
A、首先，请用户描述他们如何完成自己当前的工作，并与用户一起抽象出一个工作流程或工作模型。
然后，在得到用户的认可后，向用户解释自己是怎样来实现这些功能的，并说明哪些环节可以用自动化方式实现等。
Q、采用哪一种方式做需求分析最好？
A、不同的需求分析有不同的特点。
还没有哪一种方法可以完全替代别的方法，否则，现在就不会存在不同的需求建模方式了。
一般来说，可以使用DFD＋ERD来描述那些功能层次比较清晰的需求；而USECASE则适于描述功能结构复杂的需求。
做需求分析的目的是为了建立需求的模型，不同的子系统有可能使用不同的建模方法。
Q、怎样做原型，原型的目的是什么？
A、通常使用原型分析方法来帮助开发方进一步获取用户需求或让用户确认需求。
开发方往往先向用户提供一个可视界面作为原型，并在界面上布置必要的元素以演示用户所需要的功能。
可以使用第四代语言（例如VisualBasic、Delphi等）来快速生成用户界面，也可以使用FrontPage等网页制作工具来生成用户可视的页面流。
原型的目的往往是获取需求。
但有时也使用原型的方式来验证关键技术或技术难点。
对于技术原型，界面则往往被忽略掉。
需求的问题
需求的问题，是一个简单的问题
需求决定了软件做什么，要提供什么功能。
软件工程初期的一般过程是，软件开发的计划，确定要实现的目标和进度等，然后就是需求规格说明书，该说明书要得到用户的认可。
用户往往提供了一份要求的说明，开发人员在这个基础上进行了加工和整理。
此后的开发过程，都是围绕着需求规格说明书进行进一步地细化，直至开发出产品。
当然，测试计划中也要针对需求进行验证，看看是否满足了用户的要求。
一般来说，用例视图可以很好地表现需求。
用例图中，若干角色actor与系统提供的用例（功能）之间的连接关系。
需求的问题，是一个复杂的问题
有些时候，需求的问题会变得很复杂的。
尤其是在做行业软件或者ERP的时候，你遇到不同的客户，每个客户都有他的想法或要求，而且有些客户没有明确的思路，有些则有他们很固执的思路，一时间仿佛需求是没完没了的。
或许你的软件已经是一个产品，那么究竟对什么功能进行取舍，对什么功能要增加进软件的核心，对什么功能采用二次开发，都是需要仔细判断的事情。
1需求的重复和变更
对于比较大的系统，客户不可能一次性地把需求完全提清楚。
这是必须容忍的。
只要你不断沟通和了解，用户需求就会不断增加。
有些公司采用的方法是在需求规格说明书上让客户签字，然后严格按照该说明书来实现。
如果以后客户有新的要求，则要另外考虑。
但在另一方面，客户永远是上帝，一个软件的成功，应该是用户用得非常流畅和满意。
2有些需求无法实现
和客户的沟通也很重要。
什么是必须满足的需求，而另外一些需求可能暂时不能提供实现，这也需要解释清楚。
3实现的功能和客户原来提出的需求会有所差别。
很多软件的问题最后总结下来是因为需求没有明确。
开发人员没有认准客户究竟需要什么。
这时候只能修改软件。
需求的问题，是一个技术的问题
每个需求的特性可体现在很多方面：
如优先级、有效性，效率，灵活性，完整性，互操作性，可靠性，健壮性，可用性；可维护性，可移植性，可重用性，可测试性等。
确定需求优先级：
可以粗略地分为三级：
高
一个关键任务的需求，必须在此版本实现；只有在这些需求上达成一致意见，软件才会被接受；必须完美地实现
中
支持必要的系统操作，最终所要求的，但如果有必要，可以延迟到下一版本；实现这些需求将增强产品的性能，但如果忽略这些需求，产品也是可以被接受的；需要付出努力，但不必做得太完美
低
功能或质量上的增强，如果资源允许的话，实现这些需求会使产品更完美；实现或不实现均可；可以包含缺陷
更精确的优先级设定如下表：
权值
1
1
1
1
需求
收益
代价
价值
价值%
成本
成本%
风险
风险%
优先级
<需求>
<1-9>
<1-9>
<>
<>
<1-9>
<>
<1-9>
<>
<>
其中各权值按实际情况而定，不能确定按1取值。
收益：
实现此需求对用户的益处；
代价：
未实现此需求对用户的损害；
价值=收益*收益权值+代价*代价权值
价值%=价值/（总价值）*100%
成本：
实现此需求所需的各种成本；
成本%=成本/（总成本）*100%
风险：
实现此需求所承担的风险，特别是技术上的；
风险%=风险/（总风险）*100%
优先级=价值%/（成本%*成本权值+风险%*风险权值）
最后按需求优先级排序，优先实现高优先级的需求。
风险的控制和避免：
对需求将可能面临的风险要有充分的估计并尽量避免风险的发生及其所造成的损失。
建立风险跟踪，保持对危害最大的几项风险的控制，并在开发过程中周期性地更新风险跟踪项目。
需求的问题，是一个管理的问题
需求取得：
市场销售部门、技术支持或客户服务所得到的需求，或者开发人员内部通过对业务的分析归纳得出的一些要改进的功能。
对需求进行管理的环节应该尽可能精简。
最好直接由系统分析来做。
经过很多环节的筛选，需求可能已经走样了。
纸面上只有一两句话的需求，背后有你看不到的真正想法存在。
所以应该主动走出去寻找需求，应该选择最典型的客户进行访问。
领会他们的管理思路和改革方向。
需求决策：
对于相互矛盾的需求，在同类用户中由产品代表决策；对于不同类用户要根据重要性作适当折衷；对于用户的特别喜好要根据用户的重要性决定；用户中领导的需求要服从最终实际使用的用户需求；当开发者想象中的产品通常要服从用户的需求，但并不表示用户总是对的。
需求分析：
分析需求的各个特性，制作出需求分析规格说明书。
需求评审：
由相关人员共同对需求进行评审。
需求变更：
如果遇到需求的变更，需要及时作出调整，即使与开发部门联系，提出变更的建议，并分析可能产生的影响，如对产品稳定性的影响。
变更的需求需要严格的测试。
版本控制：
确定需求文档版本，确定单个需求文档的版本；
需求跟踪：
需求的跟踪记录需求的状态，包括未定义、放弃、需完善、已定义、实现中、待测试、测试中、完成、放弃实现等
需求管理工具：
曾经看到过的工具有RationalRequsitePro4.5版。
需要用Word97支持。
但对中文的支持不够好。
如何对电子商务系统进行需求分析
一、需求分析
在具体的研究需求分析之前，我们先了解一下软件工程这个概念。
软件工程分为三个层次，过程层、方法层、工具层。
在最基础的过程层，最重要的就是一组被称为关键过程区域（KPAs）的框架（KPA的概念在讨论CMM的书中有详细的概念说明）。
关键过程区域构成了软件项目的管理控制的基础，并且确立了上下文各区域的关系，其中规定了技术方法的采用、工程产品的，模型、文档、数据、报告、表格等，等的产生、里程碑的建立、质量的保证及变化的适当管理。
方法层主要是过程在技术上的实现。
它解决的问题是如何做。
软件工程方法涵盖了一系列的任务：
需求分析、设计、编程、测试、维护。
同时他还包括了一组基本原则，控制了每一个的关键过程区域。
工具层就很好理解了，他对过程层和方法层提供了自动和半自动的支持。
这些辅助工具就称为CASE。
可以看到需求分析的位置，但是事实上需求分析是跨越了软件工程的三个层次的。
这一点是和其他的过程是一样的。
当然我们这里比较重点强调的是在软件工程的方法层，同时也涉及到一些过程层的思想，至于工具层则不再我们的讨论之列，但是会提到一些很适合在需求分析时应用的工具，诸如Word、Excel、Visio等。
方法需求分析都包括了哪些方法呢？
这里列举出在《需求分析》一书中推荐的一些方法。
1）绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
同时它也明确了通过接口的信息流和物质流。
2）创建用户接口原型，当开发人员或用户不能确定需求时，开发一个用户接口原型—一个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。
用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。
注意要找出需求文档与原型之间所有的冲突之处。
3）分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
4）确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。
以优先级为基础确定产品版本将包括哪些特性或哪类需求。
当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
5）为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。
它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。
这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
6）创建数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。
在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。
分析和设计工具通常包括数据字典组件。
7）使用质量功能调配，（QFD）是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。
该技术提供了一种分析方法以明确那些是客户最为关注的特性。
QFD将需求分为三类：
期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备（Zultner1993;Pardee1996）。
记住一点，不要试图在你的项目中把这些方法都用上去，四个现代化并不是一夜就可以实现的。
同样，尝试着使用你认为对你很有帮助的方法，确实收到效果之后，在考虑继续学习方法。
因为上面提到的都是需求分析的大方法，事实号、记录业务规范、创建需求跟踪能力矩阵、审查需求文档、以需求为依据编写测试用例、编写用户手册、确定合格的标准。
二、业务建模
很多人都没有意识到业务需求阶段应该做些什么事情，实际上业务建模是最重要的一件事情。
不要觉得业务建模这个词很深奥，让人模不着头脑。
其实所有做过需求分析的人都做过业务建模，比如你了解企业的运作模式就?
是一种你脑海中的业务建模。
但是大多数人都没有科学的、系统的、文档化的做过业务建模。
业务建模的目的在于：
了解目标组织（将要在其中部署系统的组织）的结构及机制。
了解目标组织中当前存在的问题并确定改进的可能性。
确保客户、最终用户和开发人员就目标组织达成共识。
导出支持目标组织所需的业务需求。
上面的话是不是很抽象呢，其实没有什么复杂的：
人和电脑是完全不同的思想（思维方式）。
所以，原先适合人的业务流程对于计算机来说可不一定合适的，为了最大限度的利用计算机，必须要了解原先的业务流程并对此加易改造（流程自动化），当然这些动作需要得到用户的许可。
有些人认为说只有ERP这种大系统才需要对业务流程进行重组，但是实际，不论是部门级的MIS系统，还是社会级的电子商务系统，都需要对业务流程进行改造，所不同的只是改造的程度。
业务建模很重要的一点是在分析企业流程的同时分析出基础企业对象（CommonBusinessObject）（这个词我翻译的不好，如果大家有更好的翻译，请告诉我）。
任何企业都有最基础的一些元素，例如银行的CBO就有帐户，制造业的CB对多，订单和产品之间又是一对多，这样一个多对多的关系就拆分成两个一对多的关系，而新的订单类也就顺理成章的产生了。
在订单类产生时，你可能还会加入一个关联类：
业务员类。
而业务员类又是从员工类继承下来的。
所以呢，企业的四种CBO通过不同的组合，不同的关系，能够形成企业运作的许许多多的CBO。
CBO是做业务建模的基础，在此基础上，通过评估业务状态，说明当前业务，确定业务流程，改进业务流程的定义，设计业务流程实现，改进角色和职责，研究流程自动化，开发领域模型等一系列在RUP中定义的工作流程实现业务建模的目标。
三、需求获取
需求获取（requirementelicitation）是需求工程的主体。
对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。
获取用户需求位于软件需求三个层次的中间一层。
业务需求决定用户需求，它描述了用户利用系统需要完成的任务。
从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。
需求获取是在问题及其最终解决方案之间架设桥梁的第一步。
获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。
一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。
参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。
把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。
需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。
当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。
同时，你将处理这些信息以理解它们，并把它们分成不同的类别，要交流的方面。
需求获取只有通过有效的客户—开发者的合作才能成功。
分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。
为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。
对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。
确定用户已经理解：
对于某些功能的讨论并不意味着即将在产品中实现它。
对于想到的需求必须集中处理并设定优先级?
，以避免一个不能带来任何益处的无限大的项目。
需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本。
作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。
询问一个可扩充（open-ended）的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。
调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。
想像你自己在学习用户的工作，你需要完成什么任务？
你有什么问题？
从这一角度来指导需求的开发和利用。
还有，探讨例外的情况：
什么会妨碍用户顺利完成任务？
对系统错误情况的反映，用户是如何想的？
询问问题时，以“还有什么能”,”当?
时，将会发生什么”“你有没有曾经想过”,“有没有人曾经”为开头。
记下每一个需求的来源，这样向下跟踪直到发现特定的客户。
有些时候，尝试着问一些“愚蠢”的问题也有助于客户打开话匣子。
如果你直接要求客户写出业务是如何实现的，客户十有八九无法完成。
但是如果你尝试着问一些实际的问题，例如：
“以我的理解，你们收到订单后，会...”。
客户立刻就会指出你的错误，并滔滔不绝的开始谈论业务，而你，就在一边仔细的聆听吧。
这一招就叫做“抛砖引玉”。
需求讨论会上必须要使用笔记本电脑，还要指定一个打字熟练的人把所有的讨论记录下来，记录的同时还要做一定的整理。
如果不这样做，那么你结束会议的时候就会发现，所有的讨论只剩下一个模糊的印象，需求对你来说仍然是一件遥远的事情。
在座谈讨论之后，记下所讨论的条目（item），并请参与讨论的用户评论并更正。
及早并经常进行座谈讨论是需求获取成功的一个关键途径，因为只有提供需求的人才能确定是否真正获取需求。
进行深入收集和分析以消除任何冲突或不一致性。
尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。
从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。
Gause和Weinberg（1989）提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。
客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？
”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。
需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。
一个研究表明：
比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式（KielandCarmel1995）。
与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。
直接聘请用户进行获取需求的过程是为项目获得支持和买入（buy-in）的一种方式。
尽量理解用户用于表述他们需求的思维过程。
充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。
流程图和决策树是描述这些逻辑决策途径的好方法。
在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。
如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。
如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。
当前的范围太小，以致不能提供一个令人满意的产品。
需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。
正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。
这样说虽然很
升级会员 