《信息系统工程与实践》实验指导书.doc

《《信息系统工程与实践》实验指导书.doc》由会员分享，可在线阅读，更多相关《《信息系统工程与实践》实验指导书.doc（33页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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三、实验预习与准备15四、实验内容和步骤15五、实验报告要求1

2、6六、实验注意事项17七、思考题17实验4：软件需求分析（用户需求）（综合性实验，4学时）18一、实验目的与要求18二、实验环境18三、实验预习与准备18四、实验内容和步骤19五、实验报告要求19六、实验注意事项22七、思考题22实验五：“系统”软件需求规格说明书的编写23一、实验目的23二、实验的软硬件环境23三、实验要求与任务23四、实验步骤23【附录一】软件需求规格说明模板24实验八：软件实现及测试（综合设计性实验，4学时）29五、实验报告要求29六、实验注意事项32七、思考题32【附录二】 评分标准33实验1：软件功能描述与确认（验证性实验2学时）一、实验目的与要求针对常用软件（如Wo

3、rd），描述软件功能，确认描述的正确性（至少10个功能）要求：1.一人一组。2.严格按照实验报告格式编写；3.实验报告内容详实，公正，态度认真。二、实验环境1.个人计算机2.常用工具软件：MS Office 20033.CASE软件：Visio2002三、实验预习与准备1.组成实验小组2.复习课堂教学内容3.选择实验对象，查阅有关资料4.熟悉实验指导书内容5.实验报告、实验记录用纸等四、实验内容和步骤每实验小组自己选择实验对象软件（如Office Word, PowerPoint, Excel等），对其常用的软件功能进行描述。任选一组或两组功能，总共不少10个子功能，边确认边用文字描述其功能。

4、例如：在Word字处理软件的功能分类中有：1. 文本格式化选择文本的显示方式。2. 文本编辑和更正更改已经输入的文本内容。3. 文件操作实现文本的保存、打印、输出及做其他操作。4. 工具添加列、表格、图片、对数据排序、检查拼写等等。5. 宏允许用户合并多个任务。6. 视图功能使用多种方式查看文档。7. 通信从外部资源中获得信息。五、实验报告要求 实验对象及实验内容、结果等信息按照下列表格填写。功能大分类： 实验小组成员： 班级：序号功能名称功能描述是否非功能需求你希望的功能实验者签名实验操作与记录要求示例Word2003软件的“保存文档”功能 从菜单上操作，有保存、另存为。基本功能是：把当前文

5、件保存到指定的文件夹内。保存1） 新建文件，缺省情况下，提示用户保存到我的文档，在提示窗口下，用户可选择其他任意路径下的任何文件夹（可新建文件夹）；2） 既有文件，缺省情况下，直接保存到该文件所在的文件夹内。3） 保存操作完的表现：正常情况下无任何显示，如文件较大，则保存操作的进度由进度条表现。异常情况下，显示信息通知。另存为1） 系统显示提示窗口，用户可选择任意路径下的任何文件夹（可新建文件夹）；2） 保存操作完的表现：正常情况下无任何显示，如文件较大，则保存操作的进度由进度条表现。异常情况下，显示信息通知。六、实验注意事项1. 必须保证有足够的实验工作量。2. 试验中要开展组内的讨论。3.

6、 实验结果记录要严谨，有条理。七、思考题1. 你认为上述功能中,哪些功能属于否非功能需求?为什么?2. 你认为利用上述格式描述软件需求有何好处，上表的格式还可以如何改进？3. 总结一下你在做这个实验的过程和方法。实验2：从程序设计看软件需求（综合设计性实验，2学时）一、实验目的与要求针对给定的程序设计题目,或根据给定的可视控件人机界面设计，提炼/补充软件功能需求和非功能需求。要求：1.2-3人一组。2.严格按照实验报告格式编写；3.实验报告内容详实，公正，态度认真。二、实验环境1.个人计算机2.常用工具软件：MS Office 20033.CASE软件：Visio2002三、实验预习与准备1.

