1、1目 录 第第1 1章章 绪论绪论 第第2 2章章 可行性分析与项目计划可行性分析与项目计划 第第3 3章章 需求分析需求分析 第第4 4章章 概要设计概要设计 第第5 5章章 详细设计详细设计 第第6 6章章 编程与测试编程与测试 第第7 7章章 软件维护软件维护 第第8 8章章 面向对象的方法面向对象的方法 第第9 9章章 面向对象的需求获取面向对象的需求获取第第1010章章 面向对象的分析面向对象的分析第第1111章章 面向对象的设计面向对象的设计第第1212章章 面向对象的测试面向对象的测试第第3 3章章 软件需求分析软件需求分析可行性研究通过以后，下一步就要根据草拟的开发计划，展开详
2、细的需求分析活动。软件需求分析，是详细分析需求，并建立需求分析模型的阶段3第第3 3章章 软件需求分析软件需求分析n 3.1 3.1 需求分析概述需求分析概述n 3.2 3.2 结构化分析方法结构化分析方法n 3.3 3.3 数据流图的绘制数据流图的绘制n 3.4 3.4 编制数据字典编制数据字典n 3.5 3.5 加工逻辑的分析与表达加工逻辑的分析与表达n 3.6 3.6 原型技术原型技术n 3.7 3.7 需求验证与评审需求验证与评审43.1 3.1 需求分析需求分析概述概述n 3.1.1 3.1.1 需求分析的任务、特点、主要困难需求分析的任务、特点、主要困难n 3.1.2 3.1.2
3、人员组成人员组成n 3.1.3 3.1.3 分析师的角色分析师的角色n 3.1.4 3.1.4 需求分析的活动和原则需求分析的活动和原则53.1.1 3.1.1 需求分析的任务需求分析的任务1.1.完成完成“分析建模分析建模”;2.2.拟定拟定“确认测试确认测试”计划计划3.3.修订修订“开发计划开发计划”4.4.编写编写“需求规划说明书需求规划说明书”5.5.需求评审需求评审61.1.分析建模分析建模n 针对用户要求实现的软件功能、性能等目标，针对用户要求实现的软件功能、性能等目标，与开发人员进一步澄清、达成共识、形成规与开发人员进一步澄清、达成共识、形成规约约;n 准确讲，需求分析是发掘需
4、求、分析求精、准确讲，需求分析是发掘需求、分析求精、逻辑建模、形成规约的过程。逻辑建模、形成规约的过程。71.1.分析建模分析建模 发掘需求发掘需求调查需求、挖掘潜在需求、预测未来可能调查需求、挖掘潜在需求、预测未来可能的需求；的需求；需求求精需求求精对模糊不清的用户需求明确、精化；对模糊不清的用户需求明确、精化；逻辑建模逻辑建模在现行系统逻辑模型的基础上，考虑新的在现行系统逻辑模型的基础上，考虑新的用户需求、限制和约束的基础上导出新系统的逻辑模型；用户需求、限制和约束的基础上导出新系统的逻辑模型；形成规约形成规约将双方达成共识的需求文档化、模型化，将双方达成共识的需求文档化、模型化，这份文档
5、被称为这份文档被称为“需求规约需求规约”和和“需求规格说明书需求规格说明书”，它将是后需活动开发方努力实现的目标它将是后需活动开发方努力实现的目标82.2.拟定拟定“确认测试确认测试”计划计划n 有了共同的需求约定以后，就可以制定有了共同的需求约定以后，就可以制定“确确认测试认测试”计划，它是用户验证软件是否满足计划，它是用户验证软件是否满足需求的依据；需求的依据；n 这个计划到综合测试后期执行。这个计划到综合测试后期执行。93.3.修订开发计划修订开发计划n 系统调查与可行性研究阶段的最后，草拟了初系统调查与可行性研究阶段的最后，草拟了初步的开发计划，当时由于需求尚不详细，现可步的开发计划，
6、当时由于需求尚不详细，现可有了详细的需求分析结果以后，应该使开发计有了详细的需求分析结果以后，应该使开发计划更准确一些。划更准确一些。104.4.编写编写“需求规划说明书需求规划说明书”n 需求分析阶段的成果集中体现在需求分析阶段的成果集中体现在“需求规格需求规格说明书说明书”中，这是一个里程碑；中，这是一个里程碑；11“需求规划说明书需求规划说明书”的内容的内容n 有明确的格式和内容有明确的格式和内容125.5.需求评审需求评审n 需求评审是需求评审是“质量保证活动质量保证活动”的内容；的内容；n 体现出瀑布模型的体现出瀑布模型的“文档驱动文档驱动”特点特点n 由项目经理、用户、分析员、前一
7、阶段（可由项目经理、用户、分析员、前一阶段（可行性研究）的主要人员和后一阶段（概要设行性研究）的主要人员和后一阶段（概要设计）的主要人员组成评审小组；计）的主要人员组成评审小组；13阶段性成果（主要文档）包括：阶段性成果（主要文档）包括：n 需求规格说明书需求规格说明书n 细化的项目计划细化的项目计划n 确认测试计划确认测试计划14主要特点主要特点:v面向问题域（即用户业务领域）面向问题域（即用户业务领域）v只关注只关注“逻辑逻辑”，不考虑，不考虑“物理物理”只研究应该只研究应该“做什么？做什么？”，暂不考虑用什么手，暂不考虑用什么手段、如何实现，即段、如何实现，即“怎么做怎么做”的问题；的问
8、题；v用数流据图、数据字典、加工描述等工具用数流据图、数据字典、加工描述等工具建立逻辑模型建立逻辑模型15面临的主要困难面临的主要困难n 需求分析活动面临的挑战：需求分析活动面临的挑战：使用有效的软件工程方法克服复杂性使用有效的软件工程方法克服复杂性建立分析员与用户的有效沟通建立分析员与用户的有效沟通使用有效的工具，克服需求表述的二义性使用有效的工具，克服需求表述的二义性163.1 3.1 需求分析需求分析概述概述n 3.1.1 3.1.1 需求分析的任务、特点、主要困难需求分析的任务、特点、主要困难n 3.1.2 3.1.2 人员组成人员组成n 3.1.3 3.1.3 分析师的角色分析师的角
9、色n 3.1.4 3.1.4 需求分析的活动和原则需求分析的活动和原则173.1.2 3.1.2 人员组成人员组成n 如果是一个企业信息系统开发项目，那么项目团队如果是一个企业信息系统开发项目，那么项目团队成员应包括用户和开发人员；成员应包括用户和开发人员；n 参与团队的用户包括：参与团队的用户包括：v 企业负责人、部门负责人、专业岗位上的员工；企业负责人、部门负责人、专业岗位上的员工；n 参开团队的开发人员包括：参开团队的开发人员包括：v 系统分析师、数据管理员；系统分析师、数据管理员；n 在需求评审时，还需要在需求评审时，还需要”可行性分析可行性分析“和和”系统设系统设计计“阶段的主要人员
10、参与；阶段的主要人员参与；183.1 3.1 需求分析需求分析概述概述n 3.1.1 3.1.1 需求分析的任务、特点、主要困难需求分析的任务、特点、主要困难n 3.1.2 3.1.2 人员组成人员组成n 3.1.3 3.1.3 分析师的角色分析师的角色n 3.1.4 3.1.4 需求分析的活动和原则需求分析的活动和原则193.1.3 3.1.3 分析师的角色分析师的角色n 是用户与开发人员的桥梁；是用户与开发人员的桥梁；n 与项目经理合作，是开发团队的领军人物；与项目经理合作，是开发团队的领军人物；n 具体业务主要集中在可行性研究和需求分析阶段；具体业务主要集中在可行性研究和需求分析阶段；n
11、 个人素质方面：个人素质方面：v 具有领导才能，善于沟通；具有领导才能，善于沟通；v 具有实干作风；具有实干作风；v 知识面宽，重在广度而不是深度；知识面宽，重在广度而不是深度；v 技术全面；技术全面；v 有时分析师是一个团队，由若干人承担；有时分析师是一个团队，由若干人承担；203.1 3.1 需求分析需求分析概述概述n 3.1.1 3.1.1 需求分析的任务、特点、主要困难需求分析的任务、特点、主要困难n 3.1.2 3.1.2 人员组成人员组成n 3.1.3 3.1.3 分析师的角色分析师的角色n 3.1.4 3.1.4 需求分析的活动和原则需求分析的活动和原则213.1.4 3.1.4
12、 需求分析的活动和原则需求分析的活动和原则n 活动主要分为：活动主要分为：v需求获取需求获取；v分析建模；分析建模；v需求评审需求评审22需求获取的目标需求获取的目标n 对用户需求进行鉴别、综合，清除用户需求的模糊性、对用户需求进行鉴别、综合，清除用户需求的模糊性、歧义性和不一致性；歧义性和不一致性；n 把对原始问题的理解和软件开发经验结合起来，鉴别由把对原始问题的理解和软件开发经验结合起来，鉴别由于用户的片面性或短期行为所导致的不合理要求，发现于用户的片面性或短期行为所导致的不合理要求，发现用户尚未发现的但具有真正价值的潜在需求；用户尚未发现的但具有真正价值的潜在需求；23需求获取中风验需求
13、获取中风验n 需求获取隐藏着很大的风险需求获取隐藏着很大的风险n 任何错误的需求描述，都必然造成错误的设计、错误任何错误的需求描述，都必然造成错误的设计、错误的编程和错误的软件结果的编程和错误的软件结果24需求获取的困难需求获取的困难 n 第一，通讯渠道不畅，数据管理不严第一，通讯渠道不畅，数据管理不严n 第二，专业领域知识的鸿沟对分析师的业务技能是第二，专业领域知识的鸿沟对分析师的业务技能是一个绝对的挑战一个绝对的挑战n 第三，对分析活动没有系统的工作方法第三，对分析活动没有系统的工作方法 25第一，通讯渠道不畅，数据管理不严第一，通讯渠道不畅，数据管理不严n 用户和开发者之间免不了会有错误
14、的解释或误传的用户和开发者之间免不了会有错误的解释或误传的可能性，造成需求模糊、错误或二义性。可能性，造成需求模糊、错误或二义性。n 解决这个问题的原则是：建立有效的通信渠道，如解决这个问题的原则是：建立有效的通信渠道，如调查、座谈会、交流、报告会、电子文档等，做好调查、座谈会、交流、报告会、电子文档等，做好数据管理，充分发挥数据字典的作用。数据管理，充分发挥数据字典的作用。26第二，专业领域知识的鸿沟第二，专业领域知识的鸿沟n 用户想要什么他说不清，分析师告诉他新系统将会做用户想要什么他说不清，分析师告诉他新系统将会做什么他听不懂什么他听不懂n 分析师由于受计算机专业知识影响，容易把用户拒之
15、分析师由于受计算机专业知识影响，容易把用户拒之门外。例如，每当用户提出一个问题，分析师都马上门外。例如，每当用户提出一个问题，分析师都马上回答用计算机是如何实现的，或探讨应该如何用计算回答用计算机是如何实现的，或探讨应该如何用计算机实现，使得用户无法参与交流机实现，使得用户无法参与交流n 解决这个问题的原则是：解决这个问题的原则是：避免使用计算机专业术语。避免使用计算机专业术语。在访谈时，不要试图把用户带到自己的专业知识领域在访谈时，不要试图把用户带到自己的专业知识领域探讨问题。好的作法是，使用大家都能看得懂的图形探讨问题。好的作法是，使用大家都能看得懂的图形工具描述问题。如数据流图、工具描述
16、问题。如数据流图、IPOIPO图、功能目标图等。图、功能目标图等。27第三，对分析活动没有系统的工作方法第三，对分析活动没有系统的工作方法n 没有成熟的系统的策略，需求获取和分析没有章法，没有成熟的系统的策略，需求获取和分析没有章法，不分主次，容易陷入数据堆中。不分主次，容易陷入数据堆中。n 有些分析人员在获取用户需求时，经常是随意地问一有些分析人员在获取用户需求时，经常是随意地问一些主要的问题，记录下回答，然后继续这样问下去。些主要的问题，记录下回答，然后继续这样问下去。这种不规范的做法常常导致分析师与用户的思路前后这种不规范的做法常常导致分析师与用户的思路前后不连贯，效率低下。不连贯，效率
17、低下。28第三，对分析活动没有系统的工作方法第三，对分析活动没有系统的工作方法n 解决上述问题的原则是：解决上述问题的原则是：n 一方面，以数据为出发点，或是以功能为出发点，一方面，以数据为出发点，或是以功能为出发点，利用系统的过程性的特点，顺藤摸瓜。以绘制数据利用系统的过程性的特点，顺藤摸瓜。以绘制数据流图为线索，安排需求的调查和挖掘的顺序。流图为线索，安排需求的调查和挖掘的顺序。n 另一方面，合理掌握问题的抽象级别，分析绘制上另一方面，合理掌握问题的抽象级别，分析绘制上层数据流图时，不要把问题考虑的过细。这好比是层数据流图时，不要把问题考虑的过细。这好比是拔洋葱皮，需要采取由表及里，自上而
18、下挖掘和剖拔洋葱皮，需要采取由表及里，自上而下挖掘和剖析的策略。析的策略。29总的原则总的原则 n 分析师关注的焦点是分析师关注的焦点是“做什么（做什么（WhatWhat）”，而不是，而不是“怎么做怎么做How”How”，系统会产生和使用什么数据？系统，系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会遇到什么必须完成什么功能？将定义什么界面？会遇到什么约束？等。约束？等。n 这一阶段主要精力集中在获取和分析系统的逻辑功这一阶段主要精力集中在获取和分析系统的逻辑功能上。不要把能上。不要把“用计算机如何实现用计算机如何实现”这样的物理因这样的物理因素牵扯进来，影响逻辑功能的分析。
19、素牵扯进来，影响逻辑功能的分析。303.1.4 3.1.4 需求分析的活动和原则需求分析的活动和原则n 活动主要分为：活动主要分为：v需求获取；需求获取；v分析建模；分析建模；v需求评审需求评审31分析建模；分析建模；n由于用户往往会从不同的角度、不同的抽象级别中阐述对原始由于用户往往会从不同的角度、不同的抽象级别中阐述对原始问题的理解和需求，相对比较另零乱，有必要借助模型。问题的理解和需求，相对比较另零乱，有必要借助模型。n一方面，模型用于精确地记录用户从各个视角、不同抽象级别一方面，模型用于精确地记录用户从各个视角、不同抽象级别上对原始问题及目标软件的描述；另一方面，它将帮助分析人上对原始
20、问题及目标软件的描述；另一方面，它将帮助分析人员去伪存真、由表及里地挖掘用户需求。员去伪存真、由表及里地挖掘用户需求。n不同的方法有不同的建模规则，但建模的用途都是一致的，它不同的方法有不同的建模规则，但建模的用途都是一致的，它不仅是描述系统的工具，也是用户与开发人员进行交流的工具。不仅是描述系统的工具，也是用户与开发人员进行交流的工具。例如，在面向对象的分析方法中，要建立对象模型，而在结构例如，在面向对象的分析方法中，要建立对象模型，而在结构化分析方法中，数据流图则是建模的主要工具。逻辑模型不仅化分析方法中，数据流图则是建模的主要工具。逻辑模型不仅是描述问题的图形工具，同时更是分析问题的一种
21、工作方法。是描述问题的图形工具，同时更是分析问题的一种工作方法。32分析建模；分析建模；n 调研阶段产生的文档，是需求分析的起点，是目标软调研阶段产生的文档，是需求分析的起点，是目标软件系统逻辑模型的雏型。件系统逻辑模型的雏型。n 在需求分析阶段，分析师将进一步对它进行细化、扩在需求分析阶段，分析师将进一步对它进行细化、扩充，直到足够具体为止。在分析的过程中建立数据字充，直到足够具体为止。在分析的过程中建立数据字典，对模型进行注解。典，对模型进行注解。n 逻辑模型是分析师与用户交流的主要工具，也是需求逻辑模型是分析师与用户交流的主要工具，也是需求分析阶段的成果的主要体现。分析阶段的成果的主要体
22、现。333.3.需求评审需求评审 n 需求审查和管理复审是需求分析的最后一个环节，需求审查和管理复审是需求分析的最后一个环节，通过了这一环节，就等于暂时为需求分析阶段画上通过了这一环节，就等于暂时为需求分析阶段画上了一个了一个“句号句号”。尽管后期可能还会有些对需求分。尽管后期可能还会有些对需求分析的反复，但有了这个析的反复，但有了这个“句号句号”，就可以进入设计，就可以进入设计阶段了。阶段了。n 经过审批之后的文档，在整个项目范围内，相当于经过审批之后的文档，在整个项目范围内，相当于用户与开发人员之间达成了一份合约，后期的系统用户与开发人员之间达成了一份合约，后期的系统设计和系统测试，都将以这份设计和系统测试，都将以这份“规约规约”为准。为准。n 任何对合约的修改，都将影响到整个项目的工期和任何对合约的修改，都将影响到整个项目的工期和开发成本，都需要经过严格的审批和签约。开发成本，都需要经过严格的审批和签约。34
