对于需求过程，范围是首要步骤。项目启动会议是为接下来的需求发现工作奠定基础，并确保项目成果需要的所有东西都已到位，主要利益相关者聚在一起对关键项目的问题达成一致意见。会议参与者有主要利益相关者：客户、关键用户、首席需求分析师、技术和业务专家，以及其他对项目的成功具有关键作用的人物。
项目启动，基本假定：如果意见软件（或设备、服务）要开发，那么它必须为拥有它的人提供最理想的价值。包括1. 项目的目标2. 工作的范围3. 利益相关者4.名称：项目中使用的特备术语5. 相关事实和假定：是否有一些特殊事实需要让大家知道？是否做了一些假定，而这些假定会影响到项目的结果？6. 估算的费用7. 风险8. 继续或终止的决定
项目启动的主要讨论内容为
l 确定业务问题的范围（上下文图）：争取让利益相关者达成一致意见，认为拥有者的组织机构的这个部分需要改进。
l 确认了需求发现工作中要包含的功能。
l 确认了需求发现工作中明确排除在外的功能。
确定业务问题的范围通常是最方便的启动方式。产品开发周期的第一项任务就是定义工作（安装了产品后，将会发生改变的业务）的准确范围。不能从环境中分离工作。任何一部分工作，都必须至少和另一部分工作有联系。所有活动都是由数据驱动，活动与活动有联系，这种联系就是数据流。为了实现拥有者的最佳价值，就要研究足够的拥有者的工作，以确定什么有价值。工作上下文范围图确定了我们打算研究的工作的边界。该图将工作显示为一个活动，周围围绕着相邻系统。命名的箭头代表了相邻系统和我们的工作之间的数据流。相邻系统是决定不研究的活动。工作上下文范围展示了工作的职责和相邻系统的职责起止之处。在多数情况下，如果项目只研究他们想象中的产品应该包含哪些内容，构建的产品一般不太有用。常常会遗漏对拥有者很有价值的功能。同时也要考虑扩大工作范围的可能性。你会发现其他部分的自动化或其他类型的改进，可能也是有价值的。范围、目标、利益相关者的三位一体。每个项目都可能有几十种利益相关者。你要为拥有者创造价值，这可能意味着和很多人交谈，他们都可能是需求的来源。项目目标是最高层次的需求。如果不能清楚地知道产品打算做什么，不知道怎样度量产品地成功，那么就不可能构建出正确地产品。
案例分析：
在IceBreaker项目中，首席需求分析师协调整个小组的讨论，直到他们对工作的范围（也就是要研究的业务领域）以及工作所包含的功能，怎样联系达成一致意见。
会议参与者在白板上画出上下文的范围模型，展示工作所包含的功能，并引申开来，展示他们认为在冰情预报业务范围之外的东西。
由此明显可见，该圆角矩形代表业务范围，系统用例图和上下文图通常用来定义系统边界。
对于这次上课为什么回答不出来这个问题进行反思，回答说是“目的”，现在看来是没有明白这道题的上下文语境。课上效率不高，没有明确这节课的重点知识。及时在后来有人告诉答案，也因为某种原因没有得到老师的认可。年龄已经不小了，却不能顺利的将自己的信息传达出去。回答问题做不到干净利落，使他人听清。软件工程是针对人的学科，在于和人的交流，正确传达出自己的信息，知他人心。介于此番博客，反思下自我的弱点。是个看以智商卓越、性格完美为主角的IP看多了的人，无论是上课的引例福尔摩斯还是天明等的异次元人，他们身上有着难以企及的高度，福尔摩斯推理的缜密与睿智，天明的运气与永不言败等优秀的主角光环，相比于缺点（使他们更有人情味）他们身上都是那么的完美。我不知道我是谁，是个整天胡思乱想的小女孩，是个傻笑与略带娇羞的疯子？在几次参加比赛中，总会被指责怎么不说话，后他们又以还小来缓解气氛。可是，知道的是快要进社会了，要得有养得起自己的一技之长。其实，就像今天上课说得那样，等你什么东西都学不到的时候你就该跳槽了。人生来就是一步步成长的，向自己心中的那个样子慢慢的学习与前进。你是你，你不能决定生与死，但你也可以促进成为促进经济生长，缓解老龄化的那一个人，小小尘埃总会有自己的用处。