搜索
第3章需求分析3.1需求分析的任务3.2与用户沟通获取需求的方法3.3分析建模与规格说明3.4实体-联系图3.5数据规范化3.6状态转换图3.7其他图形工具3.8验证软件需求3.9小结目标列举信息收集技术技巧设计项目的E-R图设计项目的状态转换图了解其他图形工具第三章需求分析(I)需求分析的基本任务是准确地回答“系统必须做什么?”这个问题。确定系统必须完成哪些工作，对目标系统提出完整、准确、清晰、具体的要求。在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书（SoftwareRequirementSpecification），以书面形式准确地描述软件需求。结构化分析方法都遵守下述准则：(1)必须理解并描述问题的信息域，根据这条准则应该建立数据模型。(2)必须定义软件应完成的功能，这条准则要求建立功能模型。(3)必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。(4)必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。第三章需求分析(II)3.1需求分析的任务3.1.1确定对系统的综合要求1.功能需求这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。2.性能需求性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。3.可靠性和可用性需求可靠性需求定量地指定系统的可靠性。可用性与可靠性密切相关，它量化了用户可以使用系统的程度。4.出错处理需求这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这类错误并不是由该应用系统本身造成的。在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键部分，而且应该尽可能少。5.接口需求接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。6.约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。在需求分析阶段提出这类需求，并不是要取代设计(或实现)过程，只是说明用户或环境强加给项目的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。7.逆向需求逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。8.将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。用户或人的因素用户类型？各种用户熟练程度？需受何种训练？用户理解、使用系统的难度？用户错误操作系统的可能性？任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息，在很大程度上决定了系统的面貌，对软件设计有深远影响。因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。分析系统的数据要求，通常采用建立数据模型的方法(见3.4节)。3.1.2分析系统的数据要求复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。利用数据字典可以全面准确地定义数据，但是数据字典的缺点是不够形象直观。为了提高可理解性，常常利用图形工具辅助描绘数据结构。常用的图形工具有层次方框图和Warnier图，在本章第3.7节中将简要地介绍这两种图形工具。软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化(见3.5节)。综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。3.1.3导出系统的逻辑模型最早在什么时候制定过开发计划?根据在分析过程中，获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。3.1.4修正系统开发计划主要问题复查现有报表、表格和过程描述观察并记录商业过程访谈分发收集调查表面向数据流分析简易规格说明书建立原型3.2与用户沟通获取需求的方法信息收集中的主要问题3.2.1主要问题主题对用户来说的问题商业过程和操作是什么你要干什么商业过程应该怎样完成如何完成它？需要哪些步骤？需求什么样的信息你要使用哪些信息？你要使用什么样的表单或报告？商业文档和过程描述是了解过程的一个好方法。表格和报表可以为面谈提供可视化的帮助、也可以提供工作文档。复查现有过程文档，将有助于识别面谈中不会提及的商业规则。有助于发现商业过程中的不一致和冗余。复查报表、表格和过程描述面谈之前确立面谈目的确定要包括的相关用户确定参加会议的项目小组成员建立要讨论的问题和要点列表复查有关文档和资料确立时间和地点通知所有参加者有关会议的目的、时间和地点面谈进行面谈衣着得体准时到达寻找异常和错误情况深入调查细节详细记录找出和记录未回答的条目和未解决的问题面谈之后复查笔记的准确性、完整性和可理解性把所收集的信息转化为适当的模型和文档确定需要进一步澄清的问题域适当的时间向参加会议的每一个人发一封感谢信3.2.1访谈访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。正式访谈时，系统分析员将提出一些事先准备好的具体问题。在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。调查表当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户，以便向他们询问在分析调查表时发现的新问题。情景分析在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。情景分析技术对用户将来使用目标系统，解决某个具体问题的方法和结果进行分析。用处主要体现在下述两个方面：(1)它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。(2)由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求，而这一信息的惟一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。软件系统本质上是信息处理系统，而任何信息处理系统的基本功能，都是把输入数据转变成需要的输出信息。数据决定了需要的处理和算法，看来数据显然是需求分析的出发点。在可行性研究阶段许多实际的数据元素被忽略了，当时分析员还不需要考虑这些细节，现在是定义这些数据元素的时候了。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。为了达到这个目标，通常从数据流图的输出端着手分析，这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。3.2.2面向数据流自顶向下求精图3.1面向数据流自顶向下求精过程前面方法定义需求时，用户处于被动地位而且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想。为了解决上述问题，人们研究出一种面向团队的需求收集法，称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。3.2.3简易的应用规格说明技术正如第1章已经讲过的，快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快速建立起来的、旨在演示目标系统主要功能的可运行的程序。构建原型的要点是，它应该实现用户看得见的功能(例如，屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如，修改文件)。尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。因此，原型的某些缺陷是可以忽略的，只要这些缺陷不严重地损害原型的功能，不会使用户对产品的行为产生误解，就不必管它们。3.2.4快速建立软件原型快速地构建和修改原型方法和工具：(1)第四代技术(2)可重用的软件构件(3)形式化规格说明和原型环境3.1需求分析的任务3.2与用户沟通获取需求的方法3.3分析建模与规格说明3.4实体-联系图3.5数据规范化3.6状态转换图3.7其他图形工具3.8验证软件需求3.9小结为了更好地理解复杂事物，人们常常采用建立事物模型的方法。所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。3.3分析建模与规格说明结构化分析实质上是一种创建模型的活动。系统分析员应该从不同角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中，逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。需求分析过程应该建立3种模型，它们分别是数据模型、功能模型、行为模型。ERD实体-联系图DFD数据流图STD状态转换图描绘了系统的各种行为模式(称为“状态”)和在不同状态间转换的方式通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。自然语言的规格说明具有容易书写、容易理解的优点，为大多数人所欢迎和采用。3.3.2软件需求规格说明数据模型为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型(也称为信息模型)。概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与在软件系统中的实现方法无关。数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。3.4实体-联系图实体：指客观世界存在的且可以相互区分的事务。实体可以是人，也可以是物，还可以是抽象概念。如职工、计算机、产品等都是实体。属性：是指实体某一方面的特征。一个实体通常由多个属性值组成，如学生实体具有学号、姓名、专业、年级等属性。联系：指实体之间的相互关系。注意，联系也可以有属性。ERD的概念联系可分为以下3种类型：(1)一对一联系(1∶1)例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。(2)一对多联系(1∶N)例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。(3)多对多联系(M∶N)例如，学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。ERD的概念ERD的基本符号符号含义表示实体表示实体间的联系，与实体的连线上需用数字标明具体的对应关系表示实体或联系的属性用于实体、属性及联系的连接某校教学管理ER图ERD实例软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。3.5数据规范化状态转换图(简称为状态图)，通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明