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

  话不多说,直接开始我的这次的总结。

  软件系统当中常见的涉众类别有用户、客户、开发者、管理者、领域专家、政府力量和市场力量。

  ①用户是最终使用和操作产品的人,他们使用软件的目的是为了更好地完成自己的任务,满足组织的目标要求。在大多数的软件开发中,用户都是主要的信息来源。而且只要软件系统的用户的实现的用户能够被清晰地确认,他们就应该得到足够的重视。

  ②客户是为软件系统的开发付费的人。在制定软件的开发中,他们本身也是用户,通常是用户中的领导或者代表。软件系统的成本和收益是处于客户角色的人们最为关心的内容,因为他们对系统运行环境、技术限制、法律法规约束等都有自己的要求。处于获益的想法,他们还常常会代替用户表达想法,在找不到明确用户的时候可以用他们作为一个合适的用户替代源。但他们毕竟不是真正的用户,所以在用户可以明确的时候,就不能因他们而忽略了用户。

  ③开发者是负责实现软件系统的人。包括软件工程师、设计人员、程序员、测试人员、集成人员等。开发者也关心系统软件的成本和收益,但与客户不同的是他们从技术的角度来考虑成本和收益,而客户更多的是从经济的角度在看待问题。只有在技术上经过可行性分析和成本/收益衡量的需求才是完整的需求,开发者的技术考虑也是需求的一种重要属性。

  ④管理者是指参与软件系统开发事务管理的人。常见的管理者包括:

    i. 投资方管理者,他们的天都和关注点会影响整个软件系统的开发进程,例如视时间为第一要素的投资方管理者会使得软件系统的开发尽可能地走捷径。

    ii. 执行负责人,他们是投资方在项目管理中的代表,对产品的完成有最终的管理权。

    iii. 项目管理者,他们是开发放负责管理项目日常工作的人。

  ⑤领域专家是在问题域中具有丰富知识的专家。他们通常不会受到软件系统的影响,但是在软件系统开发中却是一类非常重要的涉众。在自身工作所涉及的那部分问题域中,普通用户也可以算是对领域知识非常精通的人。但是和领域专家相比,用户通常具有立场的限制,他们看问题时从自己的角度出发,难免就会有所偏颇,而领域专家就更能从全局和统一的角度来分析问题。而且和普通用户相比,领域专家能够更好地提供概括性和综合性的知识,也能够更好地解决默认知识问题。

  ⑥政府力量:很多软件在功能上都存在着收到法律法规约束的问题,因此政府力量也是系统软件开发的一类重要涉众。

  ⑦市场力量是指组织中的市场部门人员。他们在市场当中的经验可以帮助判断软件的前景,重要功能和预期收益。而且在售前推销、售后服务和售后技术支持中,在一个广泛的范围内,他们能够了解大量用户的普遍想法,所以他们往往也是一种重要的用户替代源。

  上述的涉众类别知识一种具有普遍意义的分类,在实际的软件开发中,需求的是一个更加细化的分类体系,尤其是针对用户类别而言,仅有一个笼统的用户概念是远远不够的。需要特别指出的是,软件系统的涉众群体不是固定不变的。随着项目的进行,某个个人可能会从一类涉众变为另一类涉众。随着外界条件的变化,某个涉众类别可能会发生兴趣和关注点的转移。随着项目的深入,单个涉众类别可能会在不同的时间表现出互相冲突的不同要求。所以,对涉众的理解不是一个完成之后就可以结束的活动,而是应该在完成之后继续保持适当的关注。

时间: 2024-10-11 18:57:09

《需求工程——软件建模与分析》阅读笔记二的相关文章

<<软件需求最佳实践------SERU过程框架原理与应用>>读书笔记一(全书浅览)

这一学期上了软件需求分析这门课,在老师的建议下自己选择了这本需求最佳实践作为精读课本.大概的阅览了整本书后发现,作者引用各种实例与隐喻意图让读者更好的理解这本书的内容,而且每一部分内容都有一条精炼的SERU诫语来作为一个小结.在我看来,这本书确实对于我们软件需求分析的初学者来说确实是不可多得的“良本“. 全书分为三大部分,其中第一部分:“原理.模型与误区“涵盖前三章的内容.这部分作者主要分析并提及了影响软件项目实施,并导致软件出现“危机”的根本原因,即需求分析阶段. 主要是让我们认识到软件需求在

《软件需求最佳实践》阅读笔记一

这本书主要从软件需求实践中出现的主要问题和困难入手,指出了改造的主要方法,然后逐一说明了需求定义.需求捕获.需求分析与建模.编写规约.需求验证等需求开发活动的任务.要点和具体手段.还对包括需求基线.变更管理.需求跟踪在内的需求管理活动的操作要点进行了阐述. 软件项目实施过程中,会遇到很多的问题,有的甚至许多项目根本无法达到预期的目标,这些问题的根源就是软件需求实践.“在中国做软件太难了!客户连自己的需求都说不清楚!”,这种抱怨的话经常被做软件需求的人说到.需求失败也是因为不完整的需求.缺乏用户参

《软件需求模式》阅读笔记02

