|
|
|
|
知识路径： > 软件工程 > 软件工程基础知识 > 软件需求分析与定义 > 需求工程 >
|
|
|
被考次数：8次
|
|
|
被考频率：
中频率
|
|
|
总体答错率：
54%
|
|
知识难度系数：
|
|
|
考试要求：
掌握
|
|
|
相关知识点：14个
|
|
|
|
|
需求开发所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件与其他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的数据域。用一句话概括就是：需求开发主要确定开发软件的功能、性能、数据和界面等要求。
|
|
|
|
在不严格区分需求开发和需求管理的情况下，往往就把“需求分析”当作“需求开发”。也就是说，广义的“需求分析”就是指需求开发中的4个阶段的总体。
|
|
|
|
|
|
|
|
（1）问题识别：用于发现和描述需求，并预先估计以后系统可能达到的目标。
|
|
|
|
（2）分析与综合：对问题进行分析，然后在此基础上整合出解决方案。这个步骤经常是反复进行的，常用的方法有面向数据流的结构化分析方法，面向数据结构的Jackson方法，面向对象的分析方法，以及用于建立动态模型的状态迁移图和Petri网。
|
|
|
|
（3）编制需求分析的文档：也就是对已经确定的需求进行文档化描述，该文档通常称为软件需求说明书（需求规格说明书）。
|
|
|
|
（4）需求分析与评审：它是需求分析工作的最后一步，主要是对功能的正确性、完整性和清晰性，以及其他需求给予评价。
|
|
|
|
|
|
|
|
|
|
|
|
（3）必须划分描述信息、功能和行为的模型，从而可以用层次的方式揭示细节。
|
|
|
|
|
|
（5）必须按照自顶向下、逐层分解的方式对问题进行分解和不断细化。
|
|
|
|
|
|
通过应用这些原则，系统分析师可以系统地处理某些问题，包括检查信息域以使得功能可以被更完整地理解，使用模型以使得可以用简捷的方式交流功能和行为的特征，应用划分以减少问题的复杂性等。在这些处理过程中，软件的要素和视图实现由处理需求带来的逻辑约束与由其他系统元素带来的物理约束是必需的。
|
|
|
|
|
|
软件需求就是系统必须完成的事，以及必须具备的品质。具体来说，软件需求包括功能需求、非功能需求和设计约束3个方面的内容。
|
|
|
|
（1）功能需求：是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。
|
|
|
|
（2）非功能需求：是指产品必须具备的性能或品质，例如，可靠性、容错性等。
|
|
|
|
（3）设计约束：也称为限制条件、补充规约，通常是对解决方案的一些约束说明，例如，某系统必须采用国有自主知识版权的数据库，必须运行在UNIX系统之下，等等。
|
|
|
|
除了这三种需求之外，还有业务需求、用户需求和系统需求这三个处于不同层面下的概念，充分理解这些需求才能够更加清晰地理清需求的脉络。
|
|
|
|
（1）业务需求：是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。
|
|
|
|
（2）用户需求：是指描述用户使用产品必须要完成什么任务以及怎么完成的需求，通常是在问题定义的基础上进行用户访谈和调查，对用户使用的场景进行整理，然后建立的从用户角度的需求。
|
|
|
|
（3）系统需求：是从系统的角度来说明软件的需求，它包括了用特性说明的功能需求，质量属性及其他非功能需求，还有设计约束等。
|
|
|
|
我们经常围绕着“功能需求”来展开工作，而功能需求大部分都是从“系统需求”的角度来分析与理解的，也就是用“开发人员”的视角来理解需求。但要想真正地得到完整的需求，仅戴上“开发人员”的眼镜是不够的，还需要“领域专家”的眼镜，从更高的角度来理解需求，这就是“业务需求”；同时还应该更好地深入用户，了解他们的使用场景，了解他们的所思所想，这就是“用户需求”。这是一个理解层次的问题，并不仅仅是简单的概念。
|
|
|
