这周我了解到的是限制条件和估算产品的成本，对需求的了解更加深入。
限制条件
需求限制条件通常是全局性的需求。因为它们是限制条件，所以有助于确定哪些功能子
集可以包含到最终产品之中。限制条件会影响产品范围的决定: 也许它们限制了项目可以花
的时间或金钱，也许它们是事先规定的设计决定，限制了问题的解决方式。可以将限制条件
看作是特殊类型的需求，为需求收集工作关注的重点提供了指导。管理层、市场人员或者客
户可能已经知道了这些限制条件。项目启动时的任务是得到并记录这些限制条件。Volere 需求规格说明模板的第4 部分“强制的限制条件”完整地描述了如何记录限制条件。可以参考附录B中的模板。解决方案限制条件。
需求规格说明中应该有一部分用来描述任何关于问题的指令性设计或者解决方案。管理层或其他人对最终设计有这种期望，其他的设计一概不予考虑。尽管我们警告过不要在弄清所有需求之前就设计解决方案，但是这可能有一些优先的原因，诸如市场、文化、管理、政策、人们的期望、财务等，这些原因决定了只有一种设计方案可被接受。如果是这种情况，它应该写入需求规格说明。
所有的伙伴或协作应用程序也应该在启动会议上列出并记录。伙伴应用程序是那些产品
必须与之合作的应用或系统。例如产品可能与一些已有的数据库、报表系统或基于Web 的
系统有一些接口，因此那些产品的接口就成为产品的限制条件。指定选择的操作系统也属于
这一类。如果使用商业上架销售(COTS) 应用软件和开放源代码的应用程序，将它们也包括在这部分里。也许产品必须与COTS或开放源代码应用进行交互，或者产品必须在最终解决方案中包含它们。可能指定它们有很好的理由，但是也可能没有。关于使用预先构造好的软件是否真的是一个明智的决定，启动会议是个很好的机会，让开发者与风险承担者就这一问题得到一致意见。
估算产品的成本
在项目启动的时候，开发者已经获得了许多信息，可以据此对费用和工作量进行基本估
算。所需的工作量通常与工作领域包含的功能数量是成比例的。这种关系是有意又的: 工作
领域完成的功能越多，就需要越多的工作量来研究它并设计解决方案。在这个阶段不知道产
品的规模(它将包含多少功能)，但是知道工作领域的规模。也就是说，如果对工作领域进行
测量，就会知道它的规模。测量工作领域的规模或功能的最简单的方法就是计算上下文模型中相邻系统的数目和输入输出数据流的数目。尽管存在更准确的测算规模的方法，但是数一下输入输出数据流的方法很快，而且比凭空猜测规模要好很多。
如果上下文范围中有超过30个输入输出数据流，那么它就在“每输入/输出数据流的平均费用”能估计的范围之内。简单来说，机构收集每一个输入输出数据流的需求都有一个平均费用。这个数据可以通过以前的项目来获得，用被调在系统的费用除以上下文范围中输入输出数据流的数目即可。更精确的费用可以通过影响工作的业务事件的数目来确定。我们将在第4章“事件驱动用例”中讨论这种方法。同时，如果同意业务事件可以从上下文范围模型中导出，那么它们的数目就是产品费用的一个决定因系。当然，这需要知道组织平均分析每个业务事件的费用。可以通过以前的项目知道这方面的信息，或者如果需要的话，进行一些基准测试。
现在我对估算成本有了更深的认识，然后对限制条件有了一定的了解。