考勤管理系统需求文档

考勤管理系统需求文档

简介

背景

      某软件公司，员工人数100人左右，大部分员工是软件研发人员，包括项目经理、软件设计师、程序员、测试工程师、实施工程师等，除此之外还包括行政人员、财务人员。公司在软件研发及日常管理上有一套成熟的管理方法，在没有考勤系统之前，与考勤相关的管理工作是这样的：

l        每位员工需要上午上班时打一次卡，下午下班时打一次卡，中午的休息不需要打卡。

 

l        期间如果需要外出工作，从公司出发时需要打一次卡，回到公司时需要打一次卡。

 

l        员工请假需要填写请假条，请假分为事假、病假、年假等多种情况，请假需要直接领导审批，甚至还需要高层领导的审批。

 

l        行政部每天统计考勤信息，包括打卡信息、外出信息、请假信息，每月将考勤汇总信息提交给财务部。

 

l        财务部根据考勤汇总信息，调整员工的薪金。

 

但这样的管理方式，出现了一些意外事件：

 

l        某员工想请年休假，但行政部告知该员工的当年度年休假已经休完了。年休假的管理出现了问题，很可能会影响员工的工作积极性。

 

l        某员工投诉当月薪金多扣了钱，原因是考勤信息统计有误。于是财务部将责任推到行政部，行政部推诿财务部要求不明确。

 

l        某天出现了紧急状况，高层领导想找员工A来处理，但员工A当天请了假，高层领导并不知情。

 

公司高层期望通过考勤系统提高考勤工作的效率和准确性，避免因为考勤问题影响正常工作。

 

定义、缩略语

表1.1 术语表

术语	解释
年休假	年休假，是国家根据劳动者工作年限和劳动繁重紧张程度每年给予的一定期间的带薪连续休假。机关、团体、企业、事业单位、民办非企业单位、有雇工的个体工商户等单位的职工连续工作1年以上的，享受带薪年休假。 职工累计工作已满1年不满10年的，年休假5天；已满10年不满20年的，年休假10天；已满20年的，年休假15天。 国家法定休假日、休息日不计入年休假的假期。
五险一金	五险一金，是指用人单位给予劳动者的几种保障性待遇的合称，包括养老保险、医疗保险、失业保险、工伤保险和生育保险，还有住房公积金。 在职职工个人应当按照规定缴存住房公积金。”住房公积金为“应当缴纳“项目，法律上应当即为必须，同时缴纳也表现出这是一项义务。[1]
166个公司-法名词	详见 http://wenku.baidu.com/link?url=uT-h4o6jLf0uwNPIKI3QvlGHVmEZz5qaKm3V5j1UUqV09odsDS6iJX_9sp_DeikM9xvTh4BPACO71fxlCNt5z0qyM818ozsPSnOEeA2xdLG
类图	类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性信息。
部署图	部署图(deployment diagram，配置图)是用来显示系统中软件和硬件的物理架构。从部署图中，您可以了解到软件和硬件组件之间的物理关系以及处理节点的组件分布情况。使用部署图可以显示运行时系统的结构，同时还传达构成应用程序的硬件和软件元素的配置和部署方式。
活动图	活动图（activity diagram，动态图）是阐明了业务用例实现的工作流程。业务工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。业务用例由一系列活动组成，它们共同为业务主角生成某些工件。工作流程通常包括一个基本工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明。
顺序图	顺序图是将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。

约束

l        利用Windows域管理实现单点登录和权限管理。

l       无需改造或升级现有的打卡设备及相应软件。

参考资料

                                                表1.2参考资料表

资料名称	版本/日期
火球UML大战需求分析	中国水利水电出版社2012,1
《UML初学者指南》（美）	Maksimchu人民邮电出版社。
UML系统分析设计	印度优秀IT职业教育教学用书，高等教育出版社

 

目标、涉众分析和范围

目标：

（1）规范员工的上下班、请假、外出工作等行为并规范记录。

（2）共享员工的请假及外出工作信息。

（3）根据共享的信息及各种记录方便的计算员工的薪金。

（4）方面合理的管理安排各种带薪假期。

公司组织架构图：

图2.1公司组织架构图

涉众分析表：

表2.1 涉众分析表

