《信息系统工程与实践》实验指导书_第1页
《信息系统工程与实践》实验指导书_第2页
《信息系统工程与实践》实验指导书_第3页
《信息系统工程与实践》实验指导书_第4页
《信息系统工程与实践》实验指导书_第5页
已阅读5页,还剩42页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、信息系统工程与实践 实验指导书 重庆交通大学信息科学与工程学院 2013年10月 目录 实验1软件功能描述与确认(验证性实验 2学时) 4 一、实验目的与要求 4 二、实验环境4 三、实验预习与准备 4 四、实验内容和步骤 4 五、实验报告要求 5 六、实验注意事项 5 七、思考题5 实验2:从程序设计看软件需求(综合设计性实验,2学时) 6 一、实验目的与要求 6 二、实验环境6 三、实验预习与准备 6 四、实验内容和步骤 6 五、实验报告要求 13 六、实验注意事项 14 七、思考题14 实验3:软件需求分析(业务需求)(综合性实验,4学时)15 一、实验目的与要求 15 二、实验环境15

2、 三、实验预习与准备 15 四、实验内容和步骤 15 五、实验报告要求 16 六、实验注意事项 17 七、思考题 17 实验4:软件需求分析(用户需求)(综合性实验,4学时)18 一、实验目的与要求 18 二、实验环境18 三、实验预习与准备 19 四、实验内容和步骤 19 五、实验报告要求 19 六、实验注意事项 22 七、思考题22 实验五:“XX系统”软件需求规格说明书的编写 23 一、实验目的23 二、实验的软硬件环境 23 三、实验要求与任务 23 四、实验步骤23 【附录一】 软件需求规格说明模板 24 实验八:软件实现及测试(综合设计性实验,4学时) 30 五、实验报告要求 31

3、 六、实验注意事项 33 七、思考题 33 【附录二】 评分标准34 实验1:软件功能描述与确认(验证性实验 2学时) 、实验目的与要求 针对常用软件(如 Word),描述软件功能,确认描述的正确性(至少10个功能) 要求: 1一人一组。 2严格按照实验报告格式编写; 3实验报告内容详实,公正,态度认真。 、实验环境 1个人计算机 2常用工具软件:MS Office 2003 3. CASE 软件:Visio2002 、实验预习与准备 1组成实验小组 2复习课堂教学内容 3. 选择实验对象,查阅有关资料 4熟悉实验指导书内容 5实验报告、实验记录用纸等 四、实验内容和步骤 每实验小组自己选择实

4、验对象软件(如Office Word, PowerPoint. Excel等),对其常 用的软件功能进行描述。 任选一组或两组功能,总共不少10个子功能,边确认边用文字描述其功能。 例如:在Word字处理软件的功能分类中有: 1. 文本格式化选择文本的显示方式。 2. 文本编辑和更正更改已经输入的文本内容。 3 文件操作一一实现文本的保存、打印、输出及做其他操作。 4. 工具添加列、表格、图片、对数据排序、检查拼写等等。 5宏一一允许用户合并多个任务。 6视图功能一一使用多种方式查看文档。 7通信一一从外部资源中获得信息。 五、实验报告要求 实验对象及实验内容、结果等信息按照下列表格填写。 功

5、能大分类:实验小组成员:班级: 序 号 功能名称 功能描述 是否非功 能需求 你希望的功能 实验者签名 实验操作与记录要求示例 Word2003软件的“保存文档”功能 从菜单上操作,有保存、另存为。基本功能是:把当前文件保存到指定的文件夹内。 保存 1) 新建文件,缺省情况下,提示用户保存到我的文档,在提示窗口下,用户可选择其他 任意路径下的任何文件夹(可新建文件夹); 2)既有文件,缺省情况下,直接保存到该文件所在的文件夹内。 3)保存操作完的表现:正常情况下无任何显示,如文件较大,则保存操作的进度由进度条 表现。异常情况下,显示信息通知。 另存为 1) 系统显示提示窗口,用户可选择任意路径

6、下的任何文件夹(可新建文件夹); 2)保存操作完的表现:正常情况下无任何显示,如文件较大,则保存操作的进度由进度条 表现。异常情况下,显示信息通知。 六、实验注意事项 1. 必须保证有足够的实验工作量。 2. 试验中要开展组内的讨论。 3. 实验结果记录要严谨,有条理。 七、思考题 1. 你认为上述功能中,哪些功能属于否非功能需求 ?为什么? 2. 你认为利用上述格式描述软件需求有何好处,上表的格式还可以如何改进? 3. 总结一下你在做这个实验的过程和方法。 实验2:从程序设计看软件需求(综合设计性实验, 2学时) 、实验目的与要求 针对给定的程序设计题目,或根据给定的可视控件人机界面设计,提