7、组成实验小组2.复习课堂教学内容3.选择实验对象，查阅有关资料4.熟悉实验指导书内容5.实验报告、实验记录用纸等四、实验内容和步骤4-1 语言程序的软件功能需求分析说明：本实验为从C语言程序设计中提炼出软件功能需求（含非功能需求）。按照教学进度，目前学生已普遍知道软件用户需求和功能需求（含非功能需求），基本含义如下：l 用户需求：业务信息处理需求，交互需求等。l 功能需求：软件如何处理数据l 非功能需求：包括异常处理，界面友好，软件易用性等现有一些C语言程序设计题目，各题目描述的需求层次不一。要求：每实验小组从下列题目中至少选择2个，考察原题目的需求描述,判断属于上述3类需求的哪一层次，在表中

8、填写题目未描述的其他需求。示例如下表2-1所示。表2-1 C语言程序设计题目原题目：输入一组整数，当输入负数时停止，求和。用户需求功能需求非功能需求为计算一组人员年龄的平均值，先求出所有人员的年龄总和。求和开始的标志是：有一负数输入。输入一组整数，当输入负数时停止,求和。1. 该软件应为用户提供方便的输入方式，输入错误时，应放弃计算，并以错误信息提示用户。2. 所有输入数据必须为整数，否则作为异常处理。3. 最初两个输入数据不能为负值，否则作为异常处理。4. 假定各输入整数上限为120，大于者作为异常处理。5. 异常处理：中断程序执行，返回代表上述3种情况的整数，并用错误信息提示用户。实验题目

9、：1.输入一组整数,当输入负数时停止,求其中最小者。2.求 1-999 中能被 3 整除的数,并求它们的和。3.由键盘输入一个班50个学生的一门功课的成绩，求这门功课全班的平均成绩。4.编制一个运动会百米测验统计名次的程序。5.输入一组学生的姓名和成绩，从中找出成绩最高人的姓名，并打印出他们的姓名和成绩。6.编写程序，从键盘输入6名学生的5门成绩，分别统计出每个学生的平均成绩。7.设有5个学生，每个学生考4门课，编写程序能检查这些学生有无考试不及格的课程。若某一学生有一门或一门以上课程不及格，就输出该学生的序号（序号从0开始）和其全部课程成绩。8.编写程序计算10名学生1门课成绩的平均分。4-

10、2 用户界面（可视控件）的软件需求分析说明：本实验为用户界面（可视控件）的软件需求提炼。要求：对于下列16组控件界面图，每实验小组至少选择3组，用文字描述：该组各图的用户需求和功能需求。示例：示例-1用户需求：开发一学生成绩管理系统，其功能要求之一是：对数学、英语、语文三门课程的学生成绩（每生总分及平均分）用列表显示。功能需求：建立一独立窗体，从数据库中取得制定班级的三门课程成绩在窗体中的表格中显示；表格右边两列分别显示三门课程的总成绩和平均分数（精度为2位小数，第三位小数四舍五入）。示例-2用户需求：开发一客房管理系统，其功能要求之一是：快捷浏览每个房间的详细信息，是否已预订，如已有预定，要

11、求显示预定期间、客人姓名；列表显示所有房间的等级及其价格、有无空房。功能需求：建立一独立窗体，从数据库中客房信息一览表，该表含有客房类型、单价、空房间数等；该窗体中应提供方便的图形界面交互方式，快速显示已经预订的房间信息，包括房间号、房间类型、单价、预定时间等；另，应能够通过客人姓名快速检索已定客房信息。实验题目用户界面（可视控件）的软件需求分析可选题目如下：图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-

12、1图14-2图15-1图15-2图16-1图16-2五、实验报告要求要求本实验结果按照下列表格格式填写。其中：实验对象描述，指C语言程序描述；在选择控件界面设计图为实验对象时，需将图形文件贴于此处。实验对象编号及其描述软件功能需求提炼1.用户需求：功能需求：非功能需求：2.用户需求：功能需求：非功能需求：3.用户需求：功能需求：非功能需求：六、实验注意事项1.注意分析实验对象的非功能需求2.注意提高自己的文字表达能力3.注意总结对软件功能需求及非功能需求的认识七、思考题1. 上述需求分析的结果中，有没有相互矛盾的情况？为什么？2. 你认为本次实验的意义（价值）如何？3. 总结一下你在做这个实验