通过上一次对<软件需求模式>前两章的阅读,我了解了需求是什么,而作为这本书的书名,我们自然就要了解什么是需求模式以及如何编写和使用需求模式. 所谓的需求模式,就是定义一种特定类型需求的方法.然而使用需求模式能够给我们带来什么好处呢?第一,需求模式提供指导:建议包含哪些信息.提出忠告.提醒常见缺陷以及指出其他应该考虑的问题:第二,需求模式节省时间:不需要从头开始写每一个需求,因为模式给予了合适的出发点,以及开发的基础:第三,需求模式促进同种类型需求的一致性.在了解了需求模式的大概的内容之后,我们

《软件需求最佳实践》阅读笔记二

需求捕获是需求开发中的第一个活动,每个团队都必须提高需求捕获的有效性,要点在于计划性和科学性. 需求捕获的过程是人和人打交道的过程,需求捕获需要需求分析人员积极主动的去获取需求,是散网打鱼,而不是休闲钓鱼:在对用户进行需求提问时,要善于聚焦访谈话题:用户的需求是一个冰山,有很多潜在的需求我们不容易意识到,而理解业务场景有助于需求分析人员更深层次的理解用户的需求.需求捕获有很多种方法,(1)用户访谈:最常见.最基本的需求捕获技术,直接有效.形式灵活,但是要避免占用时间长和用户信息的片面性,最常见的

《软件需求模式》阅读笔记之二

在前面了解了什么是需求,什么是需求模式之后,接下来就应该学习如何使用和编写需求模式.我们不仅到了解需求模式的含义,更要学会在什么情况下使用需求模式.在定义系统期间,有两种场合使用需求模式:1.当定义需求时,看是否存在一个模式可以指导如何定义这种需求.2.当考虑系统需求是否完全时,浏览主题覆盖的整套模式——看是否有遗漏,或者是否需要添加什么东西.3.当评审需求规格时,模式可以帮助检查需求的质量,确定还有哪些主题没有定义,理解特定需求的意义和内涵.4.当评估系统的规模以及开发所需的工作量时,基于需求

《软件需求模式》阅读笔记03

在对需求模式的概念和内容方面有了深刻的了解之后,我将学习各类不同的需求模式. 基础需求模式是所有种类的系统都可能需要的一些东西,它包括了:技术.遵从标准.参考需求.文档.系统间接口.系统间交互.系统间需求模式是用来定义被定义的系统和任何与之交互的外部系统或组件之间的接口的基本细节,它包含了以下内容:接口名称.接口标识符.两端的系统.接口的目的.接口的所有者.定义接口的标准.用于接口的技术.在开发测试的时候,我们应该明确交互需求,找到隐含的交互以帮助满足间接陈述的目标.系统间交互需求模式是用来定义

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

需求的定义:用户为了解决问题或达到某些目标所需要的条件或能力:系统或系统部件为了满足合同.标准.规范.或其他正式文档所规定的要求而需要具备的条件或能力:对以上两点的一种文档化表述 满足需求就是解决问题:需求源于问题,要准确理解需求就必须明确它与问题的关系.,人们开发软件系统的目的就是希望用它作为解决方案来解决问题,使得现实改善到期望的状况.解决问题.改善现实.满足用户期望的状况. 问题解决的两个方面--问题域与解系统:问题在现实世界与软件系统的互动中的到解决,问题语是需求的背景,问题域的背景信息

软件需求最佳实践

需求建模与分析篇 需求分析基本遵循三个方向,依次是:流程,对象以及关系,用例(操作容器): 流程对应的是跨职能流程图以及活动图,对于活动图,实在是没有感到有什么优势可言:但是对于流程图究竟要细化到什么程度?只要是不影响泳道的变更就可以作为一个节点处理,这个还有待考证: 对象以及关系,作者首先推荐的是类图,但是对于类图其实使用在设计阶段,作为需求分析阶段拿了一张类图给客户看,给客户讲解你所识别出来的类?如果是给架构师以及开发团队来看还是有点意义,但是对于国内项目很多时候时间很紧急,你搞出这一套花活

《掌握需求过程》阅读笔记二

了解了一些需求过程中的方法和问题,接下来就要网罗需求.网罗工作是由需求分析师来策划的,但是要完成这个工作需要分析师.用户和其他风险承担者相互合作,要明确每一个角色各自的职责.意识到的需求是指那些用户最先想到的需求,这通常表明用户希望改进的一些事情:无意识的需求是指用户没有言明的事情:未梦想过的需求是指那些一旦用户认识到它们可能时就会要求的事情.在网罗活动的过程中,必须揭示和捕获所有的需求,网罗活动具有多面性,它使用了一些来自启动阶段活动的输出结果:业务事件在网罗活动中占主导地位. 需求网罗的第一

软件需求分析教程阅读笔记二

软件需求分析教程阅读笔记二 管理人员在要求开发一个系统时并不会理解进行需求分析的重要性,他们只知道能不能尽快开发出相应的系统来方便使用,但是如果不做好需求分析,最终开发出的系统也不会有人用. 客户的需求认识并不像软件开发人员这样,了解的比较清楚,客户通常并不懂得从系统的实际用户处得到信息的重要性,然而从产品的实际用户处收集需求有着不可替代的必要性,所以导致项目最终失败的两个原因,一个是缺乏用户参与,另一个是不完整的需求规格说明. 在进行需求分析时,只有系统的实际使用者才能清楚的描述他们要用此系统