需求分析中的问题总结

阅读完林锐《软件工程与项目管理解析》中关于需求分析章节，弄明白了以前自己做需求的时候很多问题，这些问题的存在让我觉得需求分析这个阶段就像是拦路虎，很压抑。

1、需求阶段不明

需求分析到底包含几个阶段呢？这是我一直很不理解的地方。为了弄清楚这个问题，还是得先弄明白需求的本质是什么。

”宽泛的讲，需求来源于用户的一些‘需要’，这些‘需要’被分析、确认后形成完整的文档，该文档详细的说明了产品‘必须或应当’做什么。“

由此可见，”需求“就是用户的需要，这一阶段的任务就是要搞清楚用户的需要。文档这些都是辅助手段，而且是必要的。

明白了这个道理，那如何才能做到？

整个需求工程分为：需求开发和需求管理两部分，各部分又有几个阶段：

需求开发：

            需求调查——〉得到《用户需求说明书》

            需求分析——〉使用”问答分析法“或“建模分析法”对各种需求信息进行分析，消除错误、刻画细节。

            需求定义——〉根据以上的结果，定义准确无误的产品续期，产生《产品需求规格说明书》。

需求管理：需求确认——〉需求跟踪——〉需求变更控制

“

《用户需求说明书》与《产品需求规格说明书》的主要区别与联系：

（1）前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细；

（2）后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据；

（3）两者之间可能并不存在一一映射关系，因为软件开发商会根据产品发展战略、企业当前状况适当的调整产品需求，例如用户需求可能被分配到软件的数个版本中，软件开发人员应当依据《产品需求规格说明书》来开发当前产品。

”

两者的模板都包含了产品的功能性需求，内容为：

功能类别	功能名称、标志符	描述
FeatureA	FunctionA.1
	...
FeatureB	FunctionB.1
	...
FeatureC	FunctionC.1
	...

也都包含了非功能性的需求：

需求类别	需求名称、标识符	描述
用户界面需求
软硬件需求
质量需求

从模板上来看，后者多了对前者的功能的喜欢，每个功能点都写明了：

名称、标识符
优先级
功能描述
数据及解析
输入、输出、操作系列等
其他说明
参考示例

自己之前做的工作就是真是太粗糙了，需求调查往往就是大家聊聊，记录一下他们的想法，然后再自己想想怎么实现，也没有评审，就这样就定了，开发。太儿戏了。。。难怪总是不能达到对方的要求。没有一个完整的方法论做支撑，管理一片混乱，难怪老是要吃苦果。。。。

我应该如何做？

在做需求调查的时候，根据一定的模板，记录下用户的原始需求；

按照一定的格式整理成《用户需求说明书》；

对每个功能进行细化，得到《产品需求规格说明书》。

因为面对的是内部用户，且对开发一窍不通，往往用户今天提了个想法，明天就问做完了没有，想想实在很吐血。也是由于自己对这方面的思路不清晰，导致很被动，需要改变这种做法了，不管用户如何，这个过程自己一定要遵守，按照一定的规则办事，这样才能把这件事做好，否则到时候就变得不可收拾。其实这个过程不仅是对我这边的训练，也是对用户那边的训练。

需求评审这个过程不能省略，虽然不用签合同，但是让大家都对将要开发的功能都有全盘的认识，这个很有必要。

2、需求相关的知识不足

1）需求跟踪，以前一直没搞清楚，这个是干吗用的，网上也没有得到特别明确的答案。这个工作目前来说是空白的。

需求跟踪的目的是建立与维护”需求——设计——编程——测试“之间的一致性，简单的来说，可以有个excel表，记录下面的信息：

需求规格说明书（版本日期）        设计文档（版本，日期）           代码（版本，日期）                测试用例（版本，日期）

这样，对于每个需求的功能都能找到后续的对应制品，这就可以跟踪了。那么只要检查一下产品规格需求说明书里的各个需求，是否都实现了，就知道功能需求是否都完成了。

2）需求分析方法

结构化分析方法，我只是关注了”数据流图”，实际上，整个方法涉及的部分确实有：

实体-关系图     〈——〉            数据字典      〈——〉                 数据流图

                                                                ^

                                                                 |

                                                                 v

                                                        状态-变迁图

同时由于我没有《用户需求说明书》和《产品需求规格说明书》的概念，把东西都混淆在一起进行表达了，感觉很混乱。

3）时间分配问题

由于项目小，往往要负责需求，设计，开发，由于对需求的重视不足，在这方面的付出不够，也就做的够烂。书上也说了，要能给企业带来利益。这也就是我的项目的价值。那么只有开发出来的产品，对公司业务部门有节省成本、提高效率、扩展市场，才能叫做有价值。如果一味的闭门造车，或者对用户的需求仅仅是做了粗略记录，却没有深刻分析，然后把时间都投入到开发上，这样，会带来很严重的后果：需求不对路，开发出来的东西用户不满意，或者根本不是用户要的，白干了。其实技术不是唯一（指的是这种应用型的）的，满足用户需求的技术才是最好的。总之，一定要认识到需求的重要性，花功夫去做细它。