1．引言
1.1编写目的
该文档首先给出了整个系统的整体网络结构和功能结构的概貌，试图从总体架构上给出整个系统的轮廓，然后又对功能需求、性能需求和其它非功能性需求进行了详细的描述。其中对功能需求的描述采用了UML的用例模型方式，主要描述了每一用例的基本事件流，若有备选事件流则描述，否则则省略。而且还给出了非常直观的用例图。这些文字和图形都为了本文档能详细准确地描述用户的需求，同时也为用户更容易地理解这些需求的描述创造了条件。
1.2项目背景
a.所建议开发软件的名称：学生信息管理系统
b.项目的任务提出者：xxx学校。 c.开发者：xxx软件开发公司。 d.用户：全体师生。
e.实现软件的单位：软件3071软件开发公司。 f.项目使用的软件：Microsoft acce2003。 g.系统：本软件应使用Microsoft Windows xp。 1.3定义
本文档中没有用到专门术语的定义和缩写词的原文。 1.4参考资料
[1] 周佩德.《数据库原理及应用》.电子工业出版社
[2] 刘炳文等，VISUAL BASIC程序设计——数据库篇，1999 [3] 李光明.《Visual Basic编程实例大制作》.冶金工业出版社
[4] 李红等编著，管理信息系统开发与应用，电子工业出版社，2003 [5] 软件工程，人民邮电出版社，2002年3月第一版
[6] 康博工作室，张红军，王红等缟著《Visual Basic中文版高级应用与开发指南》，人民邮电出版社，2001年4月第一版
[7] 林立军，程斌，翁迪恩缟著《Visual Basic 数据库开发指南》，西安电子科技大学出版社，2000年2月第一版
[8] 宋伟，吴建国等编著《中文Visual Basic编程基础》，北京，清华大学出版社
2．可行性研究的前提
2.1要求
通过调查,要求系统需要有以下功能:
⑴
要求有良好的人机界面;
⑵
较好的权限管理;
⑶
原始数据修改简单方便,支持多条件修改 ⑷
方便的数据查询，支持多条件查询; ⑸
相应的权限下，删除数据方便简单，数据稳定性好；
⑹
数据计算自动完成，尽量减少人工干预; 2.2目标 a.人力与设备费用的节省； b.处理速度的提高；
c.控制精度或生产能力的提高；
d.管理信息服务的改进； e.决策系统的改进； f.人员工作效率的提高。 2.3条件、假定和限制
a.开发软件运行的最短寿命为一年。 b.进行系统方案选择比较的期限：2周。 c.经费来源和使用限制：自筹资金。
d.法律和政策方面的限制：本软件公司版权所有，未经作者允许，非法传播、复制，违者追究法律责任，后果自负。 e.硬件CPU p
3、内存256M.。 f.软件：acce2003。
g.运行环境：本软件应使用Windows200
3、Windows xp操作系统。
h.开发环境：本软件应使用Windows200
3、Windows xp开发。 i.开发软件投入使用的最迟时间为2013年10月01日。 2.4可行性研究方法
由于本系统管理的对象单一,都是在校学生，且每个数据内容具有较强的关联性，涉及的计算过程不是很复杂。因此，比较适合于采用数据库管理。且学校用于学生管理的微机都是PIII以上的机器，在存储量、速度方面都能满足数据库运行的要求。在技术难度方面，由于有指导老师的指导和相关参考文献，特别是网上资料，特别是参考其它程序的功能，因此完全可以实现
3．对现有系统的分析
3.1处理流程和数据流程 班级管理业务流程图： 档案管理业务流程图： 课程管理业务流程图： 成绩管理业务流程图 3.2工作负荷
现有系统所承担的工作只能实现档案管理的简单功能，无法适应目前工作 中处理大量数据的功能。 3.3费用支出
开发这个项目总需三个人，4台计算机，一个可容纳
6、7个人的办公室，必须有充足的物质做精神动力，每台计算机上必须有所需要的软件，比如：办公软件、数据库软件、截图软件等，必须有3000万元的准备开支。 3.4人员
数据库管理人员1名，维护人员1名。
1、3.5设备
四台计算机,一台备用,一个工作室.一台打印机,扫描仪一台 。 3.6局限性
现有系统主要存在如下不足： 1） 信息分散、共享性差 每个人的时间精力是有限的，大量的信息资源分散在不同的收集者手中，难于共享和发挥作用。还有就是用户毕业和离职时需要到不同的地方开办证明。 2） 信息的及时性、准确性差
数据的采集和处理部分靠人工，效率低、速度慢、滞后严重、反馈不及时，严重影响信息的反馈速度和质量，不能有效地、及时地提供基层决策需要的定量信息和领导决策需要的宏观定性信息。
4．所建议技术可行性分析 4.1对系统的简要描述
建议系统实现注册、查询等具体功能。 4.2处理流程和数据流程
4.3与现有系统比较的优越性
系统实现学生教师查询各种信息。 4.4采用建议系统可能带来的影响 4.4.1对现有软件的影响
需将计算机升级为CPU P
3、内存256M，添加一台打印机。 4.4.2对现有软件的影响
需要将Windows升级为2000以上。 4.4.3对系统运行的影响
（1）用户的操作严格按照系统要求规程。
（2）要求创建系统管理员与普通用户两种登录方式，分权限管理。
（3）数据应有系统管理员手动输入系统，普通用户无权输入数据。
（4）对数据有保存要求，并且对数据存储，恢复的处理。
（5）输出报告以报表的形式打印出来。
（6）系统具有恢复和备份的功能。 4.4.4对开发环境的影响
1、为了建立数据库，要求提供详细的数据资源。
2、为了开发和测验所建议系统而需要的计算机资源：CPU P
3、内存256M。
3、如数据涉及保密与安全问题，应由专人负责录入。 4.4.5对经费支出的影响
所建议系统的开发、设计经费开支：5000元。 维持运行而需要的经费开支：1000元。 4.5技术可行性评价
a.在限制条件下，完成功能目标的实现； b.利用现有技术，功能目标一定能达到；
c.对开发人员数量为5个人,每个人应对数据库知识有明确的了解，我们的组员都具有这种能力,一定按期完成工作；
d.在规定的期限内，开发顺利完成。 5．所建议系统经济可行性分析 5.1支出
5.1.1基建投资
1、房屋和设施：500元。
2、ADP设备：1000元。
3、数据通讯设备500元。
4、环境保护设备200元。 5.1.2经常性支出
1、设备的租金和维护费用：500元。
2、数据的通讯方面的租金和维护费用500元。
3、人员的工资和奖金开支：3000元。
4、其他经常性的开支：2000元。 5.2收益/投资比 收益/投资比为3:1.5.3投资回收周期 投资回收周期为半年.5.4敏感性分析
1、应尽量延长系统生存周期，可延长至3年。
2、应是有效数据全部录入系统，使系统工作负荷量达到饱和。
3、应尽量提高系统的处理速度。
4、应提高设备和软件的配置。 6．社会因素可行性分析 6.1法律因素
如果发现有侵权行为,必进行严格的处罚,本公司版权所有,未经作者的允许，禁止非法传播、复制，违者追究法律责任，后果自负。 6.2用户使用可行性
本系统使用比较简单,适合普通用户操作,只要用户对说明书进行认真阅读,都可了解。 7．其他可供选择的方案
方案有许多但本公司选择了这套方案,他具有自己的优越感,运用编制菜单栏来省去代码,这是界面有好起来,又降低了工作难度,进而宏的运用更简化了工作难度。除提供的建议方案的具体功能外，还需增加网络功能，未被推荐的理由是目前尚不具备开发条件，投入与效益不成比例。 8.结论意见
结论意见可能是： a.可着手组织开发；
b.需待若干条件（如资金、人力、设备等）具备后才能开发； c.需对开发目标进行某些修改；
d.不能进行或不必进行（如技术不成熟，经济上不合算等）； e.其他。
三 软件项目计划
1.引言
1.1 编写目的
软件项目开发是一项系统而复杂的工作，它需要一个团队互相配合、分工协作。软件项目管理系统可以规范一个软件开发团队的日常工作，提高工作效率。
为了很好的管理整个开发过程，同时预算整个开发过程的费用及时间的安排，给开发人员，管理人员一个参照物，明白自己在每一个阶段所需要完成的任务，协助他们更好地完成开发工作。
预期的读者：开发人员，项目经理，测试人员 1.2 背景
a.学生信息管理系统 b.提出者：项目经理，开发者：XXX开发团队。 1.3 定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。] 1.4 参考资料
[1] 周佩德.《数据库原理及应用》.电子工业出版社
[2] 刘炳文等，VISUAL BASIC程序设计——数据库篇，1999 [3] 李光明.《Visual Basic编程实例大制作》.冶金工业出版社
[4] 李红等编著，管理信息系统开发与应用，电子工业出版社，2003 [5] 软件工程，人民邮电出版社，2002年3月第一版
[6] 康博工作室，张红军，王红等缟著《Visual Basic中文版高级应用与开发指南》，人民邮电出版社，2001年4月第一版
[7] 林立军，程斌，翁迪恩缟著《Visual Basic 数据库开发指南》，西安电子科技大学出版社，2000年2月第一版
[8] 宋伟，吴建国等编著《中文Visual Basic编程基础》，北京，清华大学出版社 2.项目概述 2.1 工作内容
1 需求分析： 1~3个月 2 概要设计： 2~3个月 3 详细设计： 2~3个月 4 编码: 2~3个月 5 测试： 1个月
6 发布： 1个月 2.2 主要参加人员 参与者 个人情况
XX 软件工程专业学生，熟悉java语言，数据库编程 XX 软件工程专业学生，熟悉C#语言 XX 软件工程专业学生，有很好的网页设计能力
XX 软件工程专业学生，有良好的界面设计的能力和测试经验 XX 专业为软件工程，从事开发工作一年，能过独立地完成小型项目的整个开发过程
2.3 产品 2.3.1 程序
名称 编程语言 媒体形式 功能及能力
系统功能 C#+SQL Server 2000 文本 管理学生的学籍信息，统计学生的相关信息。学生信息的增加、修改、删除、查询 数据信息管理 C#+SQL Server 2000 文本 学生学籍信息管理，学生选课信息管理
基本业务 C#+SQL Server 2000 文本 学生注册、学籍信息维护，学生选课，老师管理班级信息。
信息浏览与查询 C#+SQL Server 2000 文本
管理员学生学籍信息浏览、查询
数据库 SQL Server 2000 数据库文件 数据库文件可以直接附加到本地的SQL Server 2000中的数据库中
学生学籍管理系统 C#+SQL Server 2000 CD光盘
程序的运行文件，运行之后只要发布之后就可以了 2.3.2.文件
需求说明书，安装指南，用户操作手册，预计可能出现故障及解决办法 2.3.3.服务
培训安装：系统测试完毕之后，2012年10月10日至12日两天的安装和使用的培训时间，主要是让用户适应本系统的运行环境与操作习惯 维护：系统出现故障时，用户可参照手册进行自行解决，如果解决不了，则派维护人员过去，系统的维护期2012年10月14日到2013年10月15日， 超过期限将不再派人去维修 2.3.4.非移交的产品
整个系统全部的的代码不必要给用户，所使用的技术及参考的文献也可以自己保留，以及该软件所使用的技术文档，这些都是不用给用户的 3.实施计划
3.1 工作任务的分解与人员分工 1需求分析
负责人： 汪国志 参与人：汪国志 2 概要设计
负责人：汪国志 参与人：汪国志 3 实现
负责人：汪国志
参与人：汪国志，XXX，XXX，XXX，XXX，XXX 4 测试
负责人：汪国志 参与人：汪国志 5 维护及用户培训 负责人：汪国志 参与人：汪国志 3.2 接口人员 负责人：汪国志 参与人：汪国志
职责:统一接口，使不同层之间能通信 3.3 进度 1 需求分析
开始时间：2012-10-01 完成时间：2012-12-30 所需资源：客户的需求
完成标志：完成需求分析说明书 2 设计
开始时间： 2013-01-01 结束时间： 2013-03-01 所需资源： 需求分析说明书 完成标志： 概要设计说明书 3 编码实现
开始时间： 2013-03-01 结束时间： 2013-06-01 所需资源： 概要设计说明书，设配 完成标志： 系统能顺利运行 4 测试
开始时间： 2013-06-01 结束时间： 2013-08-01 所需资源： 能顺利运行的系统 完成标志： 修复现存的bug 5 移交 开始时间： 2013-08-01 结束时间： 2013-10-01 所需资源： beta版系统 6 培训 开始时间： 2013-10-01 3.4 预算
1.采购必要设备的投资： 网络平台的建设，包括了建设方式和联网建筑物数等等方面去计算，这一块需要200万左右；
服务器与存储系统，从发卡量和设备数量等估算，这一块需要100万左右； 射频卡终端，包括读写器与POS机，这一块需要20万左右。 2.开发系统的投资：
按目前市场上一卡通管理系统的开发价格来看，开发所需的投大概在50万不等； 4.总计：:350万左右； 3.5 关键问题
本系统的操作过程简单，实现技术要求也不高，所以没有要特别列出的关键问题 4.支持条件 4.1 运行环境
a.开发软件运行的最短寿命为一年。 b.进行系统方案选择比较的期限：2周。 c.经费来源和使用限制：自筹资金。
d.法律和政策方面的限制：本软件公司版权所有，未经作者允许，非法传播、复制，违者追究法律责任，后果自负。
e.硬件CPU p
3、内存256M.。 f.软件：acce2003。
g.运行环境：本软件应使用Windows200
3、Windows xp操作系统。 h.开发环境：本软件应使用Windows200
3、Windows xp开发。 4.2 需由用户承担的工作
数据库的初始化需要用户自己录入，这个应该在测试之前完成，所以编码之前，由开发人员做好数据库，然后由用户安排人录入初始数据库，且必须在2013年6月1日之前完成。 4.3 需由外单位提供的条件
本项目希望得到委托商的资金支持，人员支持，如取需求时，能够提供部分食堂为我们的测试的提供支持环境，还有技术支持 5.专题计划要点
专题计划 要点
合同计划
在分析阶段拟定合同书，分析阶段一结束就签订合同，合同包括需求的定义，如出现任何问题，可以根据合同调解，以及费用的支付，在每个阶段结束之后，委托方需支付开发方多少现金
测试计划
包括单元测试，集成测试，系统测试计划，主要参照开发文档，拟定计划，具体到输入的格式，响应的时间，需求的确认
五 进度计划风险列表
1.最常见的进度计划风险
1）功能无限蔓延； 2）质量不定 3）计划过于乐观 4）设计欠佳 5）银弹综合症 6）研发导向开发 7）人员薄弱 8）签约商失败；
10）研发人员与客户的磨擦。 2.进度计划风险完整列表
2.1 计划编制风险
1）计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；
2）计划是优化的，是“最佳状态”； 3）计划忽略了必要的任务；
4）计划基于使用特定的小组成员，而那个小组成员其实指望不上。 5）在限定的时间内无法建成已定规模大小的产品； 6）产品规模比估计的要大一些； 7）工作量大于估算数；
8）进度已经拖延的项目在重新评估时过于优化或忽视项目历史； 9）过度的进度压力造成生产率下降；
10）目标日期提前，但没有相应地调整产品范围或可用资源； 11）一个任务的延迟导致相关任务的连锁反应；
12）涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。 2.2 组织和管理
1）项目缺乏一个有凝聚力的最高领导人；
2）由于前期乏力，项目长时间被搁置； 3）解雇和削减开支导致项目小组能力下降；
4）仅由管理层或市场人员进行技术决策，导致计划进度延长； 5）低效的项目组结构降低生产率；
6）管理层审查/决策的周期比预期时间长； 7）预算削减打乱项目计划；
8）管理层做出了打击项目组织积极性的决定； 9）非技术的第三方的工作比预期延长（如审批，采购等）； 10）计划性太差，无法适应期望的开发速度；
11）项目计划由于压力而放弃，导致开发混乱、低效；
12）管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力。 2.3 开发环境
1）设施没有及时到位； 2）设施到位，但不配套； 3）设施拥挤、杂乱或者破损； 4）开发工具未能及时到位；
5）开发工具不如期望那样有效，开发人员需要时间创建工作环境或切换新的工具；
6）开发工具的选择不是基于技术需求，不能提供计划要求的性能； 7）新开发工具的学习期比预期的长，内容繁多。 2.4 最终用户
1）最终用户坚持新的需求；
2）最终用户对于最后交付的产品不满意，要求重新设计和重做； 3）最终用户不买进项目产品，无法提供后续支持；
4）最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做。
2.5 客户
1）客户坚持新的需求；
2）客户对规划、原型和规格的审核/决策周期比预期长；
3）客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和耗时的重复；
4）客户答复的时间比预期长（如回答需求中需澄清的问题）； 5）客户坚持技术决策而导致进度计划延长；
6）客户对开发进度管理过细，导致实际进展变慢；
7）客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作；
8）客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作；
9）客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低；
10）客户不接受交付的软件，尽管它满足了所有的规格； 11）客户期望的开发速度是开发人员无法达到的。 2.6 承包商
1）承包商没有按承诺交付组件；
2）承包商递交的组件质量低下无法接收，必须花时间改进质量；
3）承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平。
2.7 需求
1）需求已经成为项目基准，但变化还在继续；
2）需求定义欠佳，而进一步的定义会扩展项目范畴； 3）添加额外的需求；
4）产品定义含混的部分比预期需要更多的时间。 2.8 产品
1）错误发生率高的模块需要比预期更多的测试、设计和实现工作；
2）校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作。
3）在一个或多上新兴领域推广计算机技术使得计划进度的延长不可预 4）由于软件功能的错误，需要重新设计和实现；
5）开发额外不需要的功能（镀金）延长了计划进度；
6）要满足产品规格与速度要求，需比预期更多时间，包括重新设计和实现的时间；
7）严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；
8）要求与其他系统、复杂系统或不受本项目控制的系统相连，导致无法预料的设计、实现和测试工作。
9）要求在不同操作系统下运行将花费比预期更长的时间；
10）在不熟悉或未经检验的软（硬）件环境中运行产生未预料的问题； 11）开发一种对组织全新的模块将比预期花费更长的时间； 12）依赖正在开发中的技术将延长计划进度。 2.9 外部环境
1）产品依赖政府规章，而规章的改变将是不可预期的；
2）产品依赖草拟中的技术标准，而最后的标准将是不可预期的。 2.10 人员
1）招聘人员所花时间比预期的长；
2）作为先决条件的任务不能按时完成（如培训、其它项目）； 3）开发人员和管理层之间关系不佳导致决策缓慢，影响全局；
4）项目组成员没有全身心投入项目，进而无法达到需要的产品性能水平；
5）缺乏激励措施，士气低下，降低了生产能力； 6）缺乏必要的规范，增加了工作失误与重复工作；
7）某些人需要更多时间适应不熟悉的软件工具和环境、硬件环境、编程语言；
8）项目结束前，合同制人员离开团队，或雇员辞职；
9）项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率；
10）项目组成员不能有效地一起工作；
11）由于项目组成员间的冲突，导致沟通不畅、设计欠佳、接口错误和额外的重复工作；
12）有问题的成员没有调离项目组，损害了项目组其他成员的积极性； 13）项目的最佳人选未加入项目组；
14）项目的最佳人选已加入项目组，但因其他原因未能合理使用； 15）没有找到项目急需的具有特定技能的人； 16）关键人物只能兼职参与； 17）项目人员不足；
18）任务的分配与人员技能不匹配； 19）人员工作的进展比预期的慢；
20）项目管理人员怠工导致计划和进度失效；
21）技术人员怠工导致工作遗漏或质量低下，工作需要重做。 2.11 设计与实现
1）设计过于简单，无法确定主要事件，并导致重新设计和实现； 2）设计过于复杂，导致一些不必要的工作，影响实现效率； 3）设计质量低下，导致重复设计和实现
4）使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误；
5）产品采用低级语言来实施，导致生产率比预期的低；
6）一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新库或自选开发所要的功能；
7）代码和库质量低下，导致需要额外的测试、错误修正或重做； 8）过高估计了增强型工具对计划进度的节省量；
9）分别开发的模块无法有效集成，需要重新设计或重做。 2.12 过程
1）大量的纸面工作导致进程比预期的慢；
2）进程跟踪不准确，导致无法预知项目是否已落后于计划进度； 3）前期的质量保证行为不真实，导致后期的重复工作；
4）质量跟踪不准确，导致无法得知影响进度的质量问题； 5）太不正规，导致沟通不足，质量问题和工作重做； 6）过于正规，导致过多耗时无用的工作；
7）向管理层撰写进度报告占用的开发人员的时间比预期的多； 8）风险管理粗心，导致没有发现重大的项目风险； 9）软件项目风险管理花费的时间比预期的多。
