《需求工程—软件建模与分析》阅读笔记一

     软件经历了以“机器”为中心，以“应用”为中心，以“企业”为中心的发展过程，随着“应用”为中心的软件发展，原来的个体化“软件作坊式”的软件开发模式显示出了很多的问题，针对这些问题，人们在不断地讨论与制定对策，在软件开发技术和软件开发过程与管理方面都取得了很多进步。

     根据很多方面的调查显示，在所有的软件开发项目中，项目成功的几率是很小很小的。造成这些软件问题的一个很重要的原因是：未能很好地理解和掌握应用型软件的模拟特征以及由此而产生的一系列影响和要求。

 

      软件可以分为：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和应用型软件。不同种类的软件的评判标准是不一样的，面对不同的用户他们有不同标准。这就要求软件需求的全面性。产生需求问题的最大原因是应用型软件的模拟特征理解不透彻或应用不坚决。同样，非技术性和社会性因素重视不足、传统需求分析的方法的缺陷也会带来需求问题。需求工程必须说明软件系统将被应用环境及其目标，必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明，需要妥善处理目标、功能和约束随时间的演化情况。

 

     需求工程分为需求开发、需求管理，需求开发分为需求获取、需求分析、需求规格说明、需求验证。

 

    【IEEE1998】将需求分为功能需求、性能需求、质量属性、对外接口、约束5类，即两大类功能需求和非功能需求。

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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