《软件需求概述》第一章思考题.doc

第一章 软件需求概述思考题1 软件项目目标的三个要素是什么？质量、时间、成本2 理解IEEE对需求的定义。（1）用户解决问题或达到目标所需的条件或权能（Capability）。（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明3 谈谈需求文档的重要性。4 好的需求特征有哪些？一致性和全面性5 软件需求分析的目标是什么？软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其它系统元素的接口细节，定义软件的其它有效性需求。6 需求分析的任务是什么？需求分析的任务就是借助于当前系统（含手工作业）的逻辑模型导出目标系统的逻辑模型（如业务流程图等），解决目标系统的 “做什么” 的问题。 通俗地说,需求分析的任务就是准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用 规范的形式准确地表达用户的需求。7 错误需求的代价有哪些？v 错误的需求浪费了人力、物力，浪费了金钱，总之，浪费资源。v 影响软件项目的成功，加大软件项目的风险。v 影响项目组及开发方形象，对用户满意度埋下“祸根”。v 增加开发的成本8 产生不合格需求的原因有哪些？1. 无足够用户参与。2. 用户需求的不断增加。3. 模棱两可的需求。4. 过于精简的规格说明。5. 忽略了用户分类，如菜单驱动操作对高级用户太低效了，但含义不清的命令和快捷键又会使不熟练的用户感到困难（如SAP的事务代码）。6. 不准确的计划，往往低估开发时间。9 好的软件需求特性有哪些？理解其含义。1) 无歧义因素编写需求人员常常下意识假设所有人的某个主题、名词或术语都与自己有一样的认知水准。文档书写过简略也可能引起歧义。2. 完整性因素 避免遗漏，“待确定”项通常要在开发前明确。如OA中开发“知识库”功能的例子。又如，SAP的需求文档说明“包括上述功能，但不代表全部”。3. 一致性因素 业务需求与用户需求一致，功能需求与用户功能一致（下节讲述）。各层次的内容不矛盾。4. 可检验性因素 便于将来测试时有基准参照。5.确定性因素 明确在所有可能的条件下（满足和不满足时）系统应该做什么。6.可跟踪性因素 每条需求都应该被唯一标识，以便能够在设计、实现和测试过程中进行跟踪。这也有助于维护系统。7. 正确性因素 用户需求正确映射到软件需求。8. 可行性因素 如生产现场使用ERP系统，某酒店在OA中使用派车单。9. 必要性因素 每项需求都能回溯至某项客户提出的要求，避免“吃力不讨好”、“画蛇添足”10 理解需求层次的构成，能识别业务需求、用户需求、功能需求和非功能需求。软件需求包括不同的层次：业务需求、用户需求、功能需求和非功能需求 v 业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。v 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或场景描述中予以说明。v 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求（如，系统发送电子邮件来通知用户已接受其预定）。v 非功能需求描述了系统展现给用户的行为和执行的操作等。包括外部界面的具体细节；性能要求等，如可靠性、可用性、有效性（性能和可伸缩性）、可维护性、可移植性等。11 什么是需求的路线图，理解特性和涉众的概念。 了解从用户要求到软件需求的一般路径，即从问题领域转向解决方案领域。软件或系统项目涉众(stake holder) 包括：客户: 为达到其公司的业务目标而投资项目或购买产品。用户：直接或间接与产品打交道，是客户的一部分。需求分析员：负责编写需求并传达给开发团队。开发人员：设计、实现和维护产品。测试人员：确定产品的行为是否与预计的相一致。文档编制人员：负责编写用户手册、培训资料和系统帮助。项目经理：制定项目计划并带领开发人员获得成功。法律人员：确保产品符合所有相关