《软件需求与分析》需要掌握的内容
今天阅读了建民老师课件上提供的关于如何做需求分析的博文,下面把这篇博文的
一些重点总结一下。
需求分析既是一份体力活儿,更是一份技术活儿,它既是人际交往的艺术,又是逻辑分析与严密思考的产物。
作者给我们提出了几个例子
第一个故事讲的是发生在东软的事情,由于对客户的需求了解不够透彻最终导致了
整个这个项目组的所有成员都离开了东软,这就是不了解客户的需求。
深入地去理解客户的业务,进而想到客户的心坎儿上去,最后做出来的东西必然是客户满意的。
当客户提出业务变更的时候,我们一定不能被客户牵着走,客户说啥就是啥。我们要从业务角度深入的去分析,
他为什么提出变更,提得合不合理,我有没有更合理的方案满足这个需求。
当我们提出更加合理的方案时,客户是乐于接受的,变更也变得可控了。
第二个故事告诉我们做需求就应当首先理解现有的管理模式,然后站在信息化管理的角度去审视他们的管理模式是否合理,
最后一步一步地去引导他们按照更加合理的方式去操作与管理。
客户提出的要求是根据他们心中的理想但是他们并不是技术人员,所以他们没有考虑到需求分析必须实事求是的、基于技术可以实现的角度去考虑。
需求分析不是一蹴而就的,它应当贯穿整个开发周期,不断的分析确认的过程。
本学期软件需求与分析应该掌握需求调研、需求分析、需求确认,需求调研是需求分析最重要的一环,也最集中地体现了需求分析的特点——既是一份体力活儿,
更是一份技术活儿。它既要求我们具有一种理解能力、设计能力,更要求我们具有一种与人交往、沟通的能力。
我们对客户提出的需求进行深入理解以后,运用我们专业知识,提出比客户的原始需求更加合理、可操作的解决方案,让客户感觉你说的正是他们想要的。
业务研讨会是重要的,但同时又是灵活的,没有一个定式,甚至有时都不能称之为会议。项目经理需要根据实际情况,合理地与客户组织研讨会。但不论怎样组织,必须注意两点:有效抑制个性化差异、分模块组织专项研讨会。
需求分析不是一种简单的你说我记的收集活动,而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发,才能保证需求的正确与变更的可控。
在第一次的需求分析阶段,我们在一段时期内需要与客户进行反复地讨论,这个过程往往是这样一个反复循环的过程:需求捕获->需求整理->需求验证->再需求捕获••••••
需求分析就是按照这样的过程,每次多理解一些,再多理解一些,更多理解一些,逐渐深入的过程。每深入一步,我们的软件就更接近客户的满意。
企业信息化管理实质就是一次改革,是企业摒弃手工操作,向信息化建设迈进的一次改革。既然是改革,就必须要改变过去不合理的管理流程,向更加合理和高效的管理流程迈进。因此,我们的需求捕获最初是源于企业现有的操作流程,但当我们深入理解了客户现有的操作流程以后,应当有意识地发现那些不合理的部分,并最终提出更加合理、更适于信息化管理的流程。如果需求人员能上到这样一个高度,我们的需求分析就进入了一个更加崭新的层面。
需求分析:功能角色分析与用例图、业务流程分析、用例说明、查询报表分析、子用例与扩展用例、行动图与状态图、业务领域分析、原文分析法、领域驱动设计、
非功能需求。
需求确认:需求列表、一个需求列表的实例、快速原型法、需求规格说明书、评审与签字确认会。