需求工程中用到的方法和技术

需求工程定位：

1）需求工程：收集客户的原始需求，通过梳理、分析，形成的【需求说明规格书】，它作为设计工程的输入以及开发工程成果的客户验收依据。

2）设计工程：依据①的成果再进一步分析、抽提，形成架构、功能和数据的设计成果，这是开发工程编码的依据。

3）开发工程：依据②的成果，用编码将设计成果转换为最终的软件，交付客户。

一、需求获取：

这是一个和系统信息持有者进行交流从而发现他们的需求的过程，来自信息持有者的领域需求和文档也是在这个阶段中发现的，这一个阶段的信息源有：已有文件 + 系统信息持有者 + 类似系统的相关描述。

需求获取是一个对于准备建立的系统和正在使用的系统进行信息收集并从这些信息中提取用户需求和系统需求的过程。

需求获取一般有如下技术：
技术1：视点(viewpoint)

视点是一种收集和组织需求的方式，这些需求可能来自一组具有相同认知的信息持有者，因为每一个视点包含一组系统需求，视点可能来自于最终用户，可能来自于管理者，能够帮助识别不同的能够提供需求信息的人。

技术2：采访(interview)

对信息持有者的正式和非正式的采访时绝大多数需求工程过程的组成部分，分为封闭式采访和开放式采访，采访者需要思想开放，对需求不会先入为主，并且很善于听取信息持有者的意见。

技术3：深入实际(ethnography)

软件系统不是孤立存在的，是在一个社会或者机构的环境中使用的，软件需求来自于这样的环境，受到这样的环境的制约，满足这些社会的和机构的需求对系统的成功是至关重要的。
深入实际就是用来了解操作过程并帮助导出这些过程支持性质的需求的观察技术，可以和原型法结合使用，分析人员通过观察日常工作，记录参与者相关的实际任务，能够帮忙发现隐性的系统需求，这些需求反映了人们的实际工作方式，能够观察到社会和机构的因素对工作的影响。

适用于两种类型的需求发现：

1需求来自人们实际的工作方式而不是过程定义中所要求的方式 。
2需求来自于合作和对别人活动的了解。

技术4：脚本(scenario)

通常人们容易把事物和现实生活中的例子相互联系，不容易把事物的一个抽象描述联系起来，如果把人怎么样和一个软件系统交互用一个脚本来描述的话，人们就很容易理解。
当把细节加入一个概要需求描述中的时候，脚本(场景)可能会很有用，脚本就是对交互实例片段的描述，每个脚本可能包含一个或多个可能的交互。

绝大多数情况下脚本包括：

1在开始部分有一个系统和用户期望的描述 。
2一个关于标准事件流的描述。
3一个关于可能出错的位置以及如何处理错误信息的描述 。
4有关其他可能同时进行的活动的信息 5在脚本完成之后系统状态的描述。

技术5​​​​​​​：用例(use case):

是一种需求发现技术，它是从参与者也就是最终用户的角度描述软件或者是系统的，用例识别一个单个交互，这是系统与用户之间或者不同的系统之间的交互。

二、需求分析

需求获取后需要进行分析，主要是对需求进行分类、分析每个需求与其他需求之间的关系，检查需求的一致性、重叠和遗漏的问题，并对需求进行排序。

软件需求文档（SRS）：

SRS是对系统开发者需要实现什么的正式描述，应该包括系统的用户需求和一个详细的系统需求描述，它不是设计文档，与其说它关注怎样去实现，不如说它关注实现什么

用户需求需要让不具备专业技术方面知识的用户看懂

系统需求是用户需求的扩展版，是软件系统工程师的设计起点，它添加了很多细节，来说明如何能让系统提供用户需求，是对系统的一个详尽而完备的描述，它可以作为有关系统实现合同的一部分

SRS定义了系统的外部行为，描述了对于软件系统的约束，方便进行变更而且可以作为软件为何的参考工具【必须声明和功能(functionality)、性能(performance)、设计约束(design constraints)和外部接口(external interfaces)相关的功能】

需求文档中内容的详细程度取决于所要开发的系统的类型和所使用的开发过程，就比如说，在演化开发中，因为需求时刻在变化，所以可以不那么详细，在瀑布模型中，因为需求需要在设计阶段完备，所以需要很详细， 而当系统是由某个外部机构承担的时候，要求极高的一类的系统(critical system)的需求文档就要很详细。

三、系统建模

要求产品在开始开发之前被完全设计和建模，因此，必须提前执行设计阶段。
通过合适的工具和符号系统来描述。在用户和系统分析人员之间建立了统一的语言和理解的桥梁。

常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象方法。
面向数据流方法：
https://blog.csdn.net/qq_15037231/article/details/60589847
面向数据结构方法：

侧重从数据结构方面去分析和表达软件需求，进行软件设计的开发方法。该方法从数据结构入手，分析信息结构，并用数据结构图（特指该类方法所用的图形描述工具，例如Jackson
结构图和Warnier图）来表示，再在此基础上进行需求分析，进而导出软件的结构。

面向对象方法：

第一步，确定对象和类。这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中建立一个新对象的描述。
第二步，确定结构（structure）。结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体-部分结构反映整体和局部之间的关系。
第三步，确定主题（subject）。主题是指事物的总体概貌和总体分析模型。
第四步，确定属性（attribute）。属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。
第五步，确定方法（method）。方法是在收到消息后必须进行的一些处理方法：方法要在图中定义，并在对象的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择一个方法本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。

四、验证

检验需求是否真正按照客户的意愿来定义的系统的过程，它和需求分析有很多共性，都是要发现需求中的问题。

需求的有效性验证很重要，如果在后续的开发或者系统投入使用的时候才发现需求文档出现了问题，那么就会导致更大代价的返工，由于需求问题对系统做出变更的成本远远高于修改设计或者代码错误的成本：需求的变更会造成设计和代码的变更，从而使得系统需要重新测试。

需要进行多种类型的检查：

有效性检查(Validity)
一致性检查(Consistency) : 需求不出现冲突。
完备性检查(Completeness)：包括所用用户想要实现的功能或者约束 。
真实性检查(Realism)：检查需求确保需求能够得到实现。
可检验性检查(Verifiability) ：能设计出一组检查方法来验证交付的系统满足每个定义的需求。

有效性检验技术：

1）需求评审:当需求定义被公式化之后，应该进行经常性的正式或者非正式的评审，评审主要是为了检查可验证性(verifiability)、可读性(comprehensibility)、可追溯性(traceability)和可适应性(adaptability)，客户和合同方都应该参与评审，软件开发者、客户和用户之间拥有好的交流和沟通使得在早期解决问题成为可能。
2）原型建立
3）测试用例生成

五、管理

需求管理就是在需求工程和系统开发过程中管理需求变化的过程。

大型软件系统的需求总是在变化的，原因之一是通常要开发这些系统来满足棘手的问题，这些问题不可能被完全定义，所以软件需求注定是不完全的。同时，信息持有者对于问题的理解也是在不断变化的，因此系统需求也需要反映这些对问题观点的变化。

我们需要跟踪各个需求和优先次序，维护有依赖关系的需求之间的联系来评估需求变更的影响，建立一个形式化的过程来形成变更建议并将他们和需求联系起来。

变更的出现是不可避免的，原因如下：

1）业务、组织机构和技术上的变更会不可避免地导致需求的变更。
2）系统业务和技术环境在安装之后总是在发生变化：可能引进新的硬件，业务优先次序可能会改变，立法和规章制度可能改变等等。
3）系统购买者和系统的最终使用者很少是同一个人，系统客户可能因为机构或者预算约束对系统提出一些要求，而这些需求可能和最终用户需求冲突。
4）大型系统通常拥有不同的用户群，不同的用户群有不同的需求和优先次序，很可能发生冲突和矛盾 。