7、炼/补充软件功能 需求和非功能需求。 要求: 1.2-3 人一组。 2严格按照实验报告格式编写; 3实验报告内容详实,公正,态度认真。 二、实验环境 1个人计算机 2常用工具软件: MS Office 2003 3. CASE 软件:Visio2002 三、实验预习与准备 1组成实验小组 2复习课堂教学内容 3.选择实验对象,查阅有关资料 4熟悉实验指导书内容 5实验报告、实验记录用纸等 四、实验内容和步骤 4-1语言程序的软件功能需求分析 说明:本实验为从 C语言程序设计中提炼出软件功能需求(含非功能需求)。 按照教学进度,目前学生已普遍知道软件用户需求和功能需求(含非功能需求),基本含义

8、如下: 用户需求:业务信息处理需求,交互需求等。 功能需求:软件如何处理数据 非功能需求:包括异常处理,界面友好,软件易用性等 现有一些C语言程序设计题目,各题目描述的需求层次不一。 要求:每实验小组从下列题目中至少选择2个,考察原题目的需求描述 ,判断属于上述 3类 需求的哪一层次,在表中填写题目未描述的其他需求。 示例如下表2-1所示。 表2-1 C语言程序设计题目 原题目:输入一组整数,当输入负数时停止,求和。 用户需求 功能需求 非功能需求 为计算一组人员年龄 的平均值,先求出所有 人员的年龄总和。求和 开始的标志是:有一负 数输入。 输入一组整数,当 输入负数时停止, 求和。 1.

9、该软件应为用户提供方便的输入方式,输入错 误时,应放弃计算,并以错误信息提示用户。 2. 所有输入数据必须为整数,否则作为异常处 理。 3. 最初两个输入数据不能为负值,否则作为异常 处理。 4. 假定各输入整数上限为 120,大于者作为异常 处理。 5. 异常处理:中断程序执行,返回代表上述3 种情况的整数,并用错误信息提示用户。 实验题目: 1. 输入一组整数,当输入负数时停止,求其中最小者。 2. 求1-999中能被3整除的数,并求它们的和。 3. 由键盘输入一个班 50个学生的一门功课的成绩,求这门功课全班的平均成绩。 4. 编制一个运动会百米测验统计名次的程序。 5. 输入一组学生的

10、姓名和成绩, 从中找出成绩最高人的姓名, 并打印出他们的姓名和成绩。 6. 编写程序,从键盘输入 6名学生的5门成绩,分别统计出每个学生的平均成绩。 7. 设有5个学生,每个学生考 4门课,编写程序能检查这些学生有无考试不及格的课程。 若某一学生有一门或一门以上课程不及格,就输出该学生的序号(序号从0开始)和其全部 课程成绩。 8. 编写程序计算10名学生1门课成绩的平均分。 4-2用户界面(可视控件)的软件需求分析 说明:本实验为用户界面(可视控件)的软件需求提炼。 要求:对于下列16组控件界面图,每实验小组至少选择3组,用文字描述:该组各图 的用户需求和功能需求。 示例: 卡宝底膏st a

11、輩 , 姓枷申小品 冃 JSrr 叶 lain 示例-1 用户需求:开发一学生成绩管理系统,其功能要求之一 是:对数学、英语、语文三门课程的学生成绩(每生总 分及平均分)用列表显示。 功能需求: 建立一独立窗体,从数据库中取得制定班级的三门课程 成绩在窗体中的表格中显示;表格右边两列分别显示三 门课程的总成绩和平均分数(精度为2位小数,第三位 小数四舍五入)。 示例-2 用户需求:开发一客房管理系统,其功能要求之一是:快捷 浏览每个房间的详细信息,是否已预订,如已有预定,要求 显示预定期间、客人姓名;列表显示所有房间的等级及其价 格、有无空房。 功能需求:建立一独立窗体,从数据库中客房信息一览

12、表, 该表含有客房类型、单价、空房间数等;该窗体中应提供方 便的图形界面交互方式,快速显示已经预订的房间信息,包 括房间号、房间类型、单价、预定时间等;另,应能够通过 客人姓名快速检索已定客房信息。 实验题目 用户界面(可视控件)的软件需求分析可选题目如下: Bandon水弃祂弃;曲弃 已咖够 能力.才能 able 育力的 abnormal 反常的,术规则的 aboerc 在船匕上船 亠 gbot sl 日 tout 厌耕时向匹大韵.差琳參 above t ,.万!上向前冃上址的 gticac 左国外,在禅外】传开 naiiBi nariiriiB fibf m d:v/ord1 .tei:

