it项目需求分析与管理

1、精选优质文档倾情为你奉上精选优质文档倾情为你奉上专心专注专业专心专注专业精选优质文档倾情为你奉上专心专注专业信息系统集成项目管理人员继续教育管理理论与实践篇IT项目需求分析与管理1、需求分析的重要性需求的重要性开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难需求是产品的根源，需求工作的优劣对产品影响最大。项目成败因素分析成功因素权重失败因素权重用户的参与15.9%不完整的需求13.1%执行层的支持13.9%缺乏用户参与12.4%清晰的需求描述1

2、3.0%资源不足10.6%合适的规划9.6%不切实际的用户期望9.9%现实的客户期望8.2%缺乏执行层的支持9.3%较小的里程碑7.7%需求变更频繁8.7%有才能的员工7.2%规划不足8.1%主权5.3%提供了不再需要的7.5%清晰的愿景和目标2.9%缺乏IT管理6.2%努力地工作和稳定的员工2.4%技术能力缺乏4.3%其他13.9%其他9.9%信息系统的多维视图软件产品的需求视图1、需求分析的重要性2、需求的概念与层次3、需求开发与需求管理4、软件需求分析技术5、需求分析工具软件2、需求的概念与属性软件需求的定义I IEEE的软件工程标准术语表将需求定义为：1、用户所需的解决某个问题或达到某

3、个目标所要具备的条件或能力。2、系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。3、上述第一项或第二项中定义的条件和能力的文档表述I而RUP是这样定义需求的：需求描述了系统必须满足的情况和提供的能力，它就可以是直接来自客户需要，也可以来自合同、标准、规范或其他正规约束力的文档。需求的层次业务需求业务需求业务需求是组织或客户对于系统的高层次目标要求，定义了项目的远景和范围，即确定软件产品的发展方向、功能范围、目标客户和价值来源。业务需求的内容-业务：产品属于哪类业务范畴？应该完成什么功能？需要为什么服务？-客户：产品为谁服务？目标客户是谁？-特性：产品区别于其

4、他竞争产品的特性是什么？-价值：产品的价值体现在什么方面？-优先级：产品功能特性的优先级次序是什么？用户需求用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。用户需求的描述-原则：应该易于用户的理解。一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式进行描述。-问题：自然语言表达容易含糊和不准确。系统需求系统需求是更加详细地描述系统应该做什么，通常包括许多不同的分析模型，诸如对象模型、数据模型、状态模型等。系统需求模型的描述-结构化语言-可视化模型-形式化方法系统需求主要是面向开发人员进行描述，是开发人员进行软件设计的基础。软

5、件需求的类型功能需求描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。举例：图书馆功能需求-用户可从图书资料库中查询或选择其中的一个子集。-系统可提供适当的浏览器供用户阅读电子文献。-用户每次借阅图书应该对应一个唯一的标识号，它被记录到用户的帐户上。非功能需求从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、开发过程的标准等。举例：图书馆非功能需求-系统应在20秒之内响应所有的请求。-系统每周7天、每天24小时都可以使用。可以使用系统的所有功能。需求属性需求属性是在每个需求所描述的功能之外，为

6、每个需求建立一个上下文和背景资料，目的是方便对需求的管理和跟踪常用的需求属性包括：需求创建时间版本号作者需求来源确认需求的客户代表需求涉及的子系统需求对应的产品版本号需求状态需求优先级测试标准需求的稳定性(非功能）需求的质量属性开发期质量属性：开发人员和维栌人员兵主的所有质量属性。送行期质量属性：最终用户可以直接感爰到的一类属性。1运行期质里属性I开发期质里属性 性能（Performance )易理解性（UnderstandabUity )安全性(Security)可扩展性（Extensibility )易用性（Usability)可重用性（Reusability )持续可用性（Availab

7、ility )可测试性（Testability )可伸缩性（Scalability )可维护性（MaintainabUity )互操作性（InteroperabUity )可移植性（Portability )可靠性(Reliability)鲁棒性(Robustness )运行期质量属性性能（TerformanceJ。性能是指软件系统及对提供相应服务能力。具体而古，性能也括速度，吞吐量和持续高速性三方面的要求：吞吐量通过单位对问题处理的夂易故柬夂量；达灰往往邋过平均响应对问來灰量；而持续高达牲是指保持高速此理达夂的能力。故率 fEffidencyj 和性能（PerformanceJ 的关系：他们

8、反映了统一问題的“表” “里”两面，性能为“表”故率为“里”。故半是指软件糸浼对CPU此理能力和存贮能力达两大类计算资源的使用故率。安全性 fSecurityJ。指软件糸洗同对兼颜合法用户提供服务，以及阻止非援权使用的能力。高妾全性意味着“同对兼颜”，达是因为有些攻去的g的是使软件系统拒绝向合法用户提供服务而不是非法访问。易用性 fUsabilityJ。不少文故也称为可用性fAvailabilityJ，但为了避免和持续可用性混淆，达里采用洗行的“易用性”的叫法，指软件系统易于使用的程皮。持续可用性 rAvailabilityJ。不少文故也称为可用性，为避免混淆，采用“持繞可用性”指长对问无故障

