应用开发的思考2
我发现多数需求分析说明书编写得毫无价值,多数公司的做法是写完该需求说明书之后,就把它扔一边,埋头苦干写程序了.一方面这和公司对需求分析的认识不够有关,另一方面,也和需求分析编写方式不尽合理,以至它的价值难以体现有关.
软件程序,从最终的抽象意义而言,是计算机系统对自然语言的翻译.而需求分析充当了翻译任务的急先锋.很难想象,如果没有一份好的需求说明书,针对客户含糊不清的自然语言描述,开发者能做出一个符合要求的优秀软件.然而,什么是好的需求说明书?应具备什么样的特点?我认为好的需求说明书应有由如下三个阶段,经多次循环反馈而逐渐形成:
1 调研阶段:
客户和需求分析师讨论系统该具有的功能.客户希望系统能做什么,达到什么样的效果.需求分析师的责任是认真听取客户的原始言语,通过讨论,语言的提炼和客户达成共识,最终得到确切的需求--客户希望系统能做什么.这一过程运用的是自然语言,需求分析师必须具备良好的沟通能力,文字表达能力,并且必须具备客户领域内的相关业务知识,不使用用户不懂的计算机专业词汇.
参与人员:需求分析师,客户,系统设计师.
运用工具:自然语言.
阶段成果:调研记录书.
2 确定功能结构和设计系统原型:
需求分析师和系统设计师讨论客户的需求.需求分析师针对调研阶段的记录,逐点提出客户需求,并用uml的用例概念,和系统设计师进行讨论.系统设计师根据这些需求,运用他的技术,知识和经验,将之分解总结为系统的功能结构.(此处仅针对应用系统而言,对于其他系统,可能还要总结进程结构或部署结构)得到功能结构之后,系统设计师还要构建系统原型,该原型用于和客户进行更好的交流.
在这一阶段之后,由于得到了功能分解表和系统原型,需求分析师和系统设计师已明白系统的雏形,该成果将作为开发者和客户继续进行讨论的基础.
参与人员:需求分析师,系统设计师(或该设计师领导的相关团队).
运用工具:uml,构建原型的相关工具技术.
阶段成果:功能分解表,系统原型.(大致的业务流程图)
3 编写需求分析说明书
在参照功能分解表和系统原型的基础上,需求分析师和系统设计师编写系统的需求分析说明书.该需求分析说明书作为客户和系统开发者的桥梁,既表达了客户想要系统做什么的愿望,又反映了系统开发者针对此需求得到的努力成果(功能分解表和系统原型).通过该说明书,对系统具有的功能和最终可能的形态,客户和开发者达成共识.
有可能经过多次的1,2阶段的反复,最终才得到需求分析说明书.各阶段的成果应妥善保存.
参与人员:需求分析师,系统设计师,客户.
运用工具:自然语言,功能分解表,系统原型.
阶段成果:改进的功能分解表,系统原型,(业务流程图),需求分析说明书.
第1阶段,是开发者得到自然语言需求的阶段.该阶段的重要性不言而喻.
第2阶段,是需求分析编写的核心阶段.很多公司会有意无意忽略该阶段.确实,该阶段耗费的人力和时间挺多,但这个阶段决不能马虎的进行,甚至忽略.只有详尽的将自然语言翻译成功能需求表,并为此构建原型,开发者对系统究竟能做什么和未来该怎么做的认识才会逐渐加深.并且,对应的功能界面,能够让客户大致认识到最终的系统会是什么样子.他能够据此提出自己的满意度,修改或者增加需求.
我主张在构建功能分解表的时候,将界面的相关控件,字段,标签都一一列出,并且和原型的界面相对应.这样在功能分解表/需求分析说明书确定之后,开发者就有可能根据这些控件/字段/标签确立业务层的接口和数据库系统的表结构,减少了概要设计阶段所作的工作量.
以下是一个分解功能的例子:
功能:修改我的资料
功能简述:用户可以更新个人资料
界面控件:姓名文本框(输入姓名),邮箱文本框(输入邮箱),密码文本框(输入文本),确认密码文本框(输入确认密码),所属组别选择框 (输入所属组别),地址文本域(输入地址),备注文本域(输入备注).提交按钮.
界面标签(Label):根据界面控件描述进行配对.如姓名文本框的标签是"姓名".不再赘述.
界面:见图(修改我的资料)
只有经过详尽完备的1,2阶段后,我们才可能进行第3阶段,将1,2阶段的成果综合起来,和客户进一步讨论需求.客户可能会对功能分解不满意,对原型有异议.这样我们必须返回到1,2阶段,再次分解功能,修改原型.直到客户满意为止.
在这个基础上,我们才可能编写最终的需求说明分析书.我认为,严格按照上述流程进行编写的需求说明书,就是好的.它的特点总结如下:
1)经历过反复功能分解和原型构建.客户因原型而清楚认识到自己想要系统的形态,开发者经多次反馈明确了系统所具备的功能.
2)编写良好的功能分解表,能够帮助开发者进一步设计业务接口.
3)构建成型的原型,有助于开发者设计数据库系统.
4)*明确的业务流程图,能够协助开发者构建系统的业务流.
用户的需求永远在变化,没错.但如果我们按照上述步骤努力在分析阶段弄清楚客户的需求,以后的开发维护阶段就能将需求变更的代价降到最低.只有对事物认识越深刻,才越有可能认识到事物可能存在的变化.这条哲学法则在需求分析阶段同样适用.
经过以上讨论,我们就可以看到为什么多数公司的需求分析书难以达到预期要求.它们没有功能分解阶段,没有原型构建阶段,没有反馈认识再加深的阶段....这样的需求分析书,仅仅为构建而构建,对系统的开发毫无帮助.(我还看到过有人用三天写完一个系统的需求分析书)接踵下去的软件开发阶段,如何进行?这样做出来的软件,能好到哪里去?
一点浅见,贻笑方家. :-)
1 引言
1.1 编写目的
本说明书是客户与软件系统开发者的沟通桥梁.客户根据需求说明书提出需求,阐述系统能做什么.软件系统开发者根据此需求,阐述需求实现的功能与界面,并将之清晰明白的反映到本说明书中,以供客户审阅.
本说明书的预期读者为客户,业务需求分析人员,系统设计人员,项目管理人员,软件开发人员等系统开发的相干参与者.
1.2 项目背景
软件开发过程中无可避免的存在源码缺陷(以下简称BUG).在软件系统的开发维护阶段阶段,对BUG的修复管理工作必不可少.本系统提供了bug的管理功能.客户可应用本系统简单有效的管理BUG,以协助软件系统的开发维护工作.
1.3 定义,缩写词和符号
BUG:软件系统在功能或界面方面所产生的缺陷.
2 系统运行环境
2.1 硬件环境
2.1.1 一台586微机,建议CPU主频在500MHZ以上,内存大于512MB.
2.2 软件环境
2.2.1 WINDOWS 或类 LINUX 操作系统.该操作系统应能正常运行JAVA虚拟机.
2.2.2 安装IE6或FIREFOX1.5浏览器
2.2.3 安装J2SDK,要求版本在1.4以上.
2.2.4 安装TOMCAT或其他支持SERVLET 2.3 的WEB 服务器.
2.2.5 安装MYSQL数据库.要求版本在5.0以上.
3 系统用例说明
3.1 系统用例说明
3.1.1 用例名称:用户查看BUG列表
用例编号:1
用例说明:用户点击"查看我的BUG"标签,查看属于自己的BUG列表.或者点击"查看所有BUG"标签,查看所有BUG列表.并能根据自定 义的条件过滤器,查看符合特定条件的BUG.
前置条件:用户已登录系统.
3.1.2 用例名称:用户查看BUG详情
用例编号:2
用例说明:在BUG列表上存在HTML链接,用户点击该链接,可以看到BUG的详细情况.并且用户可以修改BUG的状态,修改时间.
前置条件:用户已登录系统
3.1.3 用例名称:用户增加新BUG
用例编号:3
用例说明:用户点击"增加新的BUG"界面,进入增加新BUG界面.可以增加新的BUG到系统.
前置条件:用户已登录系统
3.1.4 用例名称:用户管理BUG列表过滤器
用例编号:4
用例说明:用户可以增删改BUG条件过滤器.在BUG列表中,可以通过选取过滤器查看符合特定条件的BUG(请参照用例1).
前置条件:用户已登录系统.
3.1.5 用例名称:用户修改个人资料
用例编号:5
用例说明:用户可以修改个人资料,例如修改EMAIL,住址等.
前置条件:用户已登录系统.
3.1.6 用例名称:用户管理帐号
用例编号:6
用例说明:系统管理员可以增删改新的用户.
前置条件:用户已登录系统,且该用户必须是系统管理员.
3.1.7 用例名称:用户管理开发组
用例编号:7
用例说明:系统管理员可以增删改开发组.在增加新BUG界面,该组名用于划分BUG的归属.
前置条件:用户已登录系统,且该用户必须是系统管理员.
3.2 简单的用例图
见图:
4 系统功能分解
4.1 BUG管理
4.1.1 列出我的BUG
功能简述:以分页的列表方式列出指派给我的bug,可以选择某条记录进行修改,可以弹出框形式查看bug详情.
界面控件:序号Radio(可以选择某条记录),修改按钮(对记录进行修改)
界面标签(指Label):可选项,序号,概述,紧急程度,状态,所有人,发现时间.
HTML链接:序号
4.1.2 查看所有bug
功能简述:以分页的列表方式列出所有bug,可以选择某条记录进行修改,可以弹出框形式查看bug详情.可以按过滤器查看符合该 过滤器条件的bug.
界面控件:序号Radio(可以选择某条记录),修改按钮(对记录进行修改),过滤器选择框(选择某个过滤器).
界面标签(指Label):可选项,序号,概述,紧急程度,状态,所有人,发现时间.
HTML链接:序号
4.1.3 增加新的bug
功能简述:用户可以增加新的bug
界面控件:所属模块选择框(设定bug的所属模块),发现时间日期控件(确定bug的发现时间),发现者选择框(确定bug的发现者),状 态选择框(确定bug的状态),截止期限日期控件(确定bug的建议修改时间),指派给选择框(选择bug的所有人),描述文本域(输入 bug的描述),附件一(文件选择框),附件二(文件选择框),附件三(文件选择框).提交按钮.
界面标签(指Label):根据界面控件描述进行配对.如所属模块选择框的标签是"所属模块".不再赘述.
4.2 个人资料
4.2.1 修改我的资料
功能简述:用户可以更新个人资料
界面控件:姓名文本框(输入姓名),邮箱文本框(输入邮箱),密码文本框(输入文本),确认密码文本框(输入确认密码),所属组别选 择框(输入所属组别),地址文本域(输入地址),备注文本域(输入备注).提交按钮.
界面标签(Label):根据界面控件描述进行配对.如姓名文本框的标签是"姓名".不再赘述.
4.3 过滤器配置
4.3.1 列出过滤器
功能简述:列表方式列出该用户所增加的过滤器,可以选择某条记录进行修改,可以弹出框形式查看过滤器详情,可以删除某条记 录.
界面控件:序号Radio(可以选择某条记录),修改按钮(对记录进行修改),删除按钮(对某条记录进行删除)
界面标签(Label):可选项,序号,过滤器名称.
4.3.2 增加新过滤器
功能简述:用户可以增加新的过滤器.每个用户只能有最多10个过滤器.
界面控件:过滤器名称文本框(输入过滤器名称),状态选择框(选择状态),所属模块选择框(选择模块),发现者选择框(选择发现者 ),指派给选择框(选择bug的所有人),发现时间段时间选择框(选择发现起始时间),发现时间段时间选择框(选择发现终止时间 ),截止时间段时间选择框(选择截止起始时间),截止时间段时间选择框(选择截止终止时间).提交按钮.
界面标签(Label):根据界面控件描述进行配对.如过滤器名称文本框的标签是"过滤器名称".不再赘述.
4.4 系统管理
4.4.1 用户列表
功能简述:列表方式列出所有用户,可以选择某条记录进行修改,可以弹出框形式查看某用户详情,可以删除某条记录.
界面控件:序号Radio(可以选择某条记录),修改按钮(对记录进行修改),删除按钮(对某条记录进行删除)
界面标签(Label):可选项,登录ID,Email,电话,职位
4.4.2 增加新用户
功能简述:增加新用户
界面控件:登录ID文本框(输入用户帐号),姓名文本框(输入姓名),邮箱文本框(输入邮箱),密码文本框(输入文本),确认密码文本 框(输入确认密码),是否管理员选择框(设定是否管理员),地址文本域(输入地址),备注文本域(输入备注).提交按钮.
界面标签(Label):根据界面控件描述进行配对.如姓名文本框的标签是"姓名".不再赘述.
4.4.3 开发组列表
功能简述:列表方式列出所有开发组,可以选择某条记录进行修改,可以弹出框形式查看某记录详情,可以删除某条记录.
界面控件:序号Radio(可以选择某条记录),修改按钮(对记录进行修改),删除按钮(对某条记录进行删除)
界面标签(Label):可选项,开发组名称,描述.
4.4.4 增加新开发组
功能简述:增加新开发组.
界面控件:组名称文本框(输入开发组名称),备注文本域(输入备注).提交按钮.
界面标签(Label):组名称,备注.
4.4.5 日志列表
功能简述:分页列出系统日志.用户删除某条记录,可以弹出框形式查看某条记录详情.
界面控件:删除按钮.
界面标签(Label):可选项,日志时间,用户ID,操作概述.