系分——需求工程-02需求获取 、需求分析、需求定义

2024-01-31教育

考点: 数据流图、UML图(用例图、状态图、类图、活动图、时序图)、需求获取、需求分析、需求定义(需求规格说明书内容)、需求验证、需求管理和跟踪、需求变更(流程)、逆向工程、软件重构。

建议：通读教材 :第8章软件工程;第10章系统分析;第11章软件需求工程;第12章软件架构设计;第13章系统设计;

软件需求 ：是指用户对系统在 功能、行为、性能、设计约束 等方面的期望。是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

随着系统规模的扩大，需求分析与定义在整个系统开发过程中越来越重要，直接关系到系统的成功与否。需求分析活动不再仅限于系统开发的最初阶段，而是贯穿于系统开发的整个生命周期。于是形成了软件工程的子领域： 软件需求工程。

（1）软件需求工程定义

软件需求工程 是包括 创建和维护 需求文档的必需的一切活动的过程，可分为 需求开发 和 需求管理 两大工作。 需求开发 包括需求获取、需求分析、需求定义、需求验证 4个阶段 ；而 需求管理 包括定义需求基线，处理需求变更和需求跟踪等方面工作。这两部分相辅相成。其中需求开发是主线，是目标；需求管理是支持，是保障。

（2）需求分类

需求的层次 (这三个不同层次从目标到具体，从整体到局部，从概念到细节)

（1） 业务需求 ：是指反映企业或客户对系统 高层次的目标要求 ，通常来自项目投资人、购买产品的客户、客户单位的管理员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，为以后的开发工作奠定了基础。

（2） 用户需求 ：描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求；

（3） 系统需求 ：从系统的角度来说明软件的需求，包括 功能需求 、 非功能需求 和 设计约束 等。

1) 功能需求 ：也称为 行为需求 ，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。

2) 非功能需求 （ 性能需求，质量属性 ）：指系统必须具备的属性或品质，又可以细分为软件质量属性（如可维护性、可靠性、效率等）和其他非功能需求。

3) 设计约束 （ 外界强制规定的 ）：也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。

u 按质量功能部署（从用户角度出发）

（1)常规需求 。用户认为系统应该做到的功能或性能，实现越多用户会越满意。

（2)期望需求 。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。

（3)意外需求。 意外需求也称为 兴奋需求 ，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

需求分类--【PIECES框架】

PIECES框架是IT项目系统需求分析时的一个模型，PIECES框架能够完整、准确、快速地确定信息系统的需求，确认业务中存在的问题、机会和改进目标。

PIECES框架是系统非功能性需求分类的技术

性能( P reformance ): 用于描述企业当前的运行效率，可以分析当前业务的处理速度。 信息(I nformation ): 信息和数据指标用于描述业务数据的输入、输出以及处理方面存在的各种问题。

经济(E conomics [ˌiːkəˈnɒmɪks] ): 经济指标主要是从成本和收益的角度分析企业当前存在的问题。

控制(Control ): 提高信息系统的安全和控制水平。

效率(E fficiency ): 提高企业的人、财、物等的使用效率,

服务(S ervice ): 提高企业对客户、供应商、合作伙伴、顾客等的服务质量。

（3）需求开发-需求获取方法（特点?优点？缺点？根据描述能区分）

需求获取 属于软件需求工程的需求开发阶段，

（1）用户访谈 ：1 对 1-3，有代表性的用户。用户访谈是最基本的一种需求获取手段，其形式包括结构化（指事先准备好一系列问题，有针对地进行）和非结构化（只列出一个粗略的想法，根据访谈的具体情况发挥）两种，最有效的访谈是结合这两种方法进行，毕竟不可能事先一一计划清楚。用户访谈具有良好的灵活性，有较宽广的应用范围，但用户时间不好安排；谈话信息量大，不好记录；需要沟通技巧和足够的领域知识、丰富的应对经验等；

为了进行有效的用户访谈，需要在 三个方面 进行组织，分别是 准备访谈 、 主持访谈 和 访谈的后续 工作；

1）准备访谈

确定访谈目的；

确定访谈中应包括哪些用户；

为访谈准备一些详细问题；

问题可分为开放式问题和封闭式问题，开放式问题鼓励用户讨论和说明细节；封闭式问题旨在获得具体的事实。

2）主持访谈

具体访谈时，一定要准时到达，可能的话，早一点到，访谈过程，要做好几项工作：

限制访谈时间，时间控制在90分钟内，如果需要更多时间，应安排下一次，几次比较短的访谈，比一次马拉松式访谈效果要好得多。

寻找异常和错误情况，要找机会问一些类似，如果。。。那会怎么样的问题，有意识地去确定所有特殊的情况，并与用户深入探讨。

深入调查细节；

认真做好记录

注意措辞，尊重用户；避免使用IT专业术语；保持谈话轻松气氛；

3）访谈的后续工作

访谈后首要任务是吸收，理解和记录访谈所获得的信息；对于用户回答不上来，或错过的问题，不要丢弃或遗忘，准备下一次再问；谈话备忘录要送客户一份。

（2） 问卷调查 ：用户多，无法一一访谈。通过精心设计调查表，下发到相关人员手同，让他们填写答案，可以有效克服用户访谈方法中存在的问题，一张好的问卷调查表需要花费大量的时间来进行设计与制作，包括确定问题及其类型、编写问题、设计问卷调查表的格式三个重要活动。与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；问卷调查的结果比较好整理和统计。问卷调查最大的不足就是缺乏灵活性 ;其次还有由于双方未见面，无法从表情等细节获取隐性的信息，用户也无法即时澄清含糊或错误的回答；用户可能心理上不够重视，反馈信息不全面；调查表不利于展开回答，不利于了解细节；回答人数可能不及预期，效果打折扣；

较好的做法是用户访谈与问卷调查相结合，先问卷调查，整理分析的基础上，小范围用户访谈。

提高问卷返还率的方法 ：

向所有解释问卷的目的，以及如何使用；

说明问卷所有人要回答；

拜托客户领导督促手下回答并返还；

尽量参加一次企业全体会议，会上回答大家的问题，并解释这些信息的用处；

更改问卷中的问题，尽量减少回答问卷所花费的时间；

设置奖励措施；

（3） 现场观摩 ：针对较为复杂的流程和操作。想获取系统某些较为复杂的流程和操作过程，则现场观摩方法比较合适。对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户讲解，从而更直观的了解客户需求。（只是去观摩、看，不做）

（4）联合需求计划（JRP Joint Requirement Planning）是一个通过 高度组织的群体会议 来分析企业内的问题并获取需求的过程，各方参与（关键用户代表、系统分析师、开发团队代表），成本较高。为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈，它是联合应用开发（Joint Application Development，JAD）的一部分。（以会议的形式获取需求，成本高，获取需求有效）

JRP原则 ：JRP的的主要意图是收集需求，而不是对需求进行分析和验证，实施JRP应把握以下主要原则：

Ø 事先制定议题；

Ø 严格按照约定时间进行；

Ø 对议题逐一进行讨论；

Ø 会议记录

Ø 避免术语，尽量通俗易懂，利于交流；

Ø 开发方应该解决冲突的能力：极力避免与各方，尤其是甲方闹不愉快。就事论事，目的在于解决问题；

Ø 中场休息：本次会议一个上午，中午结束，并无中场休息

Ø 鼓励取得一致意见；

Ø 保证大家遵守会议决议：即会后应有相关跟进，对作出的决议，产生的问题等及时处理；

JRP一般步骤 ：

Ø 让与会者互相认识，力求会议在轻松气氛中进行；

Ø 列举问题，逐一讨论或按照议程，逐一进行；

Ø 鼓励大家对新系统畅想，形成清单；