13、的过程和方法。实验3：软件需求分析（业务需求）（综合性实验，4学时）一、实验目的与要求业务需求（Business requirement），描述了组织为什么要开发一个系统，即组织希望达到的目标。组织的目标指超越软件本身的较高层次的目标。软件的业务需求任务是：定义项目范围。本课程规定：业务需求的描述，采用前景和范围（vision and scope）文档来记录。详细的内容见教材第4章。本实验的设计依据，来自本课程第3章给出的需求过程推荐方法中的第一布，即知识方法。通过获取软件客户的业务知识，建立起软件客户的业务需求框架。实验目的：针对某小型软件产品（含小型网站）的开发，收集、获取客户的业务知识，

14、分析其业务需求，描述出：1）客户通过该软件项目预期达到的业务目标；2）客户为达到预期业务目标所实施的软件项目范围；3）将客户业务知识经整理、汇总后作为本实验报告的附件（可选）。要求：1.2-3人一组。2.严格按照实验报告格式编写；3.实验报告内容详实，公正，态度认真。二、实验环境1.个人计算机2.常用工具软件：MS Office 20033.CASE软件：Visio2002三、实验预习与准备1.组成实验小组2.复习课堂教学内容3.选择实验对象，查阅有关资料4.熟悉实验指导书内容5.实验报告、实验记录用纸等四、实验内容和步骤1. 每个小组自选一个小型软件（或网站），经小组成员讨论后确定其名称；2

15、. 利用各种渠道获取该软件的相关组织的业务知识。主要是：（1）业务领域及其产品（服务）的内容、获利方式等；（2）组织结构与主要业务人员角色；（3）业务流程及相关术语；（4）其他知识。3. 绘制基于该软件构思的“业务-软件系统关联图”（参照教材4-27中的上下文图）；4. 按照本课程规定的“前景和范围文档”模板格式（见下表3-1，作为实验记录纸的内容），描述基于预期软件作用下的业务需求；5. 学生自主讨论，教师指导、答疑。五、实验报告要求 5-1.实验记录业务需求模板本实验报告主要内容须按照下属格式填写。表3-1：业务需求描述模板（前景和范围文档，参照教材表4-6、4-7）题目：xxx软件（网站

16、）业务需求（补充内容：对题目的选择给予简要说明）1. 背景、业务机会和客户需要2. 业务目标和成功标准BO-1：BO-2：BO-3：SC-1：SC-2：3.业务风险RI-1：RI-2：内容说明：1.背景、业务机会和客户需要。（1）背景。概述新产品的来由与背景。对历史和现状进行概括性的描述，说明为什么决定开发该产品。（2）业务机遇。对于软件企业，描述该预期软件产品（网站）可能得到的市场机遇或其产品的竞争能力；对于为某组织开发的信息系统软件，描述的预期将要解决的业务问题或将要改进的业务流程；还应对产品或解决方案简要描述其优点和作用。作为限制条件，可以描述需要哪些其他的技术、过程或资源。2.业务目标

17、和成功标准。用量化和可衡量的方式概述该软件产品（网站）提供了哪些重要的业务利益；如是社会公益性项目，可采取定性的描述语句说明其社会管理、社会服务等方面给受益群体带来的好处。要按照结构化的要求描述，即将业务目标描述为BO-1、BO-2的形式，将成功标准描述为SC-1、SC-2形式。3.业务风险。概述与该软件产品（网站）开发相关的主要风险。包括可能出现的市场竞争问题、时间问题、用户认可、实现问题以及其他可能对业务造成的负面影响。5-2 实验数据处理（选做）对于“实验内容及步骤”实施的结果，回到上述的步骤2和3，按照下表3-2所示格式，仔细分析、对照、检查业务需求描述内容与客户业务知识的符合程度，修

18、改、精炼、完善业务需求。表3-2 业务需求实验信息处理表业务需求描述-1（实验内容与步骤的结果）业务需求描述-2（修改与完善后的结果）修改原因1.背景、业务机会和客户需要2.业务目标和成功标准3.业务风险另：1）本次实验不要求有关软件版本的内容。2）在本实验中，不要求使用用例图。用例方法在实验4中要求必做。六、实验注意事项本课程的实验3，4，5，为同一个软件（网站）的三部分需求，即业务需求、用户需求和功能需求。学生务必以注意保持三个实验报告和记录的连续性，以便最终完成一个完整的软件需求说明文档。七、思考题针对表3-2 中的“修改原因”进行分析，并笔答下列问题: 1.你的修改原因是怎样发现的？2

