A003-182-2268-黄清梅

作业报告

课程名称：需求分析与建模    
班级：18级软件工程2班 
实验名称：需求分析与建模读书心得与对项目的发展建议    
教导教师：董瑞生
姓名： 黄清梅   
学号：1814080902268
日期：2020年12月20日

对于刚结束的需求分析与建模这门课程，在老师的教导下我学到了很多，感谢老师的辛勤付出。在学完这门课程之后，让我对软件的需求有了进一步的认识与了解。在开始学习这门课的时候就有一些懵懂，认为在这个时期应该是往自己选择的方向走，但在老师的讲解下调整了心态，带着饱满的心情学习这门课程，这门课程让我进一步了解了需求工程的内容，目标，作用和意义，这本书还运用大量的理论知识介绍分析需求工程，让我对需求工程的了解逐步加深，同时书中也引用一些经典的的实例来分析，在分析实例中让我们对理论知识了解更加透彻。通过学习分析能让理论知识运用于实际的开发中。

关于这门课主要是关于软件需求工程的专项著述，目标是从开发者的视角出发，侧重于实践者的技术与方法，系统地介绍需求工程的最新发展，促进需求工程领域理论、方法和技术的全面融合应用，指导需求工程各阶段的系统化实践。书中从需求产生的根源出发，说明了需求工程的内容、目标、作用和意义，并介绍了需求工程的活动框架，概述了需求工程中的主要活动和实践方法，让我对需求工程有了初步的了解。在需求获取部分介绍了需求工程的需求获取活动，包括获取的活动的内容、任务、成果和实践情况，同时说明了如何为需求获取确定项目的前景和范围。讲到了如何选择需求获取的获取源，给出了需求获取的方法，并以需求获取为背景，介绍了需求工程中模型驱动方法的初步知识。

需求工程有三个主要任务:第一，需求工程必须说明软件系统将被应用的环境极其目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式，方法所施加的限制和约束，也即要同时说明软件需要做什么和为什么需要做。第二，需求工程必须将目标，功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。需求规格说明是最为重要的成果，是项目规划，设计，测试。用户手册编写等很多后继软件开发阶段的工作基础。第三，现实世界是不断变化的世界，因此，需求工程还需要妥善处理目标、功能和约束随着时间的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标，功能和约束在软件产品族中的演化和分布情况进行综合考虑与处理。

软件系统的涉众可以定义为所有能够影响软件系统的实现，或者会被实现后的软件系统所影响的个人和团体。常见的涉众类别有用户，客户，开发者，管理者，领域专家，政府力量，市场力量等。涉众群体不是固定不变的。按照复杂程度可以将信息系统分为小型系统，组织级系统，战略信息系统，组织间系统四种类型。涉众分析包括涉众识别，涉众描述，涉众评估（包括基于涉众扩展特征建立的分布图进行优先级评估，最终得到参与者，环境设定者，被影响者，观众四种类型。还有风险评估和共赢分析），涉众选择（包括以完整采样，态度积极，数量适中，比例恰当为标准的代表采样，参与策略，用户替代源等）。硬数据，包括定量（数据收集表格，统计报表）和定性（整个组织的描述文档，业务指导文档，业务备忘）硬数据两种。常用的硬数据采样技术是随机抽样和分层抽样。 

需求获取的方法之一是面谈，利用面谈可以获得事实和问题，被会见者的观点，被会见者的感受，组织和个人的目标。面谈中包括两种基本问题类型，开放式问题和封闭式问题，各有优缺点。面谈结构包括金字塔结构，即封闭问题到开放问题的过度结构。漏斗结构，即开放到封闭结构。菱形结构，前两种结构的结合。除了开放问题和封闭问题，还有探究式问题，诱导性问题，双筒问题，元问题，程序性提示等几个其他重要的问题类型。在面谈之前，需要做阅读背景资料，确定面谈主题和目标，选择被会见者，准备被会见者，确定问题和类型等准备。面谈中需要建立一个理想氛围和环境，保持有礼貌的倾听，控制面谈过程，保持面谈主题，使用探究式问题，观察被会见者，使用道具支持。结束后感谢被会见者。记录面谈可以采用笔录，录音摄像（征得被会见者的同意）。面谈结束需要复查面谈记录，总结面谈信息，完成面谈报告。面谈包括结构化面谈，半结构化面谈，非结构化面谈等几个方面。还有群体面谈。除了面谈，还有调查问卷，头脑风暴等方式。 

原型通常是一个系统的一部分或者一个模型。原型方法通过在用户和需求工程师之间设立一个有形的物件，使得双方的交流更加简单和有效。一方面可以使用户更好的理解需求工程的假设，一方面可以使需求工程师通过观察用户的反馈加深对用户的理解，明确自己的假设正确性。原型类别有演示原型，样板原型，拼凑原型，演示化原型，水平和垂直原型。原型开发方法包括探索式，实验式，演化式。原型方法包括过程，确定需求，开发，评估，修正。优点是及早解决系统开发中的不确定性，风险是会使需求不够完善。 

常见的观察方法有采样观察，民族志（长期浸入式），话语分析，协议分析，任务分析等。通过对突现，局部，暂时，涉身，开放，模糊，等几个情景性的性质中得到需要采用观察方法解决的问题有:理解复杂的协同事件，获取工作中的异常处理，获取与用户认识不一致的实际知识，了解用户的认知和获取默认知识。其中民族志的优点是能够得到信息的深度理解和让真实世界的社会性因素可见化，缺点是耗时，结果难以传递到开发过程。 

