软件需求工程复习_需求建模考试

题型：

一、案例分析题（共30分) 3题 30分
二、E-R数据模型题 1题 10分
三、UML建模题（共30分）3小题 30分 （用例图、类图，活动图）
四、 论述分析题（每小题10分，共30分）

软件需求工程会在论述题中出概念题，总共3题，应该会在第1、2、3、5、6、7中出三道论述题三道案例分析题。

第一章 需求概述

本章考点

1. 需求问题的提出（了解为什么提出需求）
2. 需求的层次和分类（了解需求的组成部分的关系）
3. 优秀需求的特征（废话）

本章考试题型

例题(论述题, 20分)
分析下列需求分别属于下面的哪种类型（业务需求，用户需求，系统级（功能）需求，质量属性）并说明原因。
1、当订单数量大于现有数量时，系统必须通知操作员；
2、产品在发布1年之后，必须在出版的A、B、C三个产品评论刊物中被评为最可靠的产品；
3、能够为用户提供库存分析报告、商品/利润报告和过期商品报告；
4、商品标识的类型要能够在0.5个人月内更改为长整型。

答题：
1、系统级需求；原因：系统必须完成的内容
2、业务需求；原因：这个问题是提出客户想从该系统中取得结果的用户所要求的目标，为后继工作建立的一个指导性的框架
3、用户需求；原因：为用户提供报告
4、质量属性；原因：这个问题是针对具体的产品提出的质量要求，并不改变产品的功能，应该属于非功能性需求的一种

例题：资料题
阅读下列材料，分析材料出现的问题是什么？说明了什么问题？
“喂，是王经理吗？我是人力资源部的小李，我们在使用你编写的职员系统时遇到一个问题，一个职员想把她的名字改成高李丽娜，而系统不允许，你能帮帮忙吗？”
“她嫁给了一个姓高 的人吗？” 王经理问道。
“不，她没有结婚，而仅仅是要更改她的名字，”小李回答。
“就是这问题，好像我们只能在婚姻状况改变时才能更改姓名。”
“当然是这样，我从没想过谁会莫名其妙地更改自己的姓名。我不记得你曾告诉我系统需要处理这样的事情，这就是为什么你们只能在改变婚姻状况对话框中才能进入更改姓名的对话框。”王经理说。
小李说：“我想你当然知道每个人只要愿意都可以随时合法更改他（她）们的姓名。但不管怎样，我们希望在下周五之前解决这个问题，否则， 李丽娜将不能支付她的账单。你能在此前修改好这个错误吗？”

答：
参考答案
材料出现的问题有：
1、非正式信息的收集
2、未确定的或不明确的功能
3、未发现或未经交流的假设
4、不完善的需求文档
5、以及突发的需求变更过程。
说明的问题有：在软件开发中遇到的许多问题，都是由于收集、编写、协商、修改产品需求过程中的手续和作法（方法）失误带来的。

（注意：做此种案例分析题时，分析材料内容。题目问存在什么问题或有什么教训时候，可以这样来分析，例如
没有分析业务需求，分析项目前景和目标
没有进行涉众分析，没有沟通交流，分析用户需求，导致用户不满
没有进行分析导致没有良好的质量属性等，
没有进行分析导致功能需求不足，
没有进行设计约束分析
没有进行分析导致没有好的对外接口
需求文档不完善 等。。）

---

第二章 需求工程

本章考点

1. 需求工程分为需求开发、需求管理两个阶段。每个阶段有什么活动，每个活动的任务（图2.1，记概念）
2. 需求分析师的职责（53页，记标题）
3. 需求分析师的技能（53页，记标题）

本章题型

例题：论述题
需求工程分为需求开发、需求管理两个阶段。每个阶段有什么活动，每个活动的任务是什么？

答：
需求开发分为需求获取、需求分析、需求规格说明、需求验证四个活动
需求获取的任务：确定待开发的软件系统的用户类
需求分析的任务：分析用户的需求信息，并按软件需求的类型对这些需求信息进行分类
需求规格说明的任务：根据收集的需求信息和逻辑模型生成需求模型构件的精确的形式化描述，编写作为用户和开发者之间协约的需求规格说明及其文档
需求验证的任务：评审需求规格说明，分析需求规格的正确性和可行性

需求管理的活动分为需求跟踪、变更管理、基线管理
需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档。
基线管理。需求基线就是项目组成员一经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合。
变更管理是指当完成需求说明之后，遇到项目需求变更时，根据需求工程思想定义，需求说明书需要在原有基础上追加或者补充新的需求，或者对原有需求进行修改和削减，这些都属于需求变更管理的范畴。

论述需求分析师的职责。

答：需求分析师是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。需求分析师是客户与开发人员交流的中间人，负责将客户对产品的初步想法转化为明确的需求说明，用来指导开发工作。需求分析是的工作有：
（1）项目前期配合项目组并参与需求调研，收集整理客户需求，编写《用户需求说明书》;
（2）分析、解析用户需求，完成《软件需求规格说明书》编写，组织需求评审,负责客户方需求评审讲解;
（3）代表项目组与用户沟通与项目需求有关的所有事项，代表客户与项目组成员沟通项目需求有关的所有事项;
（4）负责需求变更调研及变更分析，完成《需求变更说明书》编写，推动并跟进需求变更审批流程执行;
（5）协助系统架构师、系统设计人员、编码人员对需求的理解，负责软件需求符合度检查;
（6）协助售前完成符合客户要求的咨询方案、技术方案编写，参与售前支持和业务规划。

论述需求分析师所需要的技能

（1）沟通技能，沟通包括演讲、倾听、书写、展示和记录等。
（2）创造力、分析和解决问题的能力，业务分析是一项通过对需求定义和提出对干系人有价值的建议来进行的企业变革的实践。对于需求分析师而言，想要能够定义问题并且提出解决方案，他们应当有创造力、应当能分析在问题背景下众多的参与者和发挥作用的因素，并创造性地提出解决方案。深入分析有助于对于问题背景的全面透彻的理解。
（3）技术技能，需求分析师需要了解技术领域的潮流、精通解决方案会使用的技术，并且能用技术语言和实施团队沟通。需求分析师需要的技术技能有数据库、架构、框架、系统等。
（4）人际关系技巧，需求分析师依赖软件涉众的参与来获得任何有意义的产出，需求分析师需要很多人际关系技巧来和软件涉众打交道。
（5）建模分析技能，需求分析师创造的很多交付物都是未来状态的模型。他们用到的许多技能都可以归结为在任务中的建模、分析和设计技能。通常需要能够熟练使用Axure、photoshop、visio等工具，不过最重要的还是文档的能力。

---

第三章 需求获取

本章考点

1. 需求获取的任务
2. 需求获取的技术
3. 建立业务需求
4. 获取用户需求
5. 基于用例的需求获取

本章题型

案例分析：
随着旅店声誉日益提高，住宿人员越来越多，旅客为了能够获得好的房间，均提前预订房间。
然而，随着预订的增多、预订周期的拉长，存在很多问题：
1、前台服务员工作压力日益增大，还经常出现工作的失误，使得已经预订好房间的旅客也不能按期入住，这给酒店的声誉带来不好的影响。
2、前台服务员无法快速地计算房间费用、预订费用、取消预订后退款金额等信息。
3、旅店老板想根据旅客预订情况，及时调整房间价格。但统计旅客预订情况比较困难。
为此，旅店老板想到了计算机，希望能够通过计算机来自动管理这些预订业务，不过由于目前资金的问题，目前只开发一个单机版的系统，不提供网上业务；并且旅店方面的其它业务暂不考虑信息化问题
旅店老板委托某计算机公司开发该系统，并承诺如果系统运转良好的话，将会考虑进一步合作事宜。
如果你是项目经理，请进行业务目标分析， 涉众分析。

