|
|
知识路径： > 系统开发基础知识 > 需求管理 > 需求定义 >
|
|
相关知识点：3个
|
|
|
|
|
严格定义（预先定义）是目前采用较多的一种需求定义方法。在采用严格定义的传统的结构化开发方法中，各个工作阶段排列成一个理想的线性开发序列，在每一工作阶段中，都用上一阶段所提供的完整、严格的文档作为指导文件，因此它本质上是一种顺序型的开发方法。
|
|
|
|
在传统的结构化开发中，需求的严格定义建立在以下的基本假设上：
|
|
|
|
（1）所有需求都能够被预先定义。假设意味着，在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑推断得到。这对某些规模较小、功能简单的系统是可能的，但对那些功能庞大、复杂且较大的系统显然是困难的。即使事先做了深入细致的调查和分析，当用户见到新系统的实际效果时，也往往会改变原先的看法，会提出修改或更进一步增加系统功能的要求，所以再好的预先定义技术也会经常反复。这是因为人们对新事物的认识与理解将随着直观、实践的过程进一步加深，这是与人类认识世界的客观规律相一致的。所以，能够预先定义出所有需求的假设在许多场合是不能成立的。
|
|
|
|
（2）开发人员与用户之间能够准确而清晰地交流。假设认为，用户与开发人员之间，虽然每人都有自己的专业、观点、行话，但在系统开发过程中可以使用图形／文档等通信工具进行交流，进行清晰、有效的沟通，这种沟通是必不可少的。可是，在实际开发中，往往对一些共同的约定，每个人可能都会产生自己的理解和解释。即使采用结构化语言、判定树、判定表等工具，仍然存在精确的、技术上的不严密感。这将导致人们有意无意地带有个人的不同理解而各行其事，所以在多学科、多行业人员之间进行有效的通信交流是有一定困难的。
|
|
|
|
（3）采用图形／文字可以充分体现最终系统。在使用严格定义需求的开发过程中，开发人员与用户之间交流、通信的主要工具是定义报告，包括叙述文字、图形、逻辑规则和数据字典等技术工具。它们都是静止的、被动的，不能实际表演，很难在用户头脑中形成一个具体的形象。因此，要用静止的图形／文字描述来体现一个动态的系统是比较困难的。
|
|
|
|
除了所论述的情况外，上述基本假设还将导致严格定义的结构化开发方法存在以下缺陷：
|
|
|
|
（1）文档量大。由于在结构化方法的每个阶段都必须写出规范、严密的各种文档，这些文档虽然有助于开发人员之间、用户与开发人员间的通信交流，有助于开发过程的规范化，但由于编写文档花费大量人力和时间，导致系统开发周期增大。
|
|
|
|
（2）开发过程可见性差，来自用户的反馈太迟。由于在需求定义、系统设计阶段都不能在用户终端显示新系统的实际效果，一直到系统实现阶段结束，用户才有机会通过对新系统的实际操作和体会来提出他们对新系统的看法和意见，但此时整个开发已近尾声，若想修改前几段的工作或修改需求定义，都将付出较大的代价，有时这种修改甚至会导致整个系统的失败。
|
|
|
|
：需求的严格定义的基本假设在许多情况下并不成立，传统的结构化方法面临着一些难以跨越的障碍。为此，需要探求一种变通的方法。
|
|
|