19、.对修改前后对比，你认为你的业务需求实验结果发生了怎样的变化？3.总结一下你在做这个实验的过程和方法以及对业务需求文档描述工作的认识。实验4：软件需求分析（用户需求）（综合性实验，4学时）一、实验目的与要求用户需求（user requirement），描述的是用户使用预期软件系统所要达到的功能性目标及非功能性要求。一般，用户需求描述的是软件使用者（用户）使用系统能够完成什么业务任务或信息处理工作。具体内容是用例描述。场景描述不要求。本课程规定：用户需求的描述，采用用例（user case）文档来记录。详细的内容见教材第8章。用例方法，主要用于发现必要的功能性需求。对于不太复杂的用例，只要求写出

20、一个简略的描述，然后，推导出角色执行该用例（包括分支过程和异常处理）需要的所有功能性需求。实验目的针对某小型软件产品（含小型网站）的开发，在业务需求文档（前景范围文档）的基础上，进一步收集、获取用户的业务知识（重点是人机交互、任务的输入、任务功能、输出信息及业务任务的结果等），建立起用例模型，描述：1） 用户业务任务的用例图2） 用户业务任务的用例列表（示例见表4-1）3） 若干个具体的用例。即从用例出发推导部分功能需求和非功能需求，并明确说明。异常处理单独描述。（示例见表4-2）4） 用户完成业务任务中需遵循的业务规则（可选）说明：上述“若干个”具体的用例描述，指实验小组的每个成员至少从本组

21、的软件（网站）的业务主干过程中选择一个用例进行规范描述。要求：1. 2人一组。2.严格按照实验报告格式编写；3.实验报告内容详实，公正，态度认真。二、实验环境1.个人计算机2.常用工具软件：MS Office 20033.CASE软件：Visio2002三、实验预习与准备1.组成实验小组2.复习课堂教学内容3.选择实验对象，查阅有关资料4.熟悉实验指导书内容5.实验报告、实验记录用纸等四、实验内容和步骤在学生自选的小型软件（或网站）的业务需求文档的基础上，实施以下实验内容：1.深入获取业务知识，描绘用例图。2.编写用例列表。3.分工编写各自负责的用例描述。4.学生自主讨论，教师指导、答疑。五、

22、实验报告要求 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用

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

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

25、样的餐订多份（第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.系统通知顾

26、客它所能提供的同样食物曲多份餐的最大数量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.如果客户在今天的截止时间之前使用系统，那么默认的日期是当前日期。否则，默认日期是自助食堂

27、的下一个营业日2.如果顾客不要求送餐，那么“请求注册付费方式是从工资中扣除”这一前置条件就不适用3.这一用例的峰值使用负载是当地时间早晨8点到10点5-2 需求描述基本要求按照上述模板描述的用户需求（包括推导出的功能需求）、非功能需求，需参照下列要求认真编写。其中（1）、（2）、（3）和（4）是必须满足的基本要求；对于（7），参照5-3进行用例测试。（1）完整性不能缺少某些信息。（2）正确性需求之间不应发生冲突。（3）可行性避免不可实现的需求。（4）必要性必须是用户的真正需要（5）有优先次序在产品的某一版本中的重要程度。（6）无歧义 一项需求只有一种一致的解释。（7）可验证性用检查或演示可以判

28、断产品是否正确实现了需求。5-3 用例测试选择23个主要用例，按照下面的例子，进行用例测试，填写下表4-3。意图是明确该用例的若干条可能的执行路径及其处理过程（含异常）。表4-3 用例测试示例用例名称：查看定单用户输入系统输出期望的结果问题与分析用户输入要查看的定单号定单存在，表明该用户提交了定单显示定单的详细情况定单不存在显示消息“很抱歉，定单找不到！定单存在，但不是该用户提交的定单。显示消息“很抱歉，这不是您的定单！”。5-4 实验数据检查与分析要求：学生自主检查自己的实验记录（用例列表和用例描述），并填写下列表格（1）和表格（2），检查用例分析结果（注：如有重大问题，应返回修改；一般问题