答：
业务目标分析：
方便、快捷、准确地为旅客预订房间；
旅客可以方便的取消预订的房间
旅店经理能够定期的获取预订的信息，根据这些信息可以及时调整房间的价格
及时、快速地计算房间费用、预订费用、取消预订后退款金额等信息

涉众分析：

---

第四章 需求分析与建模

本章考点

1. ER数据模型
2. 用例
3. 类图
4. 活动图

本章题型

请为下列描述建立实体关系图。
设计一个图书数据库，此数据库中记录图书、出版社、著者等信息。
图书的信息包括：书号，书名，出版社号，出版年号及书价；
出版社的信息包括：编号，出版社名称及地址；
著者信息包括：编号，姓名，性别，年龄及联系电话等。另外还保存图书著者的排名信息。
每个出版社可以出版多种图书，一种图书只能被一个出版社出版。一个著者可以参加多种书的编写，但排名不同。


（注意实体之间的关系，例如n对m、n对1等关系；和主键的设置）

网络教学系统需求说明如下:
1）学生可以登录网站浏览各种信息，包括课程基本信息，教师发布的文章如教学计划，学习方法等。学生可以输入关键字查找所需文章。学生可以使用下载功能将网站上的文件（如课件及资料文件）下载。下载前要进行权限验证，只有通过权限验证才能下载。
2）教师可以登录网站为自己所教授的课程添加课程基本信息，发布教学计划等文章，上传文件（如课件和资料文件）供学生下载，更新文章。
3）系统管理员可以对页面进行维护，页面维护包括文件的审核和处理、页面更新。系统管理员可以批准用户的注册申请。
写出该系统中有哪些参与者?画出用例图。

画出网络教学系统的类图。



注意这里画的是业务级别的类图，注意画上类与类之间的关系

根据网络教学系统中教师上传文件的的活动，创建带泳道的活动图。
1）教师申请文件上传。
2）在网络教学系统网站上验证文件的大小及其他信息。
3）如果验证不通过，则返回输入有误。如果验证成功，则文件存储在网站，提交系统管理员认证。
系统管理员认证通过，则更新页面，反馈给教师，教师可知上传成功。如系统管理员未认证通过，则删除网站上文件，反馈给教师，教师可知未上传成功。



可以画泳道也可以不画，这个看题目要求，注意泳道图的格式以及开头和结尾

---

第五章 需求文档

本章考点

1. 需求文档的类型
2. 需求规格说明活动
3. 优秀需求规格说明的特征

本章题型

论述题：
软件需求规格说明的作用是什么？其包含的主要内容是什么？

答：
需求文档是最重要的软件文档之一。它使得开发人员、项目管理人员和软件用户对软件的初始规定达成共识，并使之成为整个开发工作的基础。
软件需求规格说明精确地阐述了一个软件系统必须提供的功能，性能以及它所要考虑的限制条件，它不仅是系统测试和用户文档的基础，也是所有子项目模块规划，设计和编码的基础，它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。
主要内容：
1，功能-软件将执行什么功能
2，外部接口-软件如何与人，系统的硬件以及其他的硬件和其他的软件进行交互
3，性能-各种软件功能的速度，响应时间，恢复时间等是多少
4，属性-软件的可用性，可靠性，可移植性，正确性，可维护性，安全性如何
5，影响产品实现的设计约束-是否有使用标准，编程语言，数据库完整性方针，资源限制，运行环境等方面的要求？
除了设计和实现上的限制，软件需求规格说明SRS不应该包括设计、构造、测试或工程管理细节。

论述题：
阐述撰写软件需求规格说明主要活动。阐述撰写需求文档时的各种写作风格及优缺点。

