需求分析具体要求

第3章需求分析3.1需求分析的任务3.2与用户沟通获取需求的方法3.3分析建模与规格说明3.4实体-联系图（？）3.5数据规范化（？）3.6状态转换图+有穷状态机3.7其他图形工具3.8验证软件需求3.9小结需求分析的意义软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。需求分析是软件定义时期的最后一个阶段，它的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。即：----准确地回答“系统必须做什么?”。在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。业务需求项目范围文档用户需求文档功能需求质量属性其他非功能需求设计约束需求规约(specification)非功能需求系统需求需求组成的全景图软件需求的组成其中：•业务需求：反映组织机构和客户对系统、产品高层次的目标要求。•用户需求：从用户使用的角度给出需求的描述。如一个小型超市需要一个商品的查询系统。业务需求：进货人员需要查询商品库存以便保证及时进货；收款员需要查询商品的销售价格以便结账；经理需要查询商品的销售及盈利情况。用户需求:这三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。•系统需求：从系统的角度描述要提供的服务以及所受到的约束。•功能性需求：描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务。•非功能性需求：产品必须具备的属性或品质。•设计约束：设计与实现必须遵循的标准、约束条件。如运行平台、协议、选择的技术、编程语言和工具等。软件需求的描述•结构化语言、PDL•图形化表示•数学描述（形式化语言描述）1确定对系统的综合要求---功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、逆向需求、将来可能提出的要求。3.1需求分析的具体任务2分析系统的数据要求3导出系统的逻辑模型4修正系统开发计划软件需求获取需求分析是一个包括创建和维持系统需求文档所必需的一切活动的过程。它包含了如下活动：需求获取和分析、需求描述和文档编写、需求有效性验证、需求管理（管理需求工程的变更）。软件需求过程需求获取和分析需求描述需求有效性验证系统模型用户需求和系统需求需求规约需求管理需求获取是开发人员与客户或用户一起对应用领域进行调查研究，收集系统需求的过程。需求分析是将获取到的需求准确的理解、求精，并将其转化为完整的需求定义（包括建模），进而生成需求规约的过程。需求获取和分析有一定的难度，因为：1）项目相关人员通常并不真正知道希望计算机做什么，让他们清晰的表达出需要系统做什么是件困难的事，他们或许提出不切实际的要求。2）项目相关人员用自己的语言表达需求，这些语言包含很多工作中的专业术语和专业知识。系统分析员没有这些知识和经验，而他们又必须了解这些需求。3）不同的项目相关人员有不同的需求，可能以不同的方式表达，分析人员必须发现所有潜在的需求资源，而且能发现这些需求的相容或冲突之处。4）经济和业务环境决定了分析是动态的，需求在分析过程中会发生变更。个别需求的重要程度会改变，新的需求会从新的项目相关人员那里得到。需求获取技术•建立由客户（用户）、系统分析员、领域专家参加的联合小组。•需求获取的方法：个别访谈、召集会议、文档研究、问卷调查、观察用户工作流程、建立原型。•获取的需求的表达方式：（1）需求列表需求与系统的特殊视角或环境的关系（2）业务流程图（状态/活动图）（3）数据流图（4）实体-联系图3.2与用户沟通获取需求的方法3.2.1访谈3.2.2面向数据流自顶向下求精3.2.3简易的应用规格说明技术3.2.4快速建立软件原型面向数据流自顶向下求精提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求-进行初步的访谈-开发者和用户双方组织的代表出席会议-每个小组为每张列表中的项目制定小型规格说明-根据会议成果起草完整的软件需求规格说明书3.2.3简易的应用规格说明技术3.3分析建模与规格说明1).分析建模模型----就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，由一组图形符号和组织这些符号的规则组成。建模方法在过去的数年中，人们提出了许多种分析建模的方法，其中两种在分析建模领域占有主导地位：第一种是结构化分析(StructuredAnalysis，SA)，70年代末由DeMarco等人提出，这是传统的建模方法。该方法不是被所有的使用者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发展了超过30年的一个混合物。具体的建模方法/表达方式有：面向流的建模：数据流图（DFD/CFD）数据建模：实体关系图（ERD）基于行为的建模：Petri网、状态图3.3.2软件需求规格说明(SRS)SoftwareRequirementSpecification通常用自然语言+模型，完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。软件需求规格说明书，是需求分析阶段得出的最主要的文档。软件需求说明书的编写提示（GB856T—88）1引言1.1编写目的1.2背景1.3定义1.4参考资料2任务概述2.1目标2.2用户的特点2.3假定和约束软件需求说明书的编写提示（GB856T—88）3需求规定3.1对功能的规定3.2对性能的规定3.2.1精度3.2.2时间特性要求3.2.3灵活性3.3输人输出要求3.4数据管理能力要求3.5故障处理要求3.6其他专门要求4运行环境规定4.1设备4.2支持软件4.3接口4.4控制3.4实体-联系图(ER)EntityRelationshipDiagramER图----是用来建立数据模型的工具。数据模型----是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，反映了用户的现实环境，而且与在软件系统中的实现方法无关。数据模型中包含3种相互关联的信息：数据对象（实体）、数据对象的属性及数据对象彼此间相互连接的关系。(1).数据对象数据对象:是对软件必须理解的复合信息的抽象。复合信息:是指具有一系列不同性质或属性的事物，仅有单个值的事物(例如，宽度)不是数据对象。可以由一组属性来定义的实体都可以被认为是数据对象。如：外部实体、事物、行为、事件、角色、单位、地点或结构等。数据对象彼此间是有关联的。(2).属性属性定义了数据对象的性质。必须把一个或多个属性定义为“标识符”，也就是说，当我们希望找到数据对象的一个实例时，用标识符属性作为“关键字”(通常简称为“键”)。应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。如：学生具有学号、姓名、性别、年龄、专业（其它略）等属性；课程具有课程号、课程名、学分、学时数等属性；教师具有职工号、姓名、年龄、职称等属性。(3).联系数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下3种类型：a.一对一联系(1∶1)如：一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。b.一对多联系(1∶N)如：某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。c.多对多联系(M∶N)如：学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。联系也可能有属性。如：学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学”的属性。(4).实体-联系图的符号ER图中包含了实体(即数据对象)、关系和属性等3种基本成分。通常用矩形框代表实体；用连接相关实体的菱形框表示关系；用椭圆形或圆角矩形表示实体(或关系)的属性；并用直线把实体(或关系)与其属性连接起来。举例图3.2某校教学管理ER图对象教师属性学生属性课程属性联系属性关系3.5数据规范化规范化的目的是：消除数据冗余，即消除表格中数据的重复；消除多义性，使关系中的属性含义清楚、单一；使关系的“概念”单一化，让每个数据项只是一个简单的数或字符串，而不是一个组项或重复组；方便操作。使数据的插入、删除与修改操作可行并方便；使关系模式更灵活，易于实现接近自然语言的查询方式。如何规范化？规范化---将数据的逻辑结构归结为满足一定条件的二维表（关系）。即：1.表格中每个信息项必须是一个不可分割的数据项，不可是组项。2.表格中每一列(列表示属性)中所有信息项必须是同一类型，各列的名字(属性名)互异，列的次序任意。3.表格中各行(行表示元组)互不相同，行的次序任意。教工号姓名性别职称职务001张毅坤男教授院长002李林女讲师用教学管理例说明如何规范化有三个实体型，即课程、学生和教师，用三个关系保存它们的信息：学生(学号，姓名，性别，年龄，年级，专业，籍贯)教师(职工号，姓名，年龄，职称，职务，工资级别，工资)课程(课程号，课程名，学分，学时，课程类型)为表示实体型之间的联系，又建立两个关系：选课(学号，课程号，听课出勤率，作业完成率，分数)教课(职工号，课程号，授课效果)这五个关系，组成了数据库的模型。在每个关系中，属性名下加（下划线）指明关键字。并规定关键字能唯一地标识一个元组。1、范式级别越高，存储同样数据就需要分解成更多张表，因此，“存储自身”的过程也就越复杂。2、随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。3、范式级别提高则需要访问的表增多，因此性能(速度)将下降。从实用角度看来，在大多数场合选用第三范式都比较恰当。所以，从实用角度看来，在大多数场合选用第三范式都比较恰当。通常用“范式(NormalForms)”定义消除数据冗余的程度。第一范式(1NF)数据冗余程度最大，第五范式(5NF)数据冗余程度最小。但是：第一范式每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。如：学生(学号，姓名，性别，年龄，年级，专业，籍贯)教师(职工号，姓名，年龄，职称，职务，工资级别，工资)课程(课程号，课程名，学分，学时，课程类型)第二范式满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。如：选课(学号，课程号，听课出勤率，作业完成率，分数)教课(职工号，课程号，授课效果)第三范式符合第二范式的条件。满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。3.6状态转换图状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。1).状态状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。初态(即初始状态)状态终态(即最终状态)中间状态一张状态图中只能有一个初态，而终态则可以有0至多个。2).事件事件是在某个特定时刻发生的事情，它是对引起