下载掌阅APP，畅读海量书库
立即打开
软件工程是开发、运行、维护和修复软件的系统方法。软件需求是一个为解决特定问题而必须由披开发或被修改的软件展示的特性。这个问题可能是使用软件的某人的任务中的一个自动化部分，或是支持委托开发软件的组织的业务流程，或修正当前软件的缺点，或是控制一个设备等。
软件需求主要包括功能需求、非功能需求、设计约束；业务需求、用户需求、系统需求。其中，所有软件需求的一个基本特性就是可验证性。验证某些软件需求可能很困难或者成本很高。软件需求和软件质保人员都必须保证，在现有的资源约束下，需求可以被验证。
功能需求：是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。
非功能需求：是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等。
设计约束：也称为限制条件、补充规约，这通常是对解决方案的一些约束说明，例如必须采用国有自主知识版权的数据库系统，必须运行在UNIX操作系统之下等。
业务需求（Business requirement）：是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。
用户需求（User requirement）：是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础土进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。
系统需求（System requirement）：是从系统的角度来说明软件的需求，它包括用特性说明的功能需求，质量属性，以及其他非功能需求，还有设计约束。
需求过程是一个包括创建和维护系统需求文档所必需的一切活动的过程，通常包括需求开发和需求管理两大工作。
需求开发：包括需求捕获、需求分析、编写规格说明书和需求验证四个阶段。在这个阶段需要确定产品所期望的用户类型、获取每种用户类型的需求、了解实际用户任务和目标，以及这些任务所支持的业务需求、分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型、对需求进行评审等工作。
需求管理：通常包括定义需求基线、处理需求变更、需求跟踪等方面的工作。
而对于需求过程而言，最重要的还是需求开发，而需求开发总结起来就是包括需求捕获、需求分析、需求规格化、需求验证四个环节。需求捕获是为了收集需求信息，需求分析则是在需求捕获的基础上进行分析、建立模型，然后将其进行规格化形成《软件需求规格说明书》，最后再通过客户和管理层进行验证。
需求规格化的工作就是编制《软件需求规格说明书》，具体的方法和注意事项请参考有关文档编制的相关章节。而需求验证的工作则包括组织一个由不同代表组成的小组，对需求规格说明书和相关模型进行审查；以需求为依据编写测试用例，为确认测试做好准备；在需求的基础上，起草第一份用户手册；确定合格标准，也就是让用户描述什么样的产品才算是满足他们的要求和适合他们使用的。
需求调查和问题定义的主要内容包括：要捕获的信息、信息的来源、需求捕获技术（用户访谈、用户调查、现场观摩、文档考古、联合讨论会）。当我们知道需要去寻找什么信息，并且也找到了信息的来源地，接下来就需要选择合适的技术进行需求捕获了。在此，我们列举出一些最常用的需求捕获技术。
（1） 用户访谈
用户访谈是最基本的一种需求捕获手段，也是最基本的一种手段。其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
准备问题：进行用户访谈之前，最好先对要询间的问题进行一些准备。准备的方法是围绕着想要获取的信息展开，设计一系列的问题，按顺序组织起来。而且还要预先准备好记录方式，主要包括本人记录、第三人记录或者是录音/录像的形式，不过采用录音/录像的方式应该征得被访谈者的同意，而且这种方法虽然看上去比较有效，不容易丢失信息，但这也会给后面的整理工作带来一定的工作量和难度。
访谈时的技巧：在访谈时一定要注意措辞得当，在充分尊重被访谈者的基础上，尽量避免出现“我不知你在说什么”，“我是来帮助你更好地工作”这样的言语，否则将会破坏访谈的气氛，从而使访谈的效率大打折扣。在访谈时一定要注意保持轻松的气氛，选择客户有充裕时间的时段进行，在说话、问问题时应该尽量采用易于理解、通俗化的语言。另外，值得注意的是，分析人员应该在进行访谈之前进行一些相关领域的知识培训，充分阅读相关材料，以保证自已有较专业的理解与认识，让被访谈者能够信任你。
总的来说，用户访谈具有良好的灵活性，有较宽广的应用范围，但是也存在着许多困难，诸如客户经常较忙，难以安排到时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要分析员有足够的领域知识；另外，在访谈时会遇到一些对于组织来说比较机密和敏感的话题。因此，这看似简单的技术，也需要分析人员拥有足够多的经验和较强的沟通能力。
（2） 用户调查
正如前面讲到的，用户访谈时最大的难处在于很多关键的人员时间有限，不容易安排过多的时间；而且客户面经常较广，不可能一一访谈。因此，我们就需要借助“用户调查”这一方法，通过精心设计要问的问题，然后下发到相关的人员手里，让他们填写答案。这样可以有效地克服前面提到的两个问题。
但是与用户访谈相比，用户调查最大的不足就是缺乏灵活性；而且双方未见面，分析人员无法从他们的表情等其他动作来获取一些更隐性的信息；还有就是客户有可能在心理上会不重视一张小小的表格，不认真对待从而使得反馈的信息不全面。基于上述原因，因此较好的做法是将这两种技术结合使用。具体地讲，就是先设计问题，制作成用户调查表，下发填写完后，进行仔细的分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作为补充。
（3） 现场观摩
百闻不如一见，对于许多较为复杂的流程和操作而言，是比较难以用言语表达清楚的，而且这样做也会显得很低效。针对这一现象，分析团队可以就一些较复杂、较难理解的流程、操作采用现场观摩的方法来获取需求。
具体来说，就是走到客户的工作现场，一边观察，一边听客户的讲解，甚至可以安排人员跟随客户工作一小段时间。这样就可以使得分析人员更加直观地理解需求。
（4） 文档考古
对于一些数据流程比较复杂的，工作表单较多的项目，有时是难以通过说，或者通过观察来了解需求细节的。这个时候就可以借助于“文档考古”的方法，也就是对历史存在的一些文档进行研究，考古一词正是形象地说明了其主要的工作重心是结合已经填写完毕的、也就是带有数据的文件、表单、报告，从中获得所需的信息。
不过当你准备采用该方法时，也要记住这个方法的主要风险，那就是历史的文档可能与新系统的流程、数据有一些不吻合的地方，并且还可能承载一些原有系统的缺陷。要想有效地避免和发现这些问题，需要分析人员能够运用自已的聪明才智，将其与其他需求捕获技术结合对照。还有一个负面因素就是，这些历史的文档中记载的信息有可能涉及到客户的商业秘密，因此对数据信息的保密也是分析人员基本的职业道德。
（5） 联合讨论会
这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表、分析人员、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6～18人，召开时间为1～5小时。
在会议之前，应该将与讨论主题相关的材料提前分发给所有要参加会议的人。在会议开始之后，首先应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。会议的最初，就是针对所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，第三步则是大家在此基础上对新的解决方案进行一番设想，在过程中将这些想法、问题、不足之处记录下来，形成一个要点清单。第四步就是针对这个要点清单进行整理，明确优先级，并进行评审。
这种联合讨论会将会起到群策群力的效果，对于一些最有歧义的问题和对需求最不清晰的领域都是十分有用的一种技术。而最大的难度就是会议的组织，要做到言之有物，气氛开放，否则将难以达到预想的效果。