>>>>>下一页：需求管理的需求
通过我们对需求管理实际应用的分析，几个关键因素凸现出来。首先，需求管理在开发周期中是自始至终存在的。注意：不要把它简单理解为"需求周期"，需求管理必须始终保持更新，它构成了技术管理的基础。
其次，需求管理同项目管理是密不可分的。如果我们把每一个需求的解决看作一个里程碑，并以此出发对整个开发进程进行监控，我们就应该对整体开发工作进行精密细致的划分，从而将需求分析具体化。
☆需求管理的概念化阐释
需求管理应当具有以下几个特征：能够在开发周期的初期就建立需求模型;建模的成本很低;易于以后的具体化和优化;本身能体现最终解决方案的特征。也许某些细节是抽象的，但需求管理模型本身必须是完整的。需求模型不应当具有诱导性或倾向性，必须为开发工作留有充分发挥和优化的空间。同时，我们能够通过需求模型对最终产品作出评估。但不幸的是，这些特征本身也不是彼此完全兼容的，很难在一个简单模型中做到面面俱到。
在开发初期针对需求而搭建产品模型(Early Models)是容易的，成本也不会太高，但是这样的模型是很抽象的，绝非等同于最终产品。随后的产品原型(Prototypes)或高级模型 (Qualification Models) 将更接近于最终产品，但搭建这样的模型会要求更高的成本，同时可供修改的余地也更少。
需求管理的多种模式：
需求管理所要搭建的不同模式是由系统工程所采用的标准决定的。传统上需求管理有两种模式：客户模式和系统需求模式。从这两种模式出发的方案应该分别进行设计，不幸的是我们常常将此二者混为一谈。
用户模式着重描述用户面临的问题或希望得到的结果。用户模式的语言组织很象使用场景的实地描述，指明时间，侧重结果。无论谁搭建用户模式，都必须从用户的角度出发。
系统需求模式实际是抽象化的解决方案。系统需求模式的语言组织经常运用功能描述或使用详解性的说明文字，事实上功能描述和使用详解正是系统需求模式语言组织的典型风格。
实际上设计方案应当是第三种模式，即具体化的解决方案。很明显这种模式已经非常接近于最终解决方案。很多不同的设计方案都能解决用户需求，而在用户需求既定的同时对设计方案作出修改也是切实可行的。在硬件系统设计中，最终进行规模生产的产品体现的往往是第四种模式。
其他设计模式：
搭建多种系统设计模式需要付出相当的工作量，因为每种设计都做到条理清晰并不是件容易的事。如果设计构架和最终方案是一致的，那么工作量可能会减少一些。有些设计方案从产品角度出发，认为不同设计模式最好采用相同构架。但在实际应用当中，设计模式必须采用不同构架，这是因为：
●有些设计中同功能无关的需求，放在其他条件下则可能引起变化;
●出于重复利用现存模块的考虑;
●出于对机构效率的考虑;
文章来源于领测软件测试网 https://www.ltesting.net/