13、打井 k?pb bmp 打开 -w 1-2 图1-1 图2-1 图2-2 图4-1图4-2 HSTUIU (ouner H沖 hi ue I 芋P切 iflijr- fVl- TiIfI iTr -iT, alaj h Ran.- Atiqua Italir fTmjp-vpp* 0- f j / 迟匕 j Bookman Otd Stylo (TtueType bookrYiMi OU St卅 Bald fTtut mm “ 二打上 Rif Boohnw Old StldB Id htlk EJ 沖-Hw fTrjoTpc) |:C即彳曰 血 Held ItFli匚 iTilirTI Cju

14、nar Now bold riuiTyEuj 图3-1 图3-2 lit* ft * -ini m! SSTipl 卩阴3約M4 | Yr7l rrszh; I 療启 |7牛:diig STet 地址:申国北來 剝匕帘耳士弓爺曰1小兄 图 15-1 图 15-2 五、实验报告要求 要求本实验结果按照下列表格格式填写。 其中:实验对象描述,指 C语言程序描述;在选择控件界面设计图为实验对象时,需 将图形文件贴于此处。 头验对象编号及其扌田述 软件功能需求提炼 1. 用户需求: 功能需求: 非功能需求: 2. 用户需求: 功能需求: 非功能需求: 3. 用户需求: 功能需求: 非功能需求: 六、实

15、验注意事项 1注意分析实验对象的非功能需求 2注意提高自己的文字表达能力 3注意总结对软件功能需求及非功能需求的认识 七、思考题 1. 上述需求分析的结果中,有没有相互矛盾的情况?为什么? 2. 你认为本次实验的意义(价值)如何? 3. 总结一下你在做这个实验的过程和方法。 实验3:软件需求分析(业务需求)(综合性实验, 4学时) 、实验目的与要求 业务需求(Business requirement ),描述了组织为什么要开发一个系统,即组织希望达 到的目标。组织的目标指超越软件本身的较高层次的目标。软件的业务需求任务是:定义项 目范围。 本课程规定:业务需求的描述,采用前景和范围(visio

16、n and scope)文档来记录。详 细的内容见教材第 4章。 本实验的设计依据,来自本课程第3章给出的需求过程推荐方法中的第一布,即知识方 法。通过获取软件客户的业务知识,建立起软件客户的业务需求框架。 实验目的:针对某小型软件产品(含小型网站)的开发,收集、获取客户的业务知识,分析 其业务需求,描述出: 1)客户通过该软件项目预期达到的业务目标; 2)客户为达到预期业务目标所实施的软件项目范围; 3)将客户业务知识经整理、汇总后作为本实验报告的附件(可选) 要求: 1.2-3 人一组。 2严格按照实验报告格式编写; 3实验报告内容详实,公正,态度认真。 、实验环境 1个人计算机 2常用工

17、具软件:MS Office 2003 3. CASE 软件:Visio2002 、实验预习与准备 1组成实验小组 2复习课堂教学内容 3.选择实验对象,查阅有关资料 4熟悉实验指导书内容 5实验报告、实验记录用纸等 四、实验内容和步骤 1. 每个小组自选一个小型软件(或网站),经小组成员讨论后确定其名称; 2. 利用各种渠道获取该软件的相关组织的业务知识。主要是:(1)业务领域及其产品(服 务)的内容、获利方式等;(2)组织结构与主要业务人员角色;(3)业务流程及相关术 3. 绘制基于该软件构思的业务-软件系统关联图”(参照教材4-27中的上下文图); 4. 按照本课程规定的前景和范围文档”模

18、板格式(见下表3-1,作为实验记录纸的内容), 描述基于预期软件作用下的业务需求; 5. 学生自主讨论,教师指导、答疑。 五、实验报告要求 5-1.实验记录业务需求模板 本实验报告主要内容须按照下属格式填写。 表3-1 :业务需求描述模板(前景和范围文档,参照教材表4-6、4-7) 题目:xxx软件(网站)业务需求 (补充内容:对题目的选择给予简要说明) 1. 背景、业务机会和客户需要 2. 业务目标和成功标准 BO-1 : BO-2 : B0-3 : SC-1 : SC-2: 3业务风险 RI-1 : RI-2 : 内容说明: 1. 背景、业务机会和客户需要 。(1)背景。概述新产品的来由与

