搜索
第3章结构化分析本章要点可行性研究获取需求的方法结构化分析过程快速原型分析方法成本/效益分析可行性研究开发软件需要解决的问题：Whytodo?—可行性研究Whattodo?—需求分析Howtodo?—系统设计可行性研究是以预测为提前，以投资效果为目的，从技术上、经济上、管理上进行全面分析研究的方法。问题定义问题定义是软件工程过程中最简短的阶段，是一个项目的开始。问题定义阶段必须回答的关键问题是“要解决的问题是什么”。规范的问题定义：思想上重视客观全面地定义严格评审深入分析可行性研究的内容回答是否可行最短时间最小代价四个方面的可行性技术可行性（预期功能、质量、效率）经济可行性（性价比-成本效益短长期效益）社会可行性（市场与政策）人的可行性可行性研究过程接受委托书组建研究小组事前调查编制研究计划签订合同或协议正式调查分析研究优化和选择方案可行性研究报告主要内容引言可行性研究前提对现有系统的分析对所建议系统的技术可行性分析对所建议系统的经济可行性分析社会因素可行性分析其他可供选择的方案结论意见7循环可行性研究的步骤1.复查系统规模和目标2.研究现有系统功能3.导出新系统模型4.重新定义问题5.导出和分析各种可选解决方案6.推荐行动方针7.草拟开发计划8.书写文档提交审查81复查系统规模和目标问题定义阶段的成果系统规模和目标报告书复查任务改正含糊的、二义的描述改正不正确的描述核查系统限制和约束92研究现有系统功能分析现有系统高层系统流程图确定系统功能比较新旧系统新系统必须完成旧系统的基本功能新系统必须改正旧系统存在问题新系统必须比旧系统增收入、减支出103导出新系统模型旧系统逻辑模型新系统目标和规模逻辑模型描述工具数据流图数据字典用例图新系统逻辑模型114重新定义问题复查问题定义、规模和目标根据新系统模型分析员误解用户遗漏重新定义问题循环（定义，分析，求解，重定义）125导出和分析可选解决方案从逻辑模型导出物理系统方案不同角度多个方案分析各种可选方案技术可行性操作可行性经济可行性为可行方案制定初步进度计划136推荐行动方针得出可行性研究结果继续开发终止项目推荐解决方案成本/效益147草拟开发计划为推荐方案确定开发计划进度开发人员硬件设备软件工具各阶段成本估计158书写文档提交审查可行性研究报告各步骤结果推荐方案开发计划等需求分析需求的基本概念宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。需求获取是十分困难的用户不清楚自己的希望用户与开发人员领域不同不同用户需求可能有矛盾需求经常性的变更需求分析的任务深入描述软件的功能和性能确定软件设计的约束和软件同其它系统元素的接口细节定义软件的其它有效性需求需求分析研究的对象是软件项目的用户要求准确地表达被接受的用户要求确定被开发软件系统的系统元素将功能和信息结构分配到这些系统元素中需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。19需求分析的步骤(1)调查研究从系统的角度来理解软件并评审软件范围是否恰当确定对目标系统的综合要求，即软件的需求提出这些需求实现条件，以及需求应达到的标准20软件的需求包括：功能需求性能需求环境需求可靠性需求安全保密要求用户界面需求资源使用需求成本消耗需求开发进度需求预先估计以后系统可能达到的目标21调查研究的另一项工作是建立分析所需要的通信途径，以保证能顺利地对问题进行分析。22(2)分析与综合从数据流和数据结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求，是否合理。剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。23常用的分析方法面向数据流的结构化分析方法(SA)面向数据结构的Jackson方法(JSD)面向数据结构的结构化数据系统开发方法(DSSD)面向对象的分析方法(OOA)等24(3)书写文档系统规格说明书数据要求说明书用户系统描述修正的开发计划25需求分析流程261.准备调查首先，需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。–问题表可以有多份，随着调查的深入，问题表将不断地被细化。–根据经验，用户通常没有耐心回答复杂的论述题，所以问题表应当以“选择题”和“是非题”为主。–制定问题表最简便的方法就是从《用户需求说明书》的模板中提取需求问题。其次，需求分析员应当确定需求调查的方式，例如：–与用户交谈，向用户提问题。向用户群体发调查问卷。–参观用户的工作流程，观察用户的操作。–与同行、专家交谈，听取他们的意见。–分析已经存在的同类软件产品，提取需求。–从行业标准、规则中提取需求。–从Internet上搜查相关资料。最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型的用户。如何开展需求调查272.执行调查准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息。需求分析员与用户面谈时应当注意以下事项：如果与用户约好了时间，切勿迟到或早退。要注意礼节，尽可能获得用户的好感，并为下次打扰他们埋下伏笔。需求分析员应事先了解用户的身份、背景，以便随机应变。IT人士不可貌相，有些大企业的领导其外表很土气，象农民。如果你路上碰到他，以为是个勤杂工，说：“喂，老师傅，来帮我拎东西。”也许这笔生意就泡汤了。需求调查不象侦探推理那样从蛛丝马迹着手，应该先了解宏观问题，再了解细节问题。如果双方气氛融洽，可以采用灵活的访谈形式，轻易不要打断用户的谈话。当双方对某些问题的交流合乎逻辑地结束后，即可继续讨论问题表中的其它问题。尽可能避免为用户添麻烦，但也不能怕给用户添麻烦而降低需求调查的力度。避免片面地听取某些用户的需求而忽视其它用户的需求。283.《用户需求说明书》与《产品需求规格说明书》的主要区别与联系前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。两者之间可能并不存在一一映射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。4.撰写《用户需求说明书》29用户需求说明书的参考模板30什么是好的需求规格说明书1正确需求规格说明书应当正确地反映用户的真实意图，“正确”是《产品需求规格说明书》最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。2清楚清楚的需求让人易读易懂。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚：文档的结构、段落是否乱七八糟？上下文是否不连贯？文档的语句是否含糊其词、罗里罗嗦？看了半天是否还不明白需求究竟是什么？313无二义性“无二义性”是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。为了使需求无二义性，人们在写《产品需求规格说明书》时措词应当准确，切勿模棱两可。4一致“一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。5必要《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。32“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。“锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。n6完备“完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求。人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。不完备的《产品需求规格说明书》将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。337可实现《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。吹牛皮虽然不犯法，但是《产品需求规格说明书》可是白纸黑字啊。经过双方确认的《产品需求规格说明书》相当于商业合同，如果开发方不能够实现《产品需求规格说明书》中的内容，那就是违约，可能会被罚款的。对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致的处理意见，避免将来发生商业纠纷。348可验证《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试验？如果双方都认可“采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。9确定优先级为什么要确定需求的“优先级”？理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。在项目刚开始的时候，开发方和客户比较乐观，什么都要做，可是做着做着，人们常常会面临“进度延误、费用超支、人员不足”等问题，这时就乱套了。人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。35需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。n10阐述“做什么”而不是“怎么做”《产品需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。国内的很多软件公司里，开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。如果在调查、定义需求时想好了“怎么做”，当然应该写下来，否则岂不浪费！关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。36结构化分析方法面向数据流进行需求分析的方法结构化分析方法适合于数据处理类型软件的需求分析具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止37结构化分析方法使用工具：数据流图数据词典结构化语言IPO处理描述判定表与判定树38数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的传输变换过程。是结构化系统分析的主要工具。数据流图的特性：抽象性、概括性、层次性数据流图39加工(数据变换)是数据流图的核心，一个处理可以表示一个程序、一个模块或多个程序，