软件需求分析与规范

《软件需求分析与规范》由会员分享，可在线阅读，更多相关《软件需求分析与规范（5页珍藏版）》请在金锄头文库上搜索。

1、考试题一、简答题1、 需求工程通常包含需求启动、需求获取、需求分析、需求规格说明、需求验证和确认，以及需求管理这6个活动，请分别说明每个活动的主要任务是什么？2、 请从再软件工程，软件项目成败和软件质量保证等方面的地位和作用来说明“需求工程的重要性”。3、 通常可以将需求规格说明表示分为非形式化、半形式化和形式化三种形式，请从表现形式、可读性、严格性、易理解性、可验证性等方面比较这三种形式。4、 “分析已有系统”和“原形系统”是两种重要的需求获取技术，请说明这两组方法分别适用于哪些情形？5、 请列出一个在线订购系统的所有可能的涉众（至少四个）6、 需求管理主要包括版本控制、需求变更管理、需求追

2、踪和需求状态追踪等四个主要部分，请说明每个部分的主要作用是什么？二、确定需求类型A性能需求，描述速度，处理能力等相关的需求B效率需求，描述存储空间等利用效率相关的需求C安全需求，描述用户授权等安全相关的需求D可用性需求，描述使用系统错作时间、效率相关的需求E可获得性需求，描述正常使用系统能力相关的需求F可靠性需求，描述系统失败是处理能力相关的需求G可移植性需求，描述对运行环境依赖、维护相关的需求H功能性需求，描述系统做什么的需求(1) 最多有5%的源代码是面向特定操作系统 (2) 为了能够到达一个非给定标题的相关帮助应需要至少4次的鼠标按键(3) 系统应该能够在内存250M和外存2G的情况下运

3、行所有的功能(4) 平均来讲，在一个多月内至多有2次因为系统失败而重启系统(5) 为了替换一个关系数据库应需要至少5人时的人力花销(6) 系统应保证对所有删除的未授权访问请求建立日志(7) 系统应该达到或者超过99.9%的正常运行(8) 系统应该能够在高峰负荷时每小时处理25个注册(9) 需要一个用户改正数据库中不一致数据的时间间隔不少于30分钟(10) 系统应该允许用户浏览菜单，并且在线订餐三、假设将要开发一个大学选课系统UCSS，该系统可以I让学生浏览课程信息、选择下一学期开方的课程，解答问题1、 “如果学生所选的课程之间有时间冲突，系统应该给出提示”可以作为UCSS系统的一个需求定义，请

4、根据你的理解给出UCSS系统的两条功能性需求定义和两条非功能性需求2、 再UCSS系统中，学生和课程是两个重要的数据对象（实体），学生作为实体可以定义如下属性，请给出课程的属性描述（至少5个），并建立学生和课程之间的实体关系图。一、 简答题1、 软件生命周期包含几个阶段？2、 请给出软件需求的定义3、 请给出软件需求的分类4、 请列出软件需求工程的基本活动及各活动的主要任务5、 请列举三种需求获取方法，说明每种方法的使用情形6、 请列举需求规范说明的定义方式有哪些7、 请阐述需求验证和确认的含义8、 请说明需求管理的4个主要活动是什么，并简要阐述每个活动的任务9、 请说明需求状态追踪和需求追踪

5、的区别10、 已知一个Moore有限自动机如下图，其中输入字母表是a，b，c。输出是字母表是mnk，请给出acbbab的输出是什么？ Mnkkmk二、1、 请说明结构化需求分析与建模方法的主要思想2、 根据下面某仓库管理系统的部分功能描述，用实体关系图完成该系统的部分数据建模。定义所有可能的实体及其属性，定义实体间的关系。R1: 管理员将购买的商品入库R2：用户查询商品的销售情况R3：系统管理员维护仓库信息三、 图书管理系统的需求定义R1: 一个简单图书馆系统，可以为读者提供如下服务1、 查询图书馆资料情况2、 借阅图书馆资料R2: 系统必须由一名图书馆工作人员作为系统管理员来管理，她可以对图

6、书进行分类R3: 读者必须先要想系统管理员在节约之前登记注册R4: 读者可以是学生、教工、外来读者R5: 所有读者必须包含名字、图书证号、地址、帐号信息R6: 此外。再登记时还必须提供如下信息：3、 学生：学位类别和学生证号4、 教工：工作证号5、 外来读者：单位详细信息请说明如果对上面的需求定义实施面向对象需求分析与建模过程，那么1、 识别出的核心类有哪些？2、 这些类的属性及其关系如何3、 每个类的操作有哪些？系统上下文系统上下文是系统所处的环境中与定义、理解和解释系统需求相关的那些部分。系统边界 System boundary系统边界将系统和其上下文分离。系统边界将属于系统之内、在开发过

7、程中可以被改变的那些部分和那些在开发过程中不可改变、属于系统上下文的部分分割开。上下文边界 Context boundary上下文边界将环境中不相关的部分从系统上下文中分离出去。系统上下文包含了定义系统需求时需要考虑的物质对象和非物质对象。上下文刻面有四个刻面：主题，IT系统，开发，使用刻面。上下文方面 上下文方面是系统上下文的各种物质和非物质对象，如人、技术与非技术性系统、过程、物理规律等。有三种类型 ：需求来源，上下文对象，上下文对象的属性和关系需求来源：是定义系统需求的根源，有三类（涉众、现有文档、现有系统）涉众： 是在待开发系统中存在潜在利益的人或组织。涉众对于系统通常有着他们自己的需

