|
|
|
需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的数据域。用一句话概括就是：需求分析主要确定开发软件的功能、性能、数据和界面等要求。需求分析的实现步骤通常包括3个部分，分别是获取当前系统的物理模型，抽象出当前系统的逻辑模型，以及建立目标系统的逻辑模型。
|
|
|
|
|
|
具体来说，需求分析阶段的工作可以分成以下4个方面。
|
|
|
|
（1）问题识别。用于发现需求，描述需求，主要包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求，并预先估计以后系统可能达到的目标。
|
|
|
|
（2）分析与综合。也就是对问题进行分析，然后在此基础上整合出解决方案。这个步骤经常是反复进行的，常用的方法有面向数据流的结构化分析方法，面向数据结构的Jackson方法，面向对象的分析方法，以及用于建立动态模型的状态迁移图和Petri网。
|
|
|
|
（3）编制需求分析的文档。也就是对已经确定的需求进行文档化描述，该文档通常称为软件需求说明书（需求规格说明书）。
|
|
|
|
（4）需求分析与评审。它是需求分析工作的最后一步，主要是对功能的正确性、完整性和清晰性，以及其他需求给予评价。
|
|
|
|
|
|
|
|
|
|
|
|
（3）必须划分描述信息、功能和行为的模型，从而可以以层次的方式揭示细节。
|
|
|
|
|
|
（5）必须按自顶向下、逐层分解的方式对问题进行分解和不断细化。
|
|
|
|
|
|
通过应用这些原则，系统分析员可以系统地处理某些问题，包括检查信息域以使得功能可以被更完整地理解，使用模型以使得可以以简捷的方式交流功能和行为的特征，应用划分以减少问题的复杂性等。在这些处理过程中，软件的要素和视图实现由处理需求带来的逻辑约束与由其他系统元素带来的物理约束是必需的。
|
|
|
|
|
|
什么是软件的需求呢？软件需求就是系统必须完成的事，以及必须具备的品质。具体来说，软件需求包括功能需求、非功能需求和设计约束三个方面的内容。
|
|
|
|
（1）功能需求。是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。
|
|
|
|
（2）非功能需求。是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性及扩展性，等等。
|
|
|
|
（3）设计约束。也称为限制条件、补充规约，这通常是对解决方案的一些约束说明，例如必须采用国有自主知识版权的数据库系统，必须运行在UNIX操作系统之下等。
|
|
|
|
除了这三种需求之外，还有业务需求、用户需求和系统需求这三个处于不同层面下的概念，充分理解这些需求才能够更加清晰地理清需求的脉络。
|
|
|
|
（1）业务需求。是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。
|
|
|
|
（2）用户需求。是指描述用户使用产品必须要完成什么任务、怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，然后建立的从用户角度的需求。
|
|
|
|
（3）系统需求。是从系统的角度来说明软件的需求，它包括了用特性说明的功能需求，质量属性及其他非功能需求，还有设计约束。
|
|
|
|
我们经常围绕着“功能需求”来展开工作，而功能需求大部分都是从“系统需求”的角度来分析与理解的，也就是用“开发人员”的视角来理解需求。但要想真正地得到完整的需求，仅戴上“开发人员”的眼镜是不够的，还需要“领域专家”的眼镜，从更高的角度来理解需求，这就是“业务需求”。同时还应该更好地深入用户，了解他们的使用场景，了解他们的所思所想，这就是“用户需求”。这是一个理解层次的问题，并不仅仅是简单的概念。
|
|
|
|
|
|
需求工程就是包括创建和维护系统需求文档所必需的一切活动的过程，也就是指需求开发和需求管理两大工作。
|
|
|
|
（1）需求开发。包括需求捕获、需求分析、编写规格说明书和需求验证4个阶段。在需求开发阶段需要确定产品所期望的用户类型、获取每种用户类型的需求、了解实际的用户任务和目标，以及这些任务所支持的业务需求。同时还包括分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型，以及对需求进行评审等工作。
|
|
|
|
（2）需求管理。通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。
|
|
|
|
这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。换句话来说，需求开发是努力更清晰、更明确地掌握客户对系统的需求；而需求管理则是对需求的变化进行管理的过程。
|
|
|
|
|
|
（1）在开始建立分析模型前先理解问题。人们通常总存在急于求成的倾向，甚至在问题被很好地理解前就已开始建模，这经常会导致产生一个解决错误的问题。
|
|
|
|
（2）开发原型，使得用户能够了解将如何发生人机交互。因为人们对软件质量的感觉经常基于对界面“友好性”的感觉，所以强力推荐使用原型方法（以及相应产生的迭代）。
|
|
|
|
（3）记录每个需求的起源及原因，这是建立回溯到客户的可追踪性的第一步。
|
|
|
|
（4）使用多个需求视图。建立数据、功能和行为模型，为软件工程师提供三种不同的视图，这将减少忽视某些东西的可能性，并增加识别不一致性的可能性。
|
|
|
|
（5）给需求赋予优先级。过短的时限可能使每个软件需求得以实现的可能性减小，如果采用增量模型，则必须标识那些将在第一个增量中要交付的需求。
|
|
|
|
（6）努力删除含糊性。因为大多数需求以自然语言描述，存在含糊性的可能，正式的技术复审是发现并删除含糊性的一种方法。
|
|
|
