请教：怎样确保功能点没有遗漏
　

---

由需求分析提炼功能点列表，对它的完整性怎样把关？

 回复: 请教：怎样确保功能点没有遗漏
　

---

就当聊天！

 我们的人员所做的已经不止这些了
　

---

他们不仅跟客户聊天，还陪客户出去旅游，陪客户泡吧，陪客户打麻将（一般都是输），这样即使有时候在软件完成后，我们自己都发现有功能点遗漏他们还是会签字/打款。
但我觉的应该有规范的方法防止这种情况一再出现！

几陪阿

变更需求，添加功能点。
做好变更控制，
让您的软件架构强壮一点。

 回复: 呵呵
　

---

胡说！我们是正规国营企业，哪能搞这些歪门邪道的东西？！

如果你用UML和RUP,是这样做的:
功能点可以认为是系统用例,系统用例模型是从业务用例模型和业务对象模型中提取出来的.业务对象模型提供对每个业务用例的实现.每个业务用例是一个业务的需求,解决一个业务问题或提供一个业务机遇.
功能点的完整性实际上就是保证用户确认的业务问题得到解决,业务机遇得到获取的满足的程度.
需求规格说明书应该列出所有的系统用例,如果这些系统用例达到了上述要求,这个用例列表就是要"提炼"的功能点列表.

是不是在得到用户签字的需求规格说明书后还得进行需求分析，得到一个书面的东西，里面包含系统用例表；
我想在需求书里描述的仅是业务用例吧

那里的规范算官方？哪能找到这本书啊

如果整个项目够大,需求获取本身就可以当作一个项目签单来做,
需求分析主要就是业务分析,也就是与客户(代表)一起建立业务用例模型;
需求获取中除了业务分析(需求分析)之外,还有业务设计,流程自动化,领域建模(不是每个项目都需要).
需求获取最重要的成果是要得到系统前景(描述软件项目的目标,风险,范围等).

如果项目足够小,以上过程可全免.
然后进入系统分析阶段:
系统分析主要成果是系统用例模型和系统对象模型.
系统用例模型中的用例(是系统用例,不是业务用例)就是SRS中应该列出的功能点.

SRS(软件规格说明书)是技术性的商业管理文档,和用例模型不一样,用例模型是纯技术性的技术管理文档.得到用户签字的SRS如果包含这些信息(不一定是要以系统用例形式的表达,如果不是,就有您说的提炼功能点的事要做了,做的方式之一就是用系统用例方式来表达),就可以进行系统设计了.

 找到了
　

---

但站上大部分东西都是member only,是不是只有买他的产品才能成为‘member’啊？

您不是关心功能点的问题吗?
业务用例用例模型突出的是价值点问题.
有关业务用例模型的讨论可以到"技术人员的通病-缺乏市场意识"下讨论.