2021-07-05 需求整理

  需求获取可能是软件开发中最困难、最关键、最易出错及最需要沟通交流的活动。我们对需求的获取往往有错误的认识：用户知道需求是什么，

我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，
但是实际上需求获取并不是想象的这样简单。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。
其次是对问题的理解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，
他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。
最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。
成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。

1、编写项目视图和范围文档

系统的需求包括四个不同的层次：业务需求、用户需求和功能需求、非功能性需求。业务需求说明了提供给用户新系统的最初利益,反映了组织机构或用户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

非功能性需求是用户对系统良好运作提出的期望，包括了易用性、反应速度、容错性、健壮性等等质量属性。需求获取就是根据系统业务需求去获得系统用户需求，然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文档就是从高层次上描述系统的业务需求，应该包括高层的产品业务目标，评估问题解决方案的商业和技术可行性,所有的使用实例和功能需求都必须遵从的标准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。项目相关人员对项目的目标和范围能达成共识,整个项目组都应该把注意力集中在项目目标和范围上。
　　
什么是需求分析？需求分析的任务、目的是什么？
答：需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。
需求分析的任务: (1)确定对系统的综合要求;(2)分析系统的数据要求;(3)导出系统的逻辑模型;(4)修正系统开发计划.
需求分析的目的: 准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。

什么是需求定义？

未来系统的目标，确定为了满足用户的需求系统必须做什么。
用《需求规格说明书》规范的形式准确地表达用户的需求。
软件需求分析的任务:(1)提出需求;(2)描述需求;(3)评审需求;

软件需求分析的步骤: (1)和用户交流,了解用户的需求；(2)分析和综合,建立软件的逻辑模型；(3)制定规格说明书和数据字典；(4)评审需求.

需求的分析的方法与切入点？（过程分析、对象分析；功能分析、对象分析、数据分析？）

答：需求分析的方法: (1)结构化方法；(2)面向对象方法；(3)面向控制方法；(4)面向数据方法；

需求分析的描述工具？

答：需求分析的描述工具由文字叙述与图表说明两部分组成，图形与表格属于一种世界性的技术语言，建议在需求分析文档中多用图表语言，少用自然语言。

描述工具包括：实体关系图，数据流图，用例图，活动图。

软件开发模型（瀑布模型、快速原型模型、增量模型、迭代模型）
增量模型：是遵循递增方式来进行软件开发的。
快速原型模型：在初步需求分析之后，马上向客户展示一个软件产品原型（样品）
迭代模型：指活动的多次重复。

2.用户分类
　系统用户在很多方面存在着差异，将用户群分类并归纳各自特点，并详细描述出它们的个性特点及任务状况，将有助于需求的获取和系统设计。
　不可能对所有的用户都进行需求获取，这样做时间不允许效果也不一定好，所以要识别出能够确定需求和了解业务流程的用户作为每类用户的代表。
　通常用户和开发人员不自觉的都有一种"我们和他们"的想法，产生一种对立关系，把彼此放在对立面，每一方都定义自己的"边界"，只想自己的利益而忽略对方的想法。他们通过文档、记录和对话来沟通，而不是作为一个合作的整体去识别和确定需求完成任务。实践证明这样的方法是不正确的，不会给双方带来一点益处,良好的沟通关系没有建立导致了误解和忽略重要的信息。只有当双方参与者都明白要成功自己需要什么，同时也知道要成功对方需要什么时，才能建立起一种合作关系。
　　为了建立合作关系通常采取一种组队的方式来获取需求，建立一个由用户代表和开发人员组成的联合小组作为需求获取的核心队伍。联合小组将负责识别需求、分析解决方案和协商分歧，小组成员可以采用会议、电子邮件、综合办公系统等方式进行交流，但交流时应注意以下原则：小组会议应该由中立方来组织和主持，用户和开发人员都要参加；交流预先要确定准备和参与的规则；议题要明确并覆盖所有关键点，但信息来源应该自由；交流目标要明确，并告知所有的成员。
　　
3.需求获取
最常见的需求获取方法是召开会议或者面谈，联合会议是范围广的、简便的讨论会，也是核心队伍成员之间一种很好的沟通方法，该会议通过紧密而集中的讨论得以将用户代表与开发人员间的合作伙伴关系付诸于实践并能由此拟出需求文档的底稿。联合会议的第一个议题就是系统的必要性和合理性，必须所有成员都同意系统是必要的而且合理的。接下来就可以讨论使用实例清单，清单可以打印成大纸挂在墙上、写在黑板上或做成演示材料。对每个清单合并去掉重复项，加上补充内容就可以得到一份总的清单，注意避免采用负面的"太差""不可行"去否定用户的想法，这些想法都应该保留下来作为被评议的清单项，这样保护了小组成员开放的思维。最后对清单进行讨论，会议成员必须检查每一个使用实例，在把它们纳入需求之前决定其是否在项目所定义的范围内，形成最终的需求报告。

在进行讨论时，也应该避免受不成熟的细节的影响，在对系统需求取得共识之前，用户能很容易地在一个报表或对话框中列出某些精确设计，如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制，应确保用户参与者将注意力集中在与所讨论的话题适合的抽象层上，重点就是讨论做什么而不是怎么做。这里有一点很重要就是要让用户理解对于某些功能的讨论并不意味着即将在系统中实现它，更不要做暗示或者承诺什么时候完成需求。在讨论之后，记下所讨论的条目，并请参与讨论的用户评论并更正，因为只有提供需求的人才能确定是否真正获取需求。当最后拿到了一份详细准确的需求报告书的时候，会议就算成功完成了。但是要清楚需求过程本身就是一个迭代的过程，在以后的过程活动中不可避免的将要修改和完善这份报告。
　　
所需要面对的实际情况就是如何在有限的时间内，通过沟通获取到对项目来说，最重要的信息。
首先，我们一定要沟通清楚，项目业务会涉及到哪些人？这些角色的参与，会牵涉到业务进行的哪部分？哪些角色是参与了我们业务的开展？
沟通过程中，我们一定要明确对方的最终诉求是什么？希望达到的愿景是什么？或者说希望解决的问题是什么？
我们的客户，其实并不太会直接说自己想要的目的是什么？大都说的是想要解决的问题是什么？想要达到怎样一个效果，这个时候，一定要把握好，这不一定是他的最终诉求，但是肯定是对方能够表达的最直接的痛点，我们需要做的就是顺藤摸瓜，了解对方诉求。
往往对方在给你诉说需要解决的问题时，通常都会顺带给你一个建议。记住：这个建议可以当作参考，但是不一定要当作最终的解决方法，因为这样做，并不是不行，但对系统来说，并不是最优化选择。