注意：
虽然最终必须要编成基于计算机解决方案的描述，但到目前为止，我们关注的焦点的文档在相应领域方面的部分。
记住这里没有计算机方面的行话，如果是编写一个会计软件，那么一位会计师都应该清楚地理解程序员写的会计方面的问题说明书
需求说明书问题中，不要太正式。只要描述能表达您想要做的事情就行了，就和另外一个人在说话一样就可以。
对于客户或相应人员了解问题时，一定要有记笔记的习惯，谈上几个小时，很多细节是记不住的。
3.2. 整理，检查和细化需求说明书
对于客户的需要进行必要的整理和分类
有进从用户那里会得到很多信息，不行进必要的整理就不能从中进行合理的分析
分清有用功能、可选功能用、无用功能及不可实现功能
对于用户来讲他可以说出他想要的很多功能，但这些功能间的关系有时是清晰的，但对于很多用户来讲想通过计算机或新系统实现他以前没有的功能，在这时他所提出的新需求的可行性和与其它模块之间的关系就已经不清，所以对于分析员来讲，要从用户的需求中分清有用功能和无用功能和可选功能，进行分别区分处理，比如不可实现功能请用户放弃。
不要忽略明显的错误
用户倒是不经常提及他需要的东西，而这些东西对问题来说都是很基本的，要细化检查一定有注意这个问题。
你认为的也许不是对的
对于系统分析员对需求分析的自认为的情况要加以注意，对于一个行业来说，有些规则可以不是最合理，但它就是那样存在和使用，所以对于每一个非明确确定的需求，要由专业人员来审定。除非你就是专家。
3.3. 改进
最初的第一次需求在分析，细化一定有不明及不确定之处，那么就把整理出一份问题细化问询表，对发现的问题进行整理，列出不明之处，可根椐以下格式
问询人：
问题：
业务不清问题列表（业务描述不清）：
1 ….是什么含义？
2 …..与XX是什么关系？
多种选择可以列表（请用户进行选择）：
1 ……有多个可能，那么现在我们使用
A …… B……. C…….. D ……
把问询表提交用户，根据反馈对需求再分析，这个步骤可重复多次，最终了解需求，确定需求说明书
3.4. 审核需求
自我审枋
把自己从用户的角度来考虑
是否合理，是否可以提高效率，是否可以达到目的，是否有完整
由用户来评价
由最终用户来评价你所列的需求是否达到了用户要求（用户人数1-3人，再多也没有什么益处）。
重复过程，最终通过审核完成需求说明书
参考资料
标准版API 规范，JAVA 2 核心技术和其他方面的信息。
关于作者
王辉，具有八年的编程及系统管理经验，所使用的语言为C和Java 编程语言。目前在深圳一家公司做程序员，使用C和JAVA为DB2数据库编程.可通过 ddxxkk@21cn.com 联系。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
