信息系统项目管理师考试辅导教程第3版第 2 章软件工程基础知识.docx
《信息系统项目管理师考试辅导教程第3版第 2 章软件工程基础知识.docx》由会员分享，可在线阅读，更多相关《信息系统项目管理师考试辅导教程第3版第 2 章软件工程基础知识.docx（65页珍藏版）》请在冰豆网上搜索。
信息系统项目管理师考试辅导教程第3版第2章软件工程基础知识
“软件工程”这个概念最早是在1968年召开的一个当时被称“软件危机”的会议上提出的。
自1968年以来，该领域已经取得了长足的进步。
软件工程的发展已经极大地完善了我们的软件，使我们对软件开发活动也有了更深的理解。
开发一个具有一定规模和复杂性的软件系统和编写一个简单的程序大不一样。
其间的差别，借用Boodi的比喻，如同建造一座大厦和搭一个狗窝的差别。
大型的、复杂的软件系统的开发是一项工程，必须按工程学的方法组织软件的生产与管理，必须经过计划、分析、设计、编程、测试、维t等一系列的软件生命周期阶段。
这是人们从软件危机中获得的最重要的教益，这一认识促使了软件工程学的诞生。
软件工程学就是研究如何有效地组织和管理软件开发的工程学科。
IEEE在1983年将软件工程定义为：
软件工程是开发、运行、维护和修复软件的系统方法。
著名的软件工程专家Boehm于1983年提出了软件工程的7条基本原理：
（1）用分阶段的生命周期计划严格管理；
（2）坚持进行阶段评审；
（3）实行严格的产品控制；
（4）采用现代程序设计技术；
（5）结果应能清楚地审查；
（6）开发小组的人员应该少而精；
（7）承认不断改进软件工程实践的必要性。
软件工程方法学包含3个要素：
方法、工具和过程。
方法是指完成软件开发的各项任务的技术方法；工具是指为运用方法而提供的软件工程支撑环境；过程是指为获得高质量的软件所需要完成的一系列任务的框架。
根据考试大纲，在软件工程基础知识方面，要求考生掌握以下知识点：
•软件需求分析与定义；
•软件设计、测试与维护；
•软件复用；
•软件质量保证及质量评价；
•软件配置管理；
•软件开发环境；
•软件过程管理。
本章主要介绍软件需求分析与定义，软件设计、测试与维护，软件质量保证及质量评价，软件配置管理，软件开发环境和软件过程管理方面的知识，有关软件复用的知识将在第3章介绍。
2.1软件需求分析与定义
根据StandishGroup对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。
而在这些高达74%的不成功项目中，有约60%的失败是源于需求问题，也就是差不多有一半的项目都遇到了这个问题，这一可怕的现象不得不让我们对需求分析引起高度的重视。
2.1.1软件需求与需求过程
1.什么是软件需求
那么什么是软件需求呢软件需求就是系统必须完成的事，以及必须具备的品质具体来说，软件需求包括功能需求、非功能需求和设计约束3方面内容。
（1）功能需求：
是指系统必须完成的那些事，即为了向它的用户提供有用的功能,产品必须执行的动作。
（2）非功能需求：
是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等。
（3）设计约束：
也称限制条件、补充规约，这通常是对解决方案的一些约束说明’例如必须采用国有自主知识版权的数据库系统,必须运行在UNIX操作系统之下等。
另外，在大量与需求相关的书籍、文章中有一些诸如业务需求、•用户需求之类的词语，把很多读者搞得术语混淆，下面我们一起来看看这些概念。
（1）业务需求（BusinessRequirement）:
是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。
（2）用户需求（UserRequirement）:
是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。
（3）系统需求（SystemRequirement）:
是从系统的角度来说明软件的需求，它包括用特性说明的功能需求、质量属性，以及其他非功能需求，还有设计约束。
也就是说，这分别对应于需求的3个不同的层次，从目标到具体，从整体到局部，从概念到细节。
这些不同层次、不同类型的需求描述之间的关系如图2-1所示。
2.需求工程
需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程，通常包括需求开发和需求管理两大工作。
（1）需求开发：
包括需求捕获、需求分析、编写规格说明书和需求验证四个阶段。
在这个阶段需要确定产品所期望的用户类型、获取每种用户类型的需求、了解实际用户任务和目标，以及这些任务所支持的业务需求、分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型、对需求进行评审等工作。
（2）需求管理：
通常包括定义需求基线、处理需求变更、需求跟踪等方面的工作。
而对于需求工程而言，最重要的还是需求开发，而需求开发总结起来就是包括需求捕获、需求分析、需求规格化、需求验证4个环节。
需求捕获是为了收集需求信息，需求分析则是在需求捕获的基础上进行分析、建立模型，然后将其进行规格化形成《软件需求规格说明书》，最后再通过客户和管理层进行验证。
需求规格化的工作就是编制《软件需求规格说明书》，具体的方法和注意事项请参考有关文档编制的相关章节。
而需求验证的工作则包括组织一个由不同代表组成的小组，对需求规格说明书和相关模型进行审查；以需求依据编写测试用例，确认测试做好准备；在需求的基础上，起草第一份用户手册；确定合格标准，也就是让用户描述什么样的产品才算是满足他们的要求和适合他们使用的。
2.1.2需求调查与问题定义
需求调查与问题定义是看上去简单，做起来难的一件事。
在很多人的印象中，需求调查，就是找用户聊聊说说，记个笔记。
其实需求调查是否科学，准备是否充分，对调查出来的结果影响很大，这是因为大部分客户无法完整地讲述需求，而且也不可能看到系统的全貌。
要想做好需求调查，必须清楚地了解3个问题。
•What：
应该搜集什么信息。
•Where：
从什么地方搜集这些信息。
•How：
用什么机制或者技术来搜集这些信息。
接下来，我们就对这三个部分的内容进行一些更加详细的说明与描述。
1-要捕获的信息
一方面，需求分析员应该知道，从宏观的角度来看，要捕获的信息包括三大类：
一是与问题域相关的信息（如业务资料、组织结构图、业务处理流程等）；二是与要求解决的问题相关的信息；三是用户对系统的特别期望与施加的任何约束信息。
这样才能够有的放矢，不会顾此失彼。
另外一方面，需求分析员在开展具体需求捕获工作时，应该做到在此之前明确自己需要获得什么信息，这样才有可能获得所需信息，才知道工作进展是否顺利，是否完成了目标。
2.信息的来源
除了要明确地知道我们需要什么方面的信息，还要知道它们可以从哪里获得。
通常情况下，这些需要的信息会藏于客户、原有系统、原有系统用户、新系统的潜在用户、原有产品、竞争对手的产品、领域专家、技术法规与标准里。
面对这么多种可能，在具体的实践中该从何下手呢其实也很简单，首先从人的角度来说，应该首先对涉众（也就是风险承担人、项目干系人）进行分类，然后从每一类涉众中找到1〜2名代表；而对于文档、产品而言，则更容易有选择地查阅。
结合前面讲述的内容，在制订需求捕获计划的时候，不妨列出一个表格，左边写上想了解的信息，右边跟上认可能的来源，这样就能够建立一一对应的关系，使得需求捕获工作更加有的放矢，也更加高效。
3.需求捕获技术
当我们知道需要去寻找什么信息，并且也找到了信息的来源地，接下来就需要选择合适的技术进行需求捕获了。
在此，我们列举出一些最常用的需求捕获技术。
（1）用户访谈。
用户访谈是最基本的一种需求捕获手段，也是最基本的一种手段。
其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。
最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
准备问题：
进行用户访谈之前，最好先对要询问的问题进行一些准备。
准备的方法是围绕着想要获取的信息展开，设计一系列的问题，按顺序组织起来。
而且还要预先准备好记录方式，主要包括本人记录、第三人记录或者是录音/录像的形式，不过采用录音/录像的方式应该征得被访谈者的同意，而且这种方法虽然看上去比较有效，不容易丢失信息，但这也会给后面的整理工作带来一定的工作量和难度。
访谈时的技巧：
在访谈时一定要注意措辞得当，在充分尊重被访谈者的基础上，尽量避免出现“我不知你在说什么”，“我是来帮助你更好地工作”这样的言语，否则将会破坏访谈的气氛，从而使访谈的效率大打折扣。
在访谈时一定要注意保持轻松的气氛，选择客户有充时间的时段$行，在说话、问问题时应该尽量采用易于理解、通俗化的语言。
另外，值得注意的是，分析人员应该在进行访谈之前进行一些相关领域的知识培训，充分阅读相关材料，以保证自己有较专业的理解与认识，让被访谈者能够信任你。
应该询问的问题：
在设计询问的问题时，应该考虑：
自己的问题是否相关回答是否正式对方是回答这些问题的合适人选吗是否问了过多的问题是否还有更多的问题要问被访者？
另外，还可以在询问过程中询问被访者还希望自己问他什么问题，还应该见哪些人
总的来说，用户访谈具有良好的灵活性，有较宽广的应用范围，但是也存在着许多困难，诸如客户经常较忙，难以安排到时间；面谈时信息量大，记录较困难；沟通需要很多技巧，同时需要分析员有足够的领域知识；另外，在访谈时会遇到一些对于组织来说比较机密和敏感的话题。
因此，这看似简单的技术，也需要分析人员拥有足够多的经验和较强的沟通能力。
（2）用户调查。
正如前面讲到的，用户访谈时最大的难处在于很多关键的人员时间有限，不容易安排过多的时间；而且客户面经常较广，不可能一一访谈。
因此，我们就需要借助“用户调查”这一方法，通过精心设计要问的问题，然后下发到相关的人员手里，让他们填写答案。
这样可以有效地克服前面提到的两个问题。
但是与用户访谈相比，用户调查最大的不足就是缺乏灵活性；而且双方未见面，分析人员无法从他们的表情等其他动作来获取一些更隐性的信息;还有就是客户有可能在心理上会不重视一张小小的表格，不认真对待从而使得反馈的信息不全面。
基于上述原因，因此较好的做法是将这两种技术结合使用。
具体地讲，就是先设计问题，制作成用户调查表，下发填写完后，进行仔细的分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作补充。
（3）现场观摩。
俗话说得好，百闻不如一见，对于许多较为复杂的流程和操作而言，是比较难以用言语表达清楚的，而且这样做也会显得很低效。
针对这一现象，分析团队可以就一些较复杂、较难理解的流程、操作采用现场观摩的方法来获取需求。
具体来说，就是走到客户的工作现场，一边观察，一边听客户的讲解，甚至可以安排人员跟随客户工作一小段时间。
这样就可以使得分析人员更加直观地理解需求。
（4）•文档考古。
对于一些数据流程比较复杂的，工作表单较多的项目，有时是难以通过说，或者通过观察来了解需求细节的。
这个时候就可以借助于“文档考古”的方法，也就是对历史存在的一些文档进行研究，考古一词正是形象地说明了其主要的工作重心是结合已经填写完毕的、也就是带有数据的文件、表单、报告，从中获得所需的信息。
不过当你准备采用该方法时，也要记住这个方法的主要风险，那就是历史的文档可能与新系统的流程、数据有一些不吻合的地方，并且还可能承载一些原有系统的缺陷。
要想有效地避免和发现这些问题，需要分析人员能够运用自己的聪明才智，将其与其他需求捕获技术结合对照。
还有一个负面因素就是，这些历史的文档中记载的信息有可能涉及客户的商业秘密，因此对数据信息的保密也是分析人员基本的职业道德。
（5）联合讨论会。
这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。
它通过联合各个关键客户代表、分析人员、开发团队代表一起，通过有组织的会议来讨论需求。
通常该会议的参与人数6〜18人，召开时间1〜5小时。
在会议之前，应该将与讨论主题相关的材料提前分发给所有要参加会议的人。
在会议开始之后，首先应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。
会议的最初，就是针对所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，第三步则是大家在此基础上对新的解决方案进行一番设想，在过程中将这些想法、问题、不足之处记录下来，形成一个要点清单。
第四步就是针对这个要点清单进行整理，明确优先级，并进行评审。
这种联合讨论会将会起到群策群力的效果,对于一些最有歧义的问题和对需求最不清晰的领域都是十分有用的一种技术。
而最大的难度就是会议的组织,要做到言之有物,气氛开放，否则将难以达到预想的效果。
4.需求捕获的策略
在整个需求过程中，需求捕获、需求分析、需求规格化、需求验证4个阶段不是瀑布式的发展，而是应该采用迭代式的演化过程。
也就是说，在进行需求捕获时，不要期望一次就将需求收集完，而是应该捕获到一些信息后，进行相应的需求分析，并针对分析中发现的疑问和不足，带着问题再进行有针对性的需求捕获工作。
2.1.3可行性研究
进行可行性研究，其主要的目的是回答一个问题，即所提出的项目是否可以完成。
需要注意的是，可行性研究毕竟不是解决问题，而是研究问题的范围，探索这个问题是不是值得去解决，根据现有的情况是否有能力，是否有可能找到较好的、成本效益合算的解决方案。
现在很多的开发团队把软件的最终开发结果是否符合需求规格说明书作为项目的成功标准，其实这是很片面的。
真正成功的项目是满足客户的目标，客户带来了预想的价值增长。
而什么样的解决方案能够真正满足客户的需要，实现客户的目标呢这就需要大量的需求分析与可行性研究工作。
1.可行性研究工作的基础
在可行性研究工作开始之前，系统分析员应该协助客户一起完成“问题定义”工作，也就是先明确系统要做什么？
即What问题，也就是上一小节所解决的内容。
问题定义的关键是清晰地界定出问题的内容、性质，以及系统的目标、规模等内容，并形成完整的书面报告。
系统分析员在这个过程中将使用各种需求调查技术研究问题、引导问题，从而形成完整的问题定义。
2.可行性研究工作的任务
可行性研究工作的目标大家已经了解，那么具体要完成什么工作，达到什么样的目的，也就是说从何着手呢其实可行性研究工作的任务包括以下3个方面。
（1）技术可行性：
现有的技术是否能够有效地解决该问题?
是否有多种不同的解决方案?
现有的技术力量是否达到?
（2）经济可行性：
所有可能的解决方案所需投入的成本?
能否超过它的开发成本它的成本效益分析结果?
如何投资回报率如何?
（3）社会可行性：
该解决方案是否符合企业实际情况?
是否符合员工利益?
是否符合相关法规和行业规范?
完成可行性研究工作之后，必须将这些成果文档化地记录下来，形成《可行性研究报告》。
3.可行性研究工作的步骤
那么具体而言，可行性研究工作包括哪些事项呢该如何着手？
都需要哪些人参与呢下面我们就可行性研究工作的步骤做一个总结性阐述。
（1）核实问题定义与目标。
开始正式进行可行性研究工作之前，首先要做的一个工作，就是对该项工作的基础一问题定义再次核实。
具体来说，就是仔细阅读问题定义的相关材料，对该问题所涉及的领域知识进行学习、考证，然后通过走访相关人员进行验证与核实。
这一步骤的关键目标是：
使问题定义更加清晰、明确、没有歧义性，并且对系统的目标、规模，以及相关约束与限制条件做出更加细致的定义，确保可行性研究小组的所有成员达成共识。
（2）研究分析现有系统。
对现有系统的仔细分析与研究是十分重要的一项工作，因它是新系统开发的最好参照物，对其的充分分析有助于新系统的开发。
这么说的原因，主要是基于以下几点考虑：
•现有系统已实现的功能通常也是新系统要实现功能的一部分。
•新系统一定是在现有系统基础上的升华，毕竟如果旧系统没有问题，就不会有新系统开发的需求。
•另外，现有系统的运行成本分析的结果是衡量新系统的经济可行性的重要参照物。
从字面上的理解会容易产生一个常见的误区，就是认为现有系统一定是软件系统，其实这里的“现有系统”不仅包括旧的软件系统，还包括旧的非计算机系统。
（3）新系统建模。
在问题定义和对现有系统研究的基础上，开始对新的系统进行建模，建模的目的是为了获得一个对新系统的框架认识、概念性认识。
通常可以采用以下几种技术。
•系统上下文关系范围图：
其实也就是DFD（数据流图）的0层图，将系统与外界实体（可能是人、可能是外部系统）的关系（主要是数据流和控制流）体现出来，从而清晰地界定出系统的范围，实现共识。
•实体-关系图（E-R）：
这是系统的数据模型，这个阶段并不需要生成完整的E-R图，而是找到主要的实体，以及实体以间的关系即可。
•用例模型：
这是系统的一个动态模型，以Actor和use-case整理出系统的主要功能框架，这个阶段应该大部分都处于概念级，每个用例也无需花太多的时间确定细节，只要能够勾画出系统的雏形即可。
•域模型：
采用00的思想，对于系统中主要的实体类找到，并说明实体类的主要特征和它们之间的关系。
•IP0表：
采用传统的结构化思想，从输入、处理、输出的角度进行描述系统。
再次请大家注意，这个阶段的所有模型是不够精确的，只是一个框架，要达到一个宏观的角度，否则将陷入无休止的工作中。
（4）客户复核。
可以这么说，在第（3）步中建立起来的系统模型是系统分析员眼里的问题定义，那么这与客户心目中的问题是否一致呢？
因此，完整的系统模型建立之后，一个十分重要的工作就是与客户一起进行复核。
当然，由于这个时候模型将成讨论和分析的基础，因此使用客户更容易接受的模型将显得十分重要。
如果在这个过程中，发现模型与客户的目标有不一致的地方，就应该再次通过访谈、现场观摩、对现有系统分析等手段进行了解，然后在此基础上修改模型。
由此也可以看书，
（1）〜（4）的步骤是一个循环，周而复始，直至客户确认了新的系统模型止。
（5）提出并评价解决方案。
前面的工作还是停留在“系统解决什么问题”上，只是更加清晰地进行了定义和说明。
当客户与系统分析员对要解决的问题有了一个清晰的共识之后，接下来的工作就是提出解决方案，这也是系统分析员很重要的工作之一。
在这个阶段，应该尽量列举出各种可行的解决方案，并且对这些解决方案的优点、缺点做一个综合性的评价，以便下一步决策。
需要注意的是，对那些明显不可行的，如技术上还没有相应的办法、经济角度明显不可行的、违背企业或行业实际情况的解决方案应该直接过滤掉。
（6）确定最终推荐的解决方案。
明确地指出该项目是否可行，如果可行，什么方面是最合理的？
由于对这两个问题的回答，是可行性分析研究工作的核心目标。
因此在各种解决方案提出之后，接下来应该从中选中一个最合理、最可行的解决方案，更加详细地说明理由，并且还要对其进行更加完善的成本/效益分析。
具体来说，成本效益分析可以分成两个部分的内容。
①成本估计。
对于软件系统而言，主要的成本是人力资源成本，另外还包括一些直接的费用、设备采购的费用等。
相对而言，硬件设备，以及其他的一些相关费用的评估会比较容易一些，最难的是人力资源的成本分析。
因此，对系统工作量（用人月、人年等单位进行说明）进行合理、科学的评估，并在此基础上进行计算是很必要的。
要想准确地估算出工作量，通常可以借助的工具是历史数据和经验模型。
历史数据就是指你所在的开发团队以往从事项目的情况，可以通过以类似系统项目做参照的方法。
而经验模型则是一些软件工作量估算方面的研究总结，常用的有功能点分析、COCOMO分析等。
通常，可以分成以下几步进行：
•首先，进行工作任务分解，将目标细化。
•然后，就每一个工作任务包，与具体的开发团队进行共同分析，使用功能点分析法或其他相关的分析法进行估算，并且将估算的结果与类似项目的历史数据进行比较，做出微调。
•使用COCOMO分析，计算出相应的人月数。
在这个过程中，还应该根据类似项目的历史数据推出项目组队的平均产能，从而使估算值更有代表性。
另外，有一点是十分重要的，在这个阶段是不可能得到精确的估算值的，这个观念必须让开发团队、管理层和客户很清晰地认识到。
否则，即使违心地给出精确的估算值也显得没有任何意义。
这个阶段的工作，对于系统分析员而言，很重要的知识技能在于软件度量与估算方法、技术的掌握方面。
②效益分析。
有了估算出来的开发成本以后，就可以进行效益分析了。
在做效益分析之前应该首先对该系统应用之后，将会带来的直接、间接收益，以及成本降低的具体数额进行量化。
并且通过经济学的相关模型来进行分析，这要求系统分析人员能够在该方面有一定的知识积累。
通常进行效益分析时要借助以下几个概念。
•货币的时间价值：
比如说现在的1元钱，与未来的1元钱，其代表的价值是不同的。
通常是使用利率的形式来表现这个价值。
我们用厂代表未来的价值，P代表现在的价值，那么可以总结为：
和其中/代表年利率，n代表年数。
•投资回收期：
投资回收期的意思就是要多少年才能够将投资回收，越短越有利。
•纯收入：
衡量系统价值的一个很重要的指标就是纯收入，而纯收入指的是整个生命周期之内系统的累计经济效益（折成现值）与投资之差。
•投资回报率：
当投资额、每年预计可获得的经济效益这两个数据有了的时候，就可以计算投资回报率（ROI）,公式如下所示：
P=F1/（1+J）+F2/（1+J）2+......+Fn/（1+J）"
其中，P代表总投资额，F,•是第I年年底的收益，n是系统使用寿命，J就是投资回报率。
.（7）草拟开发计划。
在上一步，我们对主要推荐的解决方案进行了详细的成本效益分析，对工作内容和工作量都有了一个详细的了解，接下来需要制订一个最粗略的开发计划，说明开发所需的资源、人员和时间进度安排。
这也将作可行性分析的一个重要依据和立项开发后制订项目计划的基础。
（8）以书面的形式提交《可行性分析报告》并进行审查。
最后就是将这些研究的结果整理成文，提交客户和管理层，进行审查通过。
在这个阶段还应该制作一些相应的讲义，客户和管理层做介绍和说明。
2.1.4需求分析
在细化地说明需求分析之前，我们先温习一下分析的定义：
所谓分析就是通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明。
从上面的定义中，我们可以知道需求分析的关键在于对问题域的研究与理解。
为了便于理解问题域，现代软件工程方法所推荐的做法是对问题域进行抽象，将其分解若干的基本元素，然后对元素之间的关系进行建模。
1.需求分析的工作任务
前面对分析的定义相对比较抽象，不太易于理解，不太容易用来指导具体的操作。
其实用更通俗的话来说，需求分析就是提炼、分析和仔细审查已经收集到的需求，以确保所有的涉众都明白其含义并找出其中的错误、遗漏或其他不足的地方。
在KarlE.Wiegers的经典名作《软件需求》一书中指出，需求分析的工作通常包括
以下七个方面。
（1）绘制系统上下文范围关系图：
这种关系图是用于定义系统与系统外部实体间的界限和接口的简单模型，它可以为需求确定一个范围。
其实就是DFD的0层图，图2-2就是一个实例。
（2）创建用户接口原型：
由于用户界面对于一个系统来说是十分重要的，因此在需求分析阶段通过快速开发工具开发一"t'可抛弃原型，或者通过PowerPoint、Authorware等演示工具制作一个演示原型，甚至可以用纸笔画出一些关键的界面接口示意图，这些都会帮助客户更好地理解所要解决的问题，更好地理解需求。
（3）分析需求的可行性：
对所有获得的需求进行成本、性能、技术实现方面的可行性研究，以及这些需求项是否与其他的需求项有冲突，是否有对外的依赖关系等。
（4）确定需求的优先级：
这是一个很重要的工作，迭代开发已经成为现代软件工程方法论的一个基础，而需求的优先级是制订迭代计划的一个最重要的依据。
对于需求优先级的描述，可以采用满意度/非满意度指标进行说明（满意度：
取值1〜5,表示当需求被实现时用户的满意程度。
不满意度：
取值1〜5，表示当需求
升级会员 