需求分析与设计课后答案解析

1、第一章1需求分析与系统设计之间的界限是什么？何时从分析阶段进入 设计阶段？需求分析关注系统“做什么”，系统设计关注“如何做”当分析阶段完成后才能进入到设计阶段2需求处理要注意哪些非技术因素？为什么？要注意的非技术因素：组织机构文化、社会背景、商业目标、利 益协商等。因为利用建模与分析技术构建的解决方案一定要和具体 的应用环境相关，不存在不依赖具体应用环境的解决方案，因此，在 利用建模分析技术进行要求处理是不能忽视具体应用环境的相关因 素3需求分析与需求工程之间的关系那就是需求工程含义更广，包括需求获取、需求分析、需求定义第二章1解释名词：问题域，解系统和共享现象，并结合他们的含义说明 软件系统

2、如何与现实世界形成互动的问题域：现实的状况与人们期望的状况产生差异就产生问题。解系统:软件系统通过影响问题域，能够帮助人们解决问题称为解 系统 通过共存现象仅仅是问题域和姐系统的一个部分。而不是他们 的全部。软件系统仅仅是现实世界的一种抽象。所以问题除了共享现象之 外。还有很多在进行模型抽象时忽略的其他现实因素2解释下列名词，需求，规格说明，问题域特性和约束，并结合他们的含义说明需求工程的主要任务是什么？需求是用户对问题域中的实体状态或事件的期望描述规格说明：规格说明是解系统为满足用户需求而提供的解决方案， 规定了解系统的行为特征。问题域的特性：在和解系统相互影响的同时，问题域是自治的，它有自

3、己的运行规律，而且这些规律不会因解系统的引入而发生改变， 这种自治的规律性称为问题域特性，当这些特性非常明确时称之为约 束。需求工程的主要任务：1需求工程必须说明软件系统将应用的环境及 目标，说明用来达成这些目标的软件功能， 还要说明在设计和实现这 些功能时上下文环境对软件完成任务所用的方式、方法所施加的限制 和约束。2需求工程必须将目标、功能和约束反映到软件系统中，映 射为可行的软件行为，并对软件行为进行准确的规格说明。3需求工程还要妥善处理目标、功能和约束随着时间的演化情况。4. 需求有哪些常见的类别？功能需求和非功能需求有什么差异？严格意义上的软件需求的分类：功能需求(Functiona

4、l Requirement ):和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动， 这 些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间 的行为交互。性能需求(Performanee Requirement ):系统整体或系统组成非功能需求部分应该拥有的性能特征，例如 CPU使用率、内存使用率等。 质量属性(Quality Attribute ):系统完成工作的质量，即系统需 要在一个“好的程度”上实现功能需求，例如可靠性程度、可维 护性程度等。对外接口(External Inteface ):系统和环境中其他系统之间需要 建立的接口，包括硬件接口

5、、软件接口、数据库接口等等。约束：进行系统构造时需要遵守的约束，例如编程语言、硬件设 施等。广泛意义上的需求分类：系统级需求(System ):针对系统工程的需求，包括与硬件相关的需 求被称之为硬件需求(Hardware )、与软件相关的需求被称之为软件 需求(Software )、与人力资源相关的需求以及软件、硬件、人力之 间协同的需求被称之为其他需求。功能需求和非功能需求的差异：除功能需求之外的其他四种类别需求 又被统称为非功能需求。在非功能需求当中，质量属性对系统成败的 影响极大，因此在某些情况下，非功能需求又被用来特指质量属性。 而且通常一个软件系统的绝大部分需求都是功能需求，在比例上

6、功能 需求有可能占所有需求的90%以上。5. 描述业务需求、用户需求和系统(级)需求的区别与联系。业务需求：业务需求是抽象层次最高的需求，是系统建立的战略出发 点，表现为高层次的目标，它描述了组织为什么要开发系统。用户需求：执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够助用户 做些什么。系统需求：用户对系统行为的期望，一系列的 系统行为联系在一起可以帮助用户完成任务， 满足业务需求；系统需求可以直接映射为系统 行为，定义了系统中需要实现的功能，描述了 开发人员需要实现什么。业务需求、用户需求和系统（级）需求的区别与联系如右图所示：用户需求-> 系统需求的过程：首先需要分

7、析问题领域及其特性，从中发现问题域和计算机系统的共 享知识，建立系统的知识模型；然后将用户需求部署到系统模型当中， 即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统 行为即为一个系统需求。该过程就是需求工程当中最为重要的需求分 析活动，又称建模与分析活动。6. 优秀的需求哪些特性？试为每一个特性都举出一个不符合的示例。优秀的需求特性：1）完备性：不需要做更多的扩展就可以充分的说明用户所需要的系 统功能。每一个需求的描述都应该包含开发人员设计和实现这项 功能需要的所有信息。R6 （不完整）：系统应该允许被扩展R7 （完整、较R8精确）：系统的调度算法应该允许被扩展2）正确性：真实的反