撰写软件需求规格说明主要活动是开发组织需要根据项目的实际情况对标准模板进行裁剪、调整、定制，得到适合于当前项目的软件规格说明模板，此时需求文档的组织结构就基本确认了，采用适当的文档表达方式写入文档内容，就产生了最终的软件需求规格说明书。
写作风格
（1）非形式化语言（主要是自然语言）：就是使用结构合理的自然语言来描述需求，该显示不管对于写的人还是看的人都是一个非常容易接受的方法。以前的项目很多都是采用此方法。
优点：易于编写、易于阅读，不需要掌握特定的技巧；
缺点：不够严谨，歧义性强，表达能力弱（特别是对于复杂问题的描述）
（2）半形式化语言（比自然语言具有更加丰富的语义和严格的语法，同时又没有严格到完全基于数学的语言。如结构化文本语言、图形模型如er图、DFD图、UML图等）
半形式化语言如图形模型在表述时能够给读者提供更强的视觉效果，同时能够使问题更加聚焦。在日常交流中，我们经常会绘制一些非标准的示意图，以便更好地进行沟通。
优点：可视化、聚焦性，易于理解。
缺点：编写和阅读的人都需要能够正确地理解模型，所以一般SRS不可能完全采用复杂模型。
（3）形式化描述：形式化描述比半形式化描述精确度更高一些。对于逻辑性很强，精度要求很高的场合，形式化规格描述是一种不错的选择。
优点：严谨、精确。
缺点：编写和阅读的人都会感到很困难。
具体采用什么风格，依据要表达的内容来确定。这几种会综合使用。
（1）目前多数软件系统采用的风格：一般以非形式化语言为主，辅以图形化模型，需要的地方少量使用形式化规格描述。
（2）RUP(Rational Unified Process)统一开发过程推荐的方法：
图形化模型为主，辅以自然语言，需要的地方少量使用形式化规格描述。
这样需求管理会更加方便。对双方的技术性要求比较强。（如给图形加自然语言注释）
（3）在少量精确性要求很高的文档中，采用形式化语言为主，辅助非形式化化、半形式化语言。

---

第六章 需求验证

本章考点

1. 需求验证的目的和任务
2. 需求验证的方法
3. 需求评审的方法和过程
4. 需求评审的实践（P196）

本章题型

(论述题, 20分)什么是需求验证？需求验证的主要方法有哪些？

需求验证是需求开发的最后一个环节，是一个质量关，相当于需求分析的质量控制，主要观察需求是否正确且充分表达了涉众的需要，需求验证要确保需求符合需求规格说明的良好特性。
需求验证的主要方法有评审、原型与模拟、开发测试用例、用户手册编制、利用跟踪关系、自动化分析。

---

第七章 需求管理

本章考点

1. 什么是需求管理？
2. 需求管理的任务
3. 需求跟踪、需求跟踪的方式、需求跟踪矩阵
4. 需求基线管理
5. 需求变更控制

本章题型

)需求管理包括需求跟踪、变更管理和基线管理。请论述对需求跟踪、变更管理和基线管理的理解。

需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求、体系结构、源代码模块等，需求跟踪为我们提供了由需求到软件产品实现整个过程范围的明确查阅的能力。需求跟踪的两种方式有前向跟踪、后向跟踪。
变更管理是指，当完成需求说明之后，遇到项目需求变更时，根据需求工程思想定义，需求说明书需要在原有基础上追加或者补充新的需求，或者对原有需求进行修改和削减，这些都属于需求变更管理的范畴。
对于需求变更的处理流程分为以下步骤：提出变更、变更评估、决策、回复。如变更被接受，增加实施变更和验证两大步骤。需求变更过程中可借助辅助工具来管理需求变更。
基线管理是实施版本控制的基础，所谓需求基线就是项目组成员一经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合，需求基线的确定可以保证项目的涉众各方对发布的产品中希望具有的功能和属性有一个一致的理解。
需求基线三个特点：（1）已经经过正式评审得到认同 （2）作为进一步工作基准
（3）只有经过正式的控制流程才能更改。
基线内容不能再被随意改动,设计人员和开发人员将基于该需求基线开展后续工作。如果有需求变更,则要经过一系列审批手续,在变更被确认后,修改需求规格说明书,形成新版本的需求规格说明书,進立新的需求基线,变更后的需求才能在设计中被采用。

---

总结

要记的概念有点多，这些都会考成论述题~！！！

考前突击

1、需求的层次和分类？ （P16-19）
软件需求包括三个不同的层次
业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求
用户需求是指描述用户使用产品必须完成什么任务。怎么完成的需求
功能需求定义了系统必须完成的哪些事，即为了向它的用户提供有用的功能，产品必须执行的工作。


软件需求可分为功能需求、非功能需求和设计约束三种类型
非功能需求描述了系统展现给用户的行为和执行的操作等，包括外部界面的具体细节、性能需求、质量属性等。非功能需求是产品必须具备的品质，他们可以让产品有吸引力、易于使用、安全。
功能需求是让产品工作的需求，非功能需求是为工作赋予特性的需求
设计约束是指对开发人员在软件产品设计和构造上的限制，产品必须遵从的标准、规范和合约

注意：
1、业务需求、用户需求、功能需求中哪个最重要？
业务需求
2、满足功能需求和满足非功能需求哪个更为重要？
满足非功能需求往往比满足功能需求更为重要。

案例题
1、从下面的事件中，你可以替李经理总结出哪些教训？（提示：至少包括业务需求处理和涉众分析两个方面）
投资经理李经理对一个新的投资跟踪系统具有强烈的需求。她需要做出快速决策来考虑可能进行的投资或撤资，耽误一个小时就可能给公司造成几千美元的损失。最后她放弃使用公司的信息系统，因为公司的信息系统没有给予她的请求足够高的服务优先级。她找到软件开发商，购买了一套看似可以满足她要求的软件，但高层管理人员不同意使用，而且还遇到了其他一些问题。
首先，财务审计员重新评估了公司的投资策略和投资政策。李经理并不知道这一点，于是新的系统没有计入正在被考虑的新政策。
她自己的职员抵制这个系统产生的有关投资和撤销投资的建议，虽然新系统使用了公司信息系统现有的文件结构，但她却发现她的职员两年前就放弃使用那些文件了，因为那些文件没有包括全面分析可选替代投资方案所需的数据。她的职员也批评新系统的设计，说很小的操作错误就会把系统带入“混乱”状态，而且很难恢复过来。
她的一些下级经理坚持要有图形形式的报告，而新系统无法产生这些报告。 最后的问题是，李经理不能确定新系统是否可以进行适当的修改(数据库结构修改和程序修改)以满足新的需求而不用重写所有的程序，而且她的老板也不能肯定是否会出资请一位顾问来解决这些问题。

答：没有分析业务需求，分析项目前景和目标。
没有进行涉众分析，没有沟通交流，分析用户需求，导致用户不满。
没有进行分析导致没有良好的质量属性等。
没有进行分析导致功能需求不足。
没有进行设计约束分析。
没有进行分析导致没有好的对外接口。

2、要求：从下面的案例中进行系统业务目标分析，涉众分析。
某软件公司，员工人数 100 人，最高领导是总经理。大部分员工是软件研发人员，包括软件设计师，程序员，测试工程师等。除此以外还包括行政人员，财务人员。在没有考勤系统之前，与考勤相关的管理工作是这样的。
（1）每位员工需要上午上班时打一次卡，下午下班时打一次卡，中午的休息不需要打卡。
（2）期间如果需要外出工作，从公司出发时需要打一次卡，回到公司时需要再打一次卡。
（3）员工请假需要填写请假条，请假分为事假、病假、年假等多种情况，请假需要部门领导审批，3 天以上请假还需要最高层领导的审批。
（4）行政部每天统计考勤信息，包括打卡信息、外出信息、请假信息，每月将考勤汇总信息提交给财务部。
（5）财务部根据考勤汇总信息，调整员工的薪金。但这样的管理方式，出现了一些意外事件：
（1）某员工想请年假，但行政部告知该员工的当年度年假已经休完了。年假的管理出现了问题，很可能会影响员工的工作积极性。
（2）某员工投诉当月薪金多扣了钱，原因是考勤信息统计有误，于是财务部将责任推到行政部，行政部推诿财务部要求不明确。
（3）某员工请假，除部门领导外其他人不知情，影响工作衔接。
（3）某天出现了紧急状况，最高层领导想员工 A 来处理，但员工 A 当天请了假，最高层领导并不知道。公司高层期望通过考勤系统提高考勤工作的效率和准确性，避免因为考勤问
题影响正常工作。