序号	涉众	代表人物	待解决的问题/对系统的期望
1	普通员工	张华花、刘笑笑	1、上下班是能方便的打卡。 2、能够方便的查看自己请假记录。 3、能够方便的查看自己的请假记录及外出记录。 4、能够方便的聊了解其他人的请假及外出情况，以便调整好自己的工作安排。 希望不要出现考勤记录方面的错误，导致出现误扣工资、年休假无端减少等情况。 5、能够方便查看自己可牛年假的情况。 6、能够方便查询自己当月工资情况。
2	行政部门员工	王小强	1、方便统计考勤信息、而且不会出错。 2、与财务部门的“接口”尽量简单而且信息联通方便。 3、方便管理员工的各种带薪假期。
3	财务部门员工	李婷	1、方便以员工的考勤情况来调整员工的薪金，而且不会出错。 2、与行政部门的“接口”尽量简单，而且信息联通方便。
4	项目经理	吴天良	1、项目组的成员请假信息要尽早让他知道。 2、由于项目突发情况，需要临时安排外出工作时，相关外出申请手续应尽量简单而且到位。
5	部门经理	董成鹏	1、方便审批部门成员的请假、外出申请。 2、方便了解本部门及相关部门员工的请假、外出情况，以安排好工作。
6	副总经理	王忡	说明：3天以内的请假及外出，副总经理有最终的审批权限。所有的请假及外出，都需要经过副总经理的审批。 1、方便审批请假、外出申请。 2、方便检查部门经理有否作出合适的审批。 3、方便了解全体员工打的请假、外出情况、以安排好工作。 4、方便了解员工对请假外出事宜的安排是否认同。
7	总经理	叶空	说明：3天以上打的请假或外出，需总经理审批。 1、方便审批请假、外出申请。 2、方便检查部门经理、副总经理是否有作出合适的审批。 3、方便了解全体员工的请假、外出情况、以安排好工作。 4、避免因为考勤的问题而影响工作士气、工作效率。

范围：

    本系统主要是针对解决公司打卡记录、请假申请、外出申请等范围的问题。本系统与打卡系统相关联。根据考勤信息调整员工的薪金。本系统主要使用范围是在公司内部。本系统不与财务软件对接。

业务概念分析

概述

    本系统要管理的事情主要有：打卡记录，外出申请，请假申请

业务概念一览

图3.1 业务概念图

外出申请

图3.2 外出申请图

请假申请

图3.3 请假申请图

业务流程分析

概述

    请假申请和外出申请都需要审批，请假申请和外出申请在审批流程不同阶段处于不同的状态。

外出申请审批流程

图4.1 外出申请审批活动图

图4.2 外出申请审批状态机图

图4.3 外出申请审批顺序图

请假申请审批流程

图4.4 请假申请审批活动图

图4.5 请假申请审批状态机图

 

图4.6 请假申请审批顺序图

功能性需求

    功能性需求指的是用户通过该系统能够完成什么样的事物，该系统可以通过什么样的流程来实现用户相应的需求。

 

总用例图

    通过一个宏观的用例图来总体说明系统的功能，通过该用例图可以了解该系统的整体功能，可以用该系统完成怎样的事物。

图5.1 总用例图

普通员工的用例

图5.2 普通员工用例图

表5.1 普通员工提出请假申请用例表

编号	2.1	名称	提出请假申请
执行者	普通员工	优先级	高■低口
描述	普通员工录入请假的信息, 能成功提出请假申请
前置条件	无
基本流程	l.指示提出请假申请。 2.显示请假申请表单。 3.填写申请单,选择请假类别。 4.指示提交申请。 5.显示成功提交申请的信息。
结束状况	[列出在“正常”结束的情况下的用例的结果。] 系统保存请假申请数据, 并提示成功提交申请的信息。
可选流程1	[说明和基本流程不同的其他可能的流程。 ] 4.指示取消申请。 5.显示申请被取消的信息。
异常流程	3..显示申请被取消的信息。 4.指示提交申请。 5.发现可休年假不足,显示相应提示，并向用户显示相应通知。 6.修改请假申请单,或取消请假申请。
说明	[对本用例的补充说明] 请假申请单有以下内容:申请者、开始时间、结束时间、请假事由、请假类别。 申请者默认为当前的用户, 不可修改。 申请者默认为当前的用户, 不可修改。 类别为:事假、病假、婚嫁、产假、年假,只能而且必须选其一 请假时间不能超过年假时间

 

