一 生活灿烂,望君多珍重
写下这篇牢骚小文之前,先简略描述一番在下目前的生存状态:上班时间:基本没事情做,在看各种自己感兴趣的技术,理论,写一些实践的代码,每天下午4点,必到楼下溜达15分钟,顺便喝杯咖啡;晚上,读书,写程序;周末,游玩,唱K,足球.
很开心的日子,对不?
美好和悲惨通常不分家.作为我们公司的软件程序员,我体会更深.更多的时候我在出差,那时候我不可能还在这个匆忙的城市度过自己的悠闲时光.我会深入祖国大后方,老老实实的蹲在某个小城市政府部门某栋小楼的某个办公室(有时候是机房),每天像销售/商务人员一样向官员了解他们需要的软件功能,然后快速开发部署以供他们使用,然后等待他们的诘责再要求,然后蹲回机房老老实实再改程序再部署再接受审判......循环周而复始.没有周末,没有闲暇,没有阳光,没有足球.
在一个备受对方刁难的项目实施过程中,我在某地过了四个月这样的日子.连续120天啊!
所以,在没有出差的日子(不出差也意味着我在公司会无所事事),我要尽情的享受生活!
二
这两年大家对spring的赞美之声一直不绝于耳,囿于工作性质和时间,我不能太深入的实践这个框架,去年只是买那本<j2ee development without ejb>来翻翻.Johnson 的论点确实深得我心,很多时候,用户其实不需要分布式,不需要更改数据库,不需要太过笨重的事务管理...(这些对用户来说都是透明的),他们关心的只是软件如何满足他们的需要,让他们能尽快的展开工作.为此,我们设计的系统就要开发周期短,易维护,灵活易增加功能,还要足够健壮......
什么?高灵活性,高可靠性,高健壮性?不是我们一直追求的目标么?你也许会这么反驳我.
问题是我们所鼓吹的跟我们所实际做的完全两样.在下早年曾对sun的pet store模型很感兴趣,把相关文献源码基本看了几遍.并以开发人员的身份实际参与了一个应用该模型进行开发的大型项目.该项目80-100人的规模,总历时5年.我在项目快要接近成功的时候离开了这个公司,回首这段开发经历,不胜其苦.应用这类模型进行开发,根本不可能做到所谓的高灵活性,易于维护性,易于提高生产力.每测试一个ejb就要等待15-20分钟启动ejb容器的滋味,你尝过吗?
这段时间写了一些spring的代码,很为spring的简略而惊奇.但spring就是银弹吗?在我正要在公司内部写一系列小文鼓吹spring之前,我这么问自己.我悲哀的回忆起,我的悲惨经历完全和技术无关.对,spring采用ioc,程序易于测试;spring包装了rmi,很方便的完成ejb的功能;spring提供了各著名持久框架的胶水,让ibatis,hibernate,jdo都能轻易集成到其中...
但是,我们原来的框架也不算太差啊?虽然由于前期规划不好,代码风格混乱不堪,水平参差不齐,但从架构组成,开发周期和运行性能而言,足以满足用户的实际需求了(系统的实际运行也证明了这点).那么,问题究竟在哪里?
三
我问自己.问题在于技术吗?也许是,销售和市场人员是这么抱怨的.但如果按照经典的软件工程过程来分析,是谁在获取需求?谁在编写需求说明书?回答:可能是销售人员和项目经理进行调研进而编写需求.谁在编写概要设计说明书?回答:没有,时间很紧,来不及写.谁在编写详细设计说明书?回答:没有...谁在写测试报告?回答:来不及写...谁负责部署,反馈信息?回答:具体到每个程序员......
别笑我.你也许认为,像我目前公司的这种情况,是很极端的例子,不可能公司不写任何文档,不进行任何测试的.好的,我告诉你,我们也有文档.我从公司服务器杂乱无章的文档中翻出了最初的需求文档,它的内容证明了它是不折不扣的垃圾.我也翻出了某一两个功能模块的文档(这还是我坚持要他们写的),内容和实际程序设计不止差了十万八千里.我找不到测试报告,也许这个系统真的没有测试.就这么拿出去部署应用了.程序员又怎能不辛苦?
一句老生常谈的话概括:管理问题.这是小公司屡见不鲜的毛病.
四
如果说这个例子过于极端,那么看看管理良好的公司所开发的项目?前文所述应用pet store进行开发的公司,是某大公司在本地的子公司(简称S).S的项目开发流程非常规范.专门的需求分析员,专门的系统设计师,专门的开发人员,专门的测试小组,测试人员,测试流程.....可以说一切资源人员配置都按照大软件工程的标准进行配置.结果呢?在开发那个80 * 5 * 12 人月的项目中,众人一样累得死去活来,晚上加班到12点是常有的事.
<人月神话>强调了一个问题:开发人员之间的交流成本非常昂贵.<人件>旗帜鲜明的论证(或憧憬):在软件开发中,人是最重要的.然而这两本书我认为理论性过强了,似乎也不符合我国的现实.我更喜欢这本小书:<软件工艺> 它说:做软件如打铁,就是手艺.将系统交给好的程序员,他自然能做出好的软件.好的程序员,应该需求分析,架构设计,编码各方面都有很深的造诣.... 这本小书真让我爱不释手.
我想,即使有银弹,枪法不同的人使用,恐怕效果也不一样.最好的小说,通常都反映了人本性最深邃的一面.同样,要设计最好的程序,必须要由最好的程序员来进行.这里程序员的范畴很广,在我的概念里,是把需求分析师,架构师,开发人员,测试人员都包含进去的.
一个好的程序员应该善于与人沟通交流,逻辑思维能力要强.有一定的文史哲基础,能将枯燥的事物用形象的比喻介绍给用户.有一定的文笔,能简洁流畅的编写需求分析书.
一个好的程序员应该精通系统架构.在了解需求之后能迅速将抽象的需求实际转换为相对具体的东西(如程序原型,uml用例图,甚至一些能说明情况的草图),以充当需求和程序架构的桥梁.用户根据这些成果表达/修改他们的需求,设计师根据这些成果进行框架的设计.
一个好的程序员应该精通各种框架技术,熟悉相应数据库(指应用开发而言),这样他才能有选择,有比较的确定用户的功能如何做,如何做得好.
一个好的程序员应该有一定的编码水平.起码不能写出太离谱的代码.
一个好的程序员还要懂得如何去测试,如何发现系统漏洞,甚至如何去攻击之.
......
我的水平也就到这里了,其他的我写不出.虽然不能孤立的撇开管理谈技术,但我觉得,假如一群好的程序员能够做到了自己的最好,最后却在公司窝囊的领导下搞砸了一个项目,那他们也足以问心无愧.
五
以下一系列小文是我在公司的无聊之作.刚开始我为了实际应用spring做了个小小的源码缺陷跟踪系统(Bug Tracking System),后来我发现这个程序虽然写出来了,但我根本无从评估它是否易用,是否易维护,是否符合别人的使用准则.我不得不启动界面让别人实际的看程序,最后获得"哦,这东西不适合我使用"的评价.老实说花了这么多时间获得这样的评价真让人沮丧.于是我想写几篇需求和设计文档,以使我和别人易于沟通,易于交流,而不用每次都要实际的启动程序.
原来,在经历整年的出差/开发/部署生涯中,我极端怀疑文档的意义.我想不可能在环境很紧迫的时候能做到一边更改代码一边更改文档.但我现在意识到,这是自己的认识偏差所导致,假如不把文档作为程序开发的约束,而作为需求沟通,设计思想交流的桥梁,恐怕它的意义会大大提高.
我很喜欢<理想国>,于是把下列小文尽量写成对话的形式.并且借用了司马相如作品的主人公,力求写得生动有趣.
我想和你交流的想法如下:
1)需求分析师如何和用户聊天以提炼需求.真实模拟国内调研时间短,需求难以明确的特点,并尽量少的在获取需求过程中使用计算机术语.
2)系统设计师如何和需求分析师分析需求,编写需求说明书.
3)系统设计师如何根据需求说明书撰写概要设计,确立程序开发所采用的框架.
4)实际开发的过程
5)测试(也许会省略,^_^)
6)其他......
例子：
A公司是一个软件开发公司,正同时开发多个软件项目,急切需要一个简单易用的源码缺陷跟踪系统进行bug的记录管理,但他们没有时间精力再开发这么一个系统.于是子虚先生------A公司的商务人员联系到B软件开发公司的乌有先生(需求分析师),打算让B公司为A开发一套源码缺陷跟踪系统.
以下为用户子虚和乌有的对话.子虚(以下简称子)提出了缺陷跟踪系统的初步需求,乌有(以下简称乌)力图弄清子虚的需求.以编制需求说明分析书以供系统开发.系统设计师Diego旁听,不发言.
子:我需要一个源码缺陷跟踪系统,使我可以存档和查看开发过程中出现的bug.
乌:我明白.这个系统一般叫源码缺陷跟踪系统(Bug Tracking System),有个叫Bugzilla的老牌软件可以满足你的需要.
子:我听说过,也了解过Bugzilla的相关情况.我觉得它的配置管理使用都过于麻烦,我觉得它应该尽量简单,简单到在10分钟之内可以配置,半天之内就能让小组的人学会使用.毕竟,在我的理解里,它只是个留言本性质的东东.
乌:好吧,假设它真的是个留言本性质的东东.那么你觉得,它是一个怎样的留言本?
子:嗯,比方说我是一个开发人员,我要查看今天系统发现了多少个bug,其中有那些是属于我的.
乌:明白.我是不是可以这么总结:系统要有bug的浏览界面,并且浏览界面能看到bug的名称,代号,bug的所有人,bug的状态(是否修复)
子:对,当然,时间日期也要能看到.
乌:OK,我补充这么一条,"在浏览界面尽可能详尽的列出bug的状态",对不?
子:完全正确.
(乌有简单总结客户需求如下:1.系统应存在bug列表界面,开发人员应能在列表界面上看到bug的状态(是否修复),bug的所有人,bug的名称,bug的发现时间,bug的建议修复时间.)
子:我发现系统上有我的bug,于是我就进去改我的bug.
乌:等等."你进去改bug",这句话怎么理解?
子:很难理解吗?
乌:没有,我只是试着使你的需求清晰.例如,在bug列表上,每个bug有个连接,你点这个连接,就进到bug的修改页面,于是你查看bug的详细信息.如果发现这个bug你已经修复,你就更改它的状态,然后退出这个bug的编辑界面,回到列表.对不?
子:完全正确.
(乌有继续总结需求如下:2.在bug列表上的每个bug都有一个html链接,开发人员点击这个链接就进到bug的详尽页面.这个页面列出了bug的状态,bug的所有人,bug的名称,发现时间,建议修复时间,bug的详细描述,bug的配图(以附件形式搭配,最多可搭配5张图片).开发人员可以修改bug的状态.)
(乌有突然笑了起来.)
乌:我不自觉就写下html链接这些子句.忘了问你,这是个BS系统吗?
(子虚很奇怪的看着乌有.)
子:这还用说?据我的了解,Bugzilla就是BS系统.
(乌有补充需求:3.这是个BS系统.)
子:当然,如果这个bug不是我的,我就无权查看并修改它了.
乌:明白.这是个权限控制的问题.不同的开发人员只能查看修改属于自己的bug.
子:你说到这个我才想起,不但开发人员只能查看修改自己的bug,bug本身应该也有权限,有分组.
乌:按照我的理解,我觉得应该是这样:不同的bug应该属于不同的模块.因为很可能公司同时开发着多个产品/项目,而这个系统要管理多个产品/项目的bug.
子:你总结得对.
(乌有记录需求:
4.不同的bug属于不同的模块,并且bug有"拥有者"属性,不是该bug的拥有者不能查看修改该bug.
5.不同的开发人员属于不同的模块.
)
子:我对5有异议.一个能力强的程序员可能同时参与几个项目的开发.
乌:那把bug和开发者联系起来就可以了?
子:我觉得是.
(乌有去掉了需求5)
子:嗯.现在我把我们开发人员的要求表述完了.接下来我要说说项目经理,测试人员的需求.
乌:继续.
子:系统应该有能添加bug的地方.
乌:用户可以添加一个新的bug,设定bug的简单描述,详细描述,bug的发现时间,建议修复时间,所属模块,添加人,所有人,修改人,状态.对不?
子:对.
(乌有记录需求:5.用户能够添加bug,设定bug的简单描述,详细描述,bug的发现时间,建议修复时间,所属模块,添加人,所有人,修改人,状态.)
(子虚满意的点点头)
子:嗯,我想我的要求已经表达得很清楚了.希望你们能尽快做出满足我要求的软件.
乌:(苦笑)按照我的过往经验,软件需求很少能做到真正清晰明了.在开发和维护期间,需求总会变更.
子:我和程序员已经打过好几次交道.我发现你们总是强调需求变更的重要性,以此作为软件开发进度缓慢,使用期间bug不断的借口.
乌:其实不是我们想以此作为借口.软件开发的本质,就是使相对不确定的东西变得真正确定.如果事物是完全不确定的,那我们也很难将之完全确定下来.
子:我确定我完全不明白你在说什么.这个调研会已经有两小时了吧?该结束了?
乌:等等,我将总结的东西给你看看,然后我今晚会写份需求分析书再给你确认确认.如果没什么大问题,我们的工程师就可以进行设计.
子:好,尽快.
(乌有的需求列表如下:
1.系统采用BS结构.(建议用java进行开发).
2.系统应存在bug列表界面,用户应能在列表界面上看到bug的状态(是否修复),bug的所有人,bug的名称,bug的发现时间,bug的建议修复时间,bug所属模块.)
3.在bug列表上的每个bug都有一个html链接,开发人员点击这个链接就进到bug的详尽页面.这个页面列出了bug的状态,bug的所有人,bug的名称,发现时间,建议修复时间,bug的详细描述,bug的配图(以附件形式搭配,最多可搭配5张图片).开发人员可以修改bug的状态.
4.不同的bug属于不同的模块,并且bug有"拥有者"属性,不是该bug的拥有者不能查看修改该bug.
5.用户能够添加bug,设定bug的简单描述,详细描述,bug的发现时间,建议修复时间,所属模块,添加人,所有人,修改人,状态.
)
子:不错.就这样.
乌:那明天见.
子:乌有明天见.Diego明天见.
乌有和Diego在讨论需求
乌:Diego,对这个系统的看法怎样?
D:嗯,我觉得我们遗漏了某些东西.查看bug列表时,是允许所有用户查看呢?还是经过系统验证的用户?
乌:.... 我觉得应该是经过系统验证的用户吧.
D:不一定.如果用户要登录之后才能看到bug列表,不方便.理想状况应该打开系统就能看到.
乌:但是你要考虑这么一个问题,假设bug按发现时间的顺序分页列出且bug的数量很多,很可能在第一页该用户看不到属于自己的bug,他就以为没有bug.假如我们要求他必须先登录,那我们就可以根据他的登录信息,列出他的bug的总数,bug的列表...等等.
D:我上当当网购书的时候,发现他们可以在不登录的情况下记下用户的浏览历史.我猜想这可以通过写用户的cookie实现.
乌:但我们公司的技术人员对这项技术不熟.我可不能凭猜测确定这个需求.
(虽然Diego跃跃欲试,但看到乌有先生坚决的神色,也只有妥协)
D:好吧,那我们就必须先登录,再看列表.
(于是乌有先生编写系统的用例如下:)
用例1:用户查看bug列表
1.用户点击"bug列表"标签,查看属于自己的bug列表.
前置条件:用户已登录系统.
(该用例获得一致通过)
(乌有先生编写系统用例2)
用例2:用户查看bug详细信息
1.用户点击bug列表中的某个bug,进入bug详细信息页面.
2.用户可以修改bug的状态,修改时间.
前置条件:用户已登录系统.
D:我发现,如果系统要求用户必须先登录才能查看bug,那么此时系统列出的bug都是他的,列出其他人的bug好像没什么必要.
乌:但是你要考虑,假设我是项目经理或者测试组组长,我想看到所有bug的列表.系统列出所有bug还是必要的.
D:解决办法有两种.1)访问系统的时候,根据某种逻辑(如时间,模块,bug性质)列出bug的列表.大家不用登录就可以看到.我称这个为"公共bug列表界面".用户一访问系统就能看到这个界面. 2)或者用户登录之后,点"列出所有bug"列表.当然,用户还可以构造自己的过滤器,以决定列出bug的条件.
乌:那么其实"列出所有bug"和"列出自己的bug"功能可以合并到一起.只不过默认状态列出属于自己的bug,简单的选取条件后又可以列出所有bug.
D:对,这种想法不错.而且,各自选择应该能汇总成一个名称,姑且称之为过滤器.用户可以建几个常用的过滤器以供快捷使用.
乌:好办法!
(于是乌有先生修改用例1如下:)
用例1:用户查看bug列表
1.用户点击"bug列表"标签,查看bug列表. (此时列出的所有bug属于该用户).
2.用户可以选择某些条件,系统根据这些条件列出相应的bug.如果什么条件都不选,系统列出所有bug.
前置条件:用户已登录系统.
(乌有先生继续编写用例如下)
用例3:用户添加bug
1.用户点选"添加bug"标签,进入添加bug界面.
2.用户可以添加bug,设定bug的简单描述,详细描述,bug的发现时间,建议修复时间,所属模块,添加人,所有人,修改人,状态.
用例4:用户增删改过滤器
1.用户点击"过滤器列表"标签,查看当前过滤器列表和当前所采用的过滤器.
2.用户可以增删改新的过滤器.
(乌有满意的伸伸懒腰)
乌:我想差不多了.这个系统确实不算太复杂.
D:我设计个原型,然后一起找子虚先生继续讨论.
乌:好的,加油!
源码缺陷跟踪系统(Bug Tracking System)的需求分析
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,操作概述.
Diego打算用html开发系统的原型,在开发期间,他发现经探讨了解的需求信息还存在不足,而且,一些潜在的需求如果不经讨论确定,下一步的开发工作就没办法进行.
他向自己提出了这些要求:
1.尽快开发系统原型并获得客户的通过.
BS程序通常通过开发html模型以确定用户需求,演示系统功能.演示让客户能够最快的看到"实际的系统".尽管系统的最终开发结果不可能和原型一模一样,然而原型确实能最大限度的帮助系统开发工作.
2.尽快确定显示界面所需的字段.
这些显示字段能够帮助数据库系统设计师确定系统的表结构.
3.在开发原型时对系统进行初步的功能分解.
这步工作是系统架构设计的基础,并且可以明确需求,协助需求分析设计书的编写.经验表明,精心划分的功能需求能使开发人员和客户更好的进行交流.
另外,Diego还问自己如下问题:
1.系统是否存在权限控制?如果存在,通过什么形式实现?
2.系统有哪些隐含而必不可少的功能(例如用户管理等管理模块)?这部分功能应该明确制定,并且和用户进行讨论.
Diego的原型和功能列表如下:
功能列表:
1 Bug管理
1.1 列出我的bug
功能简述:以分页的列表方式列出指派给我的bug,可以选择某条记录进行修改,可以弹出框形式查看bug详情.
界面控件:序号Radio(可以选择某条记录),修改按钮(对记录进行修改)
界面标签(指Label):可选项,序号,概述,紧急程度,状态,所有人,发现时间.
HTML链接:序号
界面:见图(列出我的bug)
1.2 查看所有bug
功能简述:以分页的列表方式列出所有bug,可以选择某条记录进行修改,可以弹出框形式查看bug详情.可以按过滤器查看符合该过滤器条件的bug.
界面控件:序号Radio(可以选择某条记录),修改按钮(对记录进行修改),过滤器选择框(选择某个过滤器).
界面标签(指Label):可选项,序号,概述,紧急程度,状态,所有人,发现时间.
HTML链接:序号
界面:见图(查看所有bug)
1.3 增加新的bug
功能简述:用户可以增加新的bug
界面控件:所属模块选择框(设定bug的所属模块),发现时间日期控件(确定bug的发现时间),发现者选择框(确定bug的发现者),状态选择框(确定bug的状态),截止期限日期控件(确定bug的建议修改时间),指派给选择框(选择bug的所有人),描述文本域(输入bug的描述),附件一(文件选择框),附件二(文件选择框),附件三(文件选择框).提交按钮.
界面标签(指Label):根据界面控件描述进行配对.如所属模块选择框的标签是"所属模块".不再赘述.
界面:见图(增加新的bug)
2 个人资料
2.1 修改我的资料
功能简述:用户可以更新个人资料
界面控件:姓名文本框(输入姓名),邮箱文本框(输入邮箱),密码文本框(输入文本),确认密码文本框(输入确认密码),所属组别选择框(输入所属组别),地址文本域(输入地址),备注文本域(输入备注).提交按钮.
界面标签(Label):根据界面控件描述进行配对.如姓名文本框的标签是"姓名".不再赘述.
界面:见图(修改我的资料)
3 过滤器配置
3.1 列出过滤器
功能简述:列表方式列出该用户所增加的过滤器,可以选择某条记录进行修改,可以弹出框形式查看过滤器详情,可以删除某条记录.
界面控件:序号Radio(可以选择某条记录),修改按钮(对记录进行修改),删除按钮(对某条记录进行删除)
界面标签(Label):可选项,序号,过滤器名称.
界面:见图(列出过滤器)
3.2 增加新过滤器
功能简述:用户可以增加新的过滤器.每个用户只能有最多10个过滤器.
界面控件:过滤器名称文本框(输入过滤器名称),状态选择框(选择状态),所属模块选择框(选择模块),发现者选择框(选择发现者),指派给选择框(选择bug的所有人),发现时间段时间选择框(选择发现起始时间),发现时间段时间选择框(选择发现终止时间),截止时间段时间选择框(选择截止起始时间),截止时间段时间选择框(选择截止终止时间).提交按钮.
界面标签(Label):根据界面控件描述进行配对.如过滤器名称文本框的标签是"过滤器名称".不再赘述.
界面:见图(增加新的过滤器)
权限体现的实现:
系统权限:
1)用户需要登录到系统,才能进行相关操作.
2)用户存在"非活动时限",如果超过一个时间定值用户不进行系统相应操作,则提示用户重新登录.
管理权限:
1)用户必须是管理员用户,才能进行系统的管理工作.
应用权限:
1)只有系统管理员能够删除bug.
在列出用户要求的功能列表和参考权限实现方式之后,Diego将系统隐含必不可少的功能整理如下
4 系统管理 (只有管理员才能操作该模块的所有功能)
4.1 用户列表
功能简述:列表方式列出所有用户,可以选择某条记录进行修改,可以弹出框形式查看某用户详情,可以删除某条记录.
界面控件:序号Radio(可以选择某条记录),修改按钮(对记录进行修改),删除按钮(对某条记录进行删除)
界面标签(Label):可选项,登录ID,Email,电话,职位
界面:见图(用户列表)
4.2 增加新用户
功能简述:增加新用户
界面控件:登录ID文本框(输入用户帐号),姓名文本框(输入姓名),邮箱文本框(输入邮箱),密码文本框(输入文本),确认密码文本框(输入确认密码),是否管理员选择框(设定是否管理员),地址文本域(输入地址),备注文本域(输入备注).提交按钮.
界面标签(Label):根据界面控件描述进行配对.如姓名文本框的标签是"姓名".不再赘述.
界面:见图(增加新用户)
4.3 开发组列表
功能简述:列表方式列出所有开发组,可以选择某条记录进行修改,可以弹出框形式查看某记录详情,可以删除某条记录.
界面控件:序号Radio(可以选择某条记录),修改按钮(对记录进行修改),删除按钮(对某条记录进行删除)
界面标签(Label):可选项,开发组名称,描述.
界面:见图(开发组列表)
4.4 增加新开发组
功能简述:增加新开发组.
界面控件:组名称文本框(输入开发组名称),备注文本域(输入备注).提交按钮.
界面标签(Label):组名称,备注.
界面:见图(增加新开发组)
4.5 日志列表
功能简述:分页列出系统日志.用户删除某条记录,可以弹出框形式查看某条记录详情.
界面控件:删除按钮.
界面标签(Label):可选项,日志时间,用户ID,操作概述.
界面:见图(日志列表)
Diego将该原型交给乌有,乌有将据此编写需求分析说明书,和子虚先生作进一步的交流.
应用开发的思考2
我发现多数需求分析说明书编写得毫无价值,多数公司的做法是写完该需求说明书之后,就把它扔一边,埋头苦干写程序了.一方面这和公司对需求分析的认识不够有关,另一方面,也和需求分析编写方式不尽合理,以至它的价值难以体现有关.
软件程序,从最终的抽象意义而言,是计算机系统对自然语言的翻译.而需求分析充当了翻译任务的急先锋.很难想象,如果没有一份好的需求说明书,针对客户含糊不清的自然语言描述,开发者能做出一个符合要求的优秀软件.然而,什么是好的需求说明书?应具备什么样的特点?我认为好的需求说明书应有由如下三个阶段,经多次循环反馈而逐渐形成:
1 调研阶段:
客户和需求分析师讨论系统该具有的功能.客户希望系统能做什么,达到什么样的效果.需求分析师的责任是认真听取客户的原始言语,通过讨论,语言的提炼和客户达成共识,最终得到确切的需求--客户希望系统能做什么.这一过程运用的是自然语言,需求分析师必须具备良好的沟通能力,文字表达能力,并且必须具备客户领域内的相关业务知识,不使用用户不懂的计算机专业词汇.
参与人员:需求分析师,客户,系统设计师.
运用工具:自然语言.
阶段成果:调研记录书.
2 确定功能结构和设计系统原型:
需求分析师和系统设计师讨论客户的需求.需求分析师针对调研阶段的记录,逐点提出客户需求,并用uml的用例概念,和系统设计师进行讨论.系统设计师根据这些需求,运用他的技术,知识和经验,将之分解总结为系统的功能结构.(此处仅针对应用系统而言,对于其他系统,可能还要总结进程结构或部署结构)得到功能结构之后,系统设计师还要构建系统原型,该原型用于和客户进行更好的交流.
在这一阶段之后,由于得到了功能分解表和系统原型,需求分析师和系统设计师已明白系统的雏形,该成果将作为开发者和客户继续进行讨论的基础.
参与人员:需求分析师,系统设计师(或该设计师领导的相关团队).
运用工具:uml,构建原型的相关工具技术.
阶段成果:功能分解表,系统原型.(大致的业务流程图)
3 编写需求分析说明书
在参照功能分解表和系统原型的基础上,需求分析师和系统设计师编写系统的需求分析说明书.该需求分析说明书作为客户和系统开发者的桥梁,既表达了客户想要系统做什么的愿望,又反映了系统开发者针对此需求得到的努力成果(功能分解表和系统原型).通过该说明书,对系统具有的功能和最终可能的形态,客户和开发者达成共识.
有可能经过多次的1,2阶段的反复,最终才得到需求分析说明书.各阶段的成果应妥善保存.
参与人员:需求分析师,系统设计师,客户.
运用工具:自然语言,功能分解表,系统原型.
阶段成果:改进的功能分解表,系统原型,(业务流程图),需求分析说明书.
第1阶段,是开发者得到自然语言需求的阶段.该阶段的重要性不言而喻.
第2阶段,是需求分析编写的核心阶段.很多公司会有意无意忽略该阶段.确实,该阶段耗费的人力和时间挺多,但这个阶段决不能马虎的进行,甚至忽略.只有详尽的将自然语言翻译成功能需求表,并为此构建原型,开发者对系统究竟能做什么和未来该怎么做的认识才会逐渐加深.并且,对应的功能界面,能够让客户大致认识到最终的系统会是什么样子.他能够据此提出自己的满意度,修改或者增加需求.
我主张在构建功能分解表的时候,将界面的相关控件,字段,标签都一一列出,并且和原型的界面相对应.这样在功能分解表/需求分析说明书确定之后,开发者就有可能根据这些控件/字段/标签确立业务层的接口和数据库系统的表结构,减少了概要设计阶段所作的工作量.
以下是一个分解功能的例子:
功能:修改我的资料
功能简述:用户可以更新个人资料
界面控件:姓名文本框(输入姓名),邮箱文本框(输入邮箱),密码文本框(输入文本),确认密码文本框(输入确认密码),所属组别选择框 (输入所属组别),地址文本域(输入地址),备注文本域(输入备注).提交按钮.
界面标签(Label):根据界面控件描述进行配对.如姓名文本框的标签是"姓名".不再赘述.
界面:见图(修改我的资料)
只有经过详尽完备的1,2阶段后,我们才可能进行第3阶段,将1,2阶段的成果综合起来,和客户进一步讨论需求.客户可能会对功能分解不满意,对原型有异议.这样我们必须返回到1,2阶段,再次分解功能,修改原型.直到客户满意为止.
在这个基础上,我们才可能编写最终的需求说明分析书.我认为,严格按照上述流程进行编写的需求说明书,就是好的.它的特点总结如下:
1)经历过反复功能分解和原型构建.客户因原型而清楚认识到自己想要系统的形态,开发者经多次反馈明确了系统所具备的功能.
2)编写良好的功能分解表,能够帮助开发者进一步设计业务接口.
3)构建成型的原型,有助于开发者设计数据库系统.
4)*明确的业务流程图,能够协助开发者构建系统的业务流.
用户的需求永远在变化,没错.但如果我们按照上述步骤努力在分析阶段弄清楚客户的需求,以后的开发维护阶段就能将需求变更的代价降到最低.只有对事物认识越深刻,才越有可能认识到事物可能存在的变化.这条哲学法则在需求分析阶段同样适用.
经过以上讨论,我们就可以看到为什么多数公司的需求分析书难以达到预期要求.它们没有功能分解阶段,没有原型构建阶段,没有反馈认识再加深的阶段....这样的需求分析书,仅仅为构建而构建,对系统的开发毫无帮助.(我还看到过有人用三天写完一个系统的需求分析书)接踵下去的软件开发阶段,如何进行?这样做出来的软件,能好到哪里去?
浙公网安备 33010602011771号