9、送行的能力。可伸缩性 rScalabilityJ 。指当用户敖和敖据量增加对，故件糸洗持续高服务质量的能力。互操作性 flnteroperabilityj。指本故件糸洗与其它糸洗支换敖据和互相调用服务的难易程可靠性 rReliabilityJ。故件糸洗在一定的对间内无故障廷行的能汐。鲁棒性 fRobustnessJ。也称为健壮性、東错性。指故件糸洗在以下情况下仍能够正常廷行的能力：用户进行了非法操作；相迷的故硬件系统发生了故障，以及其地非正常情况。开发期质量属性易理鮮性fUnderstandabilityJ。尤指设计故开发人员理鮮的难易程皮。可护展性fExtensibilityJ。为逄应_禽求

10、或需求的支化为软件增加功能的能力。成们在卖际工作中，经常将可护展性称为灵洁性。可重用性（ReusabilityJ。重用软件系统式其一部分的能力的难易程皮。开发期质量属性可洌武牲fTestabilityj。对软件冽武以证明其满足需求规约的难易程皮。在类际工作中立要指政行单元測甙、插核測甙等的难易程皮。可维护牲rMaintainability；。为了达到下列三种目的之一，而文隹修故点并卖洗修政的难易程皮：修故Bug、增加功能、提高！量属牲。可移植牲rPortabilityj。将软件系统从一个泛行坏境转移到另一个不同的泛行环埝的难易程皮。需求开发与需求管理需求开发目标 需求开发阶段与任务循环工作任务

11、对应的RUP阶段初始循环明确项目的目标与范围，完成子系统划分，明确每个子系统的内容（业务事件与报表）和相互之间的接口初始阶段脉络循环通过对每个业务事件进行流程分析、业务实体分析、并标示出所有用例细化阶段的第一次迭代细节循环对每个用例的细节进行分析，包括事件流、用户界面原型等细化阶段的第二次迭代构建阶段表：需求开发的三次循环需求基线需求分析的任务需求分析的基本任务是软件人员和用户一起完全弄清用户对系统的确切要求。这是关系到软件开发成败的关键步骤，也是整个系统开发的基础。需求分析活动提供功能需求、质量属性需求以及约束性需求等不同需求的明确定义。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统

12、的逻辑模型，解决目标系统的“做什么”的问题。需求分析模型通常软件开发项目是要实现目标系统的物理模型，该物理模型是由它的逻辑模型的实例化，即具体到某个业务领域而得到的。需求管理工作要点统- 明确的需求项划分标准引入基线管理引入变更管理引入需求跟踪需求分析人员的来源开发人员选择的解决方案更合理缺乏领域知识，沟通能力不强用户更善于理清业务脉络软件知识欠缺，难以表述需求领域专家对业务领域十分精通易于按自己的偏好来构建系统各种能力培养的要点技能类型培养要点说明业务能力类比例如，在很多非销售型企业中也能找到“产、售、供”的线索宏观思考过于陷入细节就会影响宏观理解溯源分析技术的发展历史，可以更好地了解其作用

13、技术能力优/缺点了解优缺点就能够在正确的地方应用它沟通能力思维模式通过改变思维模式、不断训练是可以提高的软件需求最佳实践SERU模型SERU模型S:Subject Area,表示子问题域，其核心思想是要通过业务来分解系统，尽量保证业务独立和低耦合。E:Event,表示业务事件，通过业务事件能够找到流程，通过流程能够找到不同场景和用例。R:Report,表示报表，统一处理查询，分析和统计类需求。U:Use Case,表示用例，需求组织的最小单位，到了需求分析阶段的重要活动和产出。 SERU过程框架模型将需求过程分解为了三个阶段:第一个阶段是需求定义，重点是主题域划分和业务事件识别。第二个阶段是需

14、求分析，理清需求框架和脉络，重点是通过业务流程图转到具体的领域类图和用例图到了第三个阶段是需求细化，重点就是填充需求细节，包括用例的详细编写，界面和交互设计等。4、软件需求分析技术根据用户需求，通过反复讨论、分析，最终明确一个唯一性的用户需求，这个结果其实就是我们的软件需求分析报告。一般我们采用Word、PowerPoint、Visio、FrontPage、Excel 等 Off ice 工具，同时可能采用一些开发工具，如VC或BC等，同样也会使用一些图形工具，如Photoshop、调色板等画图工具。使用各种工具表达软件需求分析，其具体表达手段可以分为：效果图描述。主要是用户UI界面的描述反映

15、用户需求功能；逻辑图描述。根据用户需求功能，使用抽象化理论，以及需求分析理论，对用户需求功能进行全面的分析，建立功能性逻辑关系图，流程逻辑关系图等；关系图表描述。主要是对信息关系、数据库表格、接口函数等描述；工程数学描述。分析用户需求，分析用户需求信息，运用工程数学进行算法推导，进行合理化需求分析推导；甘特图描述。主要是软件项目工作安排，开发周期预估；其它方法描述。保证完整性合理性的有效描述。软件需求分析评估软件需求分析评估是为了检查我们进行软件需求分析工作，保证软件需求分析工作正确性、完整性、有效性、合理性、可确认性、可实施性，完全保证用户所需求的功能。组织结构与责任管理满足用户需求的功能保