表5.2 普通员工修改请假申请用例表

编号	2.2	名称	修改请假申请
执行者	普通员工	优先级	高■    低□
描述	请假申请提出后，还没有任何审批之前, 申请者可修改请假申请 。 请假申请被拒绝后， 申请者可修改请假申请, 重新提交。 请假申请不能通过行政部审核，行政部也无法代为处理时，申请者可修改请假申请，重新提交。 行政部可以代申请者处理。
前置条件	请假申请必须存在并且有效。
结束状况	[列出在“正常”结東的情况下的用例的结果。] 请假申请的状态变为“待定”，该申请需重新审批。
说明	请假申请的状态为“……已批准”时， 申请者如果对该申请进行任何修改, 其状态一律重新变为“待定”，需重新审批。 修改请假申请时，程序应做并发冲突的异常判断和处理，如果出现冲突， 应拒绝本次修改，并给出相应提示。

 

表5.3 普通员工査看请假申请用例表

 

编号	2.4	名称	査看请假申请
执行者	普通员工	优先级	高■低口
描述	目标: 可方便地査看自己的请假申请的审批情况,能查看自己的历史申请,在此基础上做下一步工作。 具体要求: l  系统默认按时间的倒序显示当前用户的请假申请列表,用户可通过该列表了解各申请的状态 。 2 . 请假申请列表可按时间的倒序或顺序排列, 也可按请假申请的状态进行筛选 。 3  在请假申请列表的基础上, 用户可査看或修改其中一个具体的申请, 或提出请假中请 。 4.用户在査看一个具体的申请时,才能删除该申请。
前置条件	无
结束状况	可以显示请假申请审批情况，系统数据不会发生变化。
说明	请假申请的状态参见业务概念图

 

 

表5.4 普通员工査看可休年假情況用例表

编号	2.5	名称	査看可休年假情況
执行者	普通员工	优先级	高口 低■
描述	用户能看到按时间倒序排列的自己的年假申请,并能看到自己的当年年假总天数,及剩余可休的年假天数。 用户可在此基础上,査看或修改其中一个具体的申请,或提出请假申请
前置条件	行政部已设置该员工的当年可休年假,参见用例“5.设置员工的可休年假”
结束状况	可以显示可休年假的具体情况，系统数据不会发生变化。
说明	请假中请类别参见业务概念图

 

表5.5 普通员工查看全体员工的外出用例表

 

编号	3	名称	查看全体员工的外出及请假信息
执行者	普通员工	优先级	高        低
描述	目标： 能方便地查看全体员工的外出及请假情况。 具体要求： 1.     用户可方便地查看当天、当周、当月所有的外出及请假情况，系统缺省显示当周的情况，用户可方便地在当天、当周、当月之间切换。 2.     系统显示当天情况时，用户可方便地切换到前一天或后一天；类似地，系统显示当周、当月情况时，用户也可以方便地切换到前一周、后一周或前一个月、后一个月。 3.     还没有通过审批的外出或请假申请，均应显示出来。 4.     用户可查看具体的一条外出或请假申请。 5.     除了该请假申请的审批者能查看请假申请的“请假事由”，其他人不能查看“请假事由”，但可查看谁在什么时间请了什么类别的假。
前置条件	无
结束状况	可以显示全体员工外出的具体情况，系统数据不会发生变化。
说明	需共享的请假申请、外出申请信息请参考业务概念图，但要注意“请假信息”并不是对所有人共享的。

 

 

 

表5.6 普通员工查看自己的打卡记录用例表

 

编号	4	名称	查看自己的打卡记录
执行者	普通员工	优先级	高       低
描述	系统默认按照时间的倒序显示该用户的打卡记录，用户可选择一个日期范围来查询相应的打卡记录
前置条件	相应的打卡记录数据应先导入到系统中，参见用例“7.导入打卡数据”
结束状况	可以显示自己的打卡记录的具体情况，系统数据不会发生变化。
说明	打卡信息包括：员工ID、打卡日期、打卡时间 该用例员工只能查看自己的打卡记录，故只需显示打卡日期、打卡时间即可

行政部员工、财务部员工的用例

图5.3 行政部员工、财务部员工的用例图