需求获取的常见模型驱动方法有:面向目标的方法（目标的获取，分析和实现），基于场景的方法，基于用例的方法。用例就是一种场景的文本化表现方式，详细用法就是uml的设计。 

模型语言有语法，语义和语用。常见的需求分析技术包括，上下文图，数据流图，实体联系图，功能实体矩阵，功能分解图，过程依赖图，用例图，类图等uml建模过程。常见需求分析技术，可以通过wieringa和zachman进行分类（书p206/209）。需求分析方法有传统分析，结构化分析，信息工程和面向对象分析。实践中的需求分析需要需求分析技术的使用，非功能需求的建模，确定需求优先级，新技术方法的需要等。 

过程建模是结构化分析方法的典型技术，也就是分析需求获取活动获得的信息，发现系统的功能和其与外界的交互，建立能够实现系统功能的过程分解结构，形成系统的过程模型，并用图形的方式将过程模型描述出来。过程建模使用的主要技术有:上下文图，数据流图，微规格说明（过程规范），数据字典。因为已经学过uml建模，大致理解各个方面。最后是逻辑DFD，物理DFD与传统的DFD三种建模方法的区别和优缺点。 

过程模型更多的是侧重数据产生与使用的时间，地点和方式，而没有描述数据的定义，结构和关系等特性。数据建模就是描述的后者。数据建模包括概念，物理和逻辑数据模型。使用ERD描述数据模型的方法，ERD的创建方法主要有三种：依据充分描述信息的创建，依据硬数据表单的创建，复杂情况下的创建。现在实现ERD与过程模型同步的技术中，功能/实体矩阵是一种比较常见的技术。 面向对象建模就是有关uml的各种图和建模方式的描述。

需求规格说明活动就是将需求极其软件解决方案进行定义和文档化，并传递给开发人员的需求工程活动。编写需求规格说明文档：清晰明确结构化的文档可以将软件系统的需求信息和解决方案更好的传递给所有的开发者；可以拓展人们的知识记忆能力；可以成为各方人员之间有关软件系统的协议基准；可以成为项目开发活动的一个重要依据；可以尽早发现和减少可能的需求错误，从而减少项目的返工，降低项目的工作量；可以成为有效的智力资产。需求规格说明文档的类型不同表现在，名称，内容，组织方式，表达方式，用途和作用，使用的辅助性。需求规格说明文档的写作需要注意：内容的组织，表达方式，细节描述。优秀的需求规格说明文档应该具备正确性，无歧义，完备性，一致性，根据重要性和稳定性分级，可验证，可修改，可跟踪。 

（1）需求验证确保需求集是正确，完备和一致的，技术上是可解决的，它们在现实世界中的满足是可行和可验证的。方法有需求评审，原型与模拟，开发测试用例，用户手册编制，利用跟踪关系，自动化分析。

（2）需求确认的目的是确保需求的内容正确性。

（3）系统验证：正确地建立系统，确保系统能够在预期的环境中正确地执行设定的功能。

（4）系统确认：建立的系统是正确的。问题修正有需求澄清，发现缺失需求，解决需求冲突，修正不切实际的期望的几种。 

需求基线就是被明确和固定的需求集合，内容包括软件需求自身和软件需求相关的描述信息。基线的维护包括配置管理和状态维护两个方面。还有需求跟踪，控制变更等模块 

需求工程的过程管理：需求工程过程需要依赖的环境因素有市场特性，领域特性，技术成熟度，组织文化，项目特性等。需求工程过程的建立包括建立过程框架和选择工作组件两个步骤。需求工程过程需要专门特定的评价标准和改进方法。评价可以参照REGPG的66个实践。改进的实施步骤有评价当前过程，计划改进活动，培训参与人员，实现新过程，度量新过程，确定下一步行动等六个步骤。过程改进中需要注意以下事项：将需求工程过程放在软件过程的背景下实施改进，改进的实施要建立在现有过程的评价之上，过程的改进要针对目标，过程的改进要有计划，过程的改进应该是渐进和持续的。 

关于项目的含义对编程系统产品的论述给出很好的启发，区分了下面几个概念：程序、编程产品、编程系统、编程系统产品。需求工程中的项目管理活动包括资源管理、活动管理和交付物件管理。资源支持主要有一定数量技能良好的可用人员；可行的时间限制和充足的资金支持；可用的系统运行环境、软件工具、道具、文档模板、可复用资源等其他资源支持。维持需求团队内部的有效共同应该建立一致的目标，建立有效的共同机制，利用有效的沟通技巧，利用辅助的工具和技术等。过程包括风险识别，风险分析，制定风险管理计划，风险跟踪，风险控制等几个方面。

对于我们小组的项目Fast Food Bill System中，在写需求分析的时候就有一些存在矛盾就像是账单的操作有些事不能进行删除之类的操作，应该再进一步的细化以及涉众这些也写的没有很好，关注软件开发活动和任务的风险和不确定性，并采取行动减少其中的不确定性或者降低风险的影响范围，进行改善以及增添一些功能去更加完善项目。