高级软件工程(3)

高级软件工程（3）3.1需求分析的任务需求分析的基本任务是准确地回答“系统必须做什么？”这一核心问题。3.1.1需求分析的概念需求分析是一种软件工程活动，使得系统分析员能够刻划出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束。需求分析是软件设计师进行软件分解的基础，需求分析建造了软件处理的数据模型、功能模型和行为模型。需求规约为软件设计师和客户提供了软件建造完后，进行质量评估的依据。1.软件需求的概念和分类比较权威的需求的定义来自于IEEE软件工程标准词汇表中的定义：l用户解决问题或达到目标所需要的条件。l系统或系统部件要满足合同、标准、规范或其他正式规定的文档所要具有的条件。l反映上面两条的文档说明。需求一方面反映了系统的外部行为，另一方面反映了系统的内部特性，反映的方式是需求文档。比较通俗的需求定义如下：需求是指明系统必须实现什么的规格说明，它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。需求分析的难点问题的复杂性交流障碍不完备性和不一致性易变性需求的类别功能需求：指定系统必须提供的服务，通过需求分析应该划分出系统必须完成的所有功能；性能需求：指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求；可靠性和可用性需求：定量地指定系统的可靠性与可用性；出错处理需求：说明系统对环境错误应该怎样响应；接口需求：描述应用系统与其环境通信的格式，常见的接口需求有用户接口需求、硬件接口需求、软件接口需求和通信接口需求；约束：描述了应用系统应遵守的限制条件，常见的约束有：精度约束、工具和语言约束、设计约束、应该使用的标准、应该使用的硬件平台等；逆向需求：说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除发生误解的那些逆向需求；将来可能提出的要求：应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。另一种分类功能性需求产品的范围功能与数据需求非功能性需求观感需求易用性性能限制条件操作需求可维护性和可移植性需求安全性需求文化与政策法律需求3.1.2.需求分析的任务需求分析的任务是借助于当前系统的物理模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求。必须全面理解用户的各项要求，但只能接受合理的要求。要将软件的需求准确地表达出来，形成软件需求说明书。目标系统当前系统物理模型逻辑模型模型化抽象化物理模型逻辑模型具体化实例化理解需求表达需求导出怎么做做什么需求分析的任务获得当前系统的物理模型：首先，分析、理解当前系统是如何运行的，并用一个具体的模型来反映自己对当前系统的理解。抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，取出非本质因素，抽取出“做什么”的本质。建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标系统要“做什么”，从而从当前系统的逻辑模型中，导出目标系统的逻辑模型。对目标系统逻辑模型进行补充：具体内容如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等。3.1.2需求获取软件需求分析中需要很好的的相互沟通，沟通总是要在两方或多方间进行。客户和系统分析员之间最常用的交流方式，是通过预备会议或访谈进行的。获取用户需求的主要方法是调查研究。做好准备制定调研计划准备调研资料访谈用户写调研报告评审需求分析阶段的文档软件需求说明书初步的用户手册修改、完善与确定软件开发实施计划3.1.4需求规格说明软件需求规格说明是分析任务的最终产物，美国国家标准局、IEEE（标准号830－1984）以及美国防部门均已提出了软件需求规约（以及其他软件工程文档）的候选格式。软件需求规格说明必须正确地定义所有的软件需求；除了设计上的特殊限制之外，软件需求规格说明中一般不描述任何设计、验证或项目管理的细节。需求必须描述的基本问题功能——所设计的软件要做什么；性能——软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；强加给实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准；属性——可移植性、正确性、可维护性及安全性等方面的考虑因素；外部接口——与人、硬件、其他软件和其他硬件的相互关系。软件需求规格说明的大纲1前言1.1目的1.2范围1.3定义、缩写词、略语1.4参考资料2项目概述2.1产品描述2.2产品功能2.3用户特点2.4一般约束2.5假设和依据3具体需求3.1功能需求3.1.1功能需求13.1.1.1引言3.1.1.2输入3.1.1.3加工3.1.1.4输出3.1.2功能需求2……3.1.n功能需求n3.2外部接口需求3.2.1用户接口3.2.2硬件接口3.2.3软件接口3.2.4通信接口3.3性能需求3.4设计约束3.4.1其他标准的约束3.4.2硬件的限制…………3.5属性3.5.1安全性3.5.2可维护性…………3.6其他需求3.6.1数据库3.6.2操作3.6.3场合适应性…………附录索引3.2软件需求分析基础：以结构化分析方法为例结构化的分析方法是最经典的需求分析方法。适用于数据处理类型软件的需求分析。它提供的工具包括：数据流图、数据字典、结构化英语、判定表和判定树。系统的分析模型必须达到三个主要目标：（1）描述客户的需要；（2）建立创建软件设计的基础；（3）定义在软件完成后可以被确认的一组需求。实体—关系图状态—迁移图数据流图数据对象描述加工规格说明数据字典控制规格说明模型的核心是数据字典——一个包含了软件使用或生产的所有数据对象描述的中心库。实体-关系图描述数据对象间的关系，实体-关系图是用来进行数据建模活动的。数据流图有两个目的：指明数据在系统中移动时如何被变换；描述对数据流进行变换的功能（和子功能）。它可以用于信息域的分析，作为功能建模的基础。状态转换图指明系统将如何动作。为此，状态转换图表示了系统的各种行为模式（称为“状态”），以及在状态间进行变迁的方式，状态转换图是行为建模的基础。3.2.1数据流图任何软件系统（或计算机系统）从根本上来说，都是对数据进行加工或变换的工具。组成符号画图步骤下面以教材购销系统中的教材销售为例，说明如何画数据流图。从用户调查中了解到某高校向学生销售教材的手续是：先由系办公室的张秘书开购书证明，学生凭证明找教材科的王会计开购书发票，向李出纳员交付书款，然后到书库找赵保管员领书。现欲将上述手工操作改为计算机处理，试画出教材销售过程的数据流图。首先找出数据的源点和终点，即找出数据源与数据汇，由此确定系统的边界。由于是由学生开始购书，最后由学生领书，因此数据的源点和终点都是“学生”。第二步找出加工，需要从描述中抽象出系统要完成的工作。学生须凭购书证明得到购书发票，然后交付书款，得到领书凭证，最后领书。其间能由计算机完成的工作是审查学生的购书凭证并开出发票，按发票开出领书单，由此我们得到2个加工（审查并开发票，并领书单）。第三步要找出数据流。学生向系统提交购书单，学生从系统得到领书单，在加工之间要传输发票信息，这样我们得到3个数据流。同时还要注意在“审查并开发票”加工中排除了无效的书单，它也因作为一个数据流，因此最后得到4个数据流：购书单，发票，领书单，无效书单。我们还要补充数据存储。数据存储一般不能通过系统描述确定，而要在设计数据流图时按照需要添加。实际上在审查购书单和开出发票之前，至少要查阅两个文件：①各班学生用书表，该表用以核对学生是否需用这些教材；②教材存量表，了解有没有该生要买的教材。把这两个文件加进上图中，并给加工添上编号，就得到计算机售书系统的完整的数据流图。命名数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。给这些成分起名字时应该仔细推敲。下面讲述在命名时应注意的问题：为数据流（或数据存储）命名名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分。考生姓名分类后的姓名录取分类注意合适的命名，尽量用现实存在的表格、单据。不要使用空洞的、缺乏具体含义的名字（如“数据”、“信息”、“输入”之类）。不要把控制流作为数据流。汇款单格式错误合格的汇款单核准的汇款单格式检查计算汇费取下一个考生成绩录取分类为处理命名通常先为数据流命名，再为与之相关联的处理命名名字应该反映整个处理的功能，而不是它的一部分功能。名字最好有一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能跟恰当些。如果在为某个处理命名时遇到了困难，则很可能是分解不恰当造成的，应该考虑重新分解。数据的源点和终点并不需要在系统中实现，它们只是系统的外围环境（可能是人员、计算机外部设备或传感器等）。通常为数据的源点和终点命名是采用它们在问题中习惯使用的名字，如“学生”，“管理员”。分层数据流图对于大型的系统，按照其层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。对任何一层数据流图来说，我们称它的上层图为父图，在它下一层的图则称为子图。在多层数据流图中，顶层流图仅包含一个加工，它代表将被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。底层流图是指其加工不需再做分解的数据流图，它处在最底层。中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。数据流图实例建立数据流模型的基本步骤概括地说，就是自外向内、自顶向下、逐层细化、完善求精。例5.建立一个简化的商业自动化系统。其中：售货员负责录入销售的商品（商品名，编号，单价，数量），有时要根据特定情况对销售的商品进行修改或删除。收款员负责收取现金，并将多交的付款退还用户。销售经理需要随时查询整个部门的销售情况（时间，商品编号，销售金额），并在每日结束时，统计各类商品的销售金额。首先：建立系统环境，确定系统边界，画出顶层DFD。其中：1数据流为：销售的商品，日销售额等2数据源点为：营业员，经理，收款员3数据终点为：经理，收款员4加工名为：要建立的系统名字然后自顶向下，逐层分解。A、按人或部门的功能要求，将加工“打碎”，形成：录入、修改或删除商品信息录入、修改现金额,并计算余额查询商品销售情况计算日销售额123注：需给每一加工编号B、”分派”数据流，形成：录入、修改或删除商品信息2录入、修改现金额,并计算余额查询商品销售情况计算日销售额销售的商品现金额现金余额查询要求销售情况日销售额13其中：要根据特定的加工要求进行分派；保持与顶层数据流的一致；可以不引入数据源和数据终点。C、引入文件，使之形成一个有机整体—系统录入、修改或删除商品信息录入、修改现金额,并计算余额查询商品销售情况计算日销售额销售的商品现金额现金余额查询要求销售情况日销售额销售文件123注：到一个文件，既有输入流，又有输出流，则可简化为，并可不给出标识。至此，体现精化，形成0层数据流图。继续A、B、C：自顶向下，逐层分解。例如：加工3查询商品销售情况计算日销售额查询要求销售情况日销售额销售文件3可分解为：3.1判定要求查询要求3.2统计销售情况3.3计算日销售额销售文件查询要求2查询要求1销售情况日销售额注意事项画数据流图不是画流程图。数据流图只描述“做什么”，不描述“怎么做”和做的顺序，而流程图表述对数据进行加工的次序和细节。父图和子图的平衡。正常情况下，父图和子图的输入数据和输出数据应分别保持一致，称为父子平衡。局部文件。随着数据流图的分解，在下层数据流图中允许出现父