浏览 9708 次
锁定老帖子 主题:我们应当怎样做需求确认:需求规格说明书
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2012-04-30
最后修改:2012-05-01
从理论上讲,需求规格说明书(Requirement Specification)分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求,是用于与用户签字确认业务需求;产品需求规格说明书是站在开发人员角度描述的系统业务需求,是指导开发人员完成设计与开发的技术性文档。但是,我认为,用户需求规格说明书与产品需求规格说明书的差别并不大。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台,使用统一的语言(一种混合语言),来表达大家都清楚明白的概念。从这个角度将,需求规格说明书就应当是一个,不区分用户需求规格说明书和产品需求规格说明书。 那么需求规格说明书怎么写呢?不同的公司、不同的人、不同的项目,特别是在需求分析中采用不同的方法,写出来的需求规格说明书格式都是不一样的。在这里,我给大家一个,采用RUP统一建模的方式分析需求,编写需求规格说明书的模板,供大家参考。 1.引言 1.1 编写目的 如题,描述你编写这篇文档的目的和作用。但最关键的是,详细说明哪些人可以使用这篇文档,做什么。需求规格说明书是用来做什么的?毫无疑问,首先供用户与开发公司确认软件开发的业务需求、功能范围。其次呢,当然就是指导设计与开发人员设计开发系统。当然,还包括测试人员设计测试,技服人员编写用户手册,以及其它相关人员熟悉系统。描述这些,可以帮助读者确定,阅读这篇文档是否可以从中获得帮助。 1.2 业务背景 描述业务背景,是为了读者了解与该文档相关的人与事。你可以罗列与文档相关的各种事件,也可以描写与项目相关的企业现状、问题分析与解决思路,以及触发开发该项目的大背景、政策法规,等等。 1.3 项目目标(或任务概述) 就是项目能为用户带来什么利益,解决用户什么问题,或者说怎样才算项目成功。前面提到过,这部分对项目成功作用巨大。 1.4 参考资料 参考资料的名称、作者、版本、编写日期。 1.5 名词定义 没啥可说的,就是文档中可能使用的各种术语或名词的定义与约定,大家可以根据需要删减。 2.整体概述 这部分是对系统整体框架性地进行描述。 2.1 整体流程分析 绘制的整体行动图,及其对它的说明。 2.2 整体用例分析 绘制的整体用例图,以及对每个用例的用例说明。如果项目比较大,存在多个子系统,可以将用例图改为构件图,详细描述每个子系统及其相互的接口调用。 2.3 角色分析 一个用例图,描述系统中所有的角色及其相互关系。在随后的说明中,详细说明每个角色的定义及其作用。 这部分还可以根据项目需要编写其它的内容,如部署方案、网络设备、功能结构、软件架构、关键点难点技术方案,等等。 3.功能需求 3.1 功能模块(子系统) 一个一个描述系统中的每个功能模块(或子系统),即整体用例分析中的每个用例。这部分是需求规格说明书最主要的部分。 3.1.1 用例图 绘制该模块的用例图(详见《功能角色分析与用例图》)。 3.1.2 用例说明 对用例图中的每个用例编写用例说明(详见《用例说明》)。 3.1.3 领域模型 为用例绘制领域模型,并编写领域模型说明,对每个实体进行说明。对实体的说明包括对实体的定义、属性说明、行为说明、实体关系说明等等。如果实体间关系复杂,还要使用对象图说明实体关系的所有情况(如《领域驱动设计》中的描述)。 4.非功能需求 这里描述的是软件对非功能需求的一般要求,即整体设计原则。那些与具体功能相关的非功能需求应该放在用例说明的“非功能需求”部分(详见《非功能需求》)。 5.接口需求 如果项目涉及到与外部系统的接口,则编写这部分需求。 5.1 接口方案 详细描述采用什么体系结构与外部系统的接口。 5.2 接口定义 接口的中文名、英文名、功能描述、参数、返回值、使用者、使用频率,等等。 我们应当怎样做需求分析 我们应当怎样做需求调研:初识 我们应当怎样做需求调研:拜访 我们应当怎样做需求调研:研讨会 我们应当怎样做需求调研:需求研讨 我们应当怎样做需求调研:迭代 我们应当怎样做需求调研:需求捕获(上) 我们应当怎样做需求调研:需求捕获(下) 我们应当怎样做需求分析:功能角色分析与用例图 我们应当怎样做需求分析:业务流程分析(上) 我们应当怎样做需求分析:业务流程分析(下) 我们应当怎样做需求分析:用例说明 我们应当怎样做需求分析:查询报表分析 我们应当怎样做需求分析:子用例与扩展用例 我们应当怎样做需求分析:行动图和状态图 我们应当怎样做需求分析:业务领域分析 我们应当怎样做需求分析:原文分析法 我们应当怎样做需求分析:领域驱动设计 我们应当怎样做需求分析:非功能需求 我们应当怎样做需求确认:需求列表 我们应当怎样做需求确认:一个需求列表的实例 我们应当怎样做需求确认:快速原型法 我们应当怎样做需求确认:需求规格说明书 我们应当怎样做需求确认:评审与签字确认会 (续) 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |