本篇文章是软件工程课程的课后作业，阅读一本关于软件工程的书，然后写随笔或读后感。 我阅读了软件工程：实践者的研究方法， 然后对其中的需求分析有很多的感谢，

正好结合我们的大作业进行分析。我们小组的大作业是《联机对战五子棋》，在开发过程中遇到了很多问题，都与需求分析分割不开，正好借此机会用书中的知识或方法，分析我们软件或软件开发过程中的需求问题。（结合了大作业的部分将用黑体字加粗）

 

一.引言

      设计和编写软件富有挑战性，创造性和趣味性。事实上，编写软件是如此吸引人，以至于很多软件开发人员在清楚地了解用户需要什么之前就迫切地投入到编写工作中。

开发人员认为：在编写过程中事情总会变得清晰，只有在检验了软件的早期版本后项目利益相关者才能够更好地理解要求；事情变化太快，以至于理解需求细节是在浪费时间；最终要做的是开发一个可运行的程序，其他都是次要的。

      虽然这本书批判了先写出程序而不顾需求细节的做法，但其实我们的项目是适合这种开发方法的。 因为我们的选题是联机对战五子棋，这种程序遍地都是，QQ游戏大厅就有五子棋游戏，而且这个项目相对来讲是相当小的项目，在写程序之前，甚至刚立项的时候，我们就对这个项目有了一个整体的把握。 整个程序的框架是一目了然地，所以这种先写出程序，然后再添加细节的方法一定程度上是可行的。 但考虑到我们的经验不足，写代码能力的欠缺，如果没有做需求分析，其实还是会遇到相当多的问题。比如我们的开发过程中，需求分析写得十分简陋，可以说只是分析出我们需要有图形化的棋盘和联网功能（等于什么都没分析），所以在后面的详细设计，测试计划，以及编码的过程中都走偏了。

      需求工程在设计和构造之间建立起联系的桥梁。桥梁源自何处？有人可能认为开始于项目利益相关者（如项目经理，客户，最终用户），也就是在他们那里定义业务需求，刻画用户场景，描述功能和特性，识别项目约束条件。其他人可能会建议从宽泛的系统定义开始，此时软件只是更大的系统范围中的一个构件。但是不管起始点在哪里，横跨这座桥梁将把我们带到项目之上更高的层次：允许由软件团队检查将要进行的软件工作的内容； 必须提交设计和构建的特定要求； 完成指导工作顺序的优先级定义；以及将深切影响随后的信息，功能和行为。

     需求工程为一下工作提供了良好的机制： 理解客户需要什么，分析要求，评估可行性，协商合理的方案，无歧义地详细说明方案，确认规格说明，管理需求以至将这些需求转化为可运行系统。需求工程过程通过执行七个不同的活动来实现： 起始，导出，精华，协商，规格说明，确认和管理。重要的是注意到，某些需求工程任务并行发生且要全部适应项目的要求。

 

二.起始

    起始阶段包括客户沟通和策划活动。通过与利益相关者协作定义软件的业务需求，提出系统大致的架构，并制定开发计划以保证项目开发具有迭代和增量的特性。该阶段识别基本的业务需求，并初步用用例描述每一类用户所需要的主要特征和功能。此时的体系架构仅是主要子系统及其功能、特性的试探性概括。随后，体系结构将被细化和扩充为一组模型，以描述系统的不同试图。

    在项目的起始阶段中，要建立基本的理解，包括对问题，谁需要解决方案，所期望解决方案的性质，与项目利益相关者和开发人员之间达成初步交流合作的效果。

 三.导出

    询问客户、用户和其他人，系统或产品的目标是什么，想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作，这些问题比其看上去的要难得多。

Christel 和 Kang 指出了一系列的问题，可以帮助理解为什么导出需求这么困难。

①范围问题： 系统的边界不清楚、或是客户或用户的说明带有不必要的技术细节，这些细节可能会导致混淆而不是澄清系统的整体目标。

②理解问题：客户或用户并不能完全确定需要什么，他们对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在沟通上存在问题，省略那些他们认为是”明显的“ 信息，确定的需求和其他客户或用户的需求相冲突，需求说明有歧义或不可测试。

③易变问题：需求随时间变化

    实际上，这个问题我们在大作业的过程中也遇不到，不仅我们没有，其它小组应该也不会遇到，准确地说是不会去考虑这些。因为我们的系统开发出来大多数是不会直接交付使用的，大多数是以学习为目的，并不会真的将大作业给目标人群使用。再加上事先没有对目标人群做调研，我们没有我们想象中的那么了解客户需求。我们的需求是自己臆想出来的，想的更多的是实现这个程序，而不是符合用户需求的真正好用的。 而我们小组一边承担了开发者的角色，一边又承担了用户的角色，所以这个项目的需求并不是真正的用户的需求，而是我们的需求，所以这比较遗憾，我们没有与通过与客户交流导出需求的阶段。

    我对需求分析的理解是它更多的是一门谈话的艺术，我们要引导客户说出他们的需求，让开发者和客户理解彼此之间的想法，这其实应该是特别难得一件事。

 四.精化

   在起始和导出阶段获得的信息将在精化阶段进行拓展和提炼。该任务集中于开发一个精确的需求模型，用以说明软件的功能、特征和信息的各个方面。

   精化是由一系列的用户场景建模和求精任务驱动的。这些用户场景描述了如何让最终用户和其他参与者与系统进行交互。解析每个用户场景以便提取分析类--最终用户可见的业务实体。应该定义每个分析类的属性，确定每个类所需要的服务，确定类之间的关联和协作关系，并完成各种补充图。

五.协商

       只给定了有限的业务资源，而客户和用户提出了过高的要求，这是常有的事。 另一个相当常见的现象是，不同的客户或用户提出了相互冲突的需求，并坚持“我们的特殊要求是至关重要的”。

    需求工程师必须通过协商过程来调节这些冲突。应该让客户，用户和其他利益相关者对各自的需求排序，然后按优先级讨论冲突。使用迭代的方法给需求排序，评估每项需求对项目产生的成本和风险，表述内部冲突，删除、组合和修改需求，以便参与各方均能达到一定的满意度。

六.规格说明

    在基于计算机的系统的环境下，术语规格说明对不同的人有不同的含义。一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或上述各项的任意组合。