下载掌阅APP，畅读海量书库
立即打开
2.1 软件需求分析与定义
根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。而在这些高达74%的不成功项目中，有约60%的失败是源于需求问题，也就是差不多有一半的项目都遇到了这个问题，这一可怕的现象不得不让我们对需求分析引起高度的重视。
那么什么是软件需求呢？软件需求就是系统必须完成的事，以及必须具备的品质。具体来说，软件需求包括功能需求、非功能需求和设计约束3方面内容。
（1）功能需求： 是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。
（2）非功能需求： 是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等。
（3）设计约束： 也称为限制条件、补充规约，这通常是对解决方案的一些约束说明，例如必须采用国有自主知识版权的数据库系统，必须运行在UNIX操作系统之下等。
另外，在大量与需求相关的书籍、文章中有一些诸如业务需求、用户需求之类的词语，把很多读者搞得术语混淆，下面我们一起来看看这些概念。
（1）业务需求（Business Requirement）： 是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。
（2）用户需求（User Requirement）： 是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。
（3）系统需求（System Requirement）： 是从系统的角度来说明软件的需求，它包括用特性说明的功能需求、质量属性，以及其他非功能需求，还有设计约束。
也就是说，这分别对应于需求的3个不同的层次，从目标到具体，从整体到局部，从概念到细节。这些不同层次、不同类型的需求描述之间的关系如图2-1所示。
需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程，通常包括需求开发和需求管理两大工作。
（1）需求开发： 包括需求捕获、需求分析、编写规格说明书和需求验证四个阶段。在这个阶段需要确定产品所期望的用户类型、获取每种用户类型的需求、了解实际用户任务和目标，以及这些任务所支持的业务需求、分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型、对需求进行评审等工作。
图2-1 需求的组成结构示意图
（2）需求管理： 通常包括定义需求基线、处理需求变更、需求跟踪等方面的工作。
而对于需求工程而言，最重要的还是需求开发，而需求开发总结起来就是包括需求捕获、需求分析、需求规格化、需求验证4个环节。需求捕获是为了收集需求信息，需求分析则是在需求捕获的基础上进行分析、建立模型，然后将其进行规格化形成《软件需求规格说明书》，最后再通过客户和管理层进行验证。
需求规格化的工作就是编制《软件需求规格说明书》，具体的方法和注意事项请参考有关文档编制的相关章节。而需求验证的工作则包括组织一个由不同代表组成的小组，对需求规格说明书和相关模型进行审查；以需求为依据编写测试用例，为确认测试做好准备；在需求的基础上，起草第一份用户手册；确定合格标准，也就是让用户描述什么样的产品才算是满足他们的要求和适合他们使用的。
需求调查与问题定义是看上去简单，做起来难的一件事。在很多人的印象中，需求调查，就是找用户聊聊说说，记个笔记。其实需求调查是否科学，准备是否充分，对调查出来的结果影响很大，这是因为大部分客户无法完整地讲述需求，而且也不可能看到系统的全貌。要想做好需求调查，必须清楚地了解3个问题。
接下来，我们就对这三个部分的内容进行一些更加详细的说明与描述。
一方面，需求分析员应该知道，从宏观的角度来看，要捕获的信息包括三大类：一是与问题域相关的信息（如业务资料、组织结构图、业务处理流程等）；二是与要求解决的问题相关的信息；三是用户对系统的特别期望与施加的任何约束信息。这样才能够有的放矢，不会顾此失彼。
另外一方面，需求分析员在开展具体需求捕获工作时，应该做到在此之前明确自己需要获得什么信息，这样才有可能获得所需信息，才知道工作进展是否顺利，是否完成了目标。
除了要明确地知道我们需要什么方面的信息，还要知道它们可以从哪里获得。通常情况下，这些需要的信息会藏于客户、原有系统、原有系统用户、新系统的潜在用户、原有产品、竞争对手的产品、领域专家、技术法规与标准里。
面对这么多种可能，在具体的实践中该从何下手呢？其实也很简单，首先从人的角度来说，应该首先对涉众（也就是风险承担人、项目干系人）进行分类，然后从每一类涉众中找到1～2名代表；而对于文档、产品而言，则更容易有选择地查阅。
结合前面讲述的内容，在制订需求捕获计划的时候，不妨列出一个表格，左边写上想了解的信息，右边跟上认为可能的来源，这样就能够建立一一对应的关系，使得需求捕获工作更加有的放矢，也更加高效。
当我们知道需要去寻找什么信息，并且也找到了信息的来源地，接下来就需要选择合适的技术进行需求捕获了。在此，我们列举出一些最常用的需求捕获技术。
（1）用户访谈。
用户访谈是最基本的一种需求捕获手段，也是最基本的一种手段。其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
准备问题： 进行用户访谈之前，最好先对要询问的问题进行一些准备。准备的方法是围绕着想要获取的信息展开，设计一系列的问题，按顺序组织起来。而且还要预先准备好记录方式，主要包括本人记录、第三人记录或者是录音/录像的形式，不过采用录音/录像的方式应该征得被访谈者的同意，而且这种方法虽然看上去比较有效，不容易丢失信息，但这也会给后面的整理工作带来一定的工作量和难度。
访谈时的技巧： 在访谈时一定要注意措辞得当，在充分尊重被访谈者的基础上，尽量避免出现“我不知你在说什么”，“我是来帮助你更好地工作”这样的言语，否则将会破坏访谈的气氛，从而使访谈的效率大打折扣。在访谈时一定要注意保持轻松的气氛，选择客户有充裕时间的时段进行，在说话、问问题时应该尽量采用易于理解、通俗化的语言。另外，值得注意的是，分析人员应该在进行访谈之前进行一些相关领域的知识培训，充分阅读相关材料，以保证自己有较专业的理解与认识，让被访谈者能够信任你。
应该询问的问题： 在设计询问的问题时，应该考虑：自己的问题是否相关？回答是否正式？对方是回答这些问题的合适人选吗？是否问了过多的问题？是否还有更多的问题要问被访者？另外，还可以在询问过程中询问被访者还希望自己问他什么问题，还应该见哪些人？
总的来说，用户访谈具有良好的灵活性，有较宽广的应用范围，但是也存在着许多困难，诸如客户经常较忙，难以安排到时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要分析员有足够的领域知识；另外，在访谈时会遇到一些对于组织来说比较机密和敏感的话题。因此，这看似简单的技术，也需要分析人员拥有足够多的经验和较强的沟通能力。
（2）用户调查。
正如前面讲到的，用户访谈时最大的难处在于很多关键的人员时间有限，不容易安排过多的时间；而且客户面经常较广，不可能一一访谈。因此，我们就需要借助“用户调查”这一方法，通过精心设计要问的问题，然后下发到相关的人员手里，让他们填写答案。这样可以有效地克服前面提到的两个问题。
但是与用户访谈相比，用户调查最大的不足就是缺乏灵活性；而且双方未见面，分析人员无法从他们的表情等其他动作来获取一些更隐性的信息；还有就是客户有可能在心理上会不重视一张小小的表格，不认真对待从而使得反馈的信息不全面。基于上述原因，因此较好的做法是将这两种技术结合使用。具体地讲，就是先设计问题，制作成用户调查表，下发填写完后，进行仔细的分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作为补充。
（3）现场观摩。
俗话说得好，百闻不如一见，对于许多较为复杂的流程和操作而言，是比较难以用言语表达清楚的，而且这样做也会显得很低效。针对这一现象，分析团队可以就一些较复杂、较难理解的流程、操作采用现场观摩的方法来获取需求。
具体来说，就是走到客户的工作现场，一边观察，一边听客户的讲解，甚至可以安排人员跟随客户工作一小段时间。这样就可以使得分析人员更加直观地理解需求。
（4）文档考古。
对于一些数据流程比较复杂的，工作表单较多的项目，有时是难以通过说，或者通过观察来了解需求细节的。这个时候就可以借助于“文档考古”的方法，也就是对历史存在的一些文档进行研究，考古一词正是形象地说明了其主要的工作重心是结合已经填写完毕的、也就是带有数据的文件、表单、报告，从中获得所需的信息。
不过当你准备采用该方法时，也要记住这个方法的主要风险，那就是历史的文档可能与新系统的流程、数据有一些不吻合的地方，并且还可能承载一些原有系统的缺陷。要想有效地避免和发现这些问题，需要分析人员能够运用自己的聪明才智，将其与其他需求捕获技术结合对照。还有一个负面因素就是，这些历史的文档中记载的信息有可能涉及客户的商业秘密，因此对数据信息的保密也是分析人员基本的职业道德。
（5）联合讨论会。
这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表、分析人员、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6～18人，召开时间为1～5小时。
在会议之前，应该将与讨论主题相关的材料提前分发给所有要参加会议的人。在会议开始之后，首先应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。会议的最初，就是针对所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，第三步则是大家在此基础上对新的解决方案进行一番设想，在过程中将这些想法、问题、不足之处记录下来，形成一个要点清单。第四步就是针对这个要点清单进行整理，明确优先级，并进行评审。
这种联合讨论会将会起到群策群力的效果，对于一些最有歧义的问题和对需求最不清晰的领域都是十分有用的一种技术。而最大的难度就是会议的组织，要做到言之有物，气氛开放，否则将难以达到预想的效果。
在整个需求过程中，需求捕获、需求分析、需求规格化、需求验证4个阶段不是瀑布式的发展，而是应该采用迭代式的演化过程。也就是说，在进行需求捕获时，不要期望一次就将需求收集完，而是应该捕获到一些信息后，进行相应的需求分析，并针对分析中发现的疑问和不足，带着问题再进行有针对性的需求捕获工作。
进行可行性研究，其主要的目的是回答一个问题，即所提出的项目是否可以完成。需要注意的是，可行性研究毕竟不是解决问题，而是研究问题的范围，探索这个问题是不是值得去解决，根据现有的情况是否有能力，是否有可能找到较好的、成本效益合算的解决方案。
现在很多的开发团队把软件的最终开发结果是否符合需求规格说明书作为项目的成功标准，其实这是很片面的。真正成功的项目是满足客户的目标，为客户带来了预想的价值增长。而什么样的解决方案能够真正满足客户的需要，实现客户的目标呢？这就需要大量的需求分析与可行性研究工作。
在可行性研究工作开始之前，系统分析员应该协助客户一起完成“问题定义”工作，也就是先明确系统要做什么？即What问题，也就是上一小节所解决的内容。
问题定义的关键是清晰地界定出问题的内容、性质，以及系统的目标、规模等内容，并形成完整的书面报告。系统分析员在这个过程中将使用各种需求调查技术研究问题、引导问题，从而形成完整的问题定义。
可行性研究工作的目标大家已经了解，那么具体要完成什么工作，达到什么样的目的，也就是说从何着手呢？其实可行性研究工作的任务包括以下3个方面。
（1）技术可行性： 现有的技术是否能够有效地解决该问题？是否有多种不同的解决方案？现有的技术力量是否达到？
（2）经济可行性： 所有可能的解决方案所需投入的成本能否超过它的开发成本？它的成本效益分析结果如何？投资回报率如何？
（3）社会可行性： 该解决方案是否符合企业实际情况？是否符合员工利益？是否符合相关法规和行业规范？
完成可行性研究工作之后，必须将这些成果文档化地记录下来，形成《可行性研究报告》。
那么具体而言，可行性研究工作包括哪些事项呢？该如何着手？都需要哪些人参与呢？下面我们就可行性研究工作的步骤做一个总结性阐述。
（1）核实问题定义与目标。
开始正式进行可行性研究工作之前，首先要做的一个工作，就是对该项工作的基础——问题定义再次核实。具体来说，就是仔细阅读问题定义的相关材料，对该问题所涉及的领域知识进行学习、考证，然后通过走访相关人员进行验证与核实。
这一步骤的关键目标是：使问题定义更加清晰、明确、没有歧义性，并且对系统的目标、规模，以及相关约束与限制条件做出更加细致的定义，确保可行性研究小组的所有成员达成共识。
（2）研究分析现有系统。
对现有系统的仔细分析与研究是十分重要的一项工作，因为它是新系统开发的最好参照物，对其的充分分析有助于新系统的开发。这么说的原因，主要是基于以下几点考虑：
从字面上的理解会容易产生一个常见的误区，就是认为现有系统一定是软件系统，其实这里的“现有系统”不仅包括旧的软件系统，还包括旧的非计算机系统。
（3）为新系统建模。
在问题定义和对现有系统研究的基础上，开始对新的系统进行建模，建模的目的是为了获得一个对新系统的框架认识、概念性认识。通常可以采用以下几种技术。
再次请大家注意，这个阶段的所有模型是不够精确的，只是一个框架，要达到一个宏观的角度，否则将陷入无休止的工作中。
（4）客户复核。
可以这么说，在第（3）步中建立起来的系统模型是系统分析员眼里的问题定义，那么这与客户心目中的问题是否一致呢？因此，完整的系统模型建立之后，一个十分重要的工作就是与客户一起进行复核。当然，由于这个时候模型将成为讨论和分析的基础，因此使用客户更容易接受的模型将显得十分重要。
如果在这个过程中，发现模型与客户的目标有不一致的地方，就应该再次通过访谈、现场观摩、对现有系统分析等手段进行了解，然后在此基础上修改模型。由此也可以看书，（1）～（4）的步骤是一个循环，周而复始，直至客户确认了新的系统模型为止。
（5）提出并评价解决方案。
前面的工作还是停留在“系统解决什么问题”上，只是更加清晰地进行了定义和说明。当客户与系统分析员对要解决的问题有了一个清晰的共识之后，接下来的工作就是提出解决方案，这也是系统分析员很重要的工作之一。
在这个阶段，应该尽量列举出各种可行的解决方案，并且对这些解决方案的优点、缺点做一个综合性的评价，以便下一步决策。需要注意的是，对那些明显不可行的，如技术上还没有相应的办法、经济角度明显不可行的、违背企业或行业实际情况的解决方案应该直接过滤掉。
（6）确定最终推荐的解决方案。
明确地指出该项目是否可行，如果可行，什么方面是最合理的？由于对这两个问题的回答，是可行性分析研究工作的核心目标。因此在各种解决方案提出之后，接下来应该从中选中一个最合理、最可行的解决方案，更加详细地说明理由，并且还要对其进行更加完善的成本/效益分析。
具体来说，成本效益分析可以分成两个部分的内容。
①成本估计。 对于软件系统而言，主要的成本是人力资源成本，另外还包括一些直接的费用、设备采购的费用等。相对而言，硬件设备，以及其他的一些相关费用的评估会比较容易一些，最难的是人力资源的成本分析。因此，对系统工作量（用人月、人年等单位进行说明）进行合理、科学的评估，并在此基础上进行计算是很必要的。
要想准确地估算出工作量，通常可以借助的工具是历史数据和经验模型。历史数据就是指你所在的开发团队以往从事项目的情况，可以通过以类似系统项目做参照的方法。而经验模型则是一些软件工作量估算方面的研究总结，常用的有功能点分析、COCOMO分析等。
通常，可以分成以下几步进行：
另外，有一点是十分重要的，在这个阶段是不可能得到精确的估算值的，这个观念必须让开发团队、管理层和客户很清晰地认识到。否则，即使违心地给出精确的估算值也显得没有任何意义。
这个阶段的工作，对于系统分析员而言，很重要的知识技能在于软件度量与估算方法、技术的掌握方面。
②效益分析。 有了估算出来的开发成本以后，就可以进行效益分析了。在做效益分析之前应该首先对该系统应用之后，将会带来的直接、间接收益，以及成本降低的具体数额进行量化。并且通过经济学的相关模型来进行分析，这要求系统分析人员能够在该方面有一定的知识积累。通常进行效益分析时要借助以下几个概念。
P = F 1 /(1+ j )+ F 2 /(1+ j ) 2 +…+ F n /(1+ j ) n
其中， P 代表总投资额， F i 是第 i 年年底的收益， n 是系统使用寿命， j 就是投资回报率。
（7）草拟开发计划。
在上一步，我们对主要推荐的解决方案进行了详细的成本效益分析，对工作内容和工作量都有了一个详细的了解，接下来需要制订一个最粗略的开发计划，说明开发所需的资源、人员和时间进度安排。这也将作为可行性分析的一个重要依据和立项开发后制订项目计划的基础。
（8）以书面的形式提交《可行性分析报告》并进行审查。
最后就是将这些研究的结果整理成文，提交客户和管理层，进行审查通过。在这个阶段还应该制作一些相应的讲义，为客户和管理层做介绍和说明。
在细化地说明需求分析之前，我们先温习一下分析的定义：所谓分析就是通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明。
从上面的定义中，我们可以知道需求分析的关键在于对问题域的研究与理解。为了便于理解问题域，现代软件工程方法所推荐的做法是对问题域进行抽象，将其分解为若干的基本元素，然后对元素之间的关系进行建模。
前面对分析的定义相对比较抽象，不太易于理解，不太容易用来指导具体的操作。其实用更通俗的话来说，需求分析就是提炼、分析和仔细审查已经收集到的需求，以确保所有的涉众都明白其含义并找出其中的错误、遗漏或其他不足的地方。
在Karl E.Wiegers的经典名作《软件需求》一书中指出，需求分析的工作通常包括以下七个方面。
（1）绘制系统上下文范围关系图： 这种关系图是用于定义系统与系统外部实体间的界限和接口的简单模型，它可以为需求确定一个范围。其实就是DFD的0层图，图2-2就是一个实例。
图2-2 系统上下文范围关系图
（2）创建用户接口原型： 由于用户界面对于一个系统来说是十分重要的，因此在需求分析阶段通过快速开发工具开发一个可抛弃原型，或者通过PowerPoint、Authorware等演示工具制作一个演示原型，甚至可以用纸笔画出一些关键的界面接口示意图，这些都会帮助客户更好地理解所要解决的问题，更好地理解需求。
（3）分析需求的可行性： 对所有获得的需求进行成本、性能、技术实现方面的可行性研究，以及这些需求项是否与其他的需求项有冲突，是否有对外的依赖关系等。
（4）确定需求的优先级： 这是一个很重要的工作，迭代开发已经成为现代软件工程方法论的一个基础，而需求的优先级是制订迭代计划的一个最重要的依据。对于需求优先级的描述，可以采用满意度/非满意度指标进行说明（满意度：取值1～5，表示当需求被实现时用户的满意程度。不满意度：取值1～5，表示当需求未被实现时用户的不满意程度。）
（5）为需求建立模型： 也就是建立分析模型，这些模型的表现形式主要是图表加上少量的文字描述，正所谓一图抵千字，图形化地描述需求使其更加清晰、易懂。根据采用的分析技术的不同，采用的图也不同，例如，OO技术下的用例模型和域模型；面向数据分析技术下的E-R图；结构化分析技术下的数据流图等。
（6）创建数据字典： 数据字典是对系统用到的所有数据项和结构进行定义，以确保开发人员使用统一的数据定义。
（7）使用质量功能调配（QFD）： 这是在需求优先级基础上的一个升华，其原理与满意度/非满意度指标十分接近。它通过将产品特性、属性与对客户的重要性联系起来，QFD将需求分为三类：期望需求，即如果缺少会让其感到不满意的需求；普通需求；兴奋需求：实现了客户会感到惊喜，但没有也不会遭到责备。
根据在需求方面的权威Alan Davis的见解，仅仅单一地看需求并不能提供对需求的完全理解，而是需要把用文字表示的需求和用图形表示的需求结合起来。而用图形表示需求，就是需求建模，获得分析模型。分析模型有助于检测需求的不一致性、模糊性、错误及遗漏。有一点需要提醒读者注意的是，迄今为止，尚未发现一种分析建模技术能够将所有的内容涵盖，我们需要根据实际情况进行有效的组合。
进行需求建模时，首先应该建立一个概念，那就是分析模型的基础是分析元素，而分析元素则来源于客户所陈述的需求。而且，我们应该尽可能地利用CASE工具创建、维护、发布需求模型，以保持其可控性。
需求分析的方法可谓种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型。我们先从分析方法发展的历史，对其建立一个概要性的认识。
结构化分析方法（Structured Analysis，SA）： 最初的分析方法都不成体系，而且通常都只包括一些笼统的告诫，在20世纪70年代分析技术发展的分水岭终于出现了。这时人们开始尝试使用标准化的方法，开发和推出各种名为“结构化分析”的方法论，Tom DeMacro是这个领域最有代表性和权威性的专家。
软系统方法： 这是一个过渡性的方法论，并未真正流行过，它的出现只是证明了结构化分析方法的一些不足。因为结构化分析方法采用的相对形式化的模型不仅与社会观格格不入，而且在解决“不确定性”时显得十分无力。最有代表性的软系统方法是Checkland方法。
面向对象分析方法（Object Oriented Analysis，OOA）： 在20世纪90年代，结构化方法的不足在面对多变的商业世界时，显得更加苍白无力，这促使了OOA的迅速发展。
面向问题域的分析（Problem Domain Oriented Analysis，PDOA）： 随着技术的应用和发展发现面向对象分析方法也存在着很多的不足，应运而生了一些新的方法论，PDOA就是其中一种。不过PDOA尚在研究阶段，并未广泛应用。
结构化分析与面向对象分析方法之间的最大差别是：结构化分析方法把系统看做一个过程的集合体，包括人完成的和电脑完成的；而面向对象方法则把系统看成一个相互影响的对象集。结构化分析方法的特点是利用数据流图来帮助人们理解问题，对问题进行分析。
结构化分析一般包括以下工具，在本节的随后部分将对它们一一做简单介绍。
结构化系统分析方法从总体上看是一种强烈依赖数据流图的自顶向下的建模方法。它不仅是需求分析技术，也是完成需求规格化的有效技术手段。
在介绍具体的结构化分析方法之前，我们先对如何进行结构化分析做一个总结性描述，以帮助大家更好地应用该方法。
（1）研究“物质环境”。 首先，应画出当前系统（可能是非计算机系统，或是半计算机系统）的数据流图，说明系统的输入、输出数据流，说明系统的数据流情况，以及经历了哪些处理过程。在这个数据流图中，可以包括一些非计算机系统中数据流及处理的命名，例如，部门名、岗位名、报表名等。这个过程可以帮助分析员有效地理解业务环境，在与用户的充分沟通与交流中完成。
（2）建立系统逻辑模型。 当物理模型建立完成之后，接下来的工作是画出相对真实系统的等价逻辑数据流图。在前一步骤建立的数据流图的基础上，将所有自然数据流都转成等价的逻辑流：例如将现实世界的报表改成存储在计算机系统中的文件里；又如将现实世界中“送往总经理办公室”改为“报送报表”。
（3）划清人机界限。 最后，我们确定在系统逻辑模型中，哪些将采用自动化完成，哪些仍然保留手工操作。这样就可以清晰地划清系统的范围。
数据流图是一种图形化的系统模型，它在一张图中展示信息系统的主要需求，即输入、输出、处理（过程）、数据存储。由于从DFD中可以很容易地一眼看出系统紧密结合的各个部分，而且整个图形模式只有五个符号需要记忆，所以深受分析人员的喜爱，因而广为流行。
正如图2-3所示，DFD中包括以下几个基本元素。
图2-3 数据流图的符号集
（1）数据流图的层次。 正如前面提到的，结构化分析的思路是依赖于数据流图进行自顶而下的分析。这也是因为系统通常比较复杂，很难在一张图上将所有的数据流和加工描述清楚。因此，数据流图提供一种表现系统高层和低层概念的机制。也就是先绘制一张较高层次的数据流图，然后在此基础上，对其中的过程（处理）进行分解，分解成若干独立的、低层次的、详细的数据流图，而且可以这样逐一地分解下去，直至系统被清晰地描述出来。
（2）Context图。 Context图，也就是在2.1.4节中提到的系统上下文范围关系图。这是描述系统最高层结构的DFD图。它的特点是，将整个待开发的系统表示为一个过程，将所有的外部实体和进出系统的数据流都画在一张图中。
图2-3就是一个Context图的实例，只不过在绘制时做了一些处理，使得它看上去更加直观易懂，图2-4也是一个Context图的例子。
图2-4 Context图实例
Context图用来描述系统有什么输入、输出数据流，与哪些外部实体直接相关，可以把整个系统的范围勾画出来。
（3）逐级分解。 当完成了Context图的建模后，就可以在此基础上进行进一步分解。下面我们以图2-4为例，进行再分解，在对原有流程了解的基础上，可以得到图2-5。
图2-5 DFD 0层图
图2-5是在Context的基础上做的第一次分解，而在Context只有一个过程，那就是系统，我们将其编号为0。接下来对Context图进行分解，其实就是对这个编号为0的过程进行更细化的描述，在这里引入了新的过程、数据存储，为了能够区分其位于的级别，在这个层次上的过程将以1、2、3为序列进行编号。
正是由于这是对过程0的分解，因此也称之为DFD 0层图。而我们可以根据需要对DFD 0层图上的过程（编号为1、2、3）进行如法炮制的分解，称之为DFD 1层图，DFD 1层图中引入的新过程，其编号规则就是1.1，1.2…，以及2.1，2.2…，依此类推，直到完成分析工作。
另外，这里存在一个很关键的要点，由于DFD 0层图是Context的细化，因此所有的输入和输出应该与Context完全一致，否则就说明存在着错误。
（4）如何画DFD。 DFD的绘制是一个自顶向下、由外到里的过程，通常按照以下几个步骤进行。
不考虑初始化和终点，暂不考虑出错路径等细节，不画控制流和控制信息。
为了能够更好地描述DFD的部件，结构化分析方法还引入了数据字典、结构化语言，以及决策树、决策表等方法。通过使用这些工具，能够对数据流图中描述不够清晰的地方进行有效的补充。
（1）结构化语言。 结构化语言是结构化编程语言与自然语言的有机结合，可以采用顺序结构、分支结构、循环结构等机制，同时还说明加工的处理流程。该技术通常用来描述一些重要的、复杂的过程的程序逻辑逻辑。表2-1所示是一个使用结构化语言描述的例子。
表2-1 使用结构化语言描述的例子
（2）决策表和决策树。 决策表是一种处理逻辑的表格表示方法，其中包括决策变量、决策变量值、参与者或公式。与上例对应的决策表示例如表2-2所示。
表2-2 决策表示例
而决策树则使用像树枝一样的线条对过程逻辑进行图表化的描述。与上例相应的决策表如图2-6所示。
图2-6 决策树示例
很显然，应用这两种手段来描述复杂决策逻辑，要远远优于使用结构化语言。而这两种技术也各有优劣，决策表更严密，而决策树更易读。分析人员可以根据自己的实际需要来灵活选择应用。
（3）数据字典。 数据字典技术是一种很实用、有效的表达数据格式的手段。它是对所有与系统相关的数据元素的一个有组织的列表和精确的、严格的定义，使用户和系统分析员对输入、输出、存储成分和中间计算机有共同的理解。通常数据字典的每一条目中包括以下信息。
表2-3是一个数据字典的实例。
表2-3 数据字典的实例
传统的系统开发方法都把重点集中在新系统的数据存储需求上，包括数据实体、数据实体的属性，以及它们之间的关系。而描述这些东西的最好形式就是借助实体-关系图（Entity Relationship Diagram，E-R图）。
（1）实体。 由于所有的系统都包括数据，而且是大量的数据。因此，我们在开发系统时，需要一个概念来抽象地表示一组相类似的事物的所有实例，我们称这个概念为实体，在E-R图中使用一个圆角的矩形来表示，如图2-7（a）所示。从这个概念上看，与面向对象分析方法中的类有些相似。不过，由于在这里只关心数据，因此实体通常是需要存储的数据。与类一样，实体也有实例，表示实体的一个具体值，称为实体实例。
由于实体是用来存储数据的，因此需要描述它具体存储什么数据，这些具体的数据叫做属性，用来描述实体的性质或特征，可以直接在圆角矩形中填入这些属性值，如图2-7（b）所示。另外还应该为属性定义合法的值，这个定义包括数据类型、域，以及默认值，这些描述可以直接跟在属性值的后面，如图2-7（c）所示。关于数据类型、域的说明如表2-4所示。
表2-4 数据类型与域说明
另外，为了能够区别每一个实体实例，经常需要设置一个标志符或键，而键就是其中的一个或一组属性，它们对每个实体实例具有唯一的值，通常在E-R图中的属性值后面加上Primary Key或Alternate Key等描述，如图2-7（d）所示。
图2-7 实体表示图例
（2）关系。 实体和属性都不是孤立存在的，它们各自代表的事物互相交互，并且互相影响，共同支持业务任务。关系是存在于一个或多个实体之间的自然业务联系。关系可以链接实体的一个事件，也可以是纯粹的逻辑关系。
通常情况下，我们还需要对关系的多重性进行说明，这也就是基数。基数定义了一个实体相对于另一个关联实体的某个具体值的最小和最大具体值数量。因为所有的关系都是双向的，因此在两个方向上都需要定义。基数定义如图2-8所示。
图2-8 关系的基数表示法
结构化分析方法为开发者和客户提供一个直观易懂的模型，能够对实现理解问题域这一基本的分析目标以支持。但也存在着很多的先天不足：
可以这么说，结构化分析方法在很大程度上推动了分析技术的发展，但又被更合适的技术逐渐取代，不过，结构化分析方法中的具体工具仍然有很广泛的应用空间。
相对而言，面向问题域的分析是一项很新的技术，还处于研究阶段，相关的文档资料还不多。与SA和OOA相比，面向问题域的分析更多地强调描述，而较少强调建模。它的描述大致分为以下两个部分。
（1）关注问题域： 用一个文档对含有问题域进行相关的描述，并列出需在该域中求解的问题列表，即需求列表。只有这个文档是在分析时产生的。
（2）关注解系统的待求行为： 用一个文档对解系统（即系统实现）的待求行为进行描述。该文档将在需求规格说明时再完成。
在面向问题域的分析方法中，对整个过程有着一个清晰的定义：
基于以上两点，收集并用文档说明新系统的需求。
从上面的描述中，我们可以看出，问题框架是面向问题域分析的核心元素。问题框架是将问题域建模成一系列相互关联的子域，而一个子域可以是那些可能算是精选出来的问题域的一部分，也可以把问题框架视为开发Context图，但不同的是Context图的建模对象是针对解系统的，而问题框架则是针对问题域的。也就是说，问题框架的目标就是大量地捕获更多有关问题域的信息。