19、背景。对历史和现状进行概括性的描述, 说明为什么决定开发该产品。(2)业务机遇。对于软件企业,描述该预期软件产品(网站)可能得到的市 场机遇或其产品的竞争能力;对于为某组织开发的信息系统软件,描述的预期将要解决的业务问题或将要 改进的业务流程;还应对产品或解决方案简要描述其优点和作用。作为限制条件,可以描述需要哪些其他 的技术、过程或资源。 2. 业务目标和成功标准。用量化和可衡量的方式概述该软件产品(网站)提供了哪些重要的业务利益;如 是社会公益性项目,可采取定性的描述语句说明其社会管理、社会服务等方面给受益群体带来的好处。要 按照结构化的要求描述,即将业务目标描述为BO-1、B0-2的形式

20、,将成功标准描述为 SC-1、SC-2形 式。 3. 业务风险。概述与该软件产品(网站)开发相关的主要风险。包括可能岀现的市场竞争问题、时间问题、 用户认可、实现问题以及其他可能对业务造成的负面影响。 5-2实验数据处理(选做) 对于 实验内容及步骤”实施的结果,回到上述的步骤2和3,按照下表3-2所示格式, 仔细分析、对照、检查业务需求描述内容与客户业务知识的符合程度,修改、精炼、完善业 务需求。 表3-2业务需求实验信息处理表 业务需求描述-1 (实验内容与步骤的结果) 业务需求描述-2 (修改与完善后的结果) 修改原因 1.背景、 业务机会 和客户需 要 2.业务目 标和成功 标准 3.

21、业务风 险 另: 1)本次实验不要求有关软件版本的内容。 2) 在本实验中,不要求使用用例图。用例方法在实验4中要求必做。 六、实验注意事项 本课程的实验3, 4, 5,为同一个软件(网站)的三部分需求,即业务需求、用户需求 和功能需求。学生务必以注意保持三个实验报告和记录的连续性,以便最终完成一个完整的 软件需求说明文档。 七、思考题 针对表3-2中的 修改原因”进行分析,并笔答下列问题: 1你的修改原因是怎样发现的? 2对修改前后对比,你认为你的业务需求实验结果发生了怎样的变化? 3总结一下你在做这个实验的过程和方法以及对业务需求文档描述工作的认识。 实验4:软件需求分析(用户需求)(综合

22、性实验, 4学时) 、实验目的与要求 用户需求(user requirement ),描述的是用户使用预期软件系统所要达到的功能性目 标及非功能性要求。一般,用户需求描述的是软件使用者(用户)使用系统能够完成什么业 务任务或信息处理工作。具体内容是用例描述。场景描述不要求。 本课程规定:用户需求的描述,采用用例(user case)文档来记录。详细的内容见教材 第8章。 用例方法,主要用于发现必要的功能性需求。 对于不太复杂的用例, 只要求写出一个简 略的描述,然后,推导出角色执行该用例(包括分支过程和异常处理)需要的所有功能性需 求。 实验目的 针对某小型软件产品(含小型网站)的开发,在业务

23、需求文档(前景范围文档)的基础 上,进一步收集、获取用户的业务知识(重点是人机交互、任务的输入、任务功能、输出信 息及业务任务的结果等),建立起用例模型,描述: 1)用户业务任务的用例图 2) 用户业务任务的用例列表(示例见表4-1) 3)若干个具体的用例。即从用例出发推导部分功能需求和非功能需求,并明确说明。 异常处理单独描述。(示例见表4-2) 4)用户完成业务任务中需遵循的业务规则(可选) 说明:上述 若干个”具体的用例描述,指实验小组的每个成员至少从本组的软件(网站)的 业务主干过程中选择一个用例进行规范描述。 要求: 1.2人一组。 2严格按照实验报告格式编写; 3实验报告内容详实,

