求一个功能点规范文档编写思路

franklzann

1、界面说明
2、业务流程
3、输入说明
4、指标说明
……
每个页面或者功能点这样按照条目列出来，需求方不容易遗漏，不需要的删除不要就好
不过你的规范文档里面，要尽量写全了。
然后每个条目需要写什么内容，进行文字说明，
然后再参考下历史的需求文档，并结合开发这边的痛点，进行下修正和进一步说明的完整实例

这样应该就比较全面了，之后就是需求和研发这边的磨合交流
双方再找到更加合适的格式和内容，对该文档做进一步的改进（毕竟这还是要需求写的文档，
不能只是按照研发的意思来，还要兼顾需求的实际情况）
即使有遗漏，也可以再后续版本里面进一步补充

franklzann

我觉得，你首先应该和研发部领导沟通下，了解他的不满主要是在哪些方面；
然后再和开发设计人员交流下，他们认为的目前需求文档缺少的内容是什么，格式方面，有没有什么要求，或者好的想法。
其实把你这个文档当作项目来做的话，以上两步骤，其实就是需求调研
把需求做好，是把项目做好的第一步；把领导的意图领会清楚，并尽可能的细化执行好，才能赢得领导的好评
不然你埋头辛苦忙会半天，一交成果，领导一看，这根本不是我要的，那就都白忙了

franklzann

另外鉴于个人经验，需求方面经常会遗漏输入限制要求，还有就是业务流程线不够清晰，缺少流程图之类的明确描述

franklzann

同意楼上说的，这个文档不像是应该由测试来写的东西。

如果是需求、设计两边衔接不好，其实也简单，
需求已经有需求文档了，然后需求 与设计开发一起开个需求交接会（事前设计开发自己先过一遍需求文档）
在交接会上，需求针对文档内容做出讲解，
设计开发人员，针对自己不明白的需求问题提出来，要求解答；
另外，关于细节，比如输入限制要求等等，没有写出来的，要求需求明确，并补充进需求文档中（这样几次之后，能够用文档表达清楚的部分，需求也就明确了）

franklzann

海海豚 发表于 2017-1-5 16:17
刚刚和领导沟通，得知领导的意思应该是功能点应该比测试用例的case分的更加的细，于是我彻底迷茫了 TUT

你们公司的项目，现在有哪些文档了？领导这个新增的文档，是准备放在哪个步骤的，由什么人员来写的？