16、证可实施性需求分析评价指标工作周期需求不确定更改与可确认保证两类分析建模技术传统建模技术：结构化分析建模SA (Structured Analysis)，又分面向数据律樟和而向教据流建模主要应用技术：数据流图（DFD)；数据字典（DD)；加工说明（PESPEC)；实体关系图（E-R)；状态变迁图（STD)等ea现代建模技术：t面型对象分析建模OOA (Object-Oriented Analysis)主要应用视图：用例图（Use Case)；时序图（Sequence);状态图（State chart)；类图（Class)；构件图（Component)；部署图（Deployment)等结构化分析

17、方法结构化分析建模又分面向数据建模和面向数据流建模结构化分析方法面向数据流进行需求分析的方法，结构化分析方法适合于数据处理类型软件的需求分析。SA法建模就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解,直到找到满足功能要求的所有可实现的软件模型为止。5、需求分析工具软件采用适当的工具，有可能显著减少需求阶段的错误，也可大幅度提高需求分析的质量和工作效率。当然工具的选用应当与实际的项目相结合，充分地发挥工具的作用。IBM Rational RoseRational Rose是一个完全的，具有能满足所有建模环境（Web开发，数据建模，Visual Studio和C+ )需求

18、能力和灵活性的一套解决方案。Rose允许将需求和系统的体系架构转换成代码，对需求和系统的体系架构进行可视化，理解和精练。Rose是美国的Rational公司的面向对象建模工具（被IBM收购），利用这个工具，可以建立用UML描述的软件系统的模型，而且可以自动生成和维护C+、Java、VB和Oracle等语言和系统的代码。Rational Rose包括了统一建模语言（UML)，00SE,以及 0 M T。其中统一建模语言（UML)由Rational公司3位世界级面向对象技术专家Grady Booch、Ivar Jacobson、和Jim Rumbaugh通过对早期面向对象研究和设计方法的进一步扩展

19、而得来的，它为可视化建模软件奠定了坚实的理论基础。第二讲：需求开发与管理过程%需求开发过程:、需求管理过程软件需求工程一、需求开发过程开发需求一般要经历如下过程：调研收集需求，细化整理并转化为客户需求分析分析产品需求，定义进行需求定义评审同行或专家评审确认需求规格说明书RUP需求开发过程初始：学会进行项目目标分解、进行项目目标可研分析，构造提交项目目标模型，形成项目大纲细化：学会进行用例图建模，进行客户需求分析，构造提供软件功能模型，形成客户需求文档构造：学会对用例进行“三位” 一体的描述方式，分析软件用例的动态行为，构造提交用例的业务流程图、实体类图、原型图，形成产品需求说明书。交付：学会从

20、需求类型与属性角度评估需求的质量，移交产品需求说明书1调研收集需求，并转化为客户需求制定需求调研计划确定交流角色和方式准备规范文件和问卷组织考察、交流和讨论活动形成需求调研记录需求人员能力要求以好沟通的能力熟悉你公司的软件产品满足需求的能力懂得管理知识和技术知识融会贯通软件需求方法充满技巧的管理矛盾的协调者企业需求的传递者和控制者制定调研计划书*ERP系统需求调研计划第一章调研目的第二章调研的范围调研的职能范围（职能部门、人数、姓名、人员资格条件）调研的业务范围（基本情况、销售、采购、仓库管理、BOM、计划、生产、质量、财务、成本、基础数据、特殊要求等）调研的地点范围第三章调研的方式（收集资料

21、、问卷调查、个别交流、开会讨论）第四章调研的阶段（任务、起止时间、实施者、客户负责人员、工作成果)第五章具体时间安排需求开发角色准备规范文件规程准备规范文件需求开发方针需求开发过程模板需求规格说明书用户需求说明书用户需求调研记录检查表需求开发QA检查单需求调研需求获取是通过积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合问题解决领域的用户需呆。现场考察。到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。I获取需求的策略：建立顺畅的沟通机制调研、访谈与调查观察用户操作流程联合

22、需求分析会议需求提取方法一般有问卷法、面谈法、数据采集法、用例法、情景实例法以及基于目标的方法等，还有知识工程方法，如场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。访谈提纲和调查问卷有助于提高交流的有效性。在具体的实践屮，通常采用折衷的方法，即适当地计划好面谈提纲，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：所提的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；提问和回答在汇总后应能够反映用户需求的全貌。联合需求分析会说的玛的通过联合需求分析会说的讨袼，让血务专

23、象、信息技术专象和领城专象在一起尤分地文洗与沟通，鮮决卖际需求最大阪皮地连免了由于用户参与不足或用户与开发团P人无法沟通而凌成的需求失敗协甫付伦需求冲臾，我出使更多人满意的析泉方素在会说结東店訧得到了：用例列表执行者列表业务规则列表 扣步走立用例旗型RUP初始：目标建模第一步:业务目标建模建立业务目标到软件功能目标的转化模型每一个需求用-个需求用一个包来表示，称为需求包。包与包之间用组成关系关联起来。包图需求包可以逐层分解，构成分层用例需求结构。第二步业务限制因素分析建立业务限制因素到软件非功能目标的转化第三步.两种底层目标的束定建立软件功能目标与非功能目标之间的双向束定关系2分析细化客户需求

24、，形成顾客、用户及产品需求定义系统的边界建立系统与其外部实体间的界限，明确接口处的信息流。分析需求可彳亍t生和I充分t生，分析每一个需求实现的可行性和充分性，确定与实现相关的开发风险。确定需求伙:先级，需求优先级有助于建立和维护必要的需求，有利于开发组织和版本规划。建立需求分析模型，通过建立需求的多种视图，揭示出需求的不正确、不一致、遗漏和冗余等更深的问题，采取多种手段确认需求。定义系统的边界绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接U的简单模型。同时它也明确了通过接U的信息流和物质流。创建开发原型：创建用户接u原型，当开发人员或用户不能确定需求时，开发一个用户接u原型

25、，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所存的冲突之处。分析可行性分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。确定需求优先级确定软件工程需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版木将包括哪些特性或哪类需求。当允许需求变更时，在特定的版木屮加入每一项变更，并在那个版本计划屮作出需要的变更。为需求建立模型为需求建立模型需求的图形分析模型是软件需

26、求规格说明极好的补充说明。它们能提供不同的信息与关系以宥助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。(在后续章节详细讲述，此处省略)RUP细化：用例建模用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法敁早是由Iva Jackboson博士提山的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。从用产的角度釆看他们笄不想了解系统的闪部结构和设计，他们所哭心的是系：统所能提偌的服务,圯就慝衹开芡幽来的系：统将慝忉何衹丨更用的,这就用彳列方法的基不慝想

27、。用例是系统功能需求的反映。软件目标是用例建模的依据。软件目标是用例引入的主要来源。用例图描述用例建模的结果。 一个系统的全部用例图构成该软件包的需求模型。建立用例模型1用例的泠法來描遠系统的功能需求的遠程就是用例建棋，用例棋型立要包招以下两部分内東：用例图(Use Case Diagram)确定系统屮所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。用例规约(Use Case Specification)针对每一个用例都应该存一个用例规约文档与之相对应，该文档描述用例的细节内容。用例的厌用在p中铍推崇备至：鼙个足程鄄绞秫饱慝用例驱劢” (Vse-CaseDriv

28、en)$各神券型的讦亥话劲窆括项目管理、分柝埂计、测芪、宾现等鄠夏以系:统用闵窍歪耍褕入工T牛用例镆型黧定了鼙个系统5U牛开茨：的基础。用例图（Use Case Diagram)用来描述软件系统向交互活动卷与者提供的一组相关的功能。在一个用例图中，有一个或多个参与者与一个或多个用例相互关联。用例模型元素:参与者(JLctot)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。通讯笑联(Communicat

29、ion Association)通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。参与关联描述角色和用例之间有信息交流或系统为谁提供哪些功能与服务。使用关联指一个用例使用另一个用例的功能行为，用于在用例间共享公共的功能行为。（也是一种泛化（继承）关联、也称包含关联）扩展关联通过对已有用例增加一些额外的步骤来建立新的用例。用例规约提供了用例规约的模杈，每一个用例的用例规约都应该包含以下内容：简要说明(Brief Description)简要介绍该用例的作用和目的。事件流(Flow of Event)包括基

30、本流和备选流，事件流应该表示出所有的场景。用例场景(Use-Case Scenario)包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。特殊需求(Special Requirement)描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。前置条件(Pre-Condition)执行用例之前系统必须所处的状态。后置条件(Post-Condition)用例执行完毕后系统可能处于的一组状态。事件流：基本流基本洗描連的是该用例最正常的一种场景，在暮本洗中系统机行一糸列活动步腺東嘀应参与者提出的服务锖求。成们建说用以下格式来描連基

31、本洗：1)每一个步骤都需要用数字编呈以清楚地标明步骤的先后顺序。2)用一句简短的来概括每一步骤的主要内容，这样阅读者可以通过丨 (1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应。具体例子请参见附录。事件流：备选流备迷洗负责描遂用例执行过程中弄常的或偶糸发生的一些情况，备速洗和基本洗的组合应该能够棗盖该用例所有可能发生的场景。在描遂备迷洗对，应该包杨以下几个要素：1)起点：该备选流从事件流的哪一步开始；2)条件：在什么条件下会触发该备选流；3)动作：系统在该备选流下会采取哪些动作；4)恢复：该备选流结束之后，该用例应如何继续执行。备速洗的描14格式可以与基木洗的格式一玫，也需要编号

