第3章 软件需求分析

西安交通大学刘海岩1第3章软件需求分析软件需求需求分析过程传统方法的分析建模举例西安交通大学刘海岩23.1软件需求1、需求的概念需求（requirements）：Jones定义为用户所需要的软件必须达到的目标和能力。Lethbridge定义为需求是关于系统将要完成什么工作的一段描述，他们必须经过所有相关人员的认可，其目的是彻底的解决用户的问题。•需求是一段描述…：意思是每个需求是相对短小简明的一段信息，表现为一个事实。它可以是一段话或用各种图表示。一组需求的集合成为需求文档。•…关于系统将要完成什么工作…：需求描述了系统应当完成的任务，不描述系统将如何实现。•…必须经过所有相关人员的认可…：意指需求必须经过评审，才能成为正式的需求。•…其目的是彻底的解决用户的问题。有助于解决用户的问题，该需求才有存在的价值。西安交通大学刘海岩32、需求的类型（1）功能性需求：描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务。（2）非功能性需求：必须遵循的标准，外部界面的细节，实现的约束条件，质量属性等等。非功能需求限定了选择解决问题方案的范围，如运行平台、实现技术、编程语言和工具等。例：将飞机订票系统中的以下方面做如下的划分，F代表“功能性”，NF代表“非功能性”，X代表“不应当是需求”。简要的说明功能性或非功能性需求的种类。对于不应当是需求的方面，说明其原因。西安交通大学刘海岩4•如何输入有关航班、乘客及订票信息。F：输入。•什么信息要出现在机票和报告中。F：输出。•如何计算乘机费用。F：计算。•什么信息必须存储在旅行社和其他人访问的数据库中。F：数据存储。•这个系统应该设计成可以处理旅行常客计划。NF：增强的容限。•这个系统在任何时候都必须是可用的。一周中只允许有2分钟宕机时间。NF：有效性。•必须使用排序算法根据离开时间对航班排序。X：这是一个设计问题。西安交通大学刘海岩53、需求的描述（1）结构化语言（2）图形化表示（3）数学描述（形式化描述）4、软件需求文档（需求规格化说明）是需求分析阶段的产品，是所有其他开发和管理活动的基础。对系统开发过程中其他活动的影响：•项目经理根据它制定或修改开发计划。•设计人员根据它进行系统设计。•测试人员根据它编写测试计划，设计测试用例。•产品发布人员根据它编写产品介绍和用户文档。•培训人员根据它编写培训教程。西安交通大学刘海岩6IEEE标准为需求文档提出了以下结构，组织机构内部可以基于此标准扩展：（1）引言a.需求文档的目的b.文档约定c.预期的读者和阅读建议d.产品范围e.参考文献（2）综合描述a.产品前景b.产品功能与优先级c.用户特征d.运行环境e.设计与实现上的限制f.假设和依赖性西安交通大学刘海岩7（3）需求描述a.功能需求b.数据需求：与功能有关的数据定义和数据关系c.性能需求：响应时间、容量要求、用户数等d.外部接口：用户界面、软硬件接口、通信接口e.设计约束：软件支持环境、报表、数据命名等f.软件质量属性（可维护性、可靠性、可移植性、可用性、安全性等等）g.其他需求这一节是文档中最实质性的部分，由于在机构组织的实践中存在极大的变数，对这一节定义的标准结构可以进行增删。（4）附录（词汇表、分析模型、待定问题列表）（5）索引西安交通大学刘海岩83.2需求分析过程需求分析是指开发人员通过对应用问题及其环境的调查分析，准确的理解用户的需求，将不规范的需求陈述转化为完整的需求定义，再将需求定义编写成需求规格化说明的过程。对于一些新的复杂的系统，如果没有专门进行可行性研究，需求分析过程前应集中回答以下几个问题：（1）系统是否符合组织机构的总题目标？（业务需求）。（2）系统是否可能在现在的技术条件、预算和时间限制内完成？（经济、技术上的可行性）（3）系统能否与已经存在的其他系统集成？当收集到信息并评估后，需要对系统是否要开发给出意见和建议，书写可行性报告。该过程可能提出对系统功能范围的修正、对预算和时间安排的调整意见或者是对系统高层需求的建议。西安交通大学刘海岩91、需求获取（1）个别访谈和召集会议（2）观察用户工作流程（3）利用原型（4）使用实例（用例）：用例把系统分成一组逻辑的、互相联系很少的部分，每一部分都描述了系统运行的某种方式。因此容易理解每个用例达到的功能。问题分析问题描述原型化文件管理与确认需求获取和分析需求定义和说明是否已经记录了用户需要的所有部分是否使用了正确的技术功能是否可行是否记录了用户期望的部分确定需求的过程西安交通大学刘海岩10例：列出图书馆系统中以下参与者的最小用例集：借阅者、借书员、图书管理员、会计系统。借阅者：•按题目查询书籍•按作者查询书籍•按主题查询书籍•预定已被其他人借出的书籍•查询借阅者的个人信息并列出借阅的书籍西安交通大学刘海岩11借书员：所有借阅者的用例，再加上•为借阅者查找某一书籍•登记已归还的书籍•续借一本书•登记缴纳的罚款•添加新的借阅者•更新借阅者的个人信息（地址、电话号码等）图书管理员：所有借阅者和借书员的用例，再加上•添加藏书•删除藏书•改变系统中对已有书籍的记录信息会计系统（独立运行）•获得借阅者支付的超期罚款西安交通大学刘海岩123、分析与综合用文字和图形描述不同视图以揭示更深的、易混淆的问题，确保与所有风险承担者达成共识。（1）分析需求的可行性：允许的成本、性能；与其他需求的冲突；外界因素的依赖和技术障碍等。（2）对于渐增式开发要确定需求的优先级别，以便确立产品版本。（3）建模：图形化的表示分析模型可以增强对软件需求的理解，也为软件设计奠定了基础。模型包括：西安交通大学刘海岩13数据流图（DFD－功能模型）实体关系图（ERD－信息模型）状态转换图（STD－行为模型）类图（信息模型）顺序图（行为模型）合作图（行为模型）等等。（4）使用原型法，减少项目风险。（5）建立数据字典。4、编写需求文档西安交通大学刘海岩145、需求验证需求验证的重要性：如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工。由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多。假设需求阶段引入1个错误的需求，设计时对这个需求需要5~10条设计实现，1条设计需要5~10条程序，1条程序需要3~5种测试组合测试。原始需求正确的规格说明错误的规格说明正确的设计错误的设计对错误需求的设计正确的编码错误的编码对错误设计的编码对错误需求的编码正确功能测试到的错误没有测试到的错误一个错误的需求，纠正成本100元×10纠正成本1000元×10×5西安交通大学刘海岩15对需求文档需执行以下类型的检查：（1）有效性检查检查不同用户使用不同功能的有效性。（2）一致性检查在文档中，需求不应该冲突。（3）完备性检查需求文档应该包括所有用户想要的功能和约束。（4）现实性检查检查保证能利用现有技术实现需求。西安交通大学刘海岩16验证技术：（1）需求评审：由分析员、设计员、测试员、用户参与的正式或非正式的会议评审。正式会议要有严格的评审程序，要有会议记录，开发组根据缺陷建议修改需求说明并重审。（2）利用原型检验系统是否符合用户的真正需要。（3）对每个需求编写概念性的测试用例。（4）编写用户手册。用浅显易懂的语言描述用户可见的功能。（5）自动的一致性分析。可用CASE工具检验需求模型的一致性。西安交通大学刘海岩173.3传统方法的分析建模分析建模是使用文本和图表形式的组合，以相对容易理解和能直接评审正确性、完整性和一致性的方式来描述数据、功能和行为的需求。在过去的数年中，人们提出了许多种分析建模的方法，其中两种在分析建模领域占有主导地位：第一种是结构化分析(StructuredAnalysis,SA)，70年代末由DeMarco等人提出，这是传统的建模方法。另一种方法是面向对象的分析，将在后面介绍。结构化分析方法不是被所有的使用者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发展了超过30年的一个混合物。西安交通大学刘海岩181、分析模型分析模型必须达到三个主要目标：（1）描述用户的需要，使用户和开发人员更好理解；（2）建立创建软件设计的基础；（3）定义在软件完成后可以被确认的一组需求。为了达到这些目标，在结构化分析中导出的分析模型如图所示：图3.1分析模型西安交通大学刘海岩19•数据字典：包含了软件生产或使用的所有数据对象描述的中心存储库。•实体－关系图（ERD)：描述数据对象间的关系，每个对象的属性由“数据对象描述”来描述。•数据流图（DFD)用于两个目的：①指明数据在系统中移动时如何被变换;②反映对数据流进行变换的功能（和子功能）;在DFD中出现的每个功能的描述包含在“加工规约”中。•状态转换图（STD）：指明作为外部事件的结果系统将如何动作，有哪些行为。软件控制方面的附加信息包含在“控制规约”中。西安交通大学刘海岩202、数据建模在数据密集型应用问题中，对复杂数据或数据间复杂关系的分析和建模是需求分析的重要任务之一，有助于数据库的设计。数据建模回答与任何数据处理应用相关的一组特定问题：系统处理哪些主要的数据对象（或实体）？每个数据对象的组成如何，哪些属性描述了这些对象？每个对象与其他对象有哪些关系？这些对象当前位于何处？对象和变换它们的处理之间有哪些关系？西安交通大学刘海岩21分析人员经常使用实体-联系(EntityRelationship,ER)图来描述数据对象及相互之间的关系。ER模型包含了3种相互关联的信息：•数据对象•数据对象的属性•数据对象相互连接的关系（1:1，1:N，M:N）。下图是一个教学管理的ER图：西安交通大学刘海岩22教师学生课程教学MNMN教师号姓名性别职称系别学号姓名性别系别班级时间成绩课程号课名学时学分其中：表示实体，表示属性，表示联系。为了降低图的复杂性，有时属性不画在ER图中，单独造表。西安交通大学刘海岩233、功能建模（1）数据流图(DataFlowDiagram,DFD)DFD用来描述数据在处理序列中的流动，由箭头给出流动的数据，泡泡表示对数据的变换（加工或处理），两条平行横线表示数据存储（数据库），矩形表示外部实体（数据源或数据池）。图3.2描述了一个反映“看病”功能的DFD。DFD可以自顶向下，逐层分解，第0层DFD将整个系统表示为一个具有输入和输出数据的泡泡，反映了系统的语境，以下各层分别是上一层泡泡的分解，分解到可理解为止。表示在第1层的每个加工是表示在语境模型中的整个系统的子功能。（见图3.3)。西安交通大学刘海岩24图3.2“看病”的数据流图西安交通大学刘海岩25图3.3数据流图的分解西安交通大学刘海岩26分解时注意保持每次精化的输入输出数据流一致，称为分层数据流图的平衡。图形并不能充分反映软件的需求，需要用数据字典和“加工规约”对分析模型进行补充。数据字典对DFD中的元素进行严格的定义与解释。加工规约说明DFD中的“泡泡”隐含的处理细节并指出加工的约束与限制。DFD符号简单，适用于数据处理系统的分析建模，关注的重点是数据流而不是控制流，不易于实时系统的分析。西安交通大学刘海岩27（2）IDEF0图美国国防部使用的图形化建模技术，一个基本活动图如图3.4所示。每个活动包括4类要素：输入、控制、机制和输出。控制是限制所描述活动的类型或活动所受约束，机制是活图3.4一个基本的IDEF0图（A-0图）动的外部支持（如工具、技术、数据库等）。该图如同DFD一样，通过逐层分解展示系统的功能与子功能，每一层分解的活动为3～6个。（图3.5为第1层的IDEF0图）西安交通大学刘海岩28图3.5“看病”的IDEF0图（A0图）症状医学知识帐目代码帐目文件病史文件诊断治疗记账结果诊断结果治疗方案帐目记录药品列表检查列表西安交通大学刘海岩294、行为建模SA的扩展版本才使用STD进行行为建模。STD通过描述状态以及导致系统改变状态的事件来表示系统的行为。STD一般用圆角矩形（以下例图中用矩形）表示状态，每个状态代表系统的一种行为模式，状态之间用箭头连接，表示当发生某个事件或满足某条