学 号
软件系统分析与设计
实验报告
衣服售货系统
起止日期： 2013 年 9 月 25 日 至 2013 年 10 月 10 日
学生姓名
班级
成绩
指导教师(签字)
计算机与信息工程学院
2013年10月7日 天津城建大学计算机与信息工程学院
设计实验任务（一）
2013 —2014 学年 第 一 学期
计算机与信息工程 学院 软件工程 专业 3 班级
设计实验名称： 需求分析文档和规格说明书设计
设计题目： 网上服装店售货系统软件需求分析说明书
完成期限：自 2013 年 9 月 25日至 2013 年 10 月 10 日
一、实验目的
1．加深并消化本课程授课内容，复习所学过的前导课程内容、方法和技术；
2．了解并熟悉编写软件需求所使用的软件工具和运行环境，对实例所描述问题模型进行分析与设计；
3．进一步鼓励学生勤思考，综合考虑实际情况，运用所学过的知识完成需求获取、抽象、分析和设计过程，编写出客观、合理、可行、优化和简洁明了的需求分档和规格说明书。
4．达到巩固课程知识和实际应用的目的。
二、实验要求
1．对通过需求获取获得的实例进行问题描述，根据用户描述，运用软件需求分析中抽象问题框架方法框定问题（五个基本问题框架和多问题框架描述）；
2．通过对问题域的分析，编写需求文档和需求规格说明书，书写格式参考老师给出的模板。先做好初步的设计文档，再来做实验，提高实验效果；
并做好模型初步分析和设计，再来做实验，提高实验效果；
3．每项内容都要独立完成，运用软件文档编辑工具和建模工具（可以是自己比较熟悉的一种或多种工具）建立文档和其中的模型；
软件需求表
子系统 模块内容 对应界面(LIC) 功能说明
内部聊天系统 办公联络 1、聊天界面 内部良好的沟通，部门的链接，工厂与公司的有序对接
客户管理子系统 客户信息维护 1、客户信息列表
2、客户信息 目的：为企业提供一个完整的客户资料库，以备查询。
内容：客户的录入，修改，删除。
客户保密体系 1、总经理查看权限
2、业务员查看权限 目的：让每个人只能看到自己的客户，以提高企业客户的保密性。
内容：客户查看权限
销售管理子系统 销售订单 1、销售订单导入
2、订单进度
3、销售订单明细
待定：合同管理 目的：建立完整的客户销售订单数据库，可随时查找客户的历史订单情况。
内容：销售订单的输入，修改，删除；销售订单明细表包括对接业务员，订单交期，产品数据，工艺标准。
销售出货管理 1、出货单
2、出货单明细
3、出货回执单（是否投诉） 目的：建立完整的出货数据库，时间节点到位；
内容：出货单的输入，修改，删除；出货单明细表包括实际交期，是否合格，工艺标准。
报价管理 了解操作（待沟通）
销售退货管理 1、退货通知单
2、退货单明细 目的：建立完整的销售退货数据库，检视产品是否合格，投诉情况，客户问题
内容：退货单的输入，修改，删除；退货单明细表。
销售结算管理 1、销售发票（进项销项）
2、销售发票明细
3、销售对账
4、订单结算 目的：建立完整的销售开票数据库，可随时查找客户的开票情况。
内容：销售发票的输入，修改，删除；销售发票明细
订单执行情况表 1、订单执行情况查询 目的：从订单的角度分析订单的状态，主要表现为 生产-入库-送货-对帐-收款-开票
6个状态
生产管理子系统 生产排产 1、生产排程管理
2、生产任务
3、员工产量统计
4、机台产量统计
5、班组产量统计
6、生产台账 目的: 建立完整的生产任务数据库，便于进度查询，有序生产，落实到人到组到机台，有效考核，如客户投诉可直接对接到人与组（产能--工序工艺--交期--考核--合格--发货--对应物流--售后（投诉）
目 录
1. 引言
1.1 目的
1.2 文档约定
1.3 预期的读者和阅读建议
1.4 产品的范围
1.5 参考文献
2. 综合描述
2.1 产品的前景
2.2 产品的功能
2.3 用户类和特征
2.4 运行环境
2.5 设计和实现的限制
2.6 假设和依赖
3. 外部接口需求
3.1 用户界面
3.2 硬件接口
3.3 软件接口
3.4 通信接口
4. 功能需求
4.1 登录页面
4.2 查询员工绩效 4.3 员工绩效管理
4.4 考勤管理
4.5 绩效评定
4.6 报表审核
4.7 安全管理
5. 其他非功能需求
5.1 性能需求
5.2 安全设施需求
5.3 安全性需求
5.4 软件质量属性
5.5 业务规则
5.6 用户文档
6. 其他需求
附录
某公司员工绩效考核管理系统需求规格说明书
1. 引言
1.1目的
（1）以文档的形式给出在需求获取和需求分析阶段所获得的所有用户需求，并为软件设计和实现奠定基础，且能够作为软件测试和用户验收软件系统的重要依据。所有技术人员都应该以该文档作为产品的功能定义，具体建设内容。
（2）为开发小组成员、客户之间提供共同的协议而创立基础，减少彼此之间交流的困难和开发中因为需求不明确而产生的不必要的麻烦，让客户指出不足，进一步了解客户的要求。
1.2文档约定
（1）必须使用国家公布的规范字。打印版面上空2.5cm，下空2cm，左空2.5cm，右空2cm（左装订），固定行距，24磅。
（2）正文字体为宋体小四号。无特殊情况下，字体颜色均采用黑色。
（3）出现序号的段落不采用自动编号功能而采用人工编号，各级别的序号依次为（1）、1）、a等，特殊情况另作规定。
1.3预期的读者和阅读建议
本文档面向多种读者对象
（1）设计员：对需求进行分析，并设计出系统，包括数据库的设计。
（2）程序员：了解系统功能，编写《用户手册》。
（3）测试员：根据本文档对软件产品进行功能性测试和非功能性测试。
第3
章
软件需求分析和软件需求规格 IEEE把软件需求定义为： （1）用户为了解决某一问题或者达到某一目标而需要的功能和条件；
（2）这些条件和功能要求必须要被系统所满足，同时要满足相关的合同
契约、标准、规范，或者其他一些正式强制性文件。需要指出的是，所需处理的软件需求是动态的，也就是系统的性能是不断发展的。
正如我们所看到的，所有的开发模型都要求有明确的需求。若使用敏捷
技术就需要高层需求说明书，详细需求通过与客户反复交换意见得到，并且
直接反映在软件中。另一方面是需求描述要精准，需求活动的目的就是要得
到软件需求规格说明书SRS（software requirement specification），它描述了
软件需要做什么，而不描述怎么做。
这一章中要讨论：
SRS在工程中的作用，以及一个好的SRS会带来的价值。
在产生所需要的SRS的过程中的一些不同的活动。
SRS文档要求的特性，结构以及它的关键部分。
用例分析方法和功能需求的指定以及怎样开发用例。
其他一些需求分析的方法，如数据流图（data flow diagram）分析法。
怎样验证需求。
3.1 好软件需求规格的意义
多数软件系统起源于某些客户的需要，软件系统本身由某些开发者生
产，最终完成的系统由用户使用。然而，在一个新的系统中有我们感兴趣的
三个主要部分，它们是：客户、开发者和用户，那些客户所要求的以及用户 软件工程导论 ·28·关心的需求必须要与开发者交换意见。问题是客户往往不懂软件和软件的开发过程，同
时开发者也往往不理解客户的问题和应用领域。这就造成在项目的开发过程中，各方交
流的空隙。SRS最基本的目的就是要填补这个交流空隙，开发出一个拥有共同视图的软
件。所以一个优秀的SRS的主要优点是： SRS使得客户与开发者之间在软件究竟要做些什么上达成一致。 客户与开发者会频繁的把这些一致做成具有法律效力的契约，所以通过SRS，客户