表5.7 行政部员工设置员工的可休年假用例表

编号	5	名称	设置员工的可休年假
执行者	行政部员工	优先级	高□ 低■
描述	目标：    行政部可根据公司的年休假制度，设置每位员工每年的可休假数量 具体要求： 1.       可查看全体员工可休年假列表，列表显示员工姓名、部门、当年可 休年假总天数，当年 以休年假天数。 2.       在查看可休年假列表的基础上，可设置每个员工的可休年假总数， 可查看每个员工当年的请假类别为年假的请假申请
前置条件	无
结束状况	系统保存了更新后的该员工的可休年假总天数，并通知员工可休年假 更改信息
说明	通常情况下，行政部设置员工可休年假的时间为： 在每个自然年的第一个工作日，重新设置每个员工的可休年假数量。 在新员工转正的第一天，设置该员工的可休年假数量 但系统不需要限制修改时间

 

 

 

 

表5.8 行政部员工查看员工的请假信息用例表

编号	6	名称	查看员工的请假信息
执行者	行政部员工	优先级	高□ 低■
描述	目标： 行政部根据公司相关制度，审核员工的请假申请。 基本要求： 1.     系统默认按时间倒序，显示通过了最终审批，但未通过行政部审核 的员工请假申请列表。 2.     可再选择查看具体的一条请假申请。 3.     不符合相关制度的请假申请，可按以下两种方式之一处理： 执行用例“6.1分解员工的请假“，具体参见用例6.1. 该申请不通过审核，通知申请者修改申请，系统不支持这种处理方式， 行政部可通过电话、Email、口头等方式，通知申请者修改请假申请。
前置条件	无
结束状况	可以显示员工请假信息的具体情况，系统数据不会发生变化。
说明	参见请假审批流程活动图，通过副总经理审批的3天或以内的请假，通过总经理是的超过3 天的请假，都需要行政部进行审核。 实际上行政部不需要对全部请假进行审核，一般只需要对婚假、产假等涉及到比较复杂的国 家政策的申请进行审核，行政部的审核也不需要立刻进行，有时候每月统一审查一次就可以 了。本系统不支持行政部的审核功能，只支持查看功能，但行政可以在查看的基础上，不通 过本系统完成审核的工作。

 

 

 

 

 

表5.9 行政部员工分解员工的请假用例表

编号	6.1	名称	分解员工的请假
执行者	行政部员工	优先级	高□ 低■
描述	目标：  行政部可以分解不符合要求的请假申请，使分解后的请假总天数不变 、起止时间不变。 例：某员工申请了10天的婚假，但行政部审核时发现该员工不符合晚 婚政策，只能享受3天婚假，于是与该员工协商，将该请假分解为3天 婚假、5天年假、2天事假。 具体要求： 1.     在查看员工具体一条请假信息的基础上，可分解该请假。 2.     分解请假时，需输入请假类别、时长。 3.     分解后的总时长等于原来申请的时长，总起止时间不变，系统按照 分解后申请的先后顺序自动生成各申请的起止时间。 4.   分解后的请假无需再次审批，自动为已批准状态。
前置条件	无
结束状况	系统保存了分解后的请假申请，原请假申请不再保留
说明	参见业务概念图。 行政部与申请者的协商过程，是系统范围外的工作。

 

表5.10 行政部员工导入打卡数据用例表

编号	7	名称	导入打卡数据
执行者	行政部员工	优先级	高■ 低口
描述	目标： 将打卡记录导入到系统中，以便用户通过本系统查询打卡记录。 具体要求： 1.     系统可导入保存有打卡记录的Excel文件。 2.     导入的数据以“增加”的方式保存到系统中，系统不判断新导入的数据是否与之前的数据有冲突。
前置条件	无
结束状况	打卡记录保存到系统中
说明	打卡数据记录在打卡机中，行政部需要每天用电脑连接打卡机来读取数据，读取的数据是Excel格式，读取数据的软件是打卡机配套提供的。 打卡记录包含：员工ID、打卡日期、打卡时间。

 

表5.11 行政部员工查看员工的打卡记录用例表

 

