Question

软件工程：需求模式和方法的多样性

Answer 1

没有正确或者的制定或表述需求的方法。对于给定的系统，没有一套完美的需求。不同的需求方法以不同的方式分解问题，得到的需求的粒度以及表达的方式也不同。本节中的“需求方法”一词只是表示概括的定义需求的一种方式或者是定义某些类型的需求。每种方法可能有自己的一套需求模式。它们可能是这种方法的承认的标准模式的独特表现方式，或者它们是这种方法的特定模式。
　　我们可以提供各种各样的需求方法——使每种方法的支持者可以建立自己希望的需求模式，以及模式特有的声明。明确承认不同的方法，可以使分析师更清楚可用的选择。
　　然而，标准模式越一致（模式表现形式越少）越好。四人帮的设计模式一直没有明确的变化的要求（尽管已经出现了很多意见），这可能证明了设计模式选择的优秀，因而也没必要提供多套设计模式。考虑到有多种需求方法，笔者利用了对本书中的需求模式的潜在的批评。并引用它们作为没有正确的一套需求模式的证明。如果任何人不喜欢它们，完全可以自己设计一套，而不必要求替换它们。不同方式的思考可以在这里共存。
　　为了避免可能的混淆，不要在同样的需求模式中混合多个需求方法的材料。模式有多个声明，但是在一个系统中只选择一种会更清楚。
　　当使用一个特定的需求方法建立新的模式（或者现有的模式的声明）的时候，考试,大提示在模式的“声明”部分陈述这个方法。需要注意的是当使用一个不同的方法建立声明，它就具有了自己的生命，可能经历一连串的版本，独立于最初的“标准”方法的声明。
　　如果存在两套需求模式覆盖相同的范围，有两种组织的方法：
　　1.一个领域规格可以包括两套需求模式。（一个“领域规格”是一个文档，或者文档的一部分，它包含它的需求模式，还有一节是关于它的基础架构。下面的八个领域每一章就是一个领域规格。）
　　2.领域规格可以有两个声明，每一个声明包含一套需求模式。
　　第二种方法更容易，更不容易使人迷惑（这样系统分析师不容易使用了错误的模式的声明）。第二种方法也允许裁剪基础架构规格的声明，以适合模式使用的方法论，如果基础架构的需求使用了这些模式将会很有用。