软件需求最佳实践
需求建模与分析篇
需求分析基本遵循三个方向,依次是:流程,对象以及关系,用例(操作容器);
流程对应的是跨职能流程图以及活动图,对于活动图,实在是没有感到有什么优势可言;但是对于流程图究竟要细化到什么程度?只要是不影响泳道的变更就可以作为一个节点处理,这个还有待考证;
对象以及关系,作者首先推荐的是类图,但是对于类图其实使用在设计阶段,作为需求分析阶段拿了一张类图给客户看,给客户讲解你所识别出来的类?如果是给架构师以及开发团队来看还是有点意义,但是对于国内项目很多时候时间很紧急,你搞出这一套花活是在玩儿吗?
用例,则是通过用例图来进行得,用例图首先通过框线"限定了"系统的范围,系统就是定义这些操作;其次用例图将角色和操作联系了起来(谁将会做什么事),这一点关系是在流程(流程图的粒度比较粗,不影响泳道的节点会被合并为一个节点)以及对象关系中无法体现出来的。用例图中的扩展(extend)意思是该"子流程"是可选的;包含(include)意思是对某一个用例的一部分抽出来作为一个"用例片"之所以要这样做是为了描述多个用例共享一个用例片,注意,extend以及include的内容都不是用例;都是从属于用例,用来对用例进行补充和说明的。在用例图中国,每一个椭圆都是一个用例(而不是一个操作)。用例的角色也有继承的价值,可以避免线条的重叠,继承者同时也继承了和用例的关系。
用例完成后,周期一的内容就结束了,周期一的职责就是在宏观上面把握需求,接下来就是周期二,周期二的职责及时来系统周期一的成果物;
细化,就需要使用原型来进行落地,有一点作者强调:就是原型的本质是解释需求内容。
数据窗口:对于数据的所属进行划分,字段属于库存类,发货类…共同类;这样可以保证在未来需求变更进行修改的时候能够考虑影响范围;我想到的,是不是把每一个字段都应用在那些业务中进行描述跟踪(比如在数据库设计文档中的"备注"一列进行说明);
数据字典:对于数据类型以及内容(规则)进行描述;
决策树:决策树是形式,对于多分支的需求逻辑,使用决策树可以更加清晰、形象地描述;
事件流的分析,这个基本和中广核的早期的需求文档是一致的,包括基本的事件流(前置条件,后置条件,注意前置和后置两者可验证的,而且,并不是总有的),备选事件流(用例图中的"extend"部分),异常处理。
接口,描述清楚"使用者","内容格式","约束"。
书看到这里我一直在想一个问题:需求分析的本质是什么?工具的纷繁很容易让人陷入"需求模式",需求分析过程的本质就是获知需求,并且和客户进行确认,进行需求重构;一切的工具的目标都是如此;这里强调一下需求重构,一个需求分析人员最大的价值在于梳理需求,并且进行重构改善,能够利用工具将需求间关系、缺陷、漏洞发现,并进行改善重组。