Ø 对清单进行整理，明确优先级，评审、最后形成结论或结议；

当然今天的联合需求计划会议并没有完全按照这样的步骤，但精神是一致的，哪就是理清需求，解决问题，形成结论，为下一步工作做好铺垫，精神贯彻就行，具体做法可以加以裁剪。

（5） 情节串联板 ：通常是一系列图片，分析人员通过这些图片来讲故事，一般情况下，图片的顺序与活动事件的顺序一致，通过一系列图片来说明会发生什么，图片类型包括流程图、交互图、报表和记录结构，简而言之，情节串联板技术就是使用工具向用户说明（或演示），系统如何适合企业的需求，并表明系统将如何运转。

情节串联板的类型：被动式、主动式和交互式，复杂程度依次递增；

被动式是静态图片，系统分析师充当系统的角色进行讲解和演示；

主动式可以自动播放，描述系统典型场景等；

交互式可以让用户体验系统的行为，可以是抛弃式原型等；

情节串联板的制作：情节串联板应该易于创建和修改，不要企图做得太好太精美，情节串联板即不是原型，也不是真实事物演示。

（6）收集资料 ：把与系统有关的、对系统开发有益的信息收集起来。

（7） 参加业务实践 ：有效地发现问题的本质和寻找解决问题的办法。（自已去做）

（8） 阅读历史文档 ：对收集数据性的信息较为有用。

（9）抽样调查 ：降低成本。采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。抽样能够提高需求获取效率，但抽样往往是由系统分析师来抽的，所以会受到他的主观因素影响。（一个企业有3万人，不可能发全，统计也麻烦，可能抽了300人，各种群体均发一些，不是需求抽样哈。）

一般看丟采样抽样这些关键字后，一般要和数理统计联系在一起。

样本大小 ＝ɑ（启发式因子）*（可信度系数/可接受的错误）2 =ɑ（启发式因子）*（可信度系数/（1-可信度））2 注：其中 可信度系数 题目给出，可信度越高，可信息度系数越大； ɑ一般默认取 0.25；但也可以变。比如：已知每张订中可能有1张存在问题，则启发式因式=0.1*（1-0.1）

序号	需求获取方法	特点	优点	缺点
1	用户访谈	1 对 1-3，有代表性的用户，比较耗时，成本高。其形式包括结构化和非结构化两种	用户访谈具有良好灵活性、有较宽广的应用范围	难以安排时间、记录困难，访谈时间有限，对系统分析师要求较高，需要有足够领域知识；
2	问卷调查	多方参与，用户多，无法一一访谈。成本低。	针对很多用户，代价比较小、结果比较好整理与统计	不灵活
3	现场观摩	针对较为复杂的流程和操作。	直观了解客户需求
4	联合需求计划（JRP）	高度组织的群体会议，各方参与，成本高	用户积参与，提高开发效率、多方参与，讨论出需求，可以降低需求获取时间，特别适合需求不明确、有争议（歧义）的需求。	以会议的形式获取需求成本高
5	情节串联板	一系列图片，通过这些图片来讲故事	直观、生动、用户友好、交互性强，对用户界面起了早期评审作用	花费时间多，使获取需求速度大大降低
6	收集资料	把与系统有关的、对系统开发有益的信息收集起来。
7	参加业务实践	有效地发现问题的本质和寻找解决问题的办法。
8	阅读历史文档	对收集数据性的信息较为有用。
9	抽样调查（采样）	从种群中系统地选出有代表性的样本集的过程，样本数量=0.25*(可信度因子/错误率)2降低成本。	加快了数据收过程，提高了效率，降低了开发成本；采用技术采用了数据统计原理，减少数据收集偏差。采样技术不仅可能用于收集数据，还可以对人员进行采样，样本选得好，对数据可靠	采样技术正因为基于统计学原理，样本规模的确定依赖于期望的可信度和已有经验知识，很有大程度上取决于系统分析师的主观因素和个人的经验能力，对系统分析师要求较高