查看完整版本: 单位需要做一个需求变更的系统（请大家支招）

单位需要做一个需求变更的系统（请大家支招）

单位项目组长趁现在时间比较闲，想让大家做一个简单的需求变更的“追踪记录系统”
希望借鉴UCM,CQ的思想，实现bug和业务需求的2种变更变化记录，做到
1、记录变更的原始的原因情况（邮件、文档、图片）
2、bug 和 需求 进行分离；对需求产生影响的bug 被需求引用；（下面都用bug举例子）
3、bug 分级别，工作流程根据实际需要，动态变更；
4、bug 分为 提交、修改方案确定（包括不修改、指定修改人、测试人）、修改、测试、关闭；bug流程

可提供若干备选路径；
5、如果bug A 产生 bug B，则 bug B 不记录（太多了记录不下来）；bug A 产生3个需求，则对应 3个不同的需求变动；

最终目的主要就是：一旦系统发生变更，可以不通过项目组长分配，这个变更请求就会发到负责这个模块

的开发人员那，开发人员修改后，通过这个系统誊写自己改变的内容，然后关闭这个需求变动。  项目组

长可以通过这个系统评定开发人员工作量，开发人员一旦离开单位，这些变更也可以被别人追踪。
仅仅是一个demo实现就可以了，不需要过多考虑权限、流程上的问题。hoho，我是这方面的门外汉，现在要写一个设计文档。想问问大家需要注意什么，rational哪个软件或者资料可以借鉴？

通过clearquest design可以实现。

可以借鉴RequisitePro对需求的管理上,它提供了动态维护需求的方法,并记录有需求变动的原因,范围等

用CQ

可以使用clearquest来定制流程，定义角色和bug状态。再做出状态迁移图。

建议:
你能够整理一个完整的需求(要到每一个细节),让后发动大家一起去完成这个项目.
有响应的没有?

用cq直接作就可以了！

需求管理可参考RequisitePro
需求变更管理可参考ClearQuest
从IBM DeveloperWorks网站可以免费下载它们的最新试用版。

[quote]原帖由 [i]听雨屋檐人[/i] 于 2007-5-17 10:46 发表
用cq直接作就可以了！ [/quote]

如果公司不大，不愿与买CQ呢？

其实需求的变更和缺陷跟踪很类似。你只要把需求的变更当作一种特殊的缺陷就可以。你可以使用开源的产品。比如bugzillar等等

RTH可以满足部分的功能

RTH可以满足部分的功能，不过工作流定制流程部分可能不可以。
你可以考虑一下ofbiz平台，想办法把RTH用java在ofbiz平台上实施。我大约3年前研究过ofbiz，它能满足你的所有的需求，而且现在ofbiz的workflow engine已经采用了shark的engine。商用defect tracking system（JIRA）就是基于ofbiz来实现的。
比较钦佩你们的领导，有这样的魄力。我们这里所有的事情都是我一个人在做。

用TD可以很容易实现你上面的要求。

9.5 需求变更控制
需求发生变更的起因主要有：
随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。
市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。
提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。
需求变更控制的目的： 如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”：
开发方与客户方达成“事不过三”的约定（符合中国人的习惯），即允许客户变更三次需求；如果客户第四此变更需求，开发方有权拒绝，除非客户愿意补偿开发方的损失。
如果事先没有“游戏规则”的话，开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时修改需求。