软件需求分析实验指导书0224.docx
《软件需求分析实验指导书0224.docx》由会员分享，可在线阅读，更多相关《软件需求分析实验指导书0224.docx（34页珍藏版）》请在冰豆网上搜索。
软件需求分析实验指导书0224
《软件需求分析》
实验指导书
软件工程系
课程编号：
课程类别：
适用专业：
软件工程
课程总学时：
72实验学时：
18
开设实验项目数：
5个
目录
实验1：
软件功能描述与确认（验证性实验2学时）4
一、实验目的与要求4
二、实验环境4
三、实验预习与准备4
四、实验内容和步骤4
五、实验报告要求5
六、实验注意事项5
七、思考题5
实验2：
从程序设计看软件需求（综合设计性实验，2学时）6
一、实验目的与要求6
二、实验环境6
三、实验预习与准备6
四、实验内容和步骤6
五、实验报告要求13
六、实验注意事项14
七、思考题14
实验3：
软件需求分析（业务需求）（综合设计性实验，2学时）15
一、实验目的与要求15
二、实验环境15
三、实验预习与准备15
四、实验内容和步骤15
五、实验报告要求16
六、实验注意事项17
七、思考题17
实验4：
软件需求分析（用户需求）（综合设计性实验，4学时）18
一、实验目的与要求18
二、实验环境18
三、实验预习与准备19
四、实验内容和步骤19
五、实验报告要求19
六、实验注意事项22
七、思考题22
实验5：
编写软件需求说明书（综合设计性实验，4学时）23
一、实验目的与要求23
二、实验环境23
三、实验预习与准备23
四、实验内容和步骤23
五、实验报告要求24
六、实验注意事项25
七、思考题25
附件26
参考文献26
格式说明26
实验1：
软件功能描述与确认（验证性实验2学时）
一、实验目的与要求
针对常用软件（如Word），描述软件功能，确认描述的正确性（至少10个功能）
要求：
1.两人或三人一组。
2.严格按照实验报告格式编写；
3.实验报告内容详实，公正，态度认真。
二、实验环境
1.个人计算机
2.常用工具软件：
MSOffice2003
3.CASE软件：
Visio2002
三、实验预习与准备
1.组成实验小组
2.复习课堂教学内容
3.选择实验对象，查阅有关资料
4.熟悉实验指导书内容
5.实验报告、实验记录用纸等
四、实验内容和步骤
每实验小组自己选择实验对象软件（如OfficeWord,PowerPoint,Excel等），对其常用的软件功能进行描述。
任选一组或两组功能，总共不少10个子功能，边确认边用文字描述其功能。
例如：
在Word字处理软件的功能分类中有：
1.文本格式化——选择文本的显示方式。
2.文本编辑和更正——更改已经输入的文本内容。
3.文件操作——实现文本的保存、打印、输出及做其他操作。
4.工具——添加列、表格、图片、对数据排序、检查拼写等等。
5.宏——允许用户合并多个任务。
6.视图功能——使用多种方式查看文档。
7.通信——从外部资源中获得信息。
五、实验报告要求
实验对象及实验内容、结果等信息按照下列表格填写。
功能大分类：
实验小组成员：
班级：
序号
功能名称
功能描述
是否非功能需求
你希望的功能
实验者签名
实验操作与记录要求示例——Word2002软件的“保存文档”功能
从菜单上操作，有[保存]、[另存为]。
基本功能是：
把当前文件保存到指定的文件夹内。
[保存]
1）新建文件，缺省情况下，提示用户保存到[我的文档]，在提示窗口下，用户可选择其他任意路径下的任何文件夹（可新建文件夹）；
2）既有文件，缺省情况下，直接保存到该文件所在的文件夹内。
3）保存操作完的表现：
正常情况下无任何显示，如文件较大，则保存操作的进度由进度条表现。
异常情况下，显示信息通知。
[另存为]
1）系统显示提示窗口，用户可选择任意路径下的任何文件夹（可新建文件夹）；
2）保存操作完的表现：
正常情况下无任何显示，如文件较大，则保存操作的进度由进度条表现。
异常情况下，显示信息通知。
六、实验注意事项
1.必须保证有足够的实验工作量。
2.试验中要开展组内的讨论。
3.实验结果记录要严谨，有条理。
七、思考题
1.你认为上述功能中,哪些功能属于否非功能需求?
为什么?
2.你认为利用上述格式描述软件需求有何好处，上表的格式还可以如何改进？
3.总结一下你在做这个实验的过程和方法。
实验2：
从程序设计看软件需求（综合设计性实验，2学时）
一、实验目的与要求
针对给定的程序设计题目,或根据给定的可视控件人机界面设计，提炼/补充软件功能需求和非功能需求。
要求：
1.两人或三人一组。
2.严格按照实验报告格式编写；
3.实验报告内容详实，公正，态度认真。
二、实验环境
1.个人计算机
2.常用工具软件：
MSOffice2003
3.CASE软件：
Visio2002
三、实验预习与准备
1.组成实验小组
2.复习课堂教学内容
3.选择实验对象，查阅有关资料
4.熟悉实验指导书内容
5.实验报告、实验记录用纸等
四、实验内容和步骤
4-1语言程序的软件功能需求分析
说明：
本实验为从C语言程序设计中提炼出软件功能需求（含非功能需求）。
按照教学进度，目前学生已普遍知道软件用户需求和供功能需求（含非功能需求），基本含义如下：
●用户需求：
业务信息处理需求，交互需求等。
●功能需求：
软件如何处理数据
●非功能需求：
包括异常处理，界面友好，软件易用性等
现有一些C语言程序设计题目，各题目描述的需求层次不一。
要求：
每实验小组从下列题目中至少选择3个，考察原题目的需求描述,判断属于上述3类需求的哪一层次，在表中填写题目未描述其他需求。
示例如下表2-1所示。
表2-1C语言程序设计题目
原题目：
输入一组整数，当输入负数时停止,求和。
用户需求
功能需求
非功能需求
为计算一组人员年龄的平均值，先求出所有人员的年龄总和。
求和开始的标志是：
有一负数输入。
输入一组整数，当输入负数时停止,求和。
1.该软件应为用户提供方便的输入方式，输入错误时，应放弃计算，并以错误信息提示用户。
2.所有输入数据必须为整数，否则作为异常处理。
3.最初两个输入数据不能为负值，否则作为异常处理。
4.假定各输入整数上限为120，大于者作为异常处理。
5.异常处理：
中断程序执行，返回代表上述3种情况的整数，并用错误信息提示用户。
实验题目：
1.输入一组整数,当输入负数时停止,求其中最小者。
2.求1-999中能被3整除的数,并求它们的和。
3.由键盘输入一个班50个学生的一门功课的成绩，求这门功课全班的平均成绩。
4.编制一个运动会百米测验统计名次的程序。
5.输入一组学生的姓名和成绩，从中找出成绩最高人的姓名，并打印出他们的姓名和成绩。
6.编写程序，从键盘输入6名学生的5门成绩，分别统计出每个学生的平均成绩。
7.设有5个学生，每个学生考4门课，编写程序能检查这些学生有无考试不及格的课程。
若某一学生有一门或一门以上课程不及格，就输出该学生的序号（序号从0开始）和其全部课程成绩。
8.编写程序计算10名学生1门课成绩的平均分。
4-2用户界面（可视控件）的软件需求分析
说明：
本实验为用户界面（可视控件）的软件需求提炼。
要求：
对于下列16组控件界面图，每实验小组至少选择4组，用文字描述：
该组各图的用户需求和功能需求。
示例：
示例-1
用户需求：
开发一学生成绩管理系统，其功能要求之一是：
对数学、英语、语文三门课程的学生成绩（每生总分及平均分）用列表显示。
功能需求：
建立一独立窗体，从数据库中取得制定班级的三门课程成绩在窗体中的表格中显示；表格右边两列分别显示三门课程的总成绩和平均分数（精度为2位小数，第三位小数四舍五入）。
示例-2
用户需求：
开发一客房管理系统，其功能要求之一是：
快捷浏览每个房间的详细信息，是否已预订，如已有预定，要求显示预定期间、客人姓名；列表显示所有房间的等级及其价格、有无空房。
功能需求：
建立一独立窗体，从数据库中客房信息一览表，该表含有客房类型、单价、空房间数等；该窗体中应提供方便的图形界面交互方式，快速显示已经预订的房间信息，包括房间号、房间类型、单价、预定时间等；另，应能够通过客人姓名快速检索已定客房信息。
实验题目
用户界面（可视控件）的软件需求分析可选题目如下：
图1-1
图1-2
图2-1
图2-2
图3-1
图3-2
图4-1
图4-2
图5-1
图5-2
图6-1
图6-2
图7-1
图7-2
图8-1
图8-2
图9-1
图9-2
图10-1
图10-2
图11-1
图11-2
图12-1
图12-2
图13-1
图13-2
图14-1
图14-2
图15-1
图15-2
图16-1
图16-2
五、实验报告要求
要求本实验结果按照下列表格格式填写。
其中：
实验对象描述，指C语言程序描述；在选择控件界面设计图为实验对象时，需将图形文件贴于此处。
实验对象编号及其描述
软件功能需求提炼
1.
用户需求：
功能需求：
非功能需求：
2.
用户需求：
功能需求：
非功能需求：
3.
用户需求：
功能需求：
非功能需求：
4.
用户需求：
功能需求：
非功能需求：
5.
用户需求：
功能需求：
非功能需求：
六、实验注意事项
1.注意分析实验对象的非功能需求
2.注意提高自己的文字表达能力
3.注意总结对软件功能需求及非功能需求的认识
七、思考题
1.上述需求分析的结果中，有没有相互矛盾的情况？
为什么？
2.你认为本次实验的意义（价值）如何？
3.总结一下你在做这个实验的过程和方法。
实验3：
软件需求分析（业务需求）（综合设计性实验，2学时）
一、实验目的与要求
业务需求（Businessrequirement），描述了组织为什么要开发一个系统，即组织希望达到的目标。
组织的目标指超越软件本身的较高层次的目标。
软件的业务需求任务是：
定义项目范围。
本课程规定：
业务需求的描述，采用前景和范围（visionandscope）文档来记录。
详细的内容见教材第5章。
本实验的设计依据，来自本课程第3章给出的需求过程推荐方法中的第一布，即知识方法。
通过获取软件客户的业务知识，建立起软件客户的业务需求框架。
实验目的：
针对某小型软件产品（含小型网站）的开发，收集、获取客户的业务知识，分析其业务需求，描述出：
1）客户通过该软件项目预期达到的业务目标；
2）客户为达到预期业务目标所实施的软件项目范围；
3）将客户业务知识经整理、汇总后作为本实验报告的附件（可选）。
要求：
1.两人或三人一组。
2.严格按照实验报告格式编写；
3.实验报告内容详实，公正，态度认真。
二、实验环境
1.个人计算机
2.常用工具软件：
MSOffice2003
3.CASE软件：
Visio2002
三、实验预习与准备
1.组成实验小组
2.复习课堂教学内容
3.选择实验对象，查阅有关资料
4.熟悉实验指导书内容
5.实验报告、实验记录用纸等
四、实验内容和步骤
1.每个小组自选一个小型软件（或网站），经小组成员讨论后确定其名称；
2.利用各种渠道获取该软件的相关组织的业务知识。
主要是：
（1）业务领域及其产品（服务）的内容、获利方式等；
（2）组织结构与主要业务人员角色；（3）业务流程及相关术语；（4）其他知识。
3.绘制基于该软件构思的“业务-软件系统关联图”；
4.按照本课程规定的“前景和范围文档”模板格式（见下表3-1，作为实验记录纸的内容），描述基于预期软件作用下的业务需求；
5.学生自主讨论，教师指导、答疑。
五、实验报告要求
5-1.实验记录——业务需求模板
本实验报告主要内容须按照下属格式填写。
表3-1：
业务需求描述模板（前景和范围文档）
题目：
xxx软件（网站）业务需求
（补充内容：
对题目的选择给予简要说明）
1.背景、业务机会和客户需要
2.业务目标和成功标准
BO-1：
BO-2：
BO-3：
…
SC-1：
SC-2：
…
3.业务风险
RI-1：
RI-2：
…
内容说明：
1.背景、业务机会和客户需要。
（1）背景。
概述新产品的来由与背景。
对历史和现状进行概括性的描述，说明为什么决定开发该产品。
（2）业务机遇。
对于软件企业，描述该预期软件产品（网站）可能得到的市场机遇或其产品的竞争能力；对于为某组织开发的信息系统软件，描述的预期将要解决的业务问题或将要改进的业务流程；还应对产品或解决方案简要描述其优点和作用。
作为限制条件，可以描述需要哪些其他的技术、过程或资源。
2.业务目标和成功标准。
用量化和可衡量的方式概述该软件产品（网站）提供了哪些重要的业务利益；如是社会公益性项目，可采取定性的描述语句说明其社会管理、社会服务等方面给受益群体带来的好处。
要按照结构化的要求描述，即将业务目标描述为BO-1、BO-2…的形式，将成功标准描述为SC-1、SC-2…形式。
3.业务风险。
概述与该软件产品（网站）开发相关的主要风险。
包括可能出现的市场竞争问题、时间问题、用户认可、实现问题以及其他可能对业务造成的负面影响。
5-2实验数据处理
对于“实验内容及步骤”实施的结果，回到上述的步骤2和3，按照下表3-2所示格式，仔细分析、对照、检查业务需求描述内容与客户业务知识的符合程度，修改、精炼、完善业务需求。
表3-2业务需求实验信息处理表
业务需求描述-1
（实验内容与步骤的结果）
业务需求描述-2
（修改与完善后的结果）
修改原因
1.背景、业务机会和客户需要
2.业务目标和成功标准
3.业务风险
另：
1）本次实验不要求有关软件版本的内容。
2）在本实验中，不要求使用用例图。
用例方法在实验4中要求必做。
六、实验注意事项
本课程的实验3，4，5，为同一个软件（网站）的三部分需求，即业务需求、用户需求和功能需求。
学生务必以注意保持三个实验报告和记录的连续性，以便最终完成一个完整的软件需求说明文档。
七、思考题
针对表3-2中的“修改原因”进行分析，并笔答下列问题:
1.你的修改原因是怎样发现的？
2.对修改前后对比，你认为你的业务需求实验结果发生了怎样的变化？
3.总结一下你在做这个实验的过程和方法以及对业务需求文档描述工作的认识。
实验4：
软件需求分析（用户需求）（综合设计性实验，4学时）
一、实验目的与要求
用户需求（userrequirement），描述的是用户使用预期软件系统所要达到的功能性目标及非功能性要求。
一般，用户需求描述的是软件使用者（用户）使用系统能够完成什么业务任务或信息处理工作。
具体内容是用例描述。
场景描述不要求。
本课程规定：
用户需求的描述，采用用例（usercase）文档来记录。
详细的内容见教材第8章。
用例方法，主要用于发现必要的功能性需求。
对于不太复杂的用例，只要求写出一个简略的描述，然后，推导出角色执行该用例（包括分支过程和异常处理）需要的所有功能性需求。
实验目的
针对某小型软件产品（含小型网站）的开发，在业务需求文档（前景范围文档）的基础上，进一步收集、获取用户的业务知识（重点是人机交互、任务的输入、任务功能、输出信息及业务任务的结果等），建立起用例模型，描述：
1）用户业务任务的用例图（参见教材图8-1）
2）用户业务任务的用例列表（示例见表4-1）
3）若干个具体的用例。
即从用例出发推导部分功能需求和非功能需求，并明确说明。
异常处理单独描述。
（示例见表4-2）
4）用户完成业务任务中需遵循的业务规则（可选）
说明：
上述“若干个”具体的用例描述，指实验小组的每个成员至少从本组的软件（网站）的业务主干过程中选择一个用例进行规范描述。
要求：
1.两人或三人一组。
2.严格按照实验报告格式编写；
3.实验报告内容详实，公正，态度认真。
二、实验环境
1.个人计算机
2.常用工具软件：
MSOffice2003
3.CASE软件：
Visio2002
三、实验预习与准备
1.组成实验小组
2.复习课堂教学内容
3.选择实验对象，查阅有关资料
4.熟悉实验指导书内容
5.实验报告、实验记录用纸等
四、实验内容和步骤
在学生自选的小型软件（或网站）的业务需求文档的基础上，实施以下实验内容：
1.深入获取业务知识，描绘用例图。
2.编写用例列表。
3.分工编写各自负责的用例描述。
4.学生自主讨论，教师指导、答疑。
五、实验报告要求
5-1实验报告模板
用例分析的结果，应按照下述示例的表格形式填写。
表4-1用例列表（示例：
自动订餐系统，教材附录D.2）
主要参与者
用例
顾客
1.订餐
2.变更订单
3.取消订单
4.查看菜单
5.注册从工资中扣除餐费的付费方式
6.取消注册的从工资中扣除餐费的付费方式
7.订购标准餐
8.修改所订的标准餐
9推翻所订的标准餐
菜单经理
10.创建菜单
11.修改菜单
12.定义特色菜
自助食堂工作人员
13.准备餐
14.生成付费请求
15.请求送货
16.生成系统使用报告
送餐人员
17.送餐
18.记录送餐情况
19.打印送餐说明
表4-2用例描述（示例：
自动订餐系统的订餐用例，教材附录D.2）
用例ID号
UC-1
用例名称
订餐
创建者
KarlWiegerss
最后更新者
JackMcGillicutty
创建日期
2002年10月21日
最后更新日期
2002年11月7日
参与者
顾客
描述
顾客从公司内联网或从家里访问“自助食堂订餐系统”，随意查看某一天的菜单，选择自己想要的食物，提交订单并要求在特定的时间窗口（15分钟）内送货到指定的地点
前置条件
1.顾客登录到“自助食堂订餐系统”
2.顾客注册的付费方式是从工资中扣除
后置条件
1.订单在“自助食堂订餐系统”中的存储状态是“已接受”
2.根据这一订单的食物条目来更新食物存货
3.根据这一次的送货请求，对请求的时间窗口更新剩余的送货能力
主干过程
1.0订一份餐
1.顾客要求查看某一天的菜单
2.系统显示有效食物菜单和当日特色菜
3.顾客从菜单中选择一种或多种食物
4.顾客表明订餐完成
5.系统显示所订菜单条目、单价和总价格，包括应交纳的税和送货费用
6.顾客确认订餐订单或请求修改订餐订单（回到第3步）
7.系统显示那一天中有效的送餐时间
8.顾客选择送餐时间和指定送餐地点
9.顾客指定付费方式
10.系统确认接收订单
11.系统向顾客发送电子邮件，确认订单细节、价格和送餐说明
12.系统将订单存储在数据库中，并发送电子邮件通知自助食堂工作人员，将食物信息发送给自助食堂库存系统，并更新有效的送餐时间
分支过程
1.1订多份餐（第4步之后分支出来）
1.顾客要求预订另一份餐
2.返回到第2步
1.2同样的餐订多份（第3步之后分支出来）
1.顾客请求预订指定数量的同样食物的多份餐
2.返回到第4步
1.3订当日特色菜（第2步之后分支出来）
1.顾客从菜单中订当日特色菜
2.返回到第5步
异常
1.0.E.1订单截止时间在当前时间之前（第1步）
1.系统通知顾客今天订餐已太晚了
2a.顾客取消订单
2b.系统终止用例
3a.顾客请求选择另一个日期
3b.系统重新启动用例
1.0.E.2没有有效的送餐时间（第1步）
1.系统通知顾客送餐日已没有有效的送餐时间
2a.顾客取消订单
2b.系统终止用例
3.顾客请求在自助食堂选择订单（跳过第7步和第8步）
1.0.E.3不能完成指定数量的同样食物的多份餐（第1步）
1.系统通知顾客它所能提供的同样食物曲多份餐的最大数量
2顾客变更所订的同样食物的份数，或者取消订单
包含
无
优先级
高
使用频率
大约400名用户，平均每天使用一次
业务规则
BR-1，BR-2，BR-3，BR-4，BR-8，BR-11，BR-12，BR-33
特别需求
1.顾客在确认订单之前的任何时间都可以取消订单
2.顾客能查看自己前6个月的全部订餐，并可以重复其中的任一次订餐作为新的订餐，只要所有食物在请求送餐日的菜单中都有效。
（优先级为中）
假设
1.假设30%的顾客会订当日特色菜（来源：
根据前6个月的自助食堂数据所得）
注意和问题
1.如果客户在今天的截止时间之前使用系统，那么默认的日期是当前日期。
否则，默认日期是自助食堂的下一个营业日
2.如果顾客不要求送餐，那么“请求注册付费方式是从工资中扣除”这一前置条件就不适用
3.这一用例的峰值使用负载是当地时间早晨8点到10点
5-2需求描述基本要求
按照上述模板描述的用户需求（包括推导出的功能需求）、非功能需求，需参照下列要求认真编写。
其中
（1）、
（2）、（3）和（4）是必须满足的基本要求；对于（7），参照5-3进行用例测试。
（1）完整性—不能缺少某些信息。
（2）正确性—需求之间不应发生冲突。
（3）可行性—避免不可实现的需求。
（4）必要性—必须是用户的真正需要
（5）有优先次序—在产品的某一版本中的重要程度。
（6）无歧义—一项需求只有一种一致的解释。
（7）可验证性—用检查或演示可以判断产品是否正确实现了需求。
5-3用例测试
选择2～3个主要用例，按照下面的例子，进行用例测试，填写下表4-3。
意图是明确该用例的若干条可能的执行路径及其处理过程（含异常）。
表4-3用例测试示例
用例名称：
查看定单
用户输入
系统输出
期望的结果
问题与分析
用户输入要查看的定单号
定单存在，表明该用户提交了定单
显示定单的详细情况
定单不存在
显示消息“很抱歉，定单找不到！
定单存在，但不是该用户提交的定单。
显示消息“很抱歉，这不是您的定单！
”。
5-4实验数据检查与分析
要求：
学生自主检查自己的实验记录（用例列表和用例描述），并填写下列表格
（1）和表格
（2），检查用例分析结果（注：
如有重大问题，应返回修改；一般问题只要记录检查结果，不必修改。
遗留问题在实验5中解决）：
（1）功能性需求描述检查
问题
检查结果
1
用例描述是否比较详细？
有没有不必要的实现细节？
2
用例中的每个参与者和步骤是否都与所执行的任务有关？
3
是否定义了系统的全部输入，包括其来源、精度、取值范围等？
4
是否定义了系统的全部输出，包括目
升级会员 