32、并以标題概連其A東，编号前可以加以孝母前敬A (Alternative)以示与基木洗步腺相区别。3.定义建立并维护操作概念和相关场景创建数据字典确保客户和开发人员使用一致的定义和术语。应用质量功能调配将产品特性、属性与对客户的重要性联系起来。编写需求规格说明书建立需求跟踪矩阵构造：用例的动态行为分析用例分析是软件行为分析的手段诸如：在线支付用例的三位一体描述业务流程图实体类图界面原型图多数情况下，使用顺序图来阐明用例实现，即说明对象如何通过交互来执行全部或部分用例的行为。可以用一个或多个顺序图来阐明实现用例的对象交互过程。在典型的组织结构屮，主事件流将有一个顺序图，而每个独立的用例分支流都分别

33、有一个丨序图。协作图协作图强调参加交互的对象的组织。顺序图和协作图都来自UML的元模型中相同的信息，所以两者在语义上是等价的。它们可以从一种形式的图转换为另一种形式的图，而不丢失任何伯息。交互图用于对系统的动态方面建模。这些动态方面可能涉及一个系统的体系结构的任意视图中的任何种类的实例的交互，包括类(含主动类）、接口、构件和节点的实例的交互。协作图中的基本原素L.对象：用于表示协作图中参与交互的类的实例多个对象：用于表不一组对象。协作图中的对象属性定义对象名称：在可视化表示屮所用的对象的名字。用冒号与类名分隔。类名：对象所属的类的名称。用冒号与对象名分隔。限制类型：可供选择的类型有：None

34、：对对象不做限制。new：说明对象在交互期间被创建。destroyed说明对象在交互期间被删除。transient说明对象是临时的。描述： 关于对象的文字描述。应用质量功能调配使用质量功能调配质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。kano模型将需求分为三类：普通需求;必须有的基本需求期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。创建数据字典数据字典是对系统用到的所存数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段

35、，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。用例说明用例说明（UseCase Explanation)是对功能用例图中的用例做出的说明。在用例说明中，需要描述用例的编号、名称、参与者和用例的功能以及交互过程。（说明文本格式目前尚未统一，下表仅供参考。)名称。名称无疑应该表明用户的意图或用例的用途，如“研究班招生”。标识符可选。唯一标识符，如UC1701，在项目的其他元素（如类模型）中可用它表引用这个用例。说明。概述用例的几句话。参与者可选。与此用例相关的参与者列表。尽管这则信息包含在用例本身中，但在没有用例图时，它有助于增加对该

36、用例的理解。状态、可选。指示、用例的状态，通常为以下几种之一：进行中、等待审查、通过華i或菜通过帝查。频手。参与者访A7此用例的频率。这是一个自由式问题，如用户每次录访问一次戒每月一次。前置条件。一个条件列表，如果其中包含条件，则这些条件必须在访问用例之if得到满足。后置条件。一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足。需求规约软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。需求规约遵循如下原则：.从现实中分离功能，即描述要“做什么”而不是“怎样实现”。(2).要求使

37、用面向处理的规约语言，讨论来自环境的各种剌激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。(3).如果被开发软件系统规模很小，那么整个系统也包括在规格说明的描述之中。.规约必须包括系统运行环境。.规约必须是一个认识模型，而不是设计或实现的模型。(6).规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，巳提出的解决方案是否都能满足规约。(7).规约必须允许不完备性并允许扩充。.规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造，以便能够很容易地加入和删去一些段落。软件

38、需求规约的一种典型格式1引言1.1需求规格说明的目的1.2软件产品的作用范围1.3定义、同义词与缩写1.4参考文献1.5需求规格说明概览2 一般性描述2.1产品与其环境之间的关联2.2产品功能23用户特征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功能或巧为需求23.1.n功能或行为需求n3.2外部界面需求3.2.1用户界面3.2.2硬件界面3.2.3故件界面3.3性能需求3.4设计约束3.4.1标准化约東3.4.2硬件约東3.5属性3.5

39、.1可用性3.5.2安全性3.5.3可维护性3.5.4可移植性3.6其它需求3.6.1数据库需求3.6.2用户操作需求3.6.3工作场地需求软件(产品）需求说明书1.引言/. /項目筒介12编写说明!. 3参考资料2.目标2. 1概述2.2此务标2. 2. ； ,# B标2. 2. 2此务标2.2. 3羅制性因案3.软件功能结构3./较件包结构图3.2致件包的说明4.软件功能规约自查法由需求分析人员对自己所确定的用例需求进行审核和验证，纠正需求中存在的问题。自查法又可以分为多种具体方法。第一种是小组审查法，即由一名分析人员向开发小组中其他人员介绍用例需求,小组中的成员进行提问，由介绍人进行解答

40、。2)专家审查法专家审查法是指聘请业务领域、用例、政策、法律等方面的专家对用例需求进行审查。3)用户审查法分析人员可以把用例需求说明书提交给用户，有条件时可以同时编写一份针对此需求的用户使用说明书并提交给用户，用户找出不满意或认为不能实现的需求，双方再对这些有争议的需求进行讨论，最后达成一致认识。4)原型法原型法是对存在的有争议或拿不准的需求，通过建立原型进行验证，以确定需求的正确性。需求移交的目的：(1)形成甲乙双方的工程实施技术合同(2)确定了施工团队的施工方案、依据(3)达成了多方公认的验收依据、标准需求管理11变更控制版本控制需求跟踪需求状态跟踪建议变更确定需求文定义对其它定义需求状分