24、公正,态度认真。 实验环境 1个人计算机 2常用工具软件:MS Office 2003 3. CASE 软件:Visio2002 、实验预习与准备 1组成实验小组 2复习课堂教学内容 3.选择实验对象,查阅有关资料 4熟悉实验指导书内容 5.实验报告、实验记录用纸等 四、实验内容和步骤 在学生自选的小型软件(或网站)的业务需求文档的基础上,实施以下实验内容: 1. 深入获取业务知识,描绘用例图。 2. 编写用例列表。 3. 分工编写各自负责的用例描述。 4. 学生自主讨论,教师指导、答疑。 五、实验报告要求 5-1实验报告模板 用例分析的结果,应按照下述示例的表格形式填写。 表4-1用例列表(

25、示例:自动订餐系统,教材附录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 用例名称

26、订餐 创建者 Karl Wiegerss 最后更新者 Jack McGillicutty 创建日期 2002年10月21日 最后更新日期 2002年11月7日 参与者 顾客 描述 顾客从公司内联网或从家里访问自助食堂订餐系统 ”随意查看某一大的菜单, 选择自己想要 的食物,提交订单并要求在特定的时间窗口(15分钟)内送货到指定的地点 前置条件 1.顾客登录到 自助食堂订餐系统” 2顾客注册的付费方式是从工资中扣除 后置条件 1订单在 自助食堂订餐系统”中的存储状态是 已接受” 2根据这一订单的食物条目来更新食物存货 3.根据这一次的送货请求,对请求的时间窗口更新剩余的送货能力 主干过程 1.0

27、订一份餐 1. 顾客要求查看某一天的菜单 2. 系统显示有效食物菜单和当日特色菜 3. 顾客从菜单中选择一种或多种食物 4. 顾客表明订餐完成 5. 系统显示所订菜单条目、单价和总价格,包括应交纳的税和送货费用 6. 顾客确认订餐订单或请求修改订餐订单(回到第3步) 7. 系统显示那一天中有效的送餐时间 8. 顾客选择送餐时间和指定送餐地点 9. 顾客指定付费方式 10. 系统确认接收订单 11. 系统向顾客发送电子邮件,确认订单细节、价格和送餐说明 12. 系统将订单存储在数据库中,并发送电子邮件通知自助食堂工作人员,将食物信息发送 给自助食堂库存系统,并更新有效的送餐时间 分支过程 1.1

28、订多份餐(第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.系统终止用例

29、 3.顾客请求在自助食堂选择订单(跳过第7步和第8步) 1.0.E.3不能完成指定数量的同样食物的多份餐(第1步) 1.系统通知顾客它所能提供的同样食物曲多份餐的最大数量 2顾客变更所订的同样食物的份数,或者取消订单 包含 无 优先级 高 使用频率 大约400名用户,平均每天使用一次 用例ID号 UC-1 用例名称 订餐 业务规则 BR-1 , BR-2 , BR-3 , BR-4 , BR-8, BR-11 , BR-12, BR-33 特别需求 1. 顾客在确认订单之前的任何时间都可以取消订单 2. 顾客能查看自己前6个月的全部订餐,并可以重复其中的任一次订餐作为新的订餐,只要所 有食物在

30、请求送餐日的菜单中都有效。(优先级为中) 假设 1.假设30%的顾客会订当日特色菜(来源:根据前6个月的自助食堂数据所得) 注意和问题 1. 如果客户在今天的截止时间之前使用系统,那么默认的日期是当前日期。否则,默认日期是 自助食堂的下一个营业日 2. 如果顾客不要求送餐,那么请求注册付费方式是从工资中扣除”这一前置条件就不适用 3. 这一用例的峰值使用负载是当地时间早晨8点到10点 5-2需求描述基本要求 按照上述模板描述的用户需求(包括推导出的功能需求)、非功能需求,需参照下列要求认 真编写。其中(1 )、( 2)、( 3)和(4)是必须满足的基本要求;对于(7),参照5-3进行用 例测试

31、。 (1)完整性一不能缺少某些信息。 (2)正确性一需求之间不应发生冲突。 (3)可行性一避免不可实现的需求。 (4)必要性一必须是用户的真正需要 (5)有优先次序一在产品的某一版本中的重要程度。 (6)无歧义一一项需求只有一种一致的解释。 (7)可验证性一用检查或演示可以判断产品是否正确实现了需求。 5-3用例测试 选择23个主要用例,按照下面的例子,进行用例测试,填写下表4-3。意图是明确 该用例的若干条可能的执行路径及其处理过程(含异常)。 表4-3用例测试示例 用例名称:查看定单 用户输入 系统输出 期望的结果 问题与分析 用户输入要查 看的定单号 定单存在,表明该用户提交 了定单 显

32、示定单的详细情况 定单不存在 显示消息“很抱歉,定单找 不到! 定单存在,但不是该用户提 交的定单。 显示消息“很抱歉,这不是 您的定单!” 5-4实验数据检查与分析 要求:学生自主检查自己的实验记录(用例列表和用例描述),并填写下列表格(1)和 表格(2),检查用例分析结果 (注:如有重大问题,应返回修改;一般问题只要记录检查结 果,不必修改。遗留问题在实验5中解决): (1) 功能性需求描述检查 问题 检查结果 1 用例描述是否比较详细?有没有不必要的实现细节? 2 用例中的每个参与者和步骤是否都与所执行的任务有关? 问题 检查结果 3 是否定义了系统的全部输入,包括其来源、精度、取值范围

33、等? 4 是否定义了系统的全部输出,包括目的地、精度、取值范围、格 式等? 5 用例的前置条件和后置条件是否合理? 7 是否列出了用户想要做的全部事情? 8 是否定义了每个任务所用的数据,以及每个任务得到的数据? (2)非功能需求描述检查 问题 检查结果 1 从用户的视角,是否按照需求描述了期望响应时间? 2 是否定义了安全要求和安全级别? 3 所有能想到的异常条件是否都已经被定义? 4 需求中是否遗漏了必要的信息? 六、实验注意事项 各小组注意: 1讨论,检查,修改用例图和用例列表。 2讨论,检查,修改用例图、用例列表和用例描述。 3上述示例的表4-1,表4-2,可作为实验记录附件。 七、思

34、考题 1总结用例法分析用户需求的过程和步骤。 2针对实验数据检查与分析 结果,总结自己的问题与收获。 实验五:“XX系统”软件需求规格说明书的编写 一、实验目的 需求开发的最终成果是: 客户和开发小组对将要开发的产品达成一致的协议。这一协议 综合了业务需求、用户需求和软件功能需求。从前面实验中所得出的一些分析文档中,我们 可以知道:项目视图和范围文档包含了业务需求, 而使用实例文档包含了用户需求。 我们还 必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档, 包括质量属 性和外部接口需求。 至此,我们综合前面的相关分析结果,来进行需求说明书的编写,进一 步理解由业务需求,用户

35、需求,功能需求三个部分综合而形成软件需求说明书的过程。 二、实验的软硬件环境 硬件:微型计算机,打印机; 软件: Windows XP/7 ,Office 2003/2007,Visual Studio、Delphi,SQL Server 等要求 实验环境为网络环境。 三、实验要求与任务 1要求: 完成软件需求规格说明书的编写: (1)用好的结构化和自然语言编写文档型文档 (2)建立图形化模型。 (3)编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求。 2、具体任务: 开发“XX系统”(如人事管理信息系统、财务信息管理系统、酒店信息管理系统、设 备信息管理系统、仓库管理信

36、息系统、进存销管理信息系统、学生信息管理系统、 图书馆信 息管理系统,图书销售信息管理新系统等等)。 通过调查获取用户需求,按照需求的内容进行分析,按照内容、格式要求撰写完整的软件需 求规格说明书。 四、实验步骤 1、参考相关模板,初步理解软件需求规格说明书的结构 2、结合项目实际,完成软件需求规格说明书 3、进一步检查、完善相应的需求部分,尽量避免需求遗漏,和定义的不清晰。同时, 应确保采用规范图例。 4、重复进行前面几个步骤,经过小组成员多次讨论,并得到客户的认可,最终达到客 【附录一】软件需求规格说明模板 1引言 引言是对整个软件需求规格说明的概览,以帮助读者更好地阅读和理解文档。包括文

37、档 的意图(目的)、主要内容(范围)、组织方式(文档组织)、参考文献(参考文献)和阅读 时的注意事项(定义、首字母缩写和缩略语)。 1.1文档的意图(目的) 目的是说明软件需求规格说明的主要目标,描述软件规格说明所定义的产品或某些产品 部分。限定预期的读者。 1.2主要内容(范围) 在这一节中: 根据名称确定将被开发的软件产品。 解释软件产品的预期功能,并在必要的时候解释没有纳人软件产品预期的功能。 描述软件产品的应用,包括相关的好处、目标和目的。 如果在此软件需求规格说明之外,还存在着一个更高层次的规格说明(例如系统需求 规格说明),那么该部分的描述应该与更高层次文档的相关段落保持一致。 1

38、.3阅读时的注意事项(定义、首字母缩写和缩略语) 定义了正确理解软件需求规格说明所必需的术语、首字母缩写和缩略语。 这部分内容也可以通过添加附录或者引用其他文档来提供。 1.4参考文献 在这一节中: 提供需求规格说明文档引用的全部文档的清单列表。 利用标题、报告编号(如果适用)旧期和出版机构来标识文档。 指出参考文献的来源,在该来源中可以获得文献。 这部分内容也可以通过添加附录或者引用其他文档来提供。 1.5组织方式(文档组织) 在这一节中: 描述软件需求规格说明余下部分所包含的内容。 解释软件需求规格说明的组织方式。 2. 总体描述 从总体上描述影响产品和需求的因素。这部分并不涉及将在文档第

39、3部分(详细需求 描 述)中描述的具体的需求,而是为其提供背景知识,使其更加易于理解。 2.1产品前景 该节将所定义的产品和其他相关的产品联系起来,在联系中描述产品的起源和背景,进 而说明对产品的总体预期。 如果产品是一个独立的、完全自包含的系统,那么就应该在这里进行声明。 如果像常见的情况那样,产品仅仅是较大系统的一个组件,那么就应该将较大系统的需 求和软件的功能联系起来进行说明,并标识它们之间的接口。 如果能够开发一个可以显示较 大系统的主要组件、内部连接和外部接口的框图,将会有很大帮助。 这一节还应该描述较大系统的其他部分对软件产品的操作预期。这些部分包括: 系统接口:系统接口对软件产品

40、的功能要求。 用户界面:软件产品和用户之间接口的逻辑特征和优化要求。 硬件接口:软件产品和较大系统中硬件组件之间接口的逻辑特征。 软件接口:其他软件系统对软件产品的要求。: 交流接口:本地网络协议之类的交流接口要求。 内存:软件产品在主存储器和辅助存储器上的局限性和可适用特性。 操作:用户要求的正常和特殊操作。 地点改变需求:对指定地点、任务或者操作模式的需求,调整软件装置而需要改变的 地点或者任务的相关特征。 2.2产品功能一 概述软件将要执行的主要功能。此处只需要概略的总结, 其详细内容将在第 3部分(详 细需求描述)中描述。例如,一个账目管理程序的软件需求规格说明会在本节中描述顾客账 目

41、维护、顾客描述和发票处理等功能,但不会提及上述功能的大量细节。如果存在为软件产 品分配功能更高一层的规格说明,那么这个部分的功能概述应该直接从更高层次规格说明的 相关部分提取。 为了清晰起见: 功能的组织应该能够让第一次看到文档的顾客或者其他人理解功能列表。 可以使用文本或者图形化的方法显示不同功能及其联系。 2.3用户特征 描述产品预期用户的一般特征,包括受教育水平、经验和技术能力等。这些描述信息可 以用来解释第 3部分(详细需求描述)中特定需求出现的原因,但是本节并不涉及这些特 定的需求。 2.4约束 对限制开发人员开发方案选择的事项进行一般性描述。这些事项包括: 规章政策。 硬件限制。

42、和其他应用的接口。 并发操作。 审计功能。 控制功能 高阶语言要求(即程序开发语言)。 信号握手协议(即信息交流的可靠性要求)。 应用的临界状态。 安全性考虑。 2.5假设和依赖 列举并描述了那些会对文档中所述需求产生影响的因素。这些因素并不是软件的设计限 制,但是这些因素的任何变化都会影响到文档中的需求。例如,有这样一个假设: 软件产品 的目标硬件上会有某个特定的操作系统。而在实际情况中,如果这样的情况并不存在,那么 文档中的需求将不得不进行相应的改变。 3. 详细需求描述 这通常是软件需求规格说明中最多和最重要的部分。它要对所有的软件需求进行充分的 描述。这部分的内容应该包括设计人员进行设

43、计时所需要的所有细节,足以让设计人员设计 出一个满足需求的系统。它还需要清楚地告诉测试人员需要怎么样的测试才能保证得到一个 满足需求的系统。 在这一部分: 细节需求的描述要符合优秀需求的特性要求(参见2. 5节),文档的组织和内容整合 要符合优秀软件需求规格说明文档的特性要求(参见15.5节)。 细节需求要能够回溯到相关的前期文档,形成前后参照。 所有的需求都要被唯一的标识。 需求的组织应该尽可能的提高可读性。 该部分内容的最佳组织方式要依赖于软件产品的应用领域和特性。IEEE 830-19981为 该部分的文档组织提供了8种不同的模板方式。 模板是按照系统特性来进行需求组织的,除此之外也可以

44、按照操作模式、类/对象、刺 激/响应、功能分解、用户类别等方式进行组织。 IEEE 830-1998将需求分成了 5种类别,并据此进行内容的组织。这5种内容是: 功能需求。 性能需求。 约束。 质量属性。 对外接口。 软件需求规格说明模板中第2章已经详细解释了 5种类型需求的区别,本章将仅仅对 文档内容的组织进行介绍。 3.1对外接口需求 描述了设计人员正确开发与软件外部实体的接口所需要的所有信息。 对软件产品对外接口中的输人/输出项,可以参照下列方式进行描述: (1) 名称。 (2) 目的描述。 (3) 输人源/输出目标。 (4 )有效范围,精确度和误差范围。 (5) 度量单位。 (6) 时

45、间要求。 (7) 和其他输人/输出项的关系。、 (8 )屏幕布局/组织。 (9 )窗口布局/组织。 (10) 数据格式。 (11) 命令格式。 (12) 结束消息。 3.1.1用户界面 描述系统所需的每个用户界面的逻辑特征。本节可能包括下列内容: 对图形用户界面(GUI)标准的引用或者将要采用的产品系列的样式指南。 有关字体、图标、按钮标签、图像、颜色选择方案、组件的tab顺序、常用控件等的 标准。 屏幕布局或解决方案的约束。 每个屏幕中将出现的标准按钮、功能或者导航链接。 快捷键。. 便于软件定位的布局标准。 满足视力有问题的用户的要求., 3.1.2硬件接口 描述系统中软件和硬件每一接口的

46、特征。这种描述可能包括支持的硬件类型、软硬件之 间交流的数据和控制信息的性质以及所使用的通信协议等。 3.1.3软件接口 描述该产品与其他外部组件(由名字和版本识别)的连接,包括数据库、操作系统、工 具、程序库和集成的商业组件等。声明在软件组件之间交换数据、消息和控制命令的目的。 描述其他外部组件所需要的服务以及组件间通信的性质。确定将在组件之间共享的数据。 3.1.4通信接口 描述与产品所使用的通信功能相关的需求,包括电子邮件,Web浏览器、网络通信标准 或协议及电子表格等。定义了相关的消息格式。规定通信安全或力。密问题、数据传输速率 和同步通信机制等。 3.2功能需求 描述了软件产品在接收

47、和处理外部输入(或者处理和产生对外输出)中发生的基本行为。 需要描述的内容有: 对输人的验证 操作的顺序 对异常的响应,例如 数值越界 通信间题 错误处理与恢复 参数的说明 输出和输人的关系 输人/输出序列 将输人转换为输出的公式和规则 3.2. x系统特性 系统特性是外部期望的系统服务,它接收一系列的输入,并产生外界预期的输出。 3.2. X.1特性描述 提出了对该系统特性的简短说明。 3.2. X.2刺激/响应序列 列出输入刺激序列(用户动作、来自外部设备的信号或其他触发器)和系统的响应序列。 3.2. X.3相关功能需求 详细列出与该特性相关的功能需求。这些是必须提交给用户的软件功能,使

48、用户可以使 用所提供的特性执行服务或者使用所指定的使用实例执行任务。描述产品如何响应可预知的 出错条件或者非法输人或动作。 3. 2.x.3.n功能需求x.n 对单个需求(功能的某个步骤或者某个方面)的清晰描述,常见形式为“RID :系统应 、亠 ” 该。 3.3性能需求 阐述了不同的应用领域对产品性能的需求,并解释它们的原理以帮助开发人员做出合理 的设计选择。确定相互合作的用户数、 所支持的操作、响应时间以及与实时系统的时间关系。 还可以定义容量需求, 例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。尽 可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求,而不

49、是 把它们都集中在一起陈述。 性能需求描述的详细内容和形式示例可参见233。 3.4约束 描述可能由法律法规、标准、规范或者硬件限制等因素带来的设计约束。 约束描述的详细内容可参见2.3.6. 3.5质量属性 详尽陈述对客户或开发人员至关重要的产品质量属性。这些特性必须是确定、定量的而 且在可能时是可验证的。 关于质量属性的详细内容可参见2.3.4. 3.6其他需求 定义在软件需求规格说明的其他部分未出现的需求,例如国际化需求或法律上的需求。 你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和 容错, 以及登录和监控操作等方面的需求。 附录 附录是对软件需求规格说明正

50、文信息的补充。虽然它并不总是必需的,但是必要的附录 可以增加文档对需求的描述能力。 常见的附录内容包括: I/O格式示例、成本分析研究、用户调查结果。 有助于阅读软件需求规格说明的背景信息,常见的有术语表、数据字典和分析模型图 示。 需要解决但是目前还悬而未决的问题列表。 为了满足安全、导出、初始加载或者其他需求而对代码和数据媒体进行特殊打包处理 的说明。 索引 对文档重要内容的位置引用,可以利用文档编辑工具自动生成。 需求规格说明文档的写作原则与技巧参见“需求规格说文档写作”。 实验八:软件实现及测试(综合设计性实验, 4学时) 一、实验目的 1掌握编码的方法和规则。 2.掌握单元测试用例生成方法; 3 掌握路径测试测试用例生成方法; 4.掌握等价类划分测试用例生成方法; 二、实验内容及要求 1、 编写一个程序如科学

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论