首页 > 代码库 > 阅读笔记之我们应当怎样做需求分析

阅读笔记之我们应当怎样做需求分析

我们应当怎样做需求分析?

成功的软件项目都是一样的,失败的项目却各有各的问题。不过归根到底还是需求的问题。正是我们在需求分析过程存在的巨大隐患,最终导致了那么多项目的失败。

只有深入地去理解客户的业务,最后做出来的东西必然是客户满意的。当客户提出业务变更的时候,一定不能被客户牵着走。要从业务角度深入的去分析,他为什么提出变更,提得合不合理,我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时,客户是乐于接受的,变更也变得可控了。

客户提出的原始需求往往是不考虑技术实现,基于非计算机管理的操作模式提出来的。但我们作为技术人员,需求分析必须实事求是的、基于技术可以实现的角度去考虑。所以我们必须要基于技术实现去引导客户的需求。

软件项目的需求调研首先必须要进行角色分析,然后对不同的角色分别进行调研。

在敏捷开发过程中,需求分析阶段不可能解决所有的需求问题,因此在设计、开发、测试,直到最终交付客户,这整个过程都应当不停地用开发的成果与客户交流,及时获得反馈。只有这样才能及时纠正需求理解的偏差,保证项目的成功。

我们应当怎样做需求调研?

首先是双方初步认识,这个时候需要树立良好的职业威信,在交谈中进行详细角色分析,将与会各方代表对号入座,最后从宏观上制订目标与方案。

做好初步认识之后,接下来就要一一去拜访这些对应角色了。需求不是一蹴而就,在这漫长的时间里,我们需要依靠客户这个群体的帮助,一步一步掌握真实可靠的业务需求,这都需要有良好的客户关系。按照现在的软件运作理念,软件项目已经不是一锤子的买卖,而是长期的、持续不断的提供服务,这更需要我们与客户建立长期友好的关系。

然后就是研讨会的形式,有大型的会议,更多还是小型的会议研讨,更加深入的交流。

在与客户进行研讨之后,接下来就是内部进行研讨了,讨论客户的潜在需求等问题。

接下来的迭代贯穿于整个开发周期,反复进行。

然后进行与客户交流,挖掘潜在需求。

在挖掘潜在需求之后,就需要重要的建模来表示了。进行功能角色分析和用例图的创建,分析各个角色的作用和相应的操作需求。

与基层人员进行交流,分析业务的流程情况,进行用例说明,

用例说明时,在面向对象的时代,我们则是绘制行动图、状态图,以及编写用例说明来完成这部分工作。在这部分工作中,编写用例说明应当是最主要的工作,之后在一些关键部分辅之以行动图、状态图。需要将图形和文字描述进行结合表达。用例分析实质是需求人员的一份设计。既然是设计就可能出现偏差,最终偏离原始的需求。因此,将需求列表附在用例后面,便于日后的需求评审与确认。当每次需要升级时,则添加上新的需求,或对以往的需求进行更新。

用例图不能描述所有事件,比如报表类的,需要单独做报表分析描述。

用例模型将现实世界中连续的一个一个业务流程,按照场景划分到了一个一个的用例中。由于场景的出现,使得用例中的业务流程存在着高度的内聚性,从而成为了日后各种对象的雏形。同时,在用例分析中,又将那些存在于各个用例中的,相同或相近的业务操作提取出来,形成一个一个的子用例或扩展用例。

用例说明中对业务流程的描述,过早地将系统的整体流程,分散到了各个用例中了,丢失了对业务流程的整体描述。行动图(Active Diagram),比较类似于我们过去绘制的流程图,是UML中描述流程与分支的视图。对关键对象中流程中状态变化的描述,就需要状态图来进行描述。

在需求分析工作中,最后一项分析工作就是业务领域分析啦。业务领域分析,就是对需求分析中涉及到的业务实体,以及它们相互之间关联关系的分析。业务流程分析是对系统进行的一种动态的分析,分析的是那些行为,那些操作。因此,系统中应当有哪些实体,这些实体都有哪些属性,被赋予了哪些行为,它们之间的相互关系是怎样的,就成为了业务领域分析的重要内容,而业务领域分析也就成为了对系统进行的一种静态分析。

进行业务领域分析时,可以采用原文分析法,是在用例说明与流程分析的基础上进行的业务领域分析,是一项在需求研讨会后整理和分析需求的工作。

需求人员在开始一个新的管理系统的分析工作时,都有可能面临着一个全新的业务领域。在这个领域中,他们不可能一夜成为专家,也不必要成为专家。他们需要时间去学习领域知识,但这并不意味着学习所有的领域知识,而是与软件相关的领域知识。对领域模型的认识被延伸到了整个软件生命周期中,包括之后一次一次的升级完善。

我们做需求分析应当化繁为简,不必去拘泥于那些过程。寻找适合自己的,避免做过度分析和设计,这种思想也是敏捷开发的精髓。需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术,是设计,是实现,是架构师关注的内容,是需求人员最不擅长的方面,这也是非功能需求为什么常常被忽略的重要原因。正因为如此,架构师应当尽早参与到项目中,参与到需求分析中,尽早分析需求的技术可行性,尽早考虑性能、安全性、可靠性等非功能需求,尽早开始架构设计。

下一步就需要做需求列表了,又称之为需求跟踪表,是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计,而是以简短扼要的语句,以业务人员的口吻表述的,今后要开发的这个系统应当提供给他们的各项功能。

首先,需求列表不掺杂我们对业务需求的任何分析与设计,这是需求列表的核心,也是它存在的意义。其次,需求列表应当是站在业务人员的视角,对业务需求的简明扼要的描述。最后,需求列表也不是一步到位的,而是经过由粗到细逐渐整理形成的。

应当在需求分析阶段采用快速原型法,拿出实物,用实物与用户确认需求,

本着实事求是、切实可行的态度,去描述用户的业务需求。那些不可行的需求被摒弃,或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。从理论上讲,需求规格说明书分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求,是用于与用户签字确认业务需求;产品需求规格说明书是站在开发人员角度描述的系统业务需求,是指导开发人员完成设计与开发的技术性文档。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台,使用统一的语言来表达大家都清楚明白的概念。从这个角度将,需求规格说明书就应当是一个,不区分用户需求规格说明书和产品需求规格说明书。

最后需要的就是评审与签字确认会。需求评审会的主要目的就是确认需求,以便以此开始我们的设计开发工作。

?

需要掌握的内容上有:

1.在开发过程中,要有迭代的思想,同时要把迭代用于实践,不断的与客户进行交流反馈,及时获得反馈信息,来进行需求的更新。

2.用例图,活动图等常用uml图的绘制。这些图是描述系统各部分之间联系的表示图形,如果不能清晰的进行表示出来,那说明这个系统还有需要分析的地方。

3.用例说明,同用例图一样重要,用例图不能清楚的反应各个相互联系,还需要语言描述来更加清楚的表达。

4.快速原型法,首先做出主要部分,与用户进行交流,然后再进行下一步。

5.需求规格说明书,文档的书写是非常重要的一个方面,需要提高文档写作的能力。

阅读笔记之我们应当怎样做需求分析