《需求工程—软件建模与分析》1

功能需求中按抽象层次的高低分为业务需求、用户需求、系统需求。业务需求是系统的目标，用户需求是系统的任务，系统需求是系统的行为。

对于非功能需求，我们很难在系统完成之前清晰地看到，很多时候是在系统完成之后才会发现非功能需求。在解决系统成功或失败的因素中，非功能需求与功能需求同等重要，甚至更重要。

      一个优秀的需求是完整的，每个需求都完整的描述出系统所需要的功能，并将用户的期望传递给了开发人员，可以在系统及运行环境的已知条件和约束下实现，任何一个需求都是不能忽视的、无歧义的、可以验证的。

     需求工程的一些工作需要很多的活动细节，通过实践的方法来完成这些活动细节，不同的需求阶段都有其标志性的活动，都有各自的实践方法。

     需求获取中会遇到很多的困难，例如：用户与开发人员的背景、立场不同，交流存在困难；用户缺乏概括性、综合性的表述能力；用户存在认知困难；开发者为用户创造需求，用户为开发者提出解决方案；用户不好选择，用户不愿参与等等，这都要采取措施去面对、解决，有一个好的需求获取流图。

     项目开始的时候要确立项目的目标，我们要有一个共同的认识，明确的分析出问题，发现业务需求，制定一个解决方案找到系统特征，这一点在写系统时有了很多的感触，面对一个系统，不知道应该有什么样的内容，不了解用户，不知道用户会用它干什么，用户需要什么，单从自己的理解去建立系统的功能，很多时候都有一种写文章的感觉，不知道下面该有什么，下文是什么？一个功能，加也不是，不加也不是。这时候真的很需要用户的需求。

     面谈是需求获取的方法之一，他可以获得很多的内容：事实和问题、被会见者的观点、被会见着的感受、组织和个人目标。但是访谈者要注意很多问题：礼貌的倾听，选择好的时间和地点，笔录，在用户同意的条件下录音或录像。

     原型的介质有很多：纸面、幻灯动画、快速语言和工具和程序代码。纸质原型的真实感最低但其能够缓解原型方法的高成本缺点。当用户需求出现了模糊、不清晰、不完整等具有一定不确定性的特征时，就可以考虑使用原型方法。[Houde1997]认真原型的需求内容有：外观、角色、实现。

     观察可以帮助理解复杂的协同事件，获取工作中的异常处理，获取与用户认知不一致的实际知识，了解用户的认知，获取默认的知识。