41、析影响档的版本需求的链接态作出决策确定需求条定义对其它跟踪需求的交流目的版本系统元素的每一个状态合并确定需求体接链测量需求的系的版本需求文档跟稳定性踪变更控制需求变更的表现形式是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因：(1)、范围没有圈定就开始细化(2)、没存指定需求的基线(3)、没存良好的软件结构适应变化版本控制版本控制透过文档控制（documentation control)记录程序各个模组的改动，并为每次改动编上

42、序号。这种方法是工程图（engineering drawings)维护(maintenance)的标准做法，它伴随着工程图从图的诞生一直到图的定型。 一种简单的版木控制形式，例如，赋给图的初版二个版本等级“A”。当做了第一次改变后，版木等级改为“B”，以此类推等等。.需求体系的版本今天，越来越多的公司采用迭代或增量开发模式。为了降低风险，将开发过程分为多个增量部分可以加快整个开发过程。每个阶段结束后，是不是要将整个项目的文档做一个快照呢？通常是需要的，那此时的项目基线也就是我们这里说的需求体系的版木。需求体系的版木包含自需求而来的多个相关文档，此时的版本管理不仅应将这些文档打上统一的基线，并且

43、将该组文档之间的追踪关系也进行基线化的管理。需求变更决策七步法需求变更决策过程可分为七步：第一步:变更申请。第二步:技术评审。第三步:评价对工期的影响第四步:评价对成本的影响第五步:评价对质量的影响第六步:风险评价第七步:变更决策七步法印证了我经常鼓吹的项目管理三部曲:细化、量化、图形化，七步法主要验证了细化和量化的必要性和好处。第三讲结构化分析方法(DFD、 DD、 PESPEC)结构化开发方法是现有的软件开发方法中最成熟，应用最广泛的方法，主要特点是快速、自然和方便。结构化开发方法包含三部分：结构化分析方法(SA法）-结构化设计方法(SD法）结构化程序设计方法(SP法)SA法建模就是用抽象

44、模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解,直到找到满足功能要求的所有可实现的软件模型为止。结构化分析方法是传统软件工程中公认的技术成熟和使用广泛的需求分析方法。它主要借助于分层数据流图和数据字典等图形及半形式化的工具表达系统的需求。结构化分析方法是面向数据流进行需求分析的方法，适合于数据处理类型软件的需表分析。结构化分析方法结构化分析方法(Structured Analysis,简称SA法)是面向数据流的需求分析方法，是70年代末办Pbwrcfoc Cons taint ine及DeMarco筝乂提出和发展，并得到广泛的应用。它适合于分析A：型的数椐处理系统，特别是企事业

45、管理系统。主要应用技术和工具：数据流图（DFD)；数据字典（DD)；加工说明(PESPEC)；实体关系图(E-R)；状态变迁图（STD)等1、数据流图（DPD)2、数据字典3、加工说明參 结构化语言參 判定表參 判断树主要应用技术和工具:数据流图（DFD)；数据字典（DD)；加工说明(PESPEC)；实体关系图(E-R)；状态变迁图（STD)等SA法的基本思想结构化分析的基本思想：“分解”和u抽象”分解：把系统的复杂性降低到可以掌握的程度，把大问题分解成若干小问题，然后分别解决。抽象：即先考虑问题最本质的属性，暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容。自顶向下逐甚分解如图所示，

46、顶层抽象地描述了整个系统，底层具体地画出了系统的每一个细节，而中间层是从抽象到具体的逐层过渡。建立当前系统的“物理模型”系统的“物理模型”就是现实环境的忠实写照，即将当前系统用DFD图描述出来。这样的表达与当前系统完全对应，因此用户容易理解。抽象出当前系统的逻辑模型;分析系统的“物理模型”，抽象出其本质的因素，排除次要因素，获得用DFD图描述的当前系统的“逻辑模型建立目标系统的逻辑模型;分析目标系统与当前系统逻辑上的差别，从而进一步明确目标系统“做什么”，建立目称系统的“逻辑模型”为了对目标系统作完整的描述，还需要考虑人机界面和其它一些问题。数据流图DFD2、数据流图数据流图(Data Flo

47、w Diagram,简称DFD)是描述系统屮数据流程的图形工具，它标识了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换成逻辑输出所需的加工处理。DFD描述系统選辑模型信息在系统中的流动和处理DFD用途交流信息的工具结构化分析和设计的工具(1)数据流图（DFD)图形符号辅助的图形符号DFD基本绘图符号说明数据流 是数据在系统内传播的路径，由一组成固定的数据项组成。数据流可以从加工流向加工，也可以从加工流向文件或从文件流向加工，也可以从源点流向加工或从加工流向终点。除了与数据存储(文件)之间的数据流不用命名外，其余数据流都应该用名词或名词短语命名。加工 也称为数据处理，它对数据流进行某些操作或变