8、映用户的意图；必须请需求的提出者予以确认。3）可行性：在检查的过程中，由开发人员进行检查可能需要进行一 定的分析和研究，而不是单纯的凭借经验和直觉。 对于难以判断的需 求，必要的时候要通过开发原型来加以验证。示例：保证系统核心功能可以7X24小时连续运行。4）必要性：满足用户的业务需求所必需的。5 ）无歧义：每一项需求都应该有而且只能有一种解释。定义一个可以共同理解的词汇表（Glossary ）6）可验证：通过分析、检查、模拟或者测试等方法能够判断需求是 否被满足。示例：实现各部门的公文流转无纸化、文档一体化、业务管理的 规范化、自动化和网络化；统一办公流程、规范公文格式，加强信息 交流和共享

9、，提高工作效率；不可验证的需求往往是因为描述模糊或 者过于抽象，所以在进行需求的描述时要让需求具体化、小心形容词 和副词的使用、避免程度词的使用。第三章1需求工程过程的工作基础（即输入）存在哪些？他的工作成果（即 输出）有哪些？答：需求过程的工作基础是获取用户面临的业务问题，用户期望 系统表现出来的各种行为，即需求获取工作成果：产生一个能够在用 户环境下解决用户业务问题的系统方案，并将其文档化为明确的规格 说明2描述需求工程的各个活动，说明他们各自的工作基础，工作目标 和工作成果1需求获取：工作基础：1.收集背景资料2定义项目前景和范围3.选择信息的 来源4选择获取方法，执 行获取5.记录获取

10、结果工作目标:获取用户需求，了解用户在完成任务的时候遇到的问题 与期望 工作成果:业务需求，项目的前景和范围，用户需求以及问题 域的特征2需求分析：工作基础：1背景分析2.确定系统边界3需求建模4. 需求细化5.确定优先权6.需求协商工作目标:1.通过建模整合各种信息，是人们更好地理解问题2. 定义一个需求集合，能够为问题界定一个游戏的解决方案工作成果：产生一个需求的基线集，它指定了系统或当前版本的 系统开发需完成的任务3. 需求规格说明：工作基础1.定制文档模板2.编写文档工作目标:为了系统涉众之间交流需求信息工作成果:需求规格文档说明4.需求验证工作基础1.执行验证2问题修改 工作目标：为

11、了尽量不给设计 实现测试后续开发活动带来不必要的影响。 需求规格说明文档定义必 须正确准确地反映用户的意图工作成果:验证之后，问题得以修正需求管理：工作基础：1.建立和维护需求基线集2.建立需求跟踪信息3进行 变更控制 工作目标:保证需求作用的持续稳定和有效发挥工作成果:需求管理会进变更控制和实现合理的变更请求拒绝不合 理的变更请求，控制变更的成本和影响范围4需求工程师需求具备的技能 专业技能，分析技能，交流技能， 观察技能，建模技能，写作技能，创新技能，协调技能第五章1为什么要定义项目的前景和范围？答、业务需求、高层解决方案和系统特性都应该被记录下来，定 义为项目的前景与范围文档，前景描述了

12、产品的作用和最终的功能， 它将所有的涉众都统一到一个方向上范围指出了当前项目是要解决 产品长远规划的那一部分，它为项目规定了需求的界限案例题：1. 你被任命为替换学生财务资助项目的项目经理。你想开发一 个工作陈述来定义范围并降低范围蔓延的风险。财务资助部 门的主管坚持要你15个月、600 000美元的预算内替换他现 有的系统就可以了。他说这就是你需要知道的全部，不需要浪费时间开发一个工作陈述了。省略工作陈述的风险是什么？ 你将如何说服主管？解答：省略工作陈述的风险是不能明确项目的前景和范围。如果省略了工作陈述的话，我们就不能和用户进行很好的沟 通与交流，这样，项目的问题也就不能明确，开发人员无

13、法 与涉众对问题达成共识；无法明确问题，也就无法发现正确 的业务需求，无法定义良好的解决方案及系统特性，继而无 法明确项目的前景和范围，这样就会造成项目的不稳定甚至 失败！第六章1什么是涉众？涉众分析？软件系统中常见的涉众？涉众是与要建设的业务系统相关的一切人和事.涉众分析就是为软件系统寻找并理解关键涉众的过程 常见的涉众:管理着：用户、客户、开发人员、管理者、领域专家、 政府力量和市场力量等领域专家：在问题域中具有丰富知识的专家*关注软件中的知识政府力量：法律法规、长远规划、政策意向*起约束和指导作用市场力量：组织中的市场部门人员，关注用户的想法*关注用户想法用户：最终使用和操作产品的人关注