8、求。一个人可以代表不同涉众的利益，即一个涉众可以有多个角色并代表多个涉众。目标：是关于系统的目的、属性或者使用的意图。目标可以在不同抽象层次上定义。软目标： 是参与者希望达成的现实世界中的某种条件，与目标不同的是，要达到的相关条件的准则并没有严格定义。软目标通常是其他某个元素上的一种质量属性。场景：场景描述了一个目标被满足或未被满足的一个具体实例。它提供了一个或多个目标的具体细节。面向方案的需求： 面向方案的需求定义了系统需要实现的属性和特征，比目标和场景更为详细。通常意味着一个概念的系统解决方案。i*i*框架是一种全面的、用于目标和目标依赖分析及描述的方法。i*的基本思想是：一个参与者依赖于

9、其他参与者来实现自己的目标。KAOSKAOS建模语言是KAOS框架的一部分，用于对目标、需求、场景和责任分配进行抽取、规约和分析。软件工程：将系统性的、严格约束的、可定量的方法应用于软件的开发、运行和维护。它是一个有关软件生产方法的工程学科。需求工程：是软件工程的一个分支，它包括一系列活动，它们关注于定位和交流软件系统的功能，和软件所应用的领域。需求工程的作用相当于一座桥梁，它一端连接着现实世界中的用户，顾客和该软件系统所有涉众的需求，另一段连接着软件技术所给予的支持。需求： 用户解决某个问题或者达到某个目标所需要的条件或能力； 一个系统或系统组件为了实现某个契约、标准、规格说明或其他需要遵循

10、的文件而必须满足的条件或拥有的能力。 对以上所描述的条件或能力的文档化表示。需求制品： 指代一个被文档化的需求，一个需求制品使用特定文档格式来刻画需求，是执行所有其他开发活动的基础，对于任何开发项目而言都是根本性的。需求类型：功能性需求，质量需求，约束，非功能性需求。用户需求：是用户和其他涉众期望系统所实现的一个预期的目标或功能，为用户而写。系统需求：整体上，系统所要建立的需求，它详细描述了系统功能、输入输出、异常等。功能性需求： 系统应提供的服务、系统针对特定输入如何响应以及系统在特定情况下的行为陈述，在某些情况下，该需求还会陈述系统不该做什么。非功能性需求：主要有两类非功能需求，不明确的功

11、能性需求和部分质量需求。质量需求：定义了一个整个系统或一个系统组件、服务或功能的质量特性。设计约束：用于定义系统设计的所有约束。包括由硬件限制或者其他标准带来的约束。约束：是一种限制了系统开发方式的组织或技术要求。项目前景：描述了该项目是什么以及它最终会变成什么样子。特征：按照系统的特征来组织需求，这些特征在不同的系统接口上表现为可见的服务形式。项目范围：确定当前项目将符合最终版本产品的哪个部分。可行性分析： 是通过对项目内容和相关条件，从各方面进行研究和分析，并对项目建成后所取得成果进行预测，从而得出该项目是否值得实施及如何实施，为项目决策提供依据的一种综合性系统分析法。原型： 是一个软件系

12、统的初始版本，用于演示概念、尝试设计方案，一般而言用于更好的认识问题及其可能的解决方案。领域模型：对领域中的概念类或真实世界中的对象的可视化表示。数据字典： 定义概念、术语或者数据元素的结构。数据字典精确地、严格地定义了每一个与系统相关的数据元素，并以字典顺序将它们组织起来，使得用户和分析员对所有的输入、输出、存储成分和中间计算有共同的理解。用例：是用户和计算机系统之间典型交互的一组相关集。用例模型：从用户的角度描述系统功能，常用用例图表示。需求规格说明： 是在需求分析过程中系统的组织系统需求，并正确的为这些需求建立需求文档过程，需求规格说明书清晰且准确的描述软件系统每条必须的需求以及外部接口

13、，包括软件的功能、性能、设计约束和质量属性。四变量模型1、监视变量：表示将会影响系统行为的，能衡量的环境属性。2、控制变量：系统能够控制的环境属性。3、输入数据项：输入设备读取的变量4、输出数据项：输出设备写入的变量需求验证： 确定正在正确地建立产品，软件应当符合它的规格说明书，也就意味着开发的每一步都应当遵循过程和标准，质量是需求验证的目标。需求确认： 确定建立的是正确的产品，软件应当按用户的需求来执行，意味着整个产品和过程都满足用户的需要，用户的满意是需求确认的目标。从用户哪里得到对需求规格说明书的认可。需求配置：配置基于版本，用于管理需求制品的不断演化，配置将相关的各种需求制品不同版本进

14、行组合。需求基准（线）：开发团队在规格说明中承诺实现的功能性和非功能性需求集。需求状态：是指用户需求的一种状态变换过程。 8个状态值，已建议，已批准，已设计，已实现，已验证，已提交，已删除，已拒绝。需求追踪： 是以软件需求规格说明文档为基线，在向前个向后两个方向，描述需求以及追踪需求变化的能力。它分为向前追踪和向后追踪两种。需求追踪的目的： 1、建立和维护从用户需求开始到测试之间的一致性与完整性。 2、确保所有的实现是以用户需求为基础，对于需求实现是否全部的覆盖。 3、同时确保所有的输出与用户需求的符合性。需求管理： 一种获取，组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。