需求分析与设计课后答案

第一章1.需求分析和系统设计之间的界限是什么？分析阶段何时进入设计阶段？需求分析关注系统“做什么”，系统设计关注如何去做。当分析阶段完成时，它可以进入设计阶段。2.需求处理中应该注意哪些非技术因素？为什么？需要注意的非技术因素：组织文化、社会背景、商业目标、利益谈判等。由于建模与分析技术构建的解决方案必须与特定的应用环境相关，没有不依赖于特定应用环境的解决方案，因此，在使用建模与分析技术进行需求处理时，特定应用环境的相关因素不可忽视3.需求分析与需求工程的关系也就是说，需求工程具有更广泛的含义，包括需求获取、需求分析和需求定义。第二章1.解释名词：的问题域，理解系统和共享现象，并解释软件系统如何通过组合它们的含义与现实世界互动。问题领域：实际情况和预期情况之间的差异会导致问题。解决方案系统：软件系统可以通过影响问题领域来帮助人们解决问题。通过共存，解决系统只是问题域和姐妹系统的一部分。不是所有人。软件系统只是现实世界的抽象。所以问题不仅仅是分享的现象。在抽象模型时，还有许多其他被忽略的现实因素。2.解释以下术语、需求、规范、问题域特征和约束，并结合它们的含义解释需求工程的主要任务。需求是用户对问题域中实体状态或事件的预期描述规格：规格是系统为满足用户需求而提供的解决方案，它规定了系统的行为特征。问题域的特征：当解决方案系统相互作用时，问题域是自治的，它有自己的操作规则，这些规则不会因为解决方案系统的引入而改变。这个自治规则被称为问题域特征，当这些特征非常清楚时，它被称为约束。需求工程的主要任务：1。需求工程必须解释软件系统将应用的环境和目标，用于实现这些目标的软件功能，以及环境对软件在设计和实现这些功能时完成任务的方式和方法的限制和约束。2需求工程必须将目标、功能和约束反映到软件系统中，将它们映射成可行的软件行为，并准确地规定软件行为。3需求工程还应该正确处理目标、功能和约束随时间的演变。4.需求的常见类别是什么？功能性需求和非功能性需求之间有什么区别？严格意义上的软件需求分类；功能需求：与系统主要工作相关的需求，即用户希望系统在不考虑物理约束的情况下执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现在系统和环境之间的行为交互上。性能要求：整个系统或其组件应该具有的性能特征，如CPU使用率、内存使用率等。非功能性需求质量属性：系统完成工作的质量，即系统需要在“好的水平”上实现功能需求，如可靠性、可维护性等。外部接口：系统与环境中其他系统之间建立的接口，包括硬件接口、软件接口、数据库接口等。约束：在系统构建中要遵守的约束，如编程语言、硬件设施等。广义的需求分类：系统级需求：对于系统工程的需求，包括与硬件相关的需求称为硬件，与软件相关的需求称为软件，与人力资源相关的需求以及软件、硬件和人力资源之间的协调需求称为软件功能性需求和非功能性需求之间的区别：除了功能性需求之外，其他四种类型的需求统称为非功能性需求。在非功能性需求中，质量属性对系统的成败有很大的影响，因此在某些情况下，非功能性需求被用来特指质量属性。此外，软件系统的大多数需求通常是功能性需求，这可能占所有需求的90%以上。5.描述业务需求、用户需求和系统(级别)需求之间的区别和联系。业务需求：业务需求是最高层次的抽象，是系统建立的战略起点。它们被表达为高层次的目标。他们描述了为什么组织需要开发系统。用户需求：用户对系统能够完成的具体任务进行实际工作的期望，并描述系统能够帮助用户做什么。系统需求：用户对系统行为的期望。一系列系统行为可以帮助用户完成任务并满足业务需求。系统需求可以直接映射到系统行为中，定义要在系统中实现的功能，并描述开发人员需要实现的功能。右图显示了业务需求、用户需求和系统(级别)需求之间的区别和联系。用户需求-系统需求流程：首先，我们需要分析问题域及其特征，发现问题域与计算机系统之间的共享知识，建立系统的知识模型。然后，将用户需求部署到系统模型中，即定义一系列系统行为，并将它们组合起来实现用户需求。每个系统行为都是一个系统需求。这个过程是需求工程中最重要的需求分析活动，也称为建模和分析活动。6.优秀需求的特征是什么？试着给每个特性一个不一致的例子。卓越的需求特征：1)完整性：用户所需的系统功能无需进一步扩展即可得到充分解释。每个需求的描述应该包含开发人员设计和实现这个功能所需的所有信息。R6(不完整):应该允许系统扩展R7(比R8更完整、更精确):系统的调度算法应允许扩展2)正确性：真实反映用户意图；必须要求需求的提议者确认。3)可行性：在检查期间，开发者可能需要进行一些分析和研究，而不是仅仅依赖经验和直觉。对于难以判断的需求，必要时应通过开发原型进行验证。示例：确保系统的核心功能能够连续运行724小时。4)必要性：满足用户业务需求的必要性。5)不含糊：每个需求应该并且只能有一个解释。定义一个可以一起理解的词汇表6)可验证性：可通过分析、检验、模拟或测试来判断是否满足要求。示例：实现各部门业务管理的无纸化、文档一体化、标准化、自动化和网络化；统一办公程序，规范文件格式，加强信息交流和共享，提高工作效率；不可验证的需求在描述中往往是模糊的或过于抽象的，因此在描述需求时，有必要明确需求，在使用形容词和副词时要小心，避免使用程度词。第三章1.需求工程过程的工作基础(即输入)是什么？他的工作成果(即产出)是什么？答：需求过程的工作基础是获取用户面临的业务问题。用户期望系统显示的各种行为，即需求获取工作成果：生成一个能够解决用户在用户环境中的业务问题的系统方案，并将其记录为清晰的规范。2.描述需求工程的活动，并解释其各自的工作基础、工作目标和工作结果1.需求获取：工作基础：1。收集背景信息2。定义项目的前景和范围。选择信息来源4.选择采集方法并执行采集。5.记录采集结果工作目标：获得用户的请求2.需求分析：工作基础：1。背景分析2。系统边界的确定。需求建模4.需求细化5。优先级确定。需求谈判工作目标：1。通过建模整合各种信息是人们更好地理解问题的一种方式。2.定义一组需求来定义问题的游戏解决方案工作结果：生成一组基线需求，指定系统或当前版本的系统开发要完成的任务3.要求规范：工作基金会1。自定义文档模板2。撰写文档工作目标：在系统涉众之间交换需求信息工作成果：要求规范文件描述4.需求验证工作基金会1。实施验证2问题修改工作目标：尽可能不给测试后续开发活动的设计和实施带来不必要的影响。需求规范文档定义必须正确和准确地反映用户的意图在验证工作成果：后，问题得到了纠正。需求管理：工作基础：1。建立并维护一套基线要求2。建立需求跟踪信息3。执行变更控制工作目标：以确保持续、稳定和有效地执行要求工作成果：需求管理将实施变更控制和合理的变更请求，拒绝不合理的变更请求，并控制变更的成本和影响范围4.需求工程师需要具备技能、专业技能、分析技能、沟通技能、观察技能、建模技能、写作技能、创新技能、协调技能第五章1.为什么要定义项目的前景和范围？答：业务需求、高级解决方案和系统特征应被记录并定义为项目的前景和范围文档。前景描述了产品的功能和最终功能。它指出，当前的项目是通过统一所有利益相关者来解决产品的长期计划的一部分。它定义了项目的需求。案例问题：1.你被任命为项目经理，取代学生资助项目。您希望开发一个工作声明来定义范围并降低范围扩展的风险。财政援助部门的负责人坚持要你在15个月60万美元的预算内更换他现有的系统。他说，这是你需要知道的全部，没有必要浪费时间来制定工作声明。省略工作说明书有什么风险？你将如何说服主管？答：省略工作说明书的风险是项目的前景和范围不能被清楚地定义。如果省略了工作说明书，我们将无法与用户进行良好的沟通，因此项目的问题将不清楚，开发人员将无法与利益相关者达成共识。如果问题不能被清楚地识别，不能找到正确的业务需求，不能定义好的解决方案和系统特征，那么项目的前景和范围就不能被清楚地定义，这将导致项目的不稳定甚至失败！第六章1.利益相关者是什么？利益相关者分析？软件系统中的共同利益相关者？利益相关者是与要建立的业务系统相关的所有人和事物。利益相关者分析是发现和理解软件系统关键利益相关者的过程。共同利益相关者：管理：用户、客户、开发人员、经理、领域专家，政府和市场力量等。领域专家：在问题领域拥有丰富知识的专家*注重软件知识政府权力：法律法规、长期规划、政策意图*发挥约束和引导作用市场力量：组织营销部门的人员，他们关注用户的想法。*关注用户的想法用户：最终使用和操作产品的人*专注于软件功能顾客：支付软件系统开发费用的人。*关注经济的成本和收益开发者：负责实现软件系统的人*关注技术成本和优势第七章2.列出面试的五个步骤面试准备的主要工作包括：1、阅读背景信息2.确定面试的主题和目标3.选择受访者4.准备会见受访者5、确定问题和类型第八章1.原型的定义原型是一个系统，内部因为原型是最终系统产生之前的本地真实表示，所以原型方法可以使人们在系统开发过程中基于物质的基础上有效地就一些具体问题进行交流，从而帮助人们解决今天上午软件开发过程中的各种不确定性。场景：产品以前从未存在过，很难想象。这些产品是创新产品。他们的基本需求是潜在的，具有很大的不确定性。产品的用户没有相关产品类别的经验，也没有采用技术的经验。此时，用户无法指定工作的具体细节，并且产品的详细要求存在不确定性。用户已经做了一段时间自己的工作，但是在完成工作的道路上仍然有障碍。用户明确表示他们的需求有困难。在澄清和理解之前，这些要求存在不确定性对需求可行性价值的怀疑，也就是说，对特定需求的满足存在不确定性。Iii .个案研究“我有一个绝妙的主意！”Bea Kwicke宣布他是系统团队中的一名新需求工程师，“让我们跳过所有的SDLC垃圾，直接为所有的东西设计原型。我们的项目会进展得更快，节省时间和金钱，所有用户会觉得我们似乎关心他们，而不是几个月不跟他们说话。a)列出你(作为比阿的同一个团队成员)曾经劝阻她放弃SDLC并直接为所有项目设计原型的原因。碧对你说的话很失望。为了鼓励她，用一段话向她解释，你认为什么样的原型方法适用(1)主要原因：原型只是开发中使用的一种手段。如果使用得当，它可以加速开发过程，但是它不能代替软件开发中的所有工作。(2)具体情况见下表，特别是红色部分。第九章1.你为什么需要观察这个方法？观察方法的适用场景是什么？答：在许多情况下，用户无法完成主动信息通知，或者用户和需求工程师之间的语言交流无法产生有效的结果。这时，有必要采用观察的方法。抽样观察：根据特定目的选择特定时间段或特定事件进行观察。人种志：观察者深入用户，花很长时间(通常是几个月)观察他们的活动。话语分析：通过观察和分析用户对话中的互动模式或特定话语形式的内部结构来发现和获取相关信息。协议分析：观察用户任务。它要求观察者在执行任务时大声解释他们的各种想法。任务分析：观察人机交互行为。介绍了观察、记录和分析用户与软件系统交互的相关建模方法个案研究1.颜后君阿威尔说：“我想我能记得他做过的大部分事情。”颜后君准备和okcorral公司战略规划副总裁Biff Weblldon接受了采访。Okcorral是一家拥有130家牛排连锁店的公司。“我是说，我记性很好。我认为听他说的比看他做的更重要。”作为需求工程团队的一员，ceciawl告诉你，他想写下他希望在面试中观察Biff的公司和Biff的活动。(1)用一段话来说服颜后君，仅仅在采访中听是不够的。观察和记录观察到的东西也很重要。(2)颜后君似乎已经接受了你的观点，即观察非常重要，但我不知道观察什么。列出需要观察的项目和行为。在每个行为旁边，用一句话来命名颜后君应该通过观察获得的信息。答：(1)访谈并不能确保用户能够将所有信息告知需求工程师，例如一些无法用语言准确描述的交易，但观察可以理解用户真正在做什么，也可以获得其他方法无法获得的关于用户及其工作环境的信息，还可以确认其他方法获得的信息。因此，我们应该注意观察方法的应用。观察客户的环境(哪种需求更适合客户)。(2)观察客