3.1软件需求分析概述
软件需求分析是软件过程中一个非常重要的阶段，也是决定性的一步，只有通过需求分析才能将客户对最终软件系统的功能性和非功能性要求归纳总结为严格的需求规约（Requirements Specification），从而为设计打下基础。
需求分析阶段的根本任务是理解和表达用户的需求。理解的过程包括用户需求的获取，适当的分析与综合，需求的验证等内容。表达则是将分析的结果以适当的形式加以描述。这里的描述形式一方面应该方便用户的理解，以便用户对需求加以确认，另一方面，必须较为容易地转化为设计阶段的结果。可见，需求分析与软件过程中的软件设计有着极为密切的关系。
但需求分析和设计的区别还是应该注意的。需求分析虽然与设计过程紧密衔接，甚至很多时候难以严格分界需求分析过程和设计过程，但是需求分析本质上是需要准确的回答系统做什么（What to do），而设计是回答系统怎么做（How to do）。
需求分析的常见方法有两种：一种是结构化分析（Structured Analysis），一种是面向对象的分析（Object Oriented Analysis）。结构化分析主要是以分析软件系统的数据流为主要思路，使用一套分层的数据流图及对数据流图上的各要素加以详细注解的数据字典为主要描述方式的一种方法。面向对象的分析方法主要是以面向对象的思维方式来展开对需求的分析，以面向对象的描述语言来表达需求。这里，在常用的面向对象的需求表达方式中，本书选用UML。此外，除了上述两种常见的方法外，在需求分析过程中，从软件工程方法学的角度来说，还常常使用原型法（Prototype）来快速确定需求。
需求分析过程中，要求分析员对目标软件所针对的行业背景极为熟悉。试想一下，如果要求做一套财务软件，不懂基本的财会知识显然是不行的。在这一背景下，对特定行业下的需求进行分析成了一门新学科的内容，即领域工程（Domain Engineering）。此外，随着软件可复用技术的发展，需求分析领域的可复用也受到了人们极大的关注，这就是框架（Framework）兴起的原因。
3.2软件需求分析的过程
3.2.1需求的识别
软件需求过程的第一个环节就是需求的识别，如需求诱导（Requirements Elicitation）。这一过程实质上包含了同用户充分交流，进行需求的采集，以最终确定用户所要实现的系统综合需求，即软件的需求。并提出这些需求的实现条件，以及需求应该达到的标准。也就是说，要在这一过程确定软件最终要实现什么样的功能，各种功能实现什么样的程度。
识别出的需求可以分为两大类：一类是功能性需求（Functional Requirements），一类是非功能性需求（Non—Functional Requirements）。功能性需求是指目标软件所要实现的功能，如实现数据货品入库登记、年终结账功能，就属于这类需求，这类需求一般来说比较容易确定，因为它很大程度上是用户所从事领域中比较关心的问题，所以用户能够明确的提出。但另外一类需求——非功能性需求则往往被人们所忽视。
非功能性需求一般包括以下几点内容：
性能需求。如系统的响应时间，系统对资源的消耗和系统对大量并发处理能力等。
环境需求。这主要是对软件运行时所处环境的要求。如运行软件所需要的硬件设备，网络设备等，再如支持软件运行的操作系统，数据库管理系统等软件环境。
还包括对系统的可靠性要求，安全性要求，可扩展性要求等多方面的内容，在这里不一一展开了。
3.2.2需求的分析与综合
分析与综合是两种典型的思维方式。分析的过程是从抽象到具体，从宏观到微观的过程，具体体现在结构化方法中的自顶向下，逐层加细的分析思路。但是一味的分析只能使设计人员只见树木不见森林，所以还需要适当的综合，用宏观的尺度把握系统的特性。结构化方法中的顶层数据流图，面向对象分析方法中的用例都是这样的一种综合的表述方式。
需求的分析实质上首先应该是对目标系统对应的现实系统的分析，所以首先是针对系统的分析。系统的分析主要包括3方面内容：一是系统所处环境的分析；二是系统结构的分析，包括系统的组成实体，以及实体间的关系；三是系统功能与行为的分析。这些系统分析的方法应用于软件需求分析，可以归纳为以下3方面的主要内容。
1.数据分析
数据分析主要侧重于组成系统的实体及其关系的分析。其中包括回答这样一些问题，系统由哪些实体组成，每个实体用哪些属性描述，实体之间是什么样的关系。通常用实体关系图（Entity Relation Diagram）来描述数据分析的结果，实体关系图一般由实体及其联系以及实体的属性3部分组成。
2.功能分析
功能分析实质上是分析系统对于环境的输入能够施加怎样的影响，这样的影响就是系统实现的功能。软件系统实现的功能很大程度上可以理解为，系统将输入转变为输出的这一过程。所以系统的功能分析通常从信息流或者数据流的角度加以考察。如取款机，输入所要取的金额，它就提取相应的现金。系统所处环境中的某一实体向该系统输入信息流，系统执行某项功能，完成相应的转换，得到输出流，最终流向系统所处环境的中某一实体。
3.行为分析
最终的目标软件系统不可能是完全孤立的，它总要与环境（如人）做一些交互，这种交互往往是通过事件触发的。如报警系统，一旦触发警铃，报警系统就会做出响应，并处于报警状态，而平时系统保持在闲置状态。行为分析的主要内容就是系统对事件的响应及系统对自身状态的变化加以分析。最为常见的表示方式，就是UML中的状态转换图。
3.2.3需求的表示
当需求分析完成后，必须将需求分析的结果清晰地描述出来，以方便用户的确认和分析员自己的复查。所以需求的表示实质上是将需求分析的结果文档化的过程。在需求的表示过程中可以综合使用各种描述方式，如SA方法中的数据流程图、数据字典、OOA方法中的Use Case图、状态转换图等。具体图表的使用，视实际情况而定，目的只有一个，清晰地描述目标系统的功能，并在最终产生一份需求规格说明（Requirements Specification）书，这就是需求分析的阶段性结果。正因为需求表示阶段的结果是需求规格说明书，所以有些教材也将需求表示阶段表示为需求规约。关于需求的表示还将在本章后面的部分详细描述。
3.2.4需求的验证
为了提高软件的质量，在第1章介绍了“V&；V”策略，该策略在需求分析阶段集中体现为需求的验证。需求验证是必不可少的环节，通过需求的验证，可以尽可能地减少需求分析环节的错误。有数据表明，软件中15%的错误就是来自于错误的需求。此外，需求分析阶段的错误若在编码调试阶段才发现，那么此时的缺陷已被放大，其查找和纠正的难度加大。而通过需求验证则很容易发现需求中的错误。
需求的验证可以从以下几个主要方面进行。
一致性（Consistency）：所有的需求必须一致，任何一条需求不能和其他需求相矛盾。
完整性（Completeness）：需求必须是完整的，用户需求的各个方面，包括功能性需求和非功能性需求都必须得到描述。
可行性（Feasibility）：所有的功能性需求和非功能性需求是否可行，从经济可行性和技术可行性两方面衡量。
清晰性（Clarity）：所有的需求是否被正确地表达，对于关键词语是否做了详细的解释。
需求的验证可以有多种方式，最基本的是分析员自己复查需求，也可以开需求验证会，邀请该领域的专家对需求报告加以评审，当然也还包括直接交付给用户，让用户最终确认需求报告的正确。
3.3结构化分析方法（SA）
3.3.1概述
软件是利用计算机技术解决现实生活中问题的一种有效方法和手段，如同其他方法和手段一样，首先必须搞清楚要解决的问题是什么，然后才能去解决它。过去总是有人忽略需求分析的重要性，在没有全面、准确和认真地完成需求分析工作之前，就急急忙忙地进行设计甚至实现工作，结果往往是事倍功半，造成不必要的多次反复，甚至给软件留下严重的后遗症。
软件需求分析阶段的工作和任务是在对问题进行调查了解的基础上，用一定的方法和手段对问题进行分析建模。需求分析的结果应该反映的是必须干什么，而不是怎么干。它的主要用途是明确需求、为用户和开发人员提供一起协商讨论的基础，作为设计和实现的依据。
3.3.2工作内容和任务
结构化软件开发方法采用结构化分析（Structured Analysis，SA）技术对问题进行分析、建模。它将问题表述为：数据流图+实体联系图的形式。其中，数据流图描述问题空间中数据变换处理之间的逻辑关系，实体联系图描述问题空间中数据存储之间的逻辑关系，同时，借用数据词典、结构化语言、判定表、判定树等工具对它们进行详细说明。因此，结构化分析工作主要包括分析确定数据流图和分析确定实体联系图。
首先，根据对问题的功能需求方面的调查了解分析建立数据流图。然后，根据对问题的数据需求方面的了解以及数据流图分析建立实体联系图。最后，根据数据流图、实体联系图以及对问题的性能、资源、可靠性、安全和保密、开发费用、开发进度等其他方面的需求确定，按照有关规范编写需求规格说明书和数据需求说明书并进行复审，完成对问题的结构化分析建模。
3.3.3如何画基本数据流图
数据流图（Data Flow Diagram，DFD）是一种最常用的结构化分析工具，它从数据传递和加工的角度，以图形的方式刻画系统内的数据运动情况。
数据流表示数据的流动情况；加工表示对数据的加工处理过程，它的名字应能简明扼要地表明所完成的是什么加工；数据存储在数据流图中起着保存数据的作用，指向数据存储的数据流可以理解为写数据，从数据存储引出的数据流可以理解为读数据，双向数据流可以理解为修改数据；数据的源点或终点，表示图中出现数据的始发点或终止点，它在图中的出现仅仅是一种符号，并不需要以软件的形式进行设计和实现。在数据流图中，如果有两个以上数据流指向一个加工或从一个加工中引出，则这些数据流之间往往存在一定的关系。通常用一些符号表示这种关系。
在画数据流图时，以下几个问题值得注意。
1.是画数据流图而不是画程序框图
对于很多人来说，通过学习计算机语言已经比较熟悉程序框图了，在画数据流图时很容易将它们搞混。程序框图是从对数据进行加工的角度描述系统的，其箭头是控制流，表示的是对数据进行加工的次序，它用于描述“怎样解决问题”；数据流图则是从数据的角度来描述系统的，其箭头是数据流，表示的是数据的流动方向，它用于描述是“什么问题”。
2.数据流及加工的命名
通常是先为数据流命名，然后再为加工命名。在给数据流命名时，应避免使用像“数据”、“输入”之类的缺乏具体含义的名字；在给加工命名时，理想的做法是由一个具体的及物动词加一个具体的宾语构成一个名字，如果必须用两个动词，则可以考虑将这个加工再分解成两个加工。在命名时，所取的名字应适合整个数据流或加工，而不是仅仅反映它的某些成分。如果发现某个数据流或加工难以命名，那么很可能是数据流图分解不当造成的，此时应该考虑重新分解数据流图。
3.分层数据流图
对于比较复杂的实际问题，在数据流图上常常出现十几个乃至几十个、上百个加工，这样的数据流图看起来很不清楚。采用层次结构的数据流图则能很好地解决这个问题。
它的输入输出反映了系统与外界环境的关系或接口，仅用图是不能表明数据的加工要求的，需要进一步细化。在画分层数据流图时应考虑以下几个问题。
1）编号
为便于管理和阅读，要对每个层次上的图及其加工进行编号。层次编号自上而下分别为顶层图（系统图）、0层图、1层图，等。各层图的关系为父子关系，下层图为子图，上层图为父图。子图的编号就是其父图中相应加工的编号；子图中加工的编号由子图号、小数点和局部号组成。在这种编号中，图号中的小数点的个数就是该图所在的层次号，最后一个小数点前的号码就是其父图的编号。父图和子图的数据平衡子图是父图的细化，因此，子图的输入、输出数据流应和父图中相应加工的输入、输出数据流一致。
2）分解的程度
对一个加工进行细化分解，一次分解成两个或三个加工，可能需要的层次过多；但分解得过多又让人难以理解。根据心理学的研究成果，人们能有效地同时处理问题的个数不超过7个。因此，一个加工每次分解细化出的子加工个数一般不要超过7个。当所分解出的子加工已十分简单时，就可停止这种分解过程。