（1）业务目标：
规范员工的上下班，请假，外出工作等行为；
方便计算员工的薪金；
方便管理各种带薪休假期；
共享员工的请假及外出工作的信息。
（2）涉众分析
序号 涉众 期望
1 普通员工 1、能方便上下班打卡
2、能方便请假、外出申请
3、能方便查看自己的外出、请假记录
4、能方便了解其它人的请假和外出记录，调、5、整自己的工
作安排
6、不要出现考勤记录方面的错误，导致出现误扣工资，年假
无端减少的情况。
2 行政部员工 1、 方便统计考勤信息，而且不会出错
2、 与财务不的“接口”尽量简单。
3、 方便管理员工的各种带薪假期。
3 财务部员工 1、 方便根据员工的考勤情况调整员工的薪金，而且不会出错。
2、 与行政部的“接口”尽量简单。
4 部门经理 1、 方便审核部门成员的请假、外出申请。
2、 方便了解本部门及相关部门员工的请假、外出情况，以安
排好工作。
5 总经理 1、 方便审批请假，外出申请。
2、 方便检查部门经理是否作出合适的审批。
3、 方便了解全体员工的请假，外出情况，以安排好工作。
4、 避免因为考勤的问题而影响工作效率。

UML 题
寝室管理系统的需求描述如下：
1、学生可以查看寝室信息，寝室设备信息。查看本系各学年各寝室卫生成
绩，当对卫生成绩不满意时，可以申请复查。可以查看公告。当寝室设备出现问
题时，可提交寝室设备报修信息，并随时查看报修情况。可通过微信、支付宝、
网上银行等缴费方式缴纳寝室电费，并可查看剩余电费等。
2、系辅导员老师可以查看本系学生相关信息。分配床位。修改相关学生的
寝室信息。查询本系各学年各专业寝室卫生成绩。
3、管理员可管理寝室信息，寝室设备信息。发布公告。可以查看寝室住宿
信息并将寝室信息分配至各系。查看寝室及床位号，确定无误时进行检查卫生，
检查完后提交卫生成绩及扣分项，提交后可查看提交的信息，当发现错误时，可
及时修改卫生成绩及扣分项，当接收到学生申请复查的信息后，及时进行复查。
管理学生申请有关寝室的报修信息，在维修后更改报修状态，能够让学生实时了
解寝室的报修状态。
（1）写出该系统中有哪些参与者?画出用例图。（10 分）
（2）写出该系统中有那些类？找出类之间的关系并画出类图。（15 分）
（3）在寝室管理系统中，各系辅导员在新生入学过程中的床位分配是一个
比较复杂的业务流程，系辅导员老师在分配宿舍床位的过程中，可先对本系学生
的学籍信息进行查看，同时可以查看宿管科已分配给该系的所有宿舍床位信息，
辅导员老师可以选择由系统自动进行床位分配或手动进行床位分配，手动分配过
程中涉及床位是否为空两种状态，如果床位为 空 ，则分配操作可以正常执行，
若该床位已有学生，则显示床位分配失败，并返回床位分配界面。分配操作结束
后，系辅导员可以查看宿舍床位结果。画出对应的活动图。（10 分）