概要
需求治理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。仅从字面出发，假如一个产品满足了客户需求，那它无疑就是成功的。需求治理的过程，从需求分析开始贯穿整个项目始终，力图实现最终产品同需求性的最佳结合（参见Figure 1）。通过对需求治理在项目进程中实施的不同任务进行分析，我们可以看出需求治理所起的作用。
需求治理能够确证：
●我们确知客户的需求是什么（质量）；
●满足客户需求的最佳解决办法（统一性）；
闻名学者Crosby对于质量的定义是"同需求保持统一"。从这个意义上说，需求治理正是从质量出发以确定需求。每个人都应当始终明白他们所做的具体任务其意义何在。然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。
对于系统工程没有严格统一的定义，因此很难找到足够的数据以说明系统工程所起的作用。有些致力于研究需求分析的组织认为，一项开发计划应当至少将8-15%的资源投入到系统工程方面。假如低于这一标准，将很可能导致无法对客户群做出准确把握。假如该项开发计划含有许多创新或实验的成分，那么这一百分比还应当适度提高。
需求治理所要完成的任务
可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。需要始终保持注重的是，需求性是始终处于变化之中的。需求治理需要完成的任务包括：
●明确需求并达成共识；
●建立关联；
●根据不同需求设计相应解决办法；
●进行系统优化；
●提出设计方案；
●监控和解决可能出现的问题以及需要做出的改变；
●控制不同开发任务的开展；
●对最终产品做出评测；
●监控可能出现的重复开发；
●提出项目实施时间表；
●确定最终用户界面。
有时侯我们所进行的需求分析只停留于分析本身，而没有进一步去思考我们为什么要进行需求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。"需求之需求"正是强调了贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求治理，无异于纸上谈兵。需求治理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求治理是不可能产生效益的。
以下篇幅分别介绍需求治理在系统工程中的不同应用。
需求共识：
首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。这里的"用户"泛指在实际应用环境中每一位可能使用最终产品的人。假如一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的技术设计水准却最终不能获得成功，其原因正在于此。可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。
需求治理的首要任务在于使开发人员和用户双方对于需求都有一个明确的熟悉。因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。因而需求治理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。
根据需求设计解决办法：
我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。
系统优化：
任何设计都应以考虑用户需求为优先，用户需求的满足程度即成为衡量设计优劣的标准。在一个项目设计周期中，开发人员经常会面临选择，以提炼需求，决定开发的优先次序，并在不同的实施方案中作出选择。这些选择必须考虑到收益与付出地平衡比例，这种选择的重要性尤其在建立需求模型的后期凸现出来。基本需求在这时都已明确，而实施方案还未敲定，为了使用户的基本需求得到落实，一定程度的开销用于搭建不同构架的需求模式是合理的。假使我们已经有了一套翔实的需求分析，我们甚至不必将每一套方案都付诸实行，就可以成功地对系统设计进行优化。
面对不同的可行性而需要作出选择时，我们也必须参照收益与付出的比例关系。例如，在被要求提供计划书时（Request for PRoposal），我们应当尽量做到每一份计划书的提供都物有所值。
方案设计：
明确需求后，开发人员就可以进行方案设计。通过对用户需求和设计方案之间所存在关联性进行分析比较，我们就能够对设计方案进行评估。
必要的修改：
方案的设计不可能是一成不变的，经常会有方案设计同需求相悖的情况。假如我们无法准确把握用户需求同方案设计之间的关系，我们就无法在需要对方案进行必要修改时正确判定。优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。
任务划分：
一个大的开发项目可能涉及20-30组不同的开发队伍，人员包括技术工程师、软件工程师以及具体项目主管等等，而每一个模块都有它自己的开发工具和开发语言。
主持一个大项目的开发并不是件轻易的事，总体项目主管的首要任务是对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍，对于开发进程的监控只需参照需求的解决情况，对于具体的开发细节则不必过问太多。
不同的开发队伍会使用不同的开发语言和开发工具，会使用不同的符号和标记。相反，作为总体项目主管所使用的语言、符号和标记等则必须简单易懂，以使所有的开发人员都等理解。换言之，总体项目主管应当使用自然语言，或只涉及少量的，简单的术语和专用词汇。
产品测试：
需求的满足情况是决定最终产品成败的判定基础，对最终产品的测试评估必须以产品所试图解决的需求为标准。下图标示了不同的开发阶段所对应的测试需求。
这里有一个需求、产品和测试系统之间的关系问题，确定需要进行的测试属于总体开发主管的工作范畴，虽然具体工作并非都要由开发主管来亲自完成。
重复开发：
对于总体开发主管而言，针对方案设计的修改是一项经常性的工作（因为修改而造成的影响则应当尽可能减小）。在进行项目开发时，随着开发进程的深入，各种修改的建议和问题的报告是屡见不鲜的，每解决一个问题，就是将产品同其需求性的结合又完善了一步。存在问题正是需求性尚未满足的表现。
方案设计的完善和需求性的满足是同步的，因此真正的用户对于产品的评价和建议尤其具有重要意义。在那些一步到位的产品设计中，真正用户无法左右开发进程；但在一个能够进行重复设计、重复开发的产品生命期中，开发人员应当及时搜集用户对于产品的反馈信息，并将这些信息结合到下一步的开发工作中去。如下图所示，用户反馈同产品开发是统一的。
QQRead.com 推出数据恢复指南教程 数据恢复指南教程
数据恢复故障解析
常用数据恢复方案
硬盘数据恢复教程
数据保护方法
数据恢复软件
专业数据恢复服务指南
概要
需求治理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。仅从字面出发，假如一个产品满足了客户需求，那它无疑就是成功的。需求治理的过程，从需求分析开始贯穿整个项目始终，力图实现最终产品同需求性的最佳结合（参见Figure 1）。通过对需求治理在项目进程中实施的不同任务进行分析，我们可以看出需求治理所起的作用。
需求治理能够确证：
●我们确知客户的需求是什么（质量）；
●满足客户需求的最佳解决办法（统一性）；
闻名学者Crosby对于质量的定义是"同需求保持统一"。从这个意义上说，需求治理正是从质量出发以确定需求。每个人都应当始终明白他们所做的具体任务其意义何在。然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。
对于系统工程没有严格统一的定义，因此很难找到足够的数据以说明系统工程所起的作用。有些致力于研究需求分析的组织认为，一项开发计划应当至少将8-15%的资源投入到系统工程方面。假如低于这一标准，将很可能导致无法对客户群做出准确把握。假如该项开发计划含有许多创新或实验的成分，那么这一百分比还应当适度提高。
需求治理所要完成的任务
可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。需要始终保持注重的是，需求性是始终处于变化之中的。需求治理需要完成的任务包括：
●明确需求并达成共识；
●建立关联；
●根据不同需求设计相应解决办法；
●进行系统优化；
●提出设计方案；
●监控和解决可能出现的问题以及需要做出的改变；
●控制不同开发任务的开展；
●对最终产品做出评测；
●监控可能出现的重复开发；
●提出项目实施时间表；
●确定最终用户界面。
有时侯我们所进行的需求分析只停留于分析本身，而没有进一步去思考我们为什么要进行需求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。"需求之需求"正是强调了贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求治理，无异于纸上谈兵。需求治理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求治理是不可能产生效益的。
以下篇幅分别介绍需求治理在系统工程中的不同应用。
需求共识：
首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。这里的"用户"泛指在实际应用环境中每一位可能使用最终产品的人。假如一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的技术设计水准却最终不能获得成功，其原因正在于此。可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。
需求治理的首要任务在于使开发人员和用户双方对于需求都有一个明确的熟悉。因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。因而需求治理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。
根据需求设计解决办法：
我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。
系统优化：
任何设计都应以考虑用户需求为优先，用户需求的满足程度即成为衡量设计优劣的标准。在一个项目设计周期中，开发人员经常会面临选择，以提炼需求，决定开发的优先次序，并在不同的实施方案中作出选择。这些选择必须考虑到收益与付出地平衡比例，这种选择的重要性尤其在建立需求模型的后期凸现出来。基本需求在这时都已明确，而实施方案还未敲定，为了使用户的基本需求得到落实，一定程度的开销用于搭建不同构架的需求模式是合理的。假使我们已经有了一套翔实的需求分析，我们甚至不必将每一套方案都付诸实行，就可以成功地对系统设计进行优化。
面对不同的可行性而需要作出选择时，我们也必须参照收益与付出的比例关系。例如，在被要求提供计划书时（Request for Proposal），我们应当尽量做到每一份计划书的提供都物有所值。
方案设计：
明确需求后，开发人员就可以进行方案设计。通过对用户需求和设计方案之间所存在关联性进行分析比较，我们就能够对设计方案进行评估。
必要的修改：
方案的设计不可能是一成不变的，经常会有方案设计同需求相悖的情况。假如我们无法准确把握用户需求同方案设计之间的关系，我们就无法在需要对方案进行必要修改时正确判定。优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。
任务划分：
一个大的开发项目可能涉及20-30组不同的开发队伍，人员包括技术工程师、软件工程师以及具体项目主管等等，而每一个模块都有它自己的开发工具和开发语言。
主持一个大项目的开发并不是件轻易的事，总体项目主管的首要任务是对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍，对于开发进程的监控只需参照需求的解决情况，对于具体的开发细节则不必过问太多。
不同的开发队伍会使用不同的开发语言和开发工具，会使用不同的符号和标记。相反，作为总体项目主管所使用的语言、符号和标记等则必须简单易懂，以使所有的开发人员都等理解。换言之，总体项目主管应当使用自然语言，或只涉及少量的，简单的术语和专用词汇。
产品测试：
需求的满足情况是决定最终产品成败的判定基础，对最终产品的测试评估必须以产品所试图解决的需求为标准。下图标示了不同的开发阶段所对应的测试需求。
这里有一个需求、产品和测试系统之间的关系问题，确定需要进行的测试属于总体开发主管的工作范畴，虽然具体工作并非都要由开发主管来亲自完成。
重复开发：
对于总体开发主管而言，针对方案设计的修改是一项经常性的工作（因为修改而造成的影响则应当尽可能减小）。在进行项目开发时，随着开发进程的深入，各种修改的建议和问题的报告是屡见不鲜的，每解决一个问题，就是将产品同其需求性的结合又完善了一步。存在问题正是需求性尚未满足的表现。
方案设计的完善和需求性的满足是同步的，因此真正的用户对于产品的评价和建议尤其具有重要意义。在那些一步到位的产品设计中，真正用户无法左右开发进程；但在一个能够进行重复设计、重复开发的产品生命期中，开发人员应当及时搜集用户对于产品的反馈信息，并将这些信息结合到下一步的开发工作中去。如下图所示，用户反馈同产品开发是统一的。
