《需求工程——软件建模与分析》读后感之二

　　最近老师讲了项目的前景与范围，还有相关者分析，正好看书看得这一章。

　　在一个项目开始之前，首先我们需要考虑一个问题就是为什么要启动这个项目，也就是说，这个项目的目标是什么？

　　项目的目标是系统的业务需求。在很多情况下，相关者可以清晰地表达出系统的业务需求，这时可以通过安排和相关者的面谈来明确项目的动机。但也有很多情况下，相关者无法表达他们的业务需求，或者表达的业务需求不够清晰。因此，要发现系统的业务需求，还是要从用户的问题开始。要分析相关者的问题，首先要明确问题，将它们变得清晰，变得适宜进行分析。这个过程从问题和相关的背景描述开始。

　　问题一般有单方相关者提出，因此在和所有相关者对其进行讨论之前，先要就问题本身达成一致，达成共识。具体的方法就是用标准化的格式描述问题，并在相关者之间取得认同。达成共识的问题是一致的问题，但一致的问题不一定是明确的问题。问题的明确性要求它们具有易于理解和能指明解决方向两个特点。

　　只有当相关者在现实世界中遇到问题时，才会试图引入软件系统来达到某些目的，因此他们对问题是感触颇深的。为发现业务需求而需要探讨的问题是指一些高层次的问题，是和组织的战略目标、利益分配、政策规划、业务流程等内容相关的问题。那些和具体业务的细节相关的问题不属于高层次问题。

　　为了从高层次问题推导出业务需求，需要对问题进行一定的分析。在问题分析过程中，还可以根据问题确定系统高层次的解决方案和系统特性，它们可以帮助回答项目启动之初的第二个问题——“项目打算做什么”。

　　根据系统的高层解决方案和系统特性，可以定义系统的上下文环境，建立系统边界。这将是需求分析活动的起点。

　　业务需求、高层解决方案及系统特性都应该被记录下来，定义为项目前景与范围文档。以为后续的开发工作打好基础。前景描述了产品的作用以及最终的功能，它将所有相关者都统一到一个方向上。范围则指出当前项目是要解决产品长远规划中的哪一部分，范围声明它为项目划定了需求的界线。

　　在需求获取的诸多获取源中，人是需求的主要来源和问题域知识的重要来源，所以得到人脑内的知识是非常重要的。但人们往往很难清晰、有条理、严谨地表达自己的知识，所以要完整得得到人脑内的知识是具有一定困难的。实际上在对人进行需求分析之前，还有一个更重要的问题需要解决——哪些人是需求获取的合适对象？在软件系统规模日益扩大的同时，人们已经无法简单地确定人是软件系统的功能的信息来源。因此，人们需要首先搞清楚哪些人对软件系统的开发和应用具有发言权和决定权。我们需要对跟软件有关的人进行分析，也就是相关者分析。

　　往往常见的相关者有：用户、客户、投资者、开发者、管理者、领域专家等。这些都是一些笼统的类别，但是在实际开发过程中，需要的是一个更加细化的分类体系。所有往往在我们分好大类之后，在进行详细划分，同时找到关键的相关者。

　　课堂上，在老师的组织下，我们进行了一次相关者分析的过程，从某一项投标项目中，找出里面的相关者，并对其进行识别分析。首先我们决定了头脑风暴的形式。采用了非结构化的模式，大家畅所欲言，有什么看法说什么。但是我们小组的同学都没有看完这本投标书，所以我们采取了一下措施，首先粗略浏览投标书，并把其中与相关者无关的内容删掉。大大减少阅读量。然后分析功能，从各大功能中反推出相关者。比如其中的用户，管理者，投资者等等。然后从中再找到关系的相关者，写出关键相关者的特征等等。由于大家对相关的操作并不熟练，所以最后头脑风暴结束后，发现结果并不尽人意。不过在这次头脑风暴中对相关者分析的过程熟悉了一把。

　　在实践调查中，一次又一次地发现缺乏足够的用户参与是导致项目失败的一个重要因素。参加一次跟物流专业的同学合作的项目，帮忙设计一款物流管理平台。由于自己并不熟悉物流相关方面的知识，他们也知识从课本上获取的大概知识。在面谈交流过程中，往往并不能获取自己所要的内容。最后回去补了一些相关知识，才搞明白。

 

 

　　最近老师讲了项目的前景与范围，还有涉众分析，正好看书看得这一章。

　　在一个项目开始之前，首先我们需要考虑一个问题就是为什么要启动这个项目，也就是说，这个项目的目标是什么？

　　项目的目标是系统的业务需求。在很多情况下，涉众可以清晰地表达出系统的业务需求，这时可以通过安排和涉众的面谈来明确项目的动机。但也有很多情况下，涉众无法表达他们的业务需求，或者表达的业务需求不够清晰。因此，要发现系统的业务需求，还是要从用户的问题开始。要分析涉众的问题，首先要明确问题，将它们变得清晰，变得适宜进行分析。这个过程从问题和相关的背景描述开始。

　　问题一般有单方涉众提出，因此在和所有涉众对其进行讨论之前，先要就问题本身达成一致，达成共识。具体的方法就是用标准化的格式描述问题，并在涉众之间取得认同。达成共识的问题是一致的问题，但一致的问题不一定是明确的问题。问题的明确性要求它们具有易于理解和能指明解决方向两个特点。

　　只有当涉众在现实世界中遇到问题时，才会试图引入软件系统来达到某些目的，因此他们对问题是感触颇深的。为发现业务需求而需要探讨的问题是指一些高层次的问题，是和组织的战略目标、利益分配、政策规划、业务流程等内容相关的问题。那些和具体业务的细节相关的问题不属于高层次问题。

　　为了从高层次问题推导出业务需求，需要对问题进行一定的分析。在问题分析过程中，还可以根据问题确定系统高层次的解决方案和系统特性，它们可以帮助回答项目启动之初的第二个问题——“项目打算做什么”。

　　根据系统的高层解决方案和系统特性，可以定义系统的上下文环境，建立系统边界。这将是需求分析活动的起点。

　　业务需求、高层解决方案及系统特性都应该被记录下来，定义为项目前景与范围文档。前景描述了产品的作用以及最终的功能，它将所有涉众都统一到一个方向上。范围则指出当前项目是要解决产品长远规划中的哪一部分，范围声明它为项目划定了需求的界线。