需求从哪儿来？来自于项目甲方，还是直接或间接的用户、经理、高级经理、操作人员、支持人员、测试人员，与你的系统有联系的其它系统的开发人员，或是维护人员？这是所有的正式需求的来源吗？事实上，提供需求、解释需求、指定需求和排列需求优先级是项目甲方的职责所在。此外，项目甲方有权利要求开发队伍投入时间去辨别和理解这些需求。要想以这种轻巧建模的方式获得成功，理解这个概念是非常重要的。项目甲方负责提供需求，开发组负责理解和实施。 这是否就意味着你可以坐等你的项目甲方来告诉你他们需要什么呢？当然不是。针对他们所告诉你的内容，你可以提出问题，进行分析，促使他们给出更具体的内容，甚而至于可以提出你自己

解决需求建模中的常见难题 为了能以灵巧的方式进行需求建模，需要具备一定的条件。但不幸的是，很多项目组并不具备。需求建模工作常常被你所处的环境所影响和破坏，一般是组织所奉行的文化不利于有效的软件开发或者项目甲方不清楚他们的决定所带来的影响。在这一节中，我列出了一些在需求建模中多数项目组经常碰到的问题，并讨论了可能的解决方案。这些常见的难题如下： 难于接近项目甲方（Limitedaccesstoprojectstakeholders） 项目甲方分散在各处（Geographicallydispersedprojectstakeholders） 项目甲方不知道他们想要得到的是什么（Pr