14、软件功能客户：为软件系统开发付费的人*关注经济的成本、收益开发者：负责实现软件系统的人*关注技术上的成本和利益第七章2列出面谈的5个步骤面谈准备的主要工作包括：1、阅读背景资料2、确定面谈的主题和目标3、选择被会见者4、准备会见被会见者5、确定问题和类型第8章1.原型的定义原型是一个系统，他内化了一个更迟系统的本质特征。2说明原型在需求获取中的作用和试用情景因为原型是在最终系统产生之前的一个局部真实表现，所以原型 方法可以让人们在系统的开发过程中，就能对一些具体问题进行基于 事物有效沟通，从而帮助人们今早解决软件开发过程中存在的各种不 确定性。场景:产品以前从未存在过，而且难以可视化，这些产品

15、属于创新产品， 他们的基本需求是潜在的，有很大的不确定性产品的用户对相关类别的产品没有经验，而且对将要采用的技术 也没有经验。此时用户无法明确工作的具体细节， 产品的细节需求存 在着不确定性 用户进行自己的工作已经有一段时间了，但在完成工 作的方式上依然存在障碍。 用户清晰说明他们的需求方面存在困难。 在澄清和理解之前，这些需求存在着不确定性需求的可行性值的怀疑，即具体需求的可满足性存在着不确定性三、案例题“我有一个绝妙的主意！” Bea Kwicke宣布，他是系统团队的一 位新来的需求工程师，“让我们跳过所有的SDLC垃圾，直接为一切 设计原型。我们的项目会进展的更快，还可以节省时间和金钱，

16、并且 所有的用户会感到我们似乎很在意他们，而不是连续几个月不与他们 交谈。a）列出你（作为与Bea同一个团队的成员）用来劝阻她不要试图 放弃SDLC，而直接为所有项目设计原型的原因。b）Bea对你所说的话很失望。为了鼓励她，用一段话向她说明，你认为适用于原型化方法的情（1）主要原因：原型仅仅是开发当中使用的一种手段，它利用得当 可以加速开发的进 程，但不能代替软件开发中的所有工作。（2）情形见下表，尤其是其中红色的部分第九章1为什么需要观方法？观察方法的适用情景是什么？答：很多时候用户无法完成主动的信息告知，或者说用户和需求工程师之间的语言交流无法产生有效的结果， 这时就有必要采用观察 的方法

17、。采样观察：根据明确的目的选取特定的时间段或者特定的事件进行观察。民族志：观察者深入到用户中，花费较长的时间（一般为 几个月）来观察用户的活动。话语分析：它通过观察和分析用户交谈中的交互方式或者特定的 话语形式的内部结构来发现和获取相关信息。协议分析：对用户任务的观察。它要求观察对象一边执行任务，一边大声地解释他们在执行任务时产生的各种想法。任务分析：专门针对人机交互行为的观察。它引入了相关的模型方法来观察、记录和分析用户与软件系统的交互行为案例题1. Ceci Awill说：“我想我能记得他所做过的大部分事情。” Ceci 准备与OK Corral公司战略规划副总裁 Biff Weblldo

18、n 进行面谈。OK C orral是一家拥有130间牛排连锁店的公司。“我的意思是说，我有好的记性。我认为听他说什么比看他做什么更重要。”作为需求工程团队的一员,Ceci Awll向你诉说了他要写下在面谈 中对Biff的办公司和Biff的活动进行观察的愿望。（1）用一段话来说服Ceci，在面谈时仅仅倾听是不够的，观察和 记录所观察的内容同样是很重要的。（2）Ceci似乎接受了你认为观察时很重要的观点，但是不知道该观 察什么。列出需要观察的项目和行为，在每一项行为的旁边用一句话 指名Ceci通过观察应该得到的信息。答：（1）面谈并不能确保用户能够将所有的信息都告知需求工程 师，诸如一些语言无法确

19、切描述的事务， 而观察能够了解用户真正做 什么，还能够获取到其他方法不能得到的用户及其工作环境的信息， 还可以对从其他方法获取的信息进行确认， 所以我们应该重视观察方 法的应用。观察客户所处的环境（得出何种需求才能更适合客户）。（2）观察客户行为、习惯特征（得出更适合客户使用的软件需求）。第十一章2什么是系统模型，他与需求分析和系统设计有什么关系？系统模型是指以某种确定的形式（如文字、符号、图表、实物、 数学公式等），对系统某一方面本质属性的描述。需求分析是挖掘和整理知识的过程，它在已掌握知识的基础上进 行。初步捕获到的需求信息往往处于不同层次，也有一些主观甚至不 正确的信息。而经过必要的需求分析工作之后，需求会更加系统、更 加有条理、更加全面。那么系统分析呢？如果说，需求分析致力于搞清楚软件系统要“做 什么”的话，那么系统分析已经涉及“怎么做”的问题了。需求捕获、需求分析以及系统分析之间的关系我们必须理解透彻， 否则就会影响工作的有效性进行。同样，在实践中，需求分析和系统分析也常常被混淆。需求分析 致力与搞清软件系统要“做什么”，而系统分析更关注“怎么做”的 问题，比如大多数分析方法（女口 00A ）应该术语系统分析的范畴。第十二章1什么是系统思想？过程模型如何反应系统思想？系统是指由相互 制约、相互作用的一些部分组成的具有某种功能的有机整体。因