我们应当怎样做需求调研：需求捕获（下）
程序员文章站
2022-05-19 16:28:44
...
另一种就是客户压根儿没有想到的需求。也许你会提出这样的疑问，客户压根儿没有想到的需求我们还提出来做什么？这种压根儿没有想到的，实际是在业务需求阶段压根儿没有想到的，并不代表最终都没有想到。很多开发人员总在埋怨，说客户需求总是在软件项目的后期改来改去，为什么？客户并不是软件研发领域的专业人员。在业务需求阶段，由于没有可以展示和操作的实物，客户总是在空对空的凭空想象今后的软件应当做成什么样子。这就注定了客户会有很多自己压根儿没有想到的需求。那么为什么他们会在软件研发的后期提出来呢？因为软件研发的后期，客户能拿到那些研发成果的实物，去操作，可以看到。这时候，很多他们起初没有想到的需求就会源源不断地被提出来。但这时候，我们作为研发人员会很伤，我们付出的代价会很大。所以，以被动的态度去完成需求分析工作，必然会给项目研发带来巨大的风险。
如何解决这样的问题呢？首先，在需求分析阶段，虽然客户压根儿没有想到，但需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。我前面谈到，客户描述的最原始的需求是编写在需求列表中的，而经过需求分析人员的整理、分析与设计，经过用例分析、领域建模，最终形成产品需求说明书（或称为产品规格说明书）。从需求列表到产品需求说明书，这之间要经过一段长长的路，这段路就是我们的分析与设计，而不是简单的记录与编写文档。只有经过这样的过程，最后得到的才是高质量的需求分析，才能有效地指导软件研发，避免项目的风险。所以说，好的需求分析人员就是软件项目的司命，掌握着项目的生死。
我们再换一个角度来分析，客户之所以提不出需求，关键就在于他们没有可以展示和操作的实物，总是在空对空的凭空想象今后的软件应当做成什么样子。我们能否改变这样一种现状呢？于是，迭代式的需求分析与开发就出现了。我们先用最短的时间先做一个可以展示和操作的原型给客户看，让客户提一些意见。然后我们再在这个原型的基础上再多做一些，再给客户看。我们就这样一步一步推进，直到最终项目研发结束。采用这样的方式，最适合那些客户在项目初期提不出什么需求，也没用合适的参照物来进行需求分析的软件项目，特别是那些数据分析与决策类的软件项目。
接下来，我们再回到那些从客户嘴里说出的需求。在需求分析人员中，比较普遍的一个看法就是，只要是从客户嘴里说出来的，就一定是对的，我们必须照着做的，这种看法是不正确的。因为客户在软件开发方面是非专业的，所以他们在提出需求的时候往往会考虑不够周全。有一次，客户在提出来一系列业务操作以后，最后提出了一个统计报表的功能。这个统计报表是从前面这一系统操作数据中统计出来的，因此我们就对这些业务操作及其结果数据进行了一个详细的分析，最后发现根据这些数据统计出来的数据存在很多的问题，甚至可能出现相互矛盾的地方。随后我们与客户就这些问题进行了深入地探讨，最终客户不得不承认，他当初在设计这个报表的时候考虑不周全。在提出问题的同时，我们又提出了我们的解决方案，这是非常关键的。当我们提出我们的合理化建议以后，客户欣然接受了。同时，客户对我们这种非常专业的分析与处理过程大加赞赏，无形中也提高了我们在客户心目中的威望。
不仅如此，客户作为一个群体，客户与客户之前对同一问题也可能存在不同的看法，这特别突出地体现在那些多组织机构的管理系统中。因此，对于一些客户非正式的场合提出的需求我们要仔细甄别。一个比较可行的方法就是，先在一些非正式的场合单独跟客户聊，产生第一手资料，最后将这些需求在比较正式的场合，如各部门参加的业务讨论会、有用户代表参加的需求评审会、需求定稿签字确认会等等，以比较正式的形式讨论和确定下来。
最后，我不得不说，企业信息化管理实质就是一次改革，是企业摒弃手工操作，向信息化建设迈进的一次改革。既然是改革，就必须要改变过去不合理的管理流程，向更加合理和高效的管理流程迈进。因此，我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。如果需求人员能上到这样一个高度，我们的需求分析就进入了一个更加崭新的层面（关于需求分析中的流程分析，我们还会在后面详细探讨）。
我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会
（续）
如何解决这样的问题呢？首先，在需求分析阶段，虽然客户压根儿没有想到，但需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。我前面谈到，客户描述的最原始的需求是编写在需求列表中的，而经过需求分析人员的整理、分析与设计，经过用例分析、领域建模，最终形成产品需求说明书（或称为产品规格说明书）。从需求列表到产品需求说明书，这之间要经过一段长长的路，这段路就是我们的分析与设计，而不是简单的记录与编写文档。只有经过这样的过程，最后得到的才是高质量的需求分析，才能有效地指导软件研发，避免项目的风险。所以说，好的需求分析人员就是软件项目的司命，掌握着项目的生死。
我们再换一个角度来分析，客户之所以提不出需求，关键就在于他们没有可以展示和操作的实物，总是在空对空的凭空想象今后的软件应当做成什么样子。我们能否改变这样一种现状呢？于是，迭代式的需求分析与开发就出现了。我们先用最短的时间先做一个可以展示和操作的原型给客户看，让客户提一些意见。然后我们再在这个原型的基础上再多做一些，再给客户看。我们就这样一步一步推进，直到最终项目研发结束。采用这样的方式，最适合那些客户在项目初期提不出什么需求，也没用合适的参照物来进行需求分析的软件项目，特别是那些数据分析与决策类的软件项目。
接下来，我们再回到那些从客户嘴里说出的需求。在需求分析人员中，比较普遍的一个看法就是，只要是从客户嘴里说出来的，就一定是对的，我们必须照着做的，这种看法是不正确的。因为客户在软件开发方面是非专业的，所以他们在提出需求的时候往往会考虑不够周全。有一次，客户在提出来一系列业务操作以后，最后提出了一个统计报表的功能。这个统计报表是从前面这一系统操作数据中统计出来的，因此我们就对这些业务操作及其结果数据进行了一个详细的分析，最后发现根据这些数据统计出来的数据存在很多的问题，甚至可能出现相互矛盾的地方。随后我们与客户就这些问题进行了深入地探讨，最终客户不得不承认，他当初在设计这个报表的时候考虑不周全。在提出问题的同时，我们又提出了我们的解决方案，这是非常关键的。当我们提出我们的合理化建议以后，客户欣然接受了。同时，客户对我们这种非常专业的分析与处理过程大加赞赏，无形中也提高了我们在客户心目中的威望。
不仅如此，客户作为一个群体，客户与客户之前对同一问题也可能存在不同的看法，这特别突出地体现在那些多组织机构的管理系统中。因此，对于一些客户非正式的场合提出的需求我们要仔细甄别。一个比较可行的方法就是，先在一些非正式的场合单独跟客户聊，产生第一手资料，最后将这些需求在比较正式的场合，如各部门参加的业务讨论会、有用户代表参加的需求评审会、需求定稿签字确认会等等，以比较正式的形式讨论和确定下来。
最后，我不得不说，企业信息化管理实质就是一次改革，是企业摒弃手工操作，向信息化建设迈进的一次改革。既然是改革，就必须要改变过去不合理的管理流程，向更加合理和高效的管理流程迈进。因此，我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。如果需求人员能上到这样一个高度，我们的需求分析就进入了一个更加崭新的层面（关于需求分析中的流程分析，我们还会在后面详细探讨）。
我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会
（续）
上一篇： 我们应当怎样做需求调研：研讨会
下一篇： 【AngularJS系列2】scope