需求分析是对用户需求的真正明确，是对要解决的问题的彻底理解。在解决问题之前要理解问题，只有真正的理解问题才能更好的解决问题。需求分析就是给系统分析、设计人员一个和用户交流来理解问题的机会—了解用户究竟需要什么。
需求分析也是一个建模的过程，与在概要设计中建模不同在需求分析中建模是面向用户的过程。而在概要设计中的建模过程是面向开发人员的过程。这样两种建模的过程就会存在差异和不同，从而使用自然语言进行描述也就不同。在传统的软件工程中并不建议大量的使用自然语言对软件的需求进行描述，因为太多的自然语言会引发出很多问题。比如说，二义性即不同的人对自然语言的描述会有不同的理解，就是再好的文档编写人员也不会保证他的文档不存在二义性。毕竟我们不是语言学家。这样就引入了借用图示进行功能的描述和建模的过程。图示有其自己的优势比如，清晰，明确给人直观的感觉。无论是何种背景的人群都可以理解。这样就大大减少需求分析中的二义性。从而使系统设计人员和用户更加有效的沟通。这样也增加了软件的正确性。在传统的软件工程中提供了多种不同的图示，每一种都从不同的角度对同一个问题进行描述，之所以这样。可以使系统开发人员在不同的图示中挑出最适合他和他的团队进行问题详尽描述的一个或者一些图示。比如数据流图，在需求分析中使用数据流图，就充分体现了数据在软件系统中移动时被变换的逻辑过程。所以就是一个建立功能模型的最好图示；而实体关系图，就是描述数据对象以及他们之间关系的图示，所以就是一个建立数据模型的最好例子。状态转换图通过事件的外部作用从而对状态进行改变，这就是一个建立行为模型的例子。
在我做需求分析时，尽量做到问题阐述明确。可是一直有一个问题困扰着我，就是应该选择什么样的图例进行系统的描述是，数据流图，状态转换图还是实体关系图？其实不同系统设计人员给出的答案不会是一样的。这并不是一个哲学问题而是一个应用问题。从客户的角度出发使用实体关系图是最好的选择，而数据流图完全就是为系统设计人员量身定做的一样。因为程序员更关心事物内部的逻辑性和相关性；而用户只关心事物的外部表征和特性。所以问题的答案只有每个人自己去寻找，寻找一个最能体现用户需求和问题解决方案的图示。
在按照模版进行需求分析撰写的时候，我发现有很多模版条目的要求是在需求分析的最初阶段是无法给出确切的答案的。有的条目要经过概要设计，详细设计之后才能对文档内容进行修改和填充。同时我对其他同行撰写的需求分析文档进行研究发现，一个优秀的需求分析说明说并不是按照规定模版条目不变的照搬。其实有些冗余的项目完全可以不必关心。毕竟撰写需求分析的真正目的，是让系统设计人员知道用户的需求。其他的不必过多强求。
发表于 @ 2006年04月29日 15:24:00|评论(loading...)|编辑