我们应当怎样做需求确认:一个需求列表的实例

现在我举一个具体实例来看看需求列表是怎样编写的吧。这是一个公司内部的评审系统,它分为制订评审计划、执行评审、制作评审报告与问题跟踪四部分。经过初次与评审人员的业务讨论以后,我们整理出这样一个需求列表:

1.评审发起人填写一份评审计划,详细记录评审时间、评审内容、评审者、评审地点,制订评审组长,并预计评审工作量,发起一个评审任务。
2.评审者在收到邮件后,进入评审任务中,对评审内容进行评审,同时填写并提交各自的评审意见。
3.评审组长汇总所有的评审意见,并在评审会上依次过所有的评审意见,对评审意见进行修改或删除,填写问题跟踪,形成此次评审会上最终的评审意见及问题跟踪表。
4.评审组长制作评审报告,并形成评审结论,以邮件的形式通知所有评审者。
5.所有评审者对评审报告进行回复意见,如果都选择同意,评审组长关闭此次评审。
6.评审组长跟踪所有问题,并可以依次关闭每个问题。

当然,在这个需求列表中,客户提出了一些名词,比如评审计划、评审意见、评审组长等。我们在整理需求列表的同时,应当注意整理这些名称,弄清它的内涵外延,以及它们相互之间的关系、作用。这将为我们后面的领域模型分析提供素材。毫无疑问,这样的需求列表过于粗略。因而在后面的业务讨论中,我们逐项对它们进行了细化:

1.评审发起人填写一份评审计划,详细记录评审时间、评审内容、评审者、评审地点,制订评审组长,并预计评审工作量,发起一个评审任务。
1.1 评审时间应当分为数个阶段分别制订时间计划,如评审准备、评审会议、评审报告;
1.2 评审内容应当可以上传数个文件,分别描述文件的内容、作者、编写日期、版本号,供评审者下载与查看;
1.3 填写评审者时,选择一个评审者为评审组长,评审发起人不能是评审组长;
1.4 评审地点与预计评审工作量只需直接填写;

在我们后面的用例分析中,我们对这段需求列表进行了大量的分析设计。但这些都是设计与实现,它们会出现在后面的用例分析及其模型中,却不应出现在需求列表中。在后来的升级开发中,客户又提出了发邮件通知的功能。将该功能描述出来,并添加到需求列表中:

1.5 评审计划提交以后,以邮件的形式发送给每个评审者,通知该评审任务。

有了这样的需求列表,当需求分析工作完成时,我们将一项一项检查用例模型是否满足需求列表的内容;当软件开发完成时,我们将一项一项检查软件功能是否满足需求列表的内容;当用户验收时,我们同样使用需求列表,一项一项检查我们的软件是否满足用户需求。

[url=http://fangang.iteye.com/blog/1345099]我们应当怎样做需求分析[/url]
[url=http://fangang.iteye.com/blog/1345283]我们应当怎样做需求调研:初识[/url]
[url=http://fangang.iteye.com/blog/1392009]我们应当怎样做需求调研:拜访[/url]
[url=http://fangang.iteye.com/blog/1394911]我们应当怎样做需求调研:研讨会[/url]
[url=http://fangang.iteye.com/blog/1396971]我们应当怎样做需求调研:需求研讨[/url]
[url=http://fangang.iteye.com/blog/1403342]我们应当怎样做需求调研:迭代[/url]
[url=http://fangang.iteye.com/blog/1474362]我们应当怎样做需求调研:需求捕获(上)[/url]
[url=http://fangang.iteye.com/blog/1474368]我们应当怎样做需求调研:需求捕获(下)[/url]
[url=http://fangang.iteye.com/blog/1481975]我们应当怎样做需求分析:功能角色分析与用例图[/url]
[url=http://fangang.iteye.com/blog/1481996]我们应当怎样做需求分析:业务流程分析(上)[/url]
[url=http://fangang.iteye.com/blog/1482008]我们应当怎样做需求分析:业务流程分析(下)[/url]
[url=http://fangang.iteye.com/blog/1482165]我们应当怎样做需求分析:用例说明[/url]
[url=http://fangang.iteye.com/blog/1482171]我们应当怎样做需求分析:查询报表分析[/url]
[url=http://fangang.iteye.com/blog/1483063]我们应当怎样做需求分析:子用例与扩展用例[/url]
[url=http://fangang.iteye.com/blog/1483082]我们应当怎样做需求分析:行动图和状态图[/url]
[url=http://fangang.iteye.com/blog/1487102]我们应当怎样做需求分析:业务领域分析[/url]
[url=http://fangang.iteye.com/blog/1488291]我们应当怎样做需求分析:原文分析法[/url]
[url=http://fangang.iteye.com/blog/1493720]我们应当怎样做需求分析:领域驱动设计[/url]
[url=http://fangang.iteye.com/blog/1497941]我们应当怎样做需求分析:非功能需求[/url]
[url=http://fangang.iteye.com/blog/1502857]我们应当怎样做需求确认:需求列表[/url]
[url=http://fangang.iteye.com/blog/1502858]我们应当怎样做需求确认:一个需求列表的实例[/url]
[url=http://fangang.iteye.com/blog/1504123]我们应当怎样做需求确认:快速原型法[/url]
[url=http://fangang.iteye.com/blog/1505381]我们应当怎样做需求确认:需求规格说明书[/url]
[url=http://fangang.iteye.com/blog/1506403]我们应当怎样做需求确认:评审与签字确认会[/url]

(续)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值