简介
与系统开发相关联的需求必将存在层次结构,从最简略的部分(定义了系统的任务或用户目标摘要)到最详细的部分,也许贯穿了几个中间级别。在最详细的级别,可用系统使用的技术词汇来表述需求;而在最高级别,通常是用系统提供的区域语言更抽象地表述需求,如能力、服务、行为、功能、特性等,对字词的选择通常是任意的。为了更准确地了解所表述的内容,很有可能将不同的含意归诸于这些字词(例如,对系统的某种特定行为的描述可能没有揭示太多目的或意图,并且需要某种其他描述类型),但在此处这并不是目的所在。
需求的优化(从最高级别,添加更多详细信息)可以按纯功能的方式继续进行,这种方式是将功能拆分为支持它们的子功能或子任务(而不考虑任何正在实现的体系结构),子功能和子任务所能到达的级别可以描述系统深处的状况(假设系统是按这种方式构造的),并且也许与系统外部无
直接通信。例如可与原始变换计划一样深入的结构化分析方法,也是这种情况。
这种方法是不明智的,首先,因为它会导致将根本不是需求而只是分解的工作产品的事物识别为需求;第二,如果设计人员将实现非常接近的映射到分解上,则可能会导致体系结构不合理(例如,未能满足其他非功能需求或非功能需求的执行情况不佳)。但是,如果将分解的深度限制到能力或功能可辨别的级别上,并且在高级别表述了远景目标,则就有理由执行
某些功能上的分解,即有足够的详细信息来获取所有重要的(对于项目干系人来说)行为、特性等,这样设计人员才能正确地实现它们。(或多或少直接)从较高级别需求优化而来的需求是一种派生的需求:
派生的需求
以下是一个简单的示例:
假设用户需求是“系统必须在户外工作,一年 12 个月都在阿拉斯加”。
有几种派生的需求:
-
系统必须在 32 F/0 C 以下的温度中工作。
-
系统必须在雪地里工作。
还有另一种类型的派生需求。如果已用适当的详细信息表述了系统级别需求以便该需求能够实现,则:
-
将系统(模型)划分为若干元素(例如,使用 OOAD 方法)。
-
确定这些元素如何协作可产生期望的系统行为。
-
聚集通过协作产生的较低级别的行为,生成元素级别的需求。
这些较低级别的需求都是派生的需求;它们已随系统的分解而出现。这与基于功能的方法形成对比,如简介中所述,在这种方法中执行了划分操作,而没有考虑任何体系结构分解以及系统级别需求的改进。
分配的需求
分配的需求是已分配(根据功能注意事项)到系统组件(例如硬件或软件子系统)的需求。在非常高的级别,例如,在推断多个系统中某个系统的任务级别需求时,可能仍适合在功能上详细描述这种需求,然后对生成的派生需求进行划分并将各组分配到
系统中 - 也许在实现之前可进一步优化。除此之外,此处的首选项将在“派生的需求”中继续起作用。即使在多个系统中某个系统级别,也可以考虑通过使用“业务建模”方法继续按这种方式进行。
注意,在派生方法中,将系统分解成了多个实体,并通过研究这些实体如何协作来确定它们的需求,从而可满足较高级别的需求。在已分配的功能性方法中,对需求进行了分解并指定了满足较低级别需求的实体。
要使用的方法取决于环境、文化和契约性预期目标。例如,国家航空和宇宙航行局(NASA)[Software Assurance Guidebook, NASA Goddard Space Flight Center Office
of Safety, Reliability, Maintainability and Quality Assurance, 9/89] 详细定义了存在的四个级别的需求:
-
级别 1,任务级别 - 这是很高的级别,并且很早就稳定下来了。
-
级别 2,系统级别(已分配)- 在这个级别也很早就稳定下来了。这些需求从任务级别派生,然后分配到各段。
-
级别 3,子系统(或段)级别(派生的)- 此级别的需求是从分配到段的系统级别需求派生的。
-
级别 4,配置项(硬件配置项 [HWCI]、软件配置项 [CSCI])级别(详细的)- 也是从上一级别分配下来然后进行优化的。
需求级别和到 RUP 的映射
通常,在级别 3 对合同进行竞标活动。NASA 习惯按这种方式处理需求,并且与 NASA
交易的任何组织采用类似的分类法也是很自然的。开发人员在研究如何派生出较低级别需求时仍有相当大的灵活性,但是如果提供了极其抽象的任务级别需求(这些需求通常更像程序级别需求),则系统级别需求就能够自然地随功能的分解而派生出来。虽然如此,但随着对企业体系结构的关注,即便是通过使用体系结构来派生出系统需求也会变得越来越普通。上图说明了此问题并显示了
NASA 级别到 RUP 工作产品(包括业务建模)的映射。注意,在 RUP 流程中,传统流程中显示的分配是如何在用例实现流程和随后的行为聚集过程中执行的。蓝色虚线链接相似级别上的工作产品。
|