大学计算机软件需求工程复习2329页.docx
《大学计算机软件需求工程复习2329页.docx》由会员分享，可在线阅读，更多相关《大学计算机软件需求工程复习2329页.docx（41页珍藏版）》请在冰豆网上搜索。
大学计算机软件需求工程复习2329页
第二章
复习题：
1.IEEE是怎样定义需求的？
从中你可以得到什么认识？
IEEE对需求的定义：
（1）用户为了解决问题或达到某些目标所需要的条件或能力；
（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；
（3）对
（1）或
（2）中的一个条件或一种能力的一种文档化表述。
为了融合不同群体的看法，IEEE的定义当中同时包括了用户的观点（第一种条件和能力）和开发者的观点（第二种条件和能力），但是即便如此，不同群体的人们也很难就IEEE的定义进行一直和准确的解读，因为需求概念的内涵和外延都非常丰富。
2.解释下列名词：
问题域、解系统和共享现象，并结合它们的含义说明软件系统是如何与现实世界形成互动的？
问题域：
Ø当现实的状况与人们期望的状况产生差距时，就产生了问题。
Ø要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。
Ø这些实体和状态构成了问题解决的基本范围，称为该问题的问题域（ProblemDomain）
解系统：
软件系统通过影响问题域，能够帮助人们解决问题，称为解系统。
共享现象：
Ø软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分的具有模拟特性。
Ø换句话说，软件系统当中含有问题域某些部分的模型（或模拟），常见的模型包括数据模型、对象模型、处理模型等。
Ø问题域中的某些信息能够和模型中的信息建立映射关系
Ø这些通过映射建立的共同知识，就是问题域和解系统之间的共享现象
共享现象就是问题域和解系统实现交互和互相影响的途径与接口，问题域和解系统都通过改变这些共同知识来影响对方，或者通过认同这些共同知识的改变来接受对方的影响。
3.解释下列名词：
需求、规格说明、问题与特性和约束，并结合它们的含义说明需求工程的主要任务是什么？
需求是用户对问题域当中的实体状态或事件的期望描述。
直接需求是可以通过更改共享现象被满足的需求;
间接需求是需要修改共享现象，同时连锁影响问题域才能满足的需求。
规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。
解决方案只能通过改变共享知识，影响问题域的运行，进而满足用户的需求，所以规格说明主要包括两个部分：
（1）对共享现象（模型）的描述；
（2）系统对共享现象所施加的操作的描述。
需求关注的是现实世界中的部分，软件关注的是解系统，而规格说明关注的是共享现象
问题域特性：
问题域自治的规律性称为问题域特性。
包括结构特性和行为特性等。
约束和假设：
问题域当中有些特性完全不受共享现象的影响，即完全不受解系统的影响，同时却可能很大程度上影响共享现象，影响解系统，甚至关乎解系统的成败。
这些特性被认为是解系统对环境的依赖特性。
当这些特性非常明确时，称之为约束；不明确时，需要限定特性的变化范围，称之为假设
需求工程的主要任务：
①进行需求开发，确定用户的期望效果R。
②研究问题背景，描述问题域特性E。
③构建解系统，描述解系统行为S，使得E，S→R。
4.需求有哪些常见的类别？
功能需求和非功能需求有什么差异？
需求的分类1：
⏹功能需求（FunctionalRequirement）：
❑和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。
功能需求主要表现为系统和环境之间的行为交互。
⏹
性能需求（PerformanceRequirement）：
❑系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。
⏹质量属性（QualityAttribute）：
❑系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。
⏹对外接口（ExternalInterface）：
❑系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。
⏹约束
❑进行系统构造时需要遵守的约束，例如编程语言、硬件设施等
需求的分类2：
系统需求（System）：
硬件需求（Hardware）、软件需求（Software）、其他需求
功能需求和非功能需求的差异：
除功能需求之外的其他四种类别需求又被统称为非功能需求。
在非功能需求当中，质量属性对系统成败的影响极大，因此在某些情况下，非功能需求又被用来特指质量属性。
5.描述业务需求、用户需求和系统（级）需求的区别与联系。
Ø业务需求：
系统建立的战略出发点，表现为高层次的目标，它描述了组织为什么要开发系统
为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature）
参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision）
特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope）
Ø用户需求：
执行实际工作的用户对系统所能完成的具体任务的期望
描述了系统能够助用户做些什么。
直接用户、间接用户
对所有的用户需求，都应该有充分的问题域知识作为背景支持
特性：
模糊不清晰、多特性混杂、多逻辑混杂
Ø系统需求：
用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求；系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。
用户需求---->系统需求的过程：
首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；
然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。
该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。
6.优秀的需求哪些特性？
试为每一个特性都举出一个不符合的示例。
优秀的需求特性：
1）完整性：
不需要做更多的扩展就可以充分的说明用户所需要的系统功能。
每一个需求的描述都应该包含开发人员设计和实现这项功能需要的所有信息
R6（不完整）：
系统应该允许被扩展
R7（完整、较R8精确）:
系统的调度算法应该允许被扩展
2）正确性：
真实的反映用户的意图；必须请需求的提出者予以确认
3）精确性：
描述仅包含必要的信息；简洁、清晰
R8（不精确）：
在实现之后，系统的调度算法应该允许被扩展。
4）可行性：
由开发人员进行检查
需要进行一定的分析和研究，而不是单纯的凭借经验和直觉
必要的时候要通过开发原型来加以验证
示例：
保证系统核心功能可以7×24小时连续运行
5）必要性：
满足用户的业务需求所必需的
6）无歧义：
每一项需求都应该有而且只能有一种解释
定义一个可以共同理解的词汇表（Glossary）
7）可验证：
通过分析、检查、模拟或者测试等方法能够判断需求是否被满足
示例：
实现各部门的公文流转无纸化、文档一体化、业务管理的规范化、自动化和网络化；
实现工作流程合理化、高效化，决策支持科学化、准确化；
统一办公流程、规范公文格式，加强信息交流和共享，提高工作效率。
不可验证的需求往往是因为描述模糊或者过于抽象，所以在进行需求的描述时要：
让需求具体化、小心形容词和副词的使用、避免程度词的使用
7.列出需求草稿中常见问题，需求工程师如何消除这些错误？
①需求并没有反映用户的真实需要。
需求工程师一定要进行问题分析，尽力发现问题背后的问题；在需求传递给开发人员之前，请提出需求的用户进行仔细地检查和确认。
②模糊和歧义的需求。
为项目中重要的词汇建立一个公共的可共同理解的词汇表，然后在词汇表的基础之上进行需求的定义。
对于用户立场冲突的正确解决方法是在项目前景的指导下，促进用户之间的协商解决。
③信息遗漏。
加强对业务需求的处理；靠需求工程师的经验加以避免。
④不必要的需求。
开发人员代表的谈判技巧；在进行用户需求的获取之前，先定义明确的业务需求，然后根据业务需求进行用户需求的过滤和选择；保持以用户为中心。
⑤不切实际的期望。
提供可行性、成本等足够的技术参考信息，帮助用户对需求进行取舍和调整。
案例题：
1.解答一：
（1）她没有仔细认真地分析问题；
（2）她没有及时跟相关人员交流信息，没能把握住有价值信息；
（3）她没能及时跟公司员工交流，引用过时的文件结构；
（4）她没有仔细研究分析新引进的系统的性能需求是否满足；
（5）她没有仔细研究新引进的系统的功能需求是否满足；
（6）她没有仔细研究引进的系统的质量属性，对外接口是否满足。
2.业务需求：
保持财务业绩与它的发展同步；有效地追踪客户账单和收据；降低成本；实行特价时能够知道是否有利可图，是否带动去他的销售；增加回头客。
解答：
业务需求如BR。
BR1：
实现客户账单和收据的有效追踪；
BR2：
实现产品特价时的利润和相关销售情况检查；
BR3：
实现一个客户数据库。
3.先定义明确的业务需求，获得开发系统的必要性，根据业务需求，协调涉众的立场，限定问题的范围，指导用户需求的获取过程：
和涉众沟通（即向业务人员了解相关的业务知识，业务流程；再和销售人员沟通，由于他们的顾客是流动的，不确定的，只能通过销售人员间接获取来自于顾客的用户需求，了解他们的背景和习惯），最后根据业务需求对用户需求进行过滤和选择，得到充分必要用户需求。
4.UR1：
使用户可以根据系统的明确操作提示做出正确的反应；
UR2：
用户插入银行卡后需要输入密码，得到验证后才可进行有效的具体操作；
UR3：
在用户进入系统后，可以选择使用查询金额、存取现金、转账的功能；
UR4：
用户能够正确、安全地退出系统。
5.SR1：
（1）系统显示用户插入磁卡的动态图像，正确标明插卡位置；
（2）用户根据提示，正确插入磁卡；
（3）系统读取磁卡卡号，界面显示输入密码的提示；
SR2：
（1）对用户输入的密码，系统自动进行字符匹配；
（2）匹配正确的话，进入具体操作界面；
（3）匹配不正确的话，警告密码不正确，并提示再次输入；
SR3：
（1）若用户选择查询金额图标和查询金额币种，系统读取银行数据库中用户对应的信息，反馈在用户界面上；
（2）若用户选择取款图标和金额币种及输入金额数目，系统读取用户请求，接受金额，修改数据库中该用户对应的信息，并提示成功与否；
（3）若用户选择存款图标和金额币种，系统弹出存款框，用户放入现金，系统接收现金并辨认真伪，并反馈存入金额数目，得到用户确认后，修改数据库中该用户对应的信息，并提示成功与否；
（4）若用户选择转账图标和金额币种并输入对方账号和转账金额数目，系统读取用户请求，修改数据库中所涉及到的用户的信息，并提示成功与否；
SR4：
（1）用户选择退出图标；
（2）系统提示拔卡信息。
6.性能需求：
在用户点击图标后，系统在3s内作出反应。
质量属性：
易用、可靠、安全、容错、可恢复、可维护。
约束：
当用户输入密码次数等于3次后就不再提示输入密码，并自动锁定银行卡。
第三章
思考题：
1.除了需求开发的四个活动和需求管理活动之外，需求工程中还有没有需要执行的活动？
如果有的话，它们是哪些活动？
给出你的理由。
还有其他一些活动，例如：
过程管理活动和项目管理活动（人力、资金的管理）。
过程管理活动是跟踪项目开发过程，记录项目开发过程当中所遇到的问题或者教训等等。
项目管理活动是管理项目开发的一系列问题与进度，管理人员配置，以求达到最该效益。
2.需求开发过程具有迭代特性，但是不是所有项目的需求开发过程都必须是迭代完成的？
如果不是，试给出举例和理由。
（不是，一般对于业务领域不熟悉的项目，需求是具有迭代性的，需要对业务领域的认知，有一个从认识到知识重构的过程。
对于某些固定需求且熟悉的项目，开发人员已经相当明确用户需求，这时，就不需要返回到需求获取阶段以继续用户需求的获取，比如学校课程的作业软件工程实践电梯系统，就不需要迭代开发）
3.需求开发的迭代特性与软件开发过程的迭代式开发有什么关系？
它们之间会相互影响吗？
如果会，那么有哪些影响？
需求开发的迭代性指的是对于开发者对知识的认知水平在某一点上，发生重构，使得知识体系复杂性下降，而继续积累知识的过程。
软件开发的迭代性指的是在软件生命周期整体开发迭代，针对变更的需求或者新增的需求一种减少风险的开发模式。
需求开发迭代不会导致软件开发过程的迭代，但有时会有影响。
（需求开发的迭代特性只是软件开发过程的迭代式开发的一个子过程，软件开发过程是一个相当庞大的工程，需要在软件开发过程的各个阶段都需要进行开发工作的迭代，当然也包括需求开发中的迭代。
它们之间互相影响。
如果需求开发中的迭代不能很好地完成需求分析任务，就必将影响到软件开发过程的其他迭代阶段的进行。
）
增量式：
需求->需求->需求->。
。
。
->需求->开发。
。
。
无需求迭代
演化式：
需求->开发->需求->开发->需求->开发。
。
。
有需求迭代
4.需求工程细节知识的实践性对不同项目的需求开发过程的差异性有没有影响？
如果有，说明影响是什么，如果没有，说明是哪些因素产生了不同项目的需求开发过程的差异性。
没有。
问题域的特性导致了不同项目的需求开发过程的差异。
丁老师解答：
没有影响。
其实是需求开发过程的差异性一定程度上导致了细节知识的实践性。
现实世界问题的复杂性和差异性主要导致了需求开发过程的差异性
第四章
思考题：
结合复习题4、5、6三个题目的答案，说明需求获取的内容和需求获取的来源是怎样影响到需求获取的方法选择的？
请一一举例。
4、5、6三个题目的答案：
需求获取的内容：
（1）需求：
需求获取的主要对象，期望解决的问题列表。
通常体现为涉众的问题、期望、观点、看法和态度等。
（2）问题与描述：
用来承载和解释需求的问题与特性，现实世界的业务运行状况。
（3）环境与约束：
属于一种特殊的问题与特性，限定了解系统部署的环境和条件。
需求获取的来源：
（1）涉众：
用户；客户；领域专家；市场人员、销售人员等其他用户替代源
（2）硬数据：
登记表格、单据、报表等定量文档；备忘录、日志等定性文档
（3）相关产品：
原有系统；竞争产品；协作产品
（4）重要文档：
原有系统的规格说明书；竞争产品的规格说明书；协作产品的规格说明书；客户需求文档
（5）相关技术标准和法规：
相关法律、法规及规章制度；行业规范，行业标准；领域参考模型
需求获取的方法：
（1）传统方法：
问卷调查、面谈、硬数据分析、文档检查、需求剥离等
（2）集体获取方法：
头脑风暴（Brainstorming）、专题讨论会（Workshop）、JAD等
（3）原型
（4）模型驱动方法：
基于场景的方法、基于目标的方法和多视图的方法
（4）认知方法：
任务分析（TaskAnalysis）、协议分析（ProtocolAnalysis）等
（5）基于上下文的方法：
观察、民族志（Ethnography）和话语分析（ConversationAnalysis）
第五章
思考题：
系统中每一个问题解决方案的边界是如何集成建立系统边界的？
集成过程中对各个问题解决方案的输入/输出和功能是如何处理的？
试举例说明。
明确每一个解决方案需要具备的功能特征，根据这些功能特征，分析解决方案需要和周围环境形成的交互作用，定义解决方案的边界。
把每一个解决方案的输入/输出列出来，如果一个解决方案外部的输入来自于同一个系统当中另一个问题解决方案的输出，即系统的内部，就可隐去。
如果不是，就保留输入/输出。
经过问题分析之后就可以得到更高层次解决方案及系统特性，它们清晰的定义了问题解决方案的功能和边界。
将所有问题的解决方案进行综合，就可以得到整个解系统的功能和边界。
为了描述系统的功能和边界，通常会使用上下文图或系统用例图。
对于用例图描述要解决的方案，一个用例就是一个功能，将其保留；对于上下文图，将功能提取出来，功能分解。
案例题：
1.不做工作陈述的风险：
1.在获取需求时，用户往往从各自的立场出发考虑问题，提出相应的功能需求。
如果没有工作陈述，用户就不会从共同的方向上考虑和理解问题，对系统的期望也就产生了较大的差距。
2.没有工作陈述，就等于在用户之间发生需求冲突时，就没有可以用来指导并且调节协商的项目前景，冲突问题也就很难解决。
风险：
1需求理解错误2不能按时完成（超期超资）3做出来的不是想要的
定义范围的必要性：
1.加强用户和开发人员的理解，定义一致的理解2.降低风险
2.
问题
业务目标
高层解决方案
系统特性
帐户太多，工作量太大
减少检查人员的工作量
能够快速、自动查询客户账户
建立一个数据库系统用来存放客户账户信息
降低工作复杂度
能够分析一个客户是否为问题账户
根据特定的判定问题账户的算法检索辨别出问题账户
需查阅账户的大量历史数据
能够给出一个问题账户的三年内的历史数据
工作人员能够检查该账户的三年内的历史数据
能够按账户号查询该账户三年历史数据
问题账户所占比例没有显示
能够计算问题账户所占比例
即时显示问题账户所占比例
根据查询结果，自动计算并显示问题账户所占比例
3.
（需要根据当时的资金，时间，以及和用户、技术人员的协商结果而定。
）用户决定
4.
解答：
她现在遇到的问题有：
问题
业务目标
高层解决方案
不能有效地从信息部门获得工资和个人数据
减少从信息部门获得工资和个人数据的时间；
度量标准（Scale）：
一次从信息部门获得工资和个人数据的时间；
计量方法（Meter）：
检查信息部门数据库日志；
理想标准：
减少50%；一般标准：
减少30%；最低标准：
减少20%；
由软件从信息部门的数据库中检索出工资和个人数据，减少所需信息获取的时间
雇员数据太过分散，而且不能及时正确地更新
集中雇员数据，并且正确更新
由软件来分析雇员数据的各种特征，及早识别出数据所在位置；或由软件集中处理雇员数据，及早识别出不准确的或没有及时更新的数据，提交人工处理或自行更新
计算复杂
降低计算的复杂性
由软件来处理投资和退休假定的计算的复杂过程
保险计划提供给未授权的人
有效正确地分析雇员的家庭，婚姻信息
由软件来分析个人数据的准确性，及早识别出不准确的个人信息，提交人工处理；
计算中可变条件的复杂性
降低计算中可变条件的复杂性
由软件来处理计算中可变条件的复杂性，降低出错率
系统特性：
Ø根据信息部门提供的数据库查询工资和个人数据；
Ø根据原始数据重新整理数据并更新；
Ø提交查询信息；
Ø创建投资和退休假定的计算过程；
Ø通过公司的内联网访问系统，根据个人情况更新信息；
Ø模拟计算中可变条件的变化；
Ø提供最灵活的福利方案。
重要的约束有：
约束源
约束
操作性
雇员信息必须有备份
设备预算
有自己已有的系统上开发
技术要求
应用面向对象的方法
行政要求
需要信息部门的信息
系统
空间不应该超过20M字节
环境
安全性
第六章
思考题：
1.用户是最终使用和操作产品的人，他们使用软件的目的是为了更好的完成自己的任务，满足组织的目标要求。
因此，一个成功的软件要能够协助用户有效的完成实际工作，用户也就自然应该是需求获取的主要信息来源。
需求工程师需要了解用户实际工作的开展状况和用户希望软件系统能够给予他们的帮助。
用户参与是以用户为中心的设计方法的核心思想，它要求开发者建立和用户的直接联系，尽早地关注与用户和用户的执行过程，通过及时获得用户的反馈来调整软件设计，以完成高质量的设计。
另一方面，用户参与就是反对通过和市场人员、管理者等中间媒介来了解用户。
在以用户为中心的设计方法中，用户需要参与软件开发的全过程，并且对最终软件设计和质量具有非常重要的影响，所以在该方法中参与用户的选择和普通的涉众代表采样有所不同，要吧他们区分开来。
2.他们建立了良好的合作关系后，可以降低风险。
理解用户：
对用户的基本特征描述（个人特征、工作特征、少数会涉及地理特征）
评估用户：
优先级评估、风险评估、共赢分析
与用户协商，处理用户间对于项目期望冲突
用户的个人特征和工作特征的描述可以帮助更好的确定功能需求。
案例题：
2.
在需求获取的诸多获取源中，人是需求的主要来源和问题域知识的重要来源，所以得到人脑内的知识是非常重要的。
但人们往往很难清晰、有条理、严谨地表达自己的知识，所以要完整得到人脑内的知识是具有一定困难的。
实际上，在对人进行需求获取之前，还有一个更重要的问题需要解决----哪些人是需求获取的合适对象？
在软件系统规模日益扩大的同时，人们已经无法简单地确定哪些人是软件系统功能的信息来源。
因此，人们需求首先搞清楚哪些人对软件系统的开发和应用具有发言权和决定权。
因而，所有能够影响软件系统的实现，或者会被实现后的软件系统所影响的个人和团体，都应该参与到需求获取工程中。
3.
Ø找出问题产生的根源，分析问题背后的问题
Ø涉众分析，找出冲突所在，找出矛盾的焦点
Ø解决信息系统部门与非信息部门之间的冲突
解答：
首先，需要细分涉众类别，这里用户，需求工程师和程序员都属于涉众类别。
需要分析他们各自的赢利条件，以在相互妥协中尽力实现一个共赢的结局。
分析涉众的关注点和兴趣取向。
了解涉众的个人特征和工作特征，以便对软件系统的功能进行合理的调整。
选择合适的代表参与项目的开发。
定期举行讨论会，让用户知道项目的进展情况。
优先级评估，风险评估，共赢分析…
4.
（1）没有以用户为中心:
没有进行涉众的选取和分析，将自己的需求作为所有用户的需求,以满足自己所需功能作为最终系统的标准，对业务需求、用户需求没有准确的认识;
（2）没有对涉众进行优先级评估、风险评估、共赢分析，因而没有即使发现并消除用户之间的需求冲突及项目中的潜在风险。
应该使用的是组织级的系统，应该进行涉众分析。
5.
个人特征：
如用户全是老年人。
由于老年人视力较差，在设计字体大小的时候就应该将字体设计得大一些。
若忽视了这一点，很可能导致多数老年用户无法正常使用系统。
工作特征：
如用户的计算机水平普遍很低，甚至不认识英文字母。
由于用户电脑水平有限，要求输入的地方不应该太多，而是应该使用选框让用户选择。
若忽视了这一点，则用户可能在需要输入非数字信息的地方遇到困难，从而无法使用系统。
地理和社会特征：
如用户是中国大陆居民，软件系统需要显示一幅中国地图。
由于政治原因和人民感情因素，必须将台湾地区放在地图之上。
若忽视了这一点，很可能遭到用户的强烈抵制。
关注点和兴趣：
如公司汽车调度系统，司机关注调度次数的公平性。
司机希望所有人出车的平均次数能大概相同。
如忽视了这一点，则可能造成汽车和司机的不公平调度，如，某车及其司机总是被派出工作而其它车和司机则很少出车。
目标期望：
如为某公司开发一个考勤系统，其领导不使用该系统，但他希望能通过指纹识别来考勤。
领导希望以此来杜绝做假行为。
若忽视了一点，很可能遭到领导的强烈反对，因为他是为软件系统的开发买单。
被影响程度：
如公司汽车调度系统。
司机虽然不直接使用系统，但深受系统影响，应该是使每个司机被派出执行任务的机会相同。
若忽视了这一点，则可能导致调度的不公平和资源的浪费。
力量程度：
如为某公司开发的考勤系统。
领导不直接使用该系统，但是他对该系统有最终决定权。
若忽视了一点，则当软件完成后，可能因该领导的一点点不满意而被完全推翻。
6.
解答：
（1）选择面谈对象的时候采用随机抽样
升级会员 