需求分析到底或简或实？

在论坛里看到zandb提问到：“作为软件产品的需求分析，我们是否应该注重具体的实现？对需求文档的撰写、需求描述，是否应该涉及到具体的实现呢？还是应该在功能上给予说明即可？”

    　这是个很好的问题，关于需求分析粒度的问题。

   　 zandb举了一个例子，例如Office Word 里 的“替换”功能。“对于这个功能的需求描述，是否应该写成：选择‘编辑’，在下拉式菜单中单击‘替换’，显示替换窗口，在替换窗口中‘查找内容’中输入想 要被替换的字符串，在‘替换为’编辑框中输入希望替换的字符串，单击‘全部替换’按钮，软件将会完成替换操作。”还是“仅仅描述功能，像这样：软件应实现 ‘替换’功能，允许用户输入被替换的内容和要替换的内容，进而完成单个替换和全部替换”就可以了呢？

    　从大家的回帖，对于需求分析，大部分人认为需求分析应该仅是功能的描述。比如，simonxln就说：“应该是功能说明吧。” mengge认为：“前者像设计，后者像需求。”daniellu1231也觉得“应该仅仅只描述这个功能是干嘛用的，因为是在寻找需求，具体实现没必要 在这个阶段考虑”。

    　事实上，需求是回答“需要什么”的问题，而实现才是解决怎样才能做到的问题。

    　针对不同的用途，需求文档可能表现为不同的形式，比如：

    　1．售前方案书：在项目签约之前为用户提供的重点功能描述。

    　2．需求分析报告：为项目双方约定设计任务的基本内容，限定设计任务的边界。

    　3．需求规格说明书：对系统的设计目标与功能体系进行相对完整的说明，在需求报告的基础上，增加对设计过程的支持与约束。

    　前两种方案对项目的实现过程影响不是很大，需求规格说明则经常是系统架构设计所要参照的重要文件。因此，个人浅见，在不同的阶段、不同的场合，需求文档的撰写也有所不同，是简单的描述还是完整的说明，要根据实际需要来决定。但不论哪种形式，都是需求文档的一种。