29、只要记录检查结果，不必修改。遗留问题在实验5中解决）：（1） 功能性需求描述检查问题检查结果1用例描述是否比较详细？有没有不必要的实现细节？2用例中的每个参与者和步骤是否都与所执行的任务有关？3是否定义了系统的全部输入，包括其来源、精度、取值范围等？4是否定义了系统的全部输出，包括目的地、精度、取值范围、格式等？5用例的前置条件和后置条件是否合理？7是否列出了用户想要做的全部事情？8是否定义了每个任务所用的数据，以及每个任务得到的数据？（2）非功能需求描述检查问题检查结果1从用户的视角，是否按照需求描述了期望响应时间？2是否定义了安全要求和安全级别？3所有能想到的异常条件是否都已经被定义？4

30、需求中是否遗漏了必要的信息？六、实验注意事项各小组注意：1.讨论，检查，修改用例图和用例列表。2.讨论，检查，修改用例图、用例列表和用例描述。3.上述示例的表4-1，表4-2，可作为实验记录附件。七、思考题1.总结用例法分析用户需求的过程和步骤。2.针对实验数据检查与分析结果，总结自己的问题与收获。实验五：“系统”软件需求规格说明书的编写一、实验目的需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致的协议。这一协议综合了业务需求、用户需求和软件功能需求。从前面实验中所得出的一些分析文档中，我们可以知道：项目视图和范围文档包含了业务需求，而使用实例文档包含了用户需求。我们还必须编写从使

31、用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。至此，我们综合前面的相关分析结果，来进行需求说明书的编写，进一步理解由业务需求，用户需求，功能需求三个部分综合而形成软件需求说明书的过程。二、实验的软硬件环境硬件：微型计算机，打印机；软件：Windows XP/7 ，Office 2003/2007，Visual Studio 、Delphi，SQL Server 等要求实验环境为网络环境。三、实验要求与任务1、要求：完成软件需求规格说明书的编写：（1）用好的结构化和自然语言编写文档型文档（2）建立图形化模型。（3）编写形式化规格说明，这可以通过使用数学上精

32、确的形式化逻辑语言来定义需求。2、具体任务：开发“系统”（如人事管理信息系统、财务信息管理系统、酒店信息管理系统、设备信息管理系统、仓库管理信息系统、进存销管理信息系统、学生信息管理系统、图书馆信息管理系统，图书销售信息管理新系统等等）。通过调查获取用户需求，按照需求的内容进行分析，按照内容、格式要求撰写完整的软件需求规格说明书。四、实验步骤1、 参考相关模板，初步理解软件需求规格说明书的结构2、 结合项目实际，完成软件需求规格说明书3、 进一步检查、完善相应的需求部分，尽量避免需求遗漏，和定义的不清晰。同时，应确保采用规范图例。4、 重复进行前面几个步骤，经过小组成员多次讨论，并得到客户的认

33、可，最终达到客户和开发小组对需求的认识一致。【附录一】软件需求规格说明模板1引言引言是对整个软件需求规格说明的概览，以帮助读者更好地阅读和理解文档。包括文档的意图（目的）、主要内容（范围）、组织方式（文档组织）、参考文献（参考文献）和阅读时的注意事项（定义、首字母缩写和缩略语）。1.1 文档的意图（目的）目的是说明软件需求规格说明的主要目标，描述软件规格说明所定义的产品或某些产品部分。限定预期的读者。1.2 主要内容（范围）在这一节中：根据名称确定将被开发的软件产品。解释软件产品的预期功能，并在必要的时候解释没有纳人软件产品预期的功能。描述软件产品的应用，包括相关的好处、目标和目的。如果在此软

34、件需求规格说明之外，还存在着一个更高层次的规格说明（例如系统需求规格说明），那么该部分的描述应该与更高层次文档的相关段落保持一致。1.3 阅读时的注意事项（定义、首字母缩写和缩略语）定义了正确理解软件需求规格说明所必需的术语、首字母缩写和缩略语。这部分内容也可以通过添加附录或者引用其他文档来提供。1.4 参考文献在这一节中：提供需求规格说明文档引用的全部文档的清单列表。利用标题、报告编号（如果适用）旧期和出版机构来标识文档。指出参考文献的来源，在该来源中可以获得文献。这部分内容也可以通过添加附录或者引用其他文档来提供。1.5 组织方式（文档组织）在这一节中：描述软件需求规格说明余下部分所包含的

