五、应用需求类型

    通过定义需求类型,以及他们之间的关系,我们就建立了一个需求管理模型的框架.当然,我们建立这样的一个模型,是为了方便我们使用需求,为了达到这一目的,我们还需要在此基础上添加相应的内容. 需要对各种需求类型添加它们的属性,以便于对需求进行查询等管理手段.比如,可以针对用户需要,确定该需要的必要性,优先级,确定性等属性.在实际的项目中,就可以确定这些属性的值,而后根据这些实际属性值来安排项目的进度表等.或是在项目进度紧急时,确定哪些需求是可以延期完成,而哪些是必须完成的,等等.

    需求的追踪性 其次,可以根据不同需求的导出情况,在不同的需求之间建立追踪关系.譬如,用户需要决定了要构建产品的特性,产品的特性又决定了产品的软件需求,等.在这些不同类型的需求之间建立关联,一旦其中的某些需求发生变化,就可以确定它可能带来的影响,从而制定相应的策略.

    六、需求管理的工作流程

    工作流明细简介

    问题分析

    问题分析可以通过了解问题及涉众的最初需要,并提出高层解决方案来实现.它是为找出"隐藏在问题之后的问题"而进行的推理和分析.问题分析期间,将对"什么是面临实际问题"和"谁是涉众"等问题达成一致.而且,您还要从业务角度界定解决方案,以及制约该解决方案的因素.您应该已经对项目进行过商业理由分析,这将便于您更好地预计能从构建中的项目中得到多少投资回报.

    理解涉众需要

    需求来自各个方面,比如来自客户,合作伙伴,最终用户或是某领域的专家.您需要掌握如何准确判断需求应来源于哪方面,如何接近这些来源并从中获取信息.提供这些信息主要出处的个人在本项目中称为涉众.如果您正在开发一个在您公司内部使用的信息系统,那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员.通常讨论将在业务模型这一级上展开,而不是在系统这一级上展开.如果正在开发一个要在市场上出售的产品,那么您可以充分调动营销人员,以便更好地了解该市场中用户的需要. 获取需要的活动可使用这样一些技巧:访谈,集体讨论,概念原型设计,问卷调查和竞争性分析等.获取结果可能是一份图文并茂的请求或需要列表,并按相互之间的优先级列出.

    定义系统

    定义系统指的是解释涉众需求,并整理为对要构建系统的意义明确的说明.在系统定义的初期要确定以下内容:需求构成,文档格式,语言形式,需求的具体程度(需求量及详细程度),需求的优先级和预计工作量(不同人在不同的实践中通常对这两项内容的看法大不相同),技术和管理风险以及最初规模.系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型.系统定义的结果是用自然语言和图解方式表达的系统说明.

    管理项目规模

    为使项目高效运作,应仔细根据所有涉众的需求确定优先级,并对项目规模进行管理.有的开发人员仅仅重视所谓的"复活节彩蛋"(即开发人员感兴趣或觉得有挑战性的特性),而不是及早将精力投入降低项目风险或提高应用程序构架稳定性方面,这已使太多的项目蒙受损失.为确保尽早解决或降低项目中的风险,应以递增的方式开发系统.要慎重选择需求,以确保每次增加都能缓解项目中的已知风险.要达到目的,您需要和项目的涉众协商每次迭代的范围.通常,这要求具备管理项目各个阶段的期望结果的良好技能.

    除了控制开发过程本身,您还需控制需求的来源,并控制项目可交付工件的外观. 改进系统定义 系统的详细定义应能让涉众理解,同意并认可.它不仅需要具备所有功能,而且应符合法律或法规上的要求,符合可用性,可靠性,性能,可支持性和可维护性.感觉构建过程复杂的系统就应该有复杂的定义,这是一种常见的错误看法.这会给解释项目和系统的目的造成困难.人们可能印象深刻,但他们会因不甚理解而无法给出建议.应该致力于

    了解您制作的系统说明文档的读者.您可能常会发现需要为不同的读者准备不同的说明文档.

    我们认为用例方法是传达系统目的和定义系统细节的一种行之有效的方法,它常与简单的可视化原型结合使用.用例有助于为需求提供一个环境,利用它可生动地说明系统使用的方式.

    系统详细定义的另一个构件是说明系统采用的测试方式.测试计划及要执行测试的定义将会说明要核实哪些系统功能.

    管理需求变更

    定义需求时无论怎样谨慎小心,也总会有可变因素.变更的需求之所以变得难以管理,不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性,而且也因为对某个需求的变更很可能影响到其他需求.应确保赋予需求一个有弹性的结构,使它能适应变更,并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系.管理变更包括建立基线,确定需要追踪的重要依赖关系,建立相关项之间的可追踪性,以及变更控制等活动.

    七、需求管理所要完成的任务

    可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。需要始终保持注意的是，需求性是始终处于变化之中的。需求管理需要完成的任务包括：

    明确需求并达成共识；
    建立关联；
    根据不同需求设计相应解决办法；
    进行系统优化；
    提出设计方案；
    监控和解决可能出现的问题以及需要做出的改变；
    控制不同开发任务的开展；
    对最终产品做出评测；
    监控可能出现的重复开发；
    提出项目实施时间表；
    确定最终用户界面。
    有时侯我们所进行的需求分析只停留于分析本身，而没有进一步去思索我们为什么要进行需求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。"需求之需求"正是强调了贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。需求管理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求管理是不可能产生效益的。

    以下篇幅分别介绍需求管理在系统工程中的不同应用。

    需求共识：

    首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。这里的"用户"泛指在实际应用环境中每一位可能使用最终产品的人。如果一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的技术设计水准却最终不能获得成功，其原因正在于此。可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。

    需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。因而需求管理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。

    根据需求设计解决办法：

    我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。