编号	8	名称	查看员工的打卡记录
执行者	行政部员工	优先级	高□ 低■
描述	目标：   掌握各员工的打卡情况，方便与员工的请假申请、外出申请进行比较 ，以核实各员工的考勤信息。 具体要求： 1.     系统默认安装时间的倒序列出各员工的打卡记录，需要显示的内容 有：员工姓名、所属 部门、打卡日期、打卡时间。 2.用户可按时间范围、所属部门、员工姓名来筛选显示打卡记录
设置条件	系统需存在已经导入的打卡记录数据，参见用例“7.导入打卡数据”
结束状况	可以显示员工的打卡记录的具体情况，系统数据不会发生变化。
说明	以用例“4.查看自己的打卡记录”不同，行政部是可以查看全体员工 的打卡记录的，其目的是通过打卡记录、请假申请、外出申请的比较， 来核实各员工的考勤情况，频道员工有没有迟到、早退、矿工等情况， 制作相应的考勤报表途径给财务部，财务部根据该报表来计算员工当 月的薪金 考勤报表是这样的一张报表：记录了当月影响员工薪金的所有考勤情况，影响员工薪金的考勤情况有：迟到、早退、矿工、非带薪假期。该报表由行政部制作， 交由财务部作为员工薪金计算及调整的依据。

 

表5.12 行政部员工、财务部员工查看请假统计表用例表

编号	9	名称	查看请假统计表
执行者	行政部员工、财务部员工	优先级	高■    低□
描述	目标： 行政部的目标有：根据请假统计报表，检查各员工的请假情况，特别是带薪假期，是否符合公司的相关制度要求。 核实各员工的请假情况，作为制作考勤报表的依据。 财务部的目标有：作为当月员工薪金计算的参考依据。 具体要求： 1.     报表首先根据员工分组，然后根据请假类别分组，列出分组后汇总的请假天数。 2.     可按如期范围、所属部门、员工姓名、请假类别来筛选统计数据范围。 3.     可在查看报表的基础上执行用例“9.1.”导出请假统计报表。
前置条件	无
结束状况	系统数据不会发生变化
说明	考勤报表参见用例“8.查看员工的打卡记录”的用例表中的说明。 财务部计算当月员工薪金的直接依据是行政部提交的“考勤报表”，该请假统计报表只是参考。 行政部每月需要根据请假统计报表，同时还需要查看员工打卡记录、外出申请记录、请假申请记录等，经过综合判断后制作考勤报表

部门经理、副总经理、总经理的用例

图5.4 部门经理、副总经理、总经理的用例图

表5.13 部门经理查看需要审批的申请用例表

编号	11.1	名称	查看需要审批的申请
执行者	部门经理	优先级	高      低
描述	目标： 部门经理可方便地查看需要审批的申请，并可以方便地审批申请。 具体要求: 1.     系统默认按照申请提出时间的顺序，列出状态为“待定”的请假申请列表。、 2.     该请假申请列表需显示：申请者姓名、所属部门、请假类别、请假起止时间、请假事由、请假申请的状态。 3.     用户可直接在此请假申请列表的基础上，直接审批某个申请，参见用例“11.1.1审批申请”。 4.     用户可在此请假申请列表的基础上，选择查看具体的某个申请，并进行审批，参见用例“11.1.1审批申请”。
前置条件	无
结束状况	可以显示需要审批申请的具体情况，系统数据不会发生变化。
说明	需要部门经理审批的请假申请是状态为“待定”的申请： 申请者提出请假申请后，申请的状态为“待定”。 申请者修改被拒绝的申请，申请的状态变为“待定”。

 

 

表5.14 部门经理审批申请用例表

编号	11.1.1	名称	审批申请
执行者	部门经理	优先级	高     低
描述	目标： 用户能根据请假申请的信息，审批该请假申请。 具体要求： 1、  参见用例“11.1查看需要审批的申请”，用户可在请假申请列表上直接审批其中一条申请，或在查看某一个具体的申请时，审批该申请。 2、  审批时需选择批准或拒绝，同时可填入审批意见。 3、  审批时间不需要用户输入，由系统自动确定
前置条件	无
结束状况	系统保存了该申请的审批信息，如果请假申请被批准，则该申请状态变为“部门经理已审批”，如果是拒绝，则状态为“已拒绝”
说明	参见“请假申请审批流程 状态机图”

 

表5.15 部门经理查看以往的审批用例表