35、内容。解释软件需求规格说明的组织方式。2总体描述从总体上描述影响产品和需求的因素。这部分并不涉及将在文档第 3 部分（详细需求描述）中描述的具体的需求，而是为其提供背景知识，使其更加易于理解。2.1 产品前景该节将所定义的产品和其他相关的产品联系起来，在联系中描述产品的起源和背景，进而说明对产品的总体预期。如果产品是一个独立的、完全自包含的系统，那么就应该在这里进行声明。如果像常见的情况那样，产品仅仅是较大系统的一个组件，那么就应该将较大系统的需求和软件的功能联系起来进行说明，并标识它们之间的接口。如果能够开发一个可以显示较大系统的主要组件、内部连接和外部接口的框图，将会有很大帮助。这一节还应

36、该描述较大系统的其他部分对软件产品的操作预期。这些部分包括：系统接口：系统接口对软件产品的功能要求。用户界面：软件产品和用户之间接口的逻辑特征和优化要求。硬件接口：软件产品和较大系统中硬件组件之间接口的逻辑特征。软件接口：其他软件系统对软件产品的要求。：交流接口：本地网络协议之类的交流接口要求。内存：软件产品在主存储器和辅助存储器上的局限性和可适用特性。操作：用户要求的正常和特殊操作。地点改变需求：对指定地点、任务或者操作模式的需求，调整软件装置而需要改变的地点或者任务的相关特征。2.2 产品功能概述软件将要执行的主要功能。此处只需要概略的总结，其详细内容将在第 3 部分（详细需求描述）中描述

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

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

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

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

41、（8）屏幕布局组织。（9）窗口布局组织。（10）数据格式。（11）命令格式。（12）结束消息。3.1.1 用户界面描述系统所需的每个用户界面的逻辑特征。本节可能包括下列内容：对图形用户界面(GUI)标准的引用或者将要采用的产品系列的样式指南。有关字体、图标、按钮标签、图像、颜色选择方案、组件的 tab 顺序、常用控件等的标准。屏幕布局或解决方案的约束。每个屏幕中将出现的标准按钮、功能或者导航链接。快捷键。消息显示约定。便于软件定位的布局标准。满足视力有问题的用户的要求，3.1.2 硬件接口描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以

42、及所使用的通信协议等。3.1.3 软件接口描述该产品与其他外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、程序库和集成的商业组件等。声明在软件组件之间交换数据、消息和控制命令的目的。描述其他外部组件所需要的服务以及组件间通信的性质。确定将在组件之间共享的数据。3.1.4 通信接口描述与产品所使用的通信功能相关的需求，包括电子邮件,Web 浏览器、网络通信标准或协议及电子表格等。定义了相关的消息格式。规定通信安全或力。密问题、数据传输速率和同步通 信机制等。3.2 功能需求描述了软件产品在接收和处理外部输入（或者处理和产生对外输出）中发生的基本行为。需要描述的内容有：对输人的验证

43、操作的顺序对异常的响应，例如数值越界通信间题错误处理与恢复参数的说明输出和输人的关系输人输出序列将输人转换为输出的公式和规则3.2.x 系统特性系统特性是外部期望的系统服务，它接收一系列的输入，并产生外界预期的输出。3.2.x.1 特性描述提出了对该系统特性的简短说明。3.2.x.2 刺激响应序列列出输入刺激序列（用户动作、来自外部设备的信号或其他触发器）和系统的响应序列。3.2.x.3 相关功能需求详细列出与该特性相关的功能需求。这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务。描述产品如何响应可预知的出错条件或者非法输人或动作。3. 2.x.3.n 功能需求 x.n对单个需求（功能的某个步骤或者某个方面）的清晰描述，常见形式为“RID：系统应该”。3.3 性能需求阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员做出合理的设计选择。确定相互合作的用户数、所支持的操作、响应时间以及与实时系统的时间关系。还可以定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。尽可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它