48、换。每个加工也要存名字，通常是动词短语，简明地描述完成什么加I:。在分层的数据流图屮，加工还应有编号。(3)数据存储指暂时保存的数据，它可以是数据库文件或任何形式的数据组织。流向数据存储的数据流可理解为写入文件，或查询文件，从数据存储流出的数据可理解为从文件读数据或得到查询结果。数据源点和终点是软件系统外部环境屮的实体(包括人员、组织或其他软件系统），统称为外部实体。一般只出现在数据流图的顶层图屮。注意事项特别要注意的是：数据流图不是传统的流程图或框图，数据流也不是控制流。数据流图是从数据的角度来描述一个系统，而框图则是从对数据进行加工的工作人员的角度来描述系统。数据流图中的箭头是数据流，而框

49、图中的箭头则是控制流，控制流表达的是程序执行的次序。(2)数据流图的细化分层理由下图是培训中心管理系统的数据流图，由于只有一层，因此分解的加工较多不易理解，而且如果其中某个加工较复杂，影响需求分析结果的可读性。 数据流图分层分层理由如果系统规模较大，仅用一个DFD图难以描述，会使得系统变得复杂，且难以理解。为了降低系统的复杂性，采取“逐层分解”的技术，画分层的DFD图。分层DFD酬“分解”与“抽象”I “先全局后局部，先整体后细节，先抽象后具体”通常将这种分层的DFD图，分为顶层、中间层、底层。顶层图说明了系统的边界，即系统的输入和输出数据流，顶层图只有一张。底层图由一些不能再分解的加工组成，

50、这些加工都已足够简单，称为基本加工。在顶层和底层之间的是屮间层。屮间层的数据流图描述了某个加工的分解，而它的组成部分又要进一步分解。画各层DFD图时，应“由外向内”。画分层DFD图的具体步骤先确定系统范围，画出顶层的DFD图。按照结构化分析方法中“自顶向下，逐步分解”的思想，可以先将整个系统看作是一个加工，它的输入数据和输出数据表明了系统和外部环境的接口，从而首先画出系统的顶层数据流图逐层分解顶层DFD图，获得若干屮间层DFD图。为了能够清楚地表明系统加工的详细过程，接着从顶层数据流图出发，逐层地对系统进行分解。每分解一次，系统中加工的数量就随之增加，每个加工的功能描述也越来越具体。重复这种分

51、解，直至得到系统的底层数据流图。(3)画出底层的DFD图。底层数据流图中的所有加工都应是不可再分解的、最简单的“原子加工”。(3)建立数据流模型的原则建立数据流模型要遵循以下的原则:(1)每个加工至少应有一个输入数据流(反映被处理数据的来源)和一个输出数据流(反映加工的结果）。(2)数据流图中各构成元素的名称必须具有明确的含义且能够代表对应元素的内容或功能。(3)对数据流图中某个加工进行细化生成的下层数据流图，称为其上层图的子图。应保证分层数据流图中任意对应的父图和子图的输入/输出数据保持一致。(4)在数据流图中，应按照层次给每个加工编号，用于表明该加工所处的层次及上、下层的父图与子图的关系。

52、(5)在父图中不要出现子图中涉及的局部数据存储文件。(6)数据流图只能由四种基本符号组成，是实际业务流程的客观映象，用于说明系统应该“做什么”，而不需要指明系统“如何做”。(7)数据流图的分解速度应保持适中。通常一个加工每次可分解为24个子加工，最多不要超过七个，因为过快的分解会增加用户对系统模型理解的难度。(8)为了便于数据流图在计算机上的输入和输出，免去画斜线、弧线、圆等符号的麻烦，数据流图还有另一套表示符号，如下表所示。分层DFD图的改进改进的原则与画分层DFD图的基本原则是一致的，可从以下方面考虑DFD图的改进：检查数据流的正确性数据守恒子图、父图的平衡文件使用是否合理。特别注意输入/

53、出文件的数据流。改进DFD图的易理解性简化加工之间的联系(加工间的数据流越少，独立性越强，易理解性越好）。改进分解的均匀性。适当命名(各成分名称无二义性，准确、具体）。3、数据字典DD数据字典的提出背景：虽然分层数据流图能够形象、清晰地描述数据在系统中流动、加工、存储的情况，但仅依靠名称并不能反映其本质含义，作为对数据流图的补充，数据字典(DD，Data Dictionary)能够准确地定义数据流图中各组成成分的具体含义，二者共同构成了系统的逻辑模型。DD的用途分析阶段的交流工具包含控制信息数据库设计的基础(1)数据字典DD的内容DFD中所有元素的定义的集合就是DD的内容。内容数据流数据流分量

54、数据存储处理（一般不用DD描述）定义数据的方法自顶向下分解数据数据字典屮的基木符号及其含义(2)数醉典巾的条目及说明数据字典是关于数据流图中各种成分详细定义的信息集合，可将其按照说明对象的类型划分为四类条目，分别为数据流条目、数据项条目、数据文件条目和数据加工条目。(2)数醉典巾的条目及说明数据字典是关于数据流图中各种成分详细定义的信息集合，可将其按照说明对象的类型划分为四类条目，分别为数据流条目、数据项条目、数据文件条目和数据加工条目。数据字典的任务是：对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。1).数据流条目数据流在数

55、据流图中主要用于说明数据结构在系统中的作用和流动方向，因此数据流也被称作“流动的数据结构”。数据字典中数据流条目应包括以下几项主要内容：数据流名称数据流别名说明数据流来源数据流流向数据流组成数据流量等。工资系统中的出勤表数据流在数据字典中的条目描述为数据流名称：出勤表数据流别名：无说明：由人事部门每月月底上报的职工考勤统计数字数据流来源：人事部门数据流流向：加工1.1.1 (统计出勤、请假及旷工时数）数据流组成：出勤表=年份+月份+职工号+出勤时数+病假时数+事假时数+旷工时数数据流量：1份/月数据流词条的描述示例1数据流名数据流别名:说明:简要介绍作用即它产生的原因和结果。数据流来源:即该数

56、据流来自何方。数据流去向:去向何处。数据流组成:数据结构。数据量流量:数据量、流通量。数据流名:发票说明:用作学生已付书款的依据数据流来源:来自加工“审查并开发票”数据流去向:流向加工“开领书单”。数据流组成：学号+姓名+书号+单价总价+书费合计数据流图中每个数 12).数据项条目数据流图中每个数据结构都是由若干个数据项构成的，数据项是加工中的最小单位，不可再分。数据字典的数据项条目中应包含的主要内容有:数据项名称数据项别名说明类型长度取值范围及含义等t例如:出勤表中的职工号数据项在数据字典中的条目描述为数据项名称:职工号数据项别名:employee。说明:本单位职工的惟一标识类型:字符串长度

57、:6取值范围及含义:12位(00. 99)为部门编号:36位（XX0001. XX9999)为人员编号3).数据文件条目数据文件是数据流图中数据结构的载体。数据字典的数据文件条目中应包含的主要内容有：数据文件名称说明数据文件组成组织方式存取方式存取频率等。例如：工资系统中的职工工资档案文件在数据字典中的条目描述为数据文件名称：工资档案说明：单位职工的基本工资、各项津贴及补贴信息数据文件组成：职工号+国家工资+国家津贴+职务津贴+职龄津贴+交通补贴+部门补贴+其他补贴组织方式：按职工号从小到大排列存取方式：顺序存取频率：1次/月3).数据文件条目数据文件是数据流图中数据结构的载体。数据字典的数据

