见仁见智

用程序员的眼光看世界

一 子虚和乌有的对话 (如何获取源码缺陷跟踪系统的需求)

    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明天见.
   
   
   

posted on 2007-03-28 11:55 Diego 阅读(1421) 评论(2)  编辑  收藏 所属分类: 需求分析/系统设计

评论

# re: 一 子虚和乌有的对话 (如何获取源码缺陷跟踪系统的需求) 2007-03-28 15:10 小陆

这就是甲方和乙方最大的冲突。业务工作经常是人工的,是目标导向的,为了达到一个目标,手段是可以选择的。而软件开发却是精确的,一定要把流程确定下来。
“其实不是我们想以此作为借口.软件开发的本质,就是使相对不确定的东西变得真正确定.如果事物是完全不确定的,那我们也很难将之完全确定下来.”
软件开发不能这样干的,你没有办法等到“确定下来”,你必须要在只知道几个重要需求的情况下开始工作,其他的需求和细节只能在开发过程中去弄清楚。
需求分析的重点在于分析用户的目标是什么,操作流程其次,一下子就精确到界面更是不可行的。
  回复  更多评论   

# re: 一 子虚和乌有的对话 (如何获取源码缺陷跟踪系统的需求) 2007-03-28 15:26 Diego

@小陆

谨受教.:-)

写这几篇小文的目的,是想把几年痛苦的开发经验总结总结,以期从中得到一些启示,指导自己新工作,和朋友交流讨论....等等.

我其实应该先把序放上去,以说明我怎样打算描述如何从一个不确定的需求以得到设计,得到软件,由于需求变更而引起系统变更,最后可以看出该架构是否合理?代码是否健壮?....所以在写子虚和乌有先生对话的时候,我尽量采用"原生态"写法,你可以发现很多时候我们其实就是这么开始,在一无所知中开始开发软件的.呵呵.

一起交流,一起进步 :)  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航: