{城乡园林规划}第3章需求工程2

《{城乡园林规划}第3章需求工程2》由会员分享，可在线阅读，更多相关《{城乡园林规划}第3章需求工程2（105页珍藏版）》请在金锄头文库上搜索。

1、2020/8/4,1,第3章 需求工程 内容提要,3.1 软件需求 3.2 需求工程过程 3.3 需求的获取 3.4 需求分析 3.5 需求定义 3.6 需求验证 3.7 需求管理 3.8 案例:小型教学管理系统 3.9 小结,2020/8/4,2,引言,软件需求是决定软件开发是否成功的一个关键因素 整个软件工程活动中，只有需求阶段可以称为需求工程。这体现了需求在整个软件工程过程中非同一般的重要性。 需求工程的所有过程包括: 需求获取 需求分析 需求定义 需求验证 需求管理,2020/8/4,3,3.1 软件需求,关于软件需求定义： 在IEEE软件工程标准词汇表（1997年）中给出如下描述：

2、（1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。 （3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。,2020/8/4,4,3.1 软件需求,从这个标准定义中可以看出需求的概念涵盖了两个方面: 用户角度（系统的外部行为） 开发人员角度（系统的内部特性） 通常，软件需求可以分为不同的层次： 业务需求 用户需求 功能需求 非功能需求,2020/8/4,5,3.1 软件需求,图3.1 不同层次的软件需求及其关系,2020/8/4,6,3.1 软件需求,业务需求反映了组织机构或客户对系统和产品高层次的目标要求

3、，它们在项目视图与范围文档中予以说明。 用户需求描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。 功能需求和非功能需求定义了开发人员必须实现的软件功能，这些需求则体现在需求文档中。,2020/8/4,7,3.1.1 业务需求,业务需求说明了提供给客户和产品开发商的新系统的最初利益, 它们在项目视图与范围文档中予以说明。 项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须能达到业务需求的需要。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。,2020/8/4,8,3.1.2 用户需求,用户需求是从

4、用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。用户需求文档描述了用户使用软件产品要完成的任务，用户需求描述的原则是：应该易于用户的理解，一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式进行描述。,2020/8/4,9,3.1.3 功能需求,功能需求描述系统所预期提供的功能或服务。即定义系统应该做什么，系统要求输入什么信息，输出什么信息，以及如何将输入变换为输出。它由开发的软件类型、软件未来的用户以及开发的系统类型决定。,2020/8/4,10,3.1.4 非功能需求,除了关心软件的功能和行为外，用户会将更多注意力集中于诸如产品的易用

5、性、运行速度、可靠性、如何进行异常处理等特性。因此，一个好的软件还必须满足一系列非功能需求。非功能需求是指那些不直接与系统具体工作相关的一类需求。主要涉及系统的总体特性，如可靠性、反映时间和储存空间等。,2020/8/4,11,3.1.4 非功能需求,非功能需求涉及的面非常广，包括系统的性能，目标系统所受的限制条件和开发和维护软件的限制，还包括如安全规章、隐私权保护的立法等外部因素。 具体内容可由三个方面构成 产品需求 机构需求 外部需求,2020/8/4,12,3.1.4 非功能需求,2020/8/4,13,3.1.4 非功能需求,对于非功能需求的表述要求尽可能的量化且可验证。表3.1给出了

6、一些可能用来指定非功能性系统特性的度量，据此可以检验系统是否满足了相应的需求。,2020/8/4,14,3.1.4 非功能需求,2020/8/4,15,3.2 需求工程过程,软件需求工程是一门应用有效的技术和方法、合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科。 需求工程过程中 ，开发人员需要： 收集和分析各方面的需求 编写规格说明文档 并采用评审和商议等有效手段对其进行验证，最终形成一个需求基线 由于软件开发过程中经常发生需求变更的情况，因此必须有效地管理和控制这些变更。,2020/8/4,16,3.2 需求工程过程,需求工程过程包括： 1.需求获取 确定和收集与待开发的

7、软件系统相关的用户需求信息。 2.需求分析 对获得的用户需求信息进行分析和综合，找出错误和冲突及遗漏的地方，获得用户的准确需求，进而建立软件系统的逻辑模型或需求模型。,2020/8/4,17,3.2 需求工程过程,3.需求定义 利用描述语言、标准格式书写软件系统的需求规格说明。 4.需求验证 审查和验证软件系统需求规格说明，进而确定需求规格说明是否正确描述了用户对软件系统的需求。 5.需求管理 需求管理的任务是：管理软件系统的需求规格说明，评估需求变更带来的影响及成本费用，跟踪软件需求的状态，管理需求规格说明的版本等。 下面分别叙述需求工程的每一部分。,2020/8/4,18,3.3 需求的获

8、取,需求获取是在问题及其最终解决方案之间架设桥梁的第一步。需求获取的关键在于通过与用户的沟通和交流，收集和理解用户的各项要求。,2020/8/4,19,3.3.1 需求获取的过程,需求获取的主要任务是与客户或用户沟通，了解系统或产品的目标是什么，客户或用户想要实现什么？ 对于不同规模及不同类型的项目，需求获取的过程不会完全一样。下面给出需求获取过程的参考步骤。,2020/8/4,20,3.3.1 需求获取的过程,开发高层的业务模型 所谓应用领域，即目标系统的应用环境，如银行、电信公司等。如果系统分析员对该领域有了充分了解，就可以建立一个业务模型，描述用户的业务过程，确定用户的初始需求。然后通过

9、迭代，更深入地了解应用领域，之后再对业务模型进行改进。 2.定义项目范围和高层需求 在项目开始之前，应当在所有利益相关方中建立一个共同的愿景，即定义项目范围和高层需求。项目范围描述系统的边界以及与外部事物（包括组织、人、硬件设备、其他软件等）的关系。高层需求不涉及过多的细节，主要表示系统需求的概貌。,2020/8/4,21,3.3.1 需求获取的过程,3. 识别用户类和用户代表 需求获取的主要目标是理解用户需求，因而客户的参与是生产出优质软件的关键因素。因此，首先确定目标系统的不同用户类型；然后挑选出每一类用户和其他利益相关方的代表，并与他们一起工作；最后确定谁是项目需求的决策者。 用户类可以

10、是人，也可以是与系统打交道的其他应用程序或硬件部件。如果是其他应用程序或硬件部件，则需要以熟悉这些系统或硬件的人员作为用户代表。 4. 获取具体的需求 确定了项目范围和高层需求，并确定了用户类及用户代表后，就需要获取更具体、完整和详细的需求。具体需求的获取方法下节详细介绍。,2020/8/4,22,3.3.1 需求获取的过程,5. 确定目标系统的业务工作流 具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则，采取需求调研的方法获取所需的信息。例如，针对信息系统的需求调研方法如下： (1) 调研用户的组织结构、岗位设置、职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确

11、系统的目标。,2020/8/4,23,3.3.1 需求获取的过程,(2) 调研每个子系统的工作流程、功能与处理规则，收集原始信息资料，用数据流来表示物流、资金流、信息流三者的关系。 (3) 对调研内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个需求的层次。,2020/8/4,24,3.3.1 需求获取的过程,6. 需求整理与总结 必须对上面步骤取得的需求资料进行整理和总结，确定对软件系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密要

12、求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求等。,2020/8/4,25,3.3.2 需求获取的常用方法,需求获取的常用方法： 1. 用户面谈 它是一种理解商业功能和商业规则的最有效方法。面谈过程需要认真的计划和准备，其基本要点： （1）面谈之前：确立面谈目的；确定要包括的相关用户；确定参加会议的项目小组成员；建立要讨论的问题和要点列表；复查有关文档和资料；确立时间和地点；通知所有参加者有关会议的目的、时间和地点。,2020/8/4,26,（2）进行面谈时：衣着得体；准时到达、寻找异常和错误情况；深入调查细节；详细记录；指出和记录下未回答条目和未解决问题。 （3）面谈之后：复查笔

13、记的准确性、完整性和可理解性；把所收集的信息转化为适当的模型和文档；确定需要进一步澄清的问题域；适当的时候向参加会议的每一个人发一封感谢信。,3.3.2 需求获取的常用方法,2020/8/4,27,3.3.2 需求获取的常用方法,2. 需求专题讨论会 需求专题讨论会也许是需求获取的一种最有力的技术。项目主要风险承担人在短暂而紧凑的时间段内集中在一起，一般为1 至2 天，与会者可以在应用需求上达成共识、对操作过程尽快取得统一意见。参加会议人员包括：主持人、用户、技术人员、项目组人员。,2020/8/4,28,3.3.2 需求获取的常用方法,专题讨论会具有以下优点： （1）协助建立一支高效的团队，

14、围绕项目成功的目标； （2）所有的风险承担人都畅所欲言； （3）促进风险承担人和开发团队之间达成共识； （4）揭露和解决那些妨碍项目成功的行政问题； (5) 能够很快地产生初步的系统定义。,2020/8/4,29,3.3.2 需求获取的常用方法,3. 问卷调查 可用于确认假设和收集统计倾向数据，问卷需要快速回答，允许匿名方式。存在问题的是：相关的问题不能事先决定；问题背后的假设对答案造成偏颇，如这符合你的期望吗；难以探索一些新领域；难以继续用户的模糊响应。在完成最初的面谈和分析后，问卷调查可作为一项协作技术可以收到良好的效果。,2020/8/4,30,3.3.2 需求获取的常用方法,4. 现场

15、观察 掌握用户如何实际使用一个系统以及到底用户需要哪些信息，最好的办法是亲自观察用户是如何完成实际工作的。一般方法是： (1)对办公室进行快速浏览，了解布局、设备要求和使用、工作流总体情况； (2)安排几个小时观察用户是如何实际完成他们的工作，理解用户实际使用计算机系统和处理事务的细节； (3)像用户一样接受训练和做实际工作，发现关键问题和瓶颈。,2020/8/4,31,3.3.2 需求获取的常用方法,5. 原型化方法 一个软件原型是所提出的新产品的部分实现 建立原型可以解决在产品开发的早期阶段需求不确定的问题。如建立基于WEB 的应用系统原型，使用HTML 进行界面设计。,2020/8/4,

16、32,3.3.2 需求获取的常用方法,6. 基于用例的方法 随着面向对象技术的发展，基于用例的方法在需求获取和建模方面应用越来越普遍。 用例建模是以任务和用户为中心的，开发和描述用户需要系统做什么。 用例有助于开发人员理解用户的业务和应用领域，并可以运用面向对象分析和设计方法将用例转化为对象模型。,2020/8/4,33,3.3.2 需求获取的常用方法,用例建模的基本步骤： （1）确定系统的参与者：参与者是与系统交互的外部实体，它既可以是人员也可以是外部系统或硬件设备。 （2）确定场景：场景是对人们利用计算机系统过程做了什么和体验了什么的叙述性描述。它从单个参与者的角度观察系统特性的具体化和非正式的描述。 （3）确定系统用例：用例描述了一个完整的系统事件流程，其重点在于参与者与系统之间的交互而不是内在的系统活动，并对参与者产生有价值的可观测结果。,2020/8/4,34,3.3.2 需求获取的常用方法,（4）确定用例之间的关系：在确定出每一个参与者的用例之后，需要将参与者和特定的用