58、文件条目中应包含的主要内容有：数据文件名称说明数据文件组成组织方式存取方式存取频率等。例如：工资系统中的职工工资档案文件在数据字典中的条目描述为数据文件名称：工资档案说明：单位职工的基本工资、各项津贴及补贴信息数据文件组成：职工号+国家工资+国家津贴+职务津贴+职龄津贴+交通补贴+部门补贴+其他补贴组织方式：按职工号从小到大排列存取方式：顺序存取频率：1次/月(3)数据字典的建立建立数据字典的方法人工方法将每一字典中的词条写在一张卡片上,由利用“字典管理程序在计算机中对字典进行管理和维护。2.建立数据字典的原则(1)所有定义必须严密、精确，不能存在二义性。(2)书写格式应简洁且严格。(3)应可

59、方便地实现对所需条目的按名查阅。(4)应便于修改和更新。4、加工说明PSPEG加工说明PSPEC说明DFD中的毎个加工 PSPEC描达工具结构化语言判定表判定树为了能够直观、明确地表达加工逻辑，经常采用结构化语言、判定树及判定表等三种描述方法，以下分别介绍。(1)结构化语言结构化语言是介于自然语言和形式语言之间的一种半形式语言，是自然语言的一个受限制的子集。描述时可以使用的词汇包括:数据字典中定义的名字、基本控制结构中的关键词、自然语言中具有明确意义的动词和少量的自定义词汇篆一般分为两层结构:外层语法较具体，为控制结构(顺序、选择、循环)，内层较灵活，表达“做什么” O结构化语言选择结构与循环

60、结构二自然语言+结构化形式选择结构如果 If 如果 则否则情况1情况nIf then Otherwisecase 1 case n 循环结构当，重复以下直至 DO WHILEENDDORepeat the following:Until /!(2)判定表提出背景：当某一加工的实现需要同时依赖多个逻辑条件的取值时，对加工逻辑的描述就会变得较为复杂，很难采用结构化语言清楚地将其描述出来，而采用判定表则能够完整且清晰地表达复杂的条件组合与由此产生的动作之间的对应关系。通常把表中任意一个条件组合的特定取值及其相应要执行的动作称为规则。二维表判定表是一种二维的表格，常用于较复杂的组合条件（与结构化语言比