编号	11.2	名称	查看以往的审批
执行者	部门经理	优先级	高       低
描述	目标： 用户可方便地查看他曾经审批过的请假申请，了解请假申请的后续审批情况。 具体要求： 1.     系统按照请假申请提出时间的倒序，列出用户曾经审批过的请假申请列表。 2.     请假申请列表需显示：申请者姓名、所属部门、请假类别、请假起止时间、请假事由、请假申请的状态
前置条件	无
结束状况	可以显示以往审批的具体情况，系统数据不会发生变化。
说明	无

 

表5.16 副总经理查看需要审批的申请用例表

编号	13.1	名称	查看需要审批的申请
执行者	副总经理	优先级	高        低
描述	与用例11.1类似，但有以下区别： 1.     需副总经理审批的是状态为“部门经理已审批”的请假申请。 2.     请假申请列表还需要显示部门经理的审批意见。 3.     查看某个具体的申请时，还需显示部门经理的审批意见
前置条件	无
结束状况	系统的数据不会发生变化
说明	无

管理员的用例

    通过该用例图可以了解该子系统的功能与管理员要完成的工作。

图5.5 管理员的用例图

其他功能性需求

表5.17 其他功能性需求表

 

邮件触发者	邮件触发事件	邮件接收者	邮件内容
普通员工	提出请假申请	需审批该申请的部门经理	告知需审批某申请，并给出该请假申请的审批连接
普通员工	删除已经批准的请假申请	已经批准该申请的领导。如果已经有多个领导批准，则每个领导都应收到邮件通知	告知某申请已经删除，并给出已删除的申请的连接
部门经理	批准请假申请	申请者 副总经理	发给申请者的邮件：并告知申请已被部门经理批准，并给出申请的链接。发给副总经理的邮件：请副总经理审批申请，并给出审批链接。
部门经理	拒绝请假申请	申请者	告知申请已被部门经理拒绝，并给出相应的链接
副总经理	批准请假申请	申请者 总经理（有需要的话）	发给申请者的邮件：告知申请已被副总经理批准，并给出申请的链接。发给总经理的链接：请总经理审批申请，并给出审批链接。
副总经理	拒绝请假申请	申请者 部门经理	告知申请已被副总经理拒绝，并给出相应的链接。
总经理	批准请假申请	申请者	告知申请已被总经理拒绝，并给出相应的链接。
总经理	拒绝请假申请	申请者 部门经理 副总经理	告知申请已被总经理拒绝，并给出相应的链接。
…..	…….	…….	…….

非功能性需求

    非功能性需求是指除功能性需求以外的所有需求，一般是指系统需求，部署环境需求，安全需求，性能需求。

部署环境需求

    部署环境一般是指客户所在公司或者部门的IT环境，电脑系统环境，与该软件相关的构件。

图6.1 系统部署图

接口需求

    1、考勤系统客户端和WEB服务器

        其传递参数可以为用户对象和请假对象，外出对象。

 

    2、考勤系统和邮件服务器

        传递用户对象

 

    3、WEB服务器和数据库服务器

        传递用户对象，请假对象，外出对象，这些对象在存入数据库时需要解封装，从数据库获得时需要封装成相应对象。

 

    4、WEB服务器和打卡机PC

        对象数据

 

    5、打开机PC和打卡机

        打卡人编号，打卡时间

安全性需求

    该系统对安全性需求不高，能保证数据不丢失则行。

性能需求

    该系统应该能同时承载100人并发操作，用户操作的响应时间不应该超过1s。

界面需求

    界面设计应该简洁易懂，该部分需求应该不断优化，直至符合用户习惯。

附录

    此附录列出的是团队中每个人所提供的原始材料。

资料名称	提供者	获取日期	说明
简介及其相关定义	XXX	2016.1.6	系统简介及其约束
目标、涉众和范围	XXX	2016.1.6	系统参与者和成功标准
业务资料	XXX	2016.1.6	系统参与者及其相关属性
业务流程资料	XXX	2016.1.6	系统活动流程
功能性需求资料	XXX	2016.1.6	系统所能实现的功能
非功能性需求	XXX	2016.1.6	系统环境架构和性能需求
文档整理资料	XXX	2016.1.6	文档排版、整理

文档下载：http://download.csdn.net/detail/q547550831/9393872