软件需求分析与规范

考试题

一、简答题

1、需求工程通常包含需求启动、需求获取、需求分析、需求规格说明、需求验证和确认，以及需求管理这6个活动，请分别说明每个活动的主要任务是什么？

2、请从再软件工程，软件项目成败和软件质量保证等方面的地位和作用来说明“需求工程的重要性”。

3、通常可以将需求规格说明表示分为非形式化、半形式化和形式化三种形式，请从表现形式、可读性、严格性、易理解性、可验证性等方面比较这三种形式。

4、“分析已有系统”和“原形系统”是两种重要的需求获取技术，请说明这两组方法分别适用于哪些情形？

5、请列出一个在线订购系统的所有可能的涉众（至少四个）

6、需求管理主要包括版本控制、需求变更管理、需求追踪和需求状态追踪等四个主要部分，请说明每个部分的主要作用是什么？

二、确定需求类型

A性能需求，描述速度，处理能力等相关的需求

B效率需求，描述存储空间等利用效率相关的需求

C安全需求，描述用户授权等安全相关的需求

D可用性需求，描述使用系统错作时间、效率相关的需求

E可获得性需求，描述正常使用系统能力相关的需求

F可靠性需求，描述系统失败是处理能力相关的需求

G可移植性需求，描述对运行环境依赖、维护相关的需求

H功能性需求，描述系统做什么的需求

(1)最多有5%的源代码是面向特定操作系统

(2)为了能够到达一个非给定标题的相关帮助应需要至少4次的鼠标按键

(3)系统应该能够在内存250M和外存2G的情况下运行所有的功能

(4)平均来讲，在一个多月内至多有2次因为系统失败而重启系统

(5)为了替换一个关系数据库应需要至少5人时的人力花销

(6)系统应保证对所有删除的未授权访问请求建立日志

(7)系统应该达到或者超过99.9%的正常运行

(8)系统应该能够在高峰负荷时每小时处理25个注册

(9)需要一个用户改正数据库中不一致数据的时间间隔不少于30分钟

(10)系统应该允许用户浏览菜单，并且在线订餐

三、假设将要开发一个大学选课系统UCSS，该系统可以I让学生浏览课程信息、选择下一学期开方的课程，解答问题

1、“如果学生所选的课程之间有时间冲突，系统应该给出提示”可以作为UCSS系统的一个需求定义，请根据你的理解给出UCSS系统的两条功能性需求定义和两条非功能性需求

2、再UCSS系统中，学生和课程是两个重要的数据对象（实体），学生作为实体可以定义如下属性，请给出课程的属性描述（至少5个），并建立学生和课程之间的实体关系图。

1、软件生命周期包含几个阶段？

2、请给出软件需求的定义

3、请给出软件需求的分类

4、请列出软件需求工程的基本活动及各活动的主要任务

5、请列举三种需求获取方法，说明每种方法的使用情形

6、请列举需求规范说明的定义方式有哪些

7、请阐述需求验证和确认的含义

8、请说明需求管理的4个主要活动是什么，并简要阐述每个活动的任务

9、请说明需求状态追踪和需求追踪的区别

10、已知一个Moore有限自动机如下图，其中输入字母表是a，b，c。输出是字母表是mnk，请给出acbbab的输出是什么？ Mnkkmk

二、

1、请说明结构化需求分析与建模方法的主要思想

2、根据下面某仓库管理系统的部分功能描述，用实体关系图完成该系统的部分数据建模。定义所有可能的实体及其属性，定义实体间的关系。

R1: 管理员将购买的商品入库

R2：用户查询商品的销售情况

R3：系统管理员维护仓库信息

三、图书管理系统的需求定义

R1: 一个简单图书馆系统，可以为读者提供如下服务

1、查询图书馆资料情况

2、借阅图书馆资料

R2: 系统必须由一名图书馆工作人员作为系统管理员来管理，她可以对图书进行分类

R3: 读者必须先要想系统管理员在节约之前登记注册

R4: 读者可以是学生、教工、外来读者

R5: 所有读者必须包含名字、图书证号、地址、帐号信息

R6: 此外。再登记时还必须提供如下信息：

3、学生：学位类别和学生证号

4、教工：工作证号

5、外来读者：单位详细信息

请说明如果对上面的需求定义实施面向对象需求分析与建模过程，那么

1、识别出的核心类有哪些？

2、这些类的属性及其关系如何

3、每个类的操作有哪些？

系统上下文是系统所处的环境中与定义、理解和解释系统需求相关的那些部分。

系统边界 System boundary

系统边界将系统和其上下文分离。系统边界将属于系统之内、在开发过程中可以被改变的那些部分和那些在开发过程中不可改变、属于系统上下文的部分分割开。

上下文边界 Context boundary

上下文边界将环境中不相关的部分从系统上下文中分离出去。系统上下文包含了定义系统需求时需要考虑的物质对象和非物质对象。

上下文刻面

有四个刻面：主题，IT系统，开发，使用刻面。

上下文方面

上下文方面是系统上下文的各种物质和非物质对象，如人、技术与非技术性系统、过程、物理规律等。

有三种类型：需求来源，上下文对象，上下文对象的属性和关系

需求来源：是定义系统需求的根源，有三类（涉众、现有文档、现有系统）

涉众：

是在待开发系统中存在潜在利益的人或组织。涉众对于系统通常有着他们自己的需求。一个人可以代表不同涉众的利益，即一个涉众可以有多个角色并代表多个涉众。

目标：是关于系统的目的、属性或者使用的意图。目标可以在不同抽象层次上定义。

软目标：

是参与者希望达成的现实世界中的某种条件，与目标不同的是，要达到的相关条件的准则并没有严格定义。软目标通常是其他某个元素上的一种质量属性。

场景：

场景描述了一个目标被满足或未被满足的一个具体实例。它提供了一个或多个目标的具体细节。

面向方案的需求：

面向方案的需求定义了系统需要实现的属性和特征，比目标和场景更为详细。通常意味着一个概念的系统解决方案。

i*

i*框架是一种全面的、用于目标和目标依赖分析及描述的方法。

i*的基本思想是：一个参与者依赖于其他参与者来实现自己的目标。

KAOS

KAOS建模语言是KAOS框架的一部分，用于对目标、需求、场景和责任分配进行抽取、规约和分析。