软件架构师的工作很辛苦,还要面对“令人不悦”的需求分析。希望本章的内容能为软件架构师更有效地工作提供一个突破口。 1 需求分析基础 1.1 什么是软件需求
什么是软件需求?简单地说,软件需求就是“这个软件到底要为用户做什么”。 IEEE的软件工程标准术语表将需求定义为:
1. 用户所需的解决某个问题或达到某个目标所要具备的条件或能力。
2. 系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力。
3. 上述第一项或第二项中定义的条件和能力的文档表述。 而RUP是这样定义需求的:
需求描述了系统必须满足的情况或提供的能力,它就可以是直接来自客户需要,也可以来自合同、标准、规范或其他有正规约束力的文档(A requirement describes a condition or either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.)。 1.2 需求捕获VS.需求分析VS.系统分析
需求捕获是获取知识的过程,只是从无到有、从少到多。需求采集者必须理解用户所从事的工作,并且了解用户和客户希望软件系统在哪些方面帮助他们。
需求分析是挖掘和整理知识的过程,它在已掌握知识的基础上进行。毕竟,初步捕获到的需求信息往往处于不同层次,也有一些主观甚至不正确的信息。而经过必要的需求分析工作之后,需求会更加系统、更加有条理、更加全面。
那么系统分析呢?如果说,需求分析致力于搞清楚软件系统要“做什么”的话,那么系统分析已经涉及“怎么做”的问题了。
需求捕获、需求分析以及系统分析之间的关系我们必须理解透彻,否则就会影响工作的有效性进行。
在实践中,需求分析和需求捕获的关系常常令人困扰。究其原因,是因为需求捕获、需求分析并不是先后进行的的两个阶段性工作,相反,它们往往是相互伴随、交叉进行的:需求工作伊始,无疑更多的是进行需求捕获工作,相伴进行的需求分析和整理工作占的比例偏少;但随着掌握的需求信息越来越多,我们需要开展的对需求的分析和整理工作也越来越多了。
同样,在实践中,需求分析和系统分析也常常被混淆。需求分析致力与搞清软件系统要“做什么”,而系统分析更关注“怎么做”的问题,比如大多数分析方法(如OOA)应该术语系统分析的范畴。 1.3 需求捕获及其工作成果
典型的需求捕获的工作成果是一摞“需求采集卡”(如表1-2所示),其中记录了需求类型、需求描述、需求背景、需求提出者和需求记录者等对进一步的需求分析非常有用的信息。