精华内容
下载资源
问答
  • 租房管理系统需求分析
    千次阅读
    2020-10-22 12:56:47

    一、项目前景和范围

    1.项目前景

    我们小组选择的项目是租房管理系统。该项目主要是解决房屋管理,对于房屋出租者来说,大量复杂的房产、租金、合同信息难于通过传统的方法进行管理;对于租房者来说,大量复杂的房产信息使他们感到迷茫。房屋出租管理系统正是钟对上述的问题而开发的,通过计算机系统来管理房屋出租情况,可以解决大量房产信息的查询和管理,便于更好的进行物业管理,同时也为租房者提供方便。

    2.项目范围

    普通用户

    用户能够找到卫生干净的房子,同时能够解决预算问题

    房东

    希望自己的房子能多多租出去,并且收益能最大化

    3.问题域

    P1:合同问题
    无论是什么房,必须要签合同。市面上存在部分不签合同的房源,像是旧街民房、二房东房源、城中村房源等,这些房子会便宜一些,而有些房东也懒得弄合同了,直接要求租客给钱,不办理任何手续。

    大量存在黑市黑市就是很多的房主并没有经过房屋管理部门的允许,也没有进行登记注册,就进行房屋租赁活动。这样的地下租赁大量存在,并且管理人员也很难察觉。有些地方这样的黑市远远超过了公开租赁的房屋市场,严重影响了房屋租赁市场的正常运行。这些隐形租赁的户主主要是为了利益不去房屋租赁管理部门登记,租赁房子的人也主要为了方便和省一些钱,这就给隐形房屋租赁提供了存在的条件。由于这些租赁并没有公开,租赁双方也没有签订什么合约,只是口头上的约定。这些都都给管理部门的管理造成了很大的困难,并且在后来出现纠纷的时候,也没有任何凭据

    P2:预算问题
    预算不单单指房租,还有水电费、WiFi费、物业费、燃气费等。所以看房时,除了要问房租与押金外,还要问清楚其余费用的明细,然后再综合比较各个房源之间的性价比。

    对于刚毕业的应届大学生而言,1/3法则(房租/工资)或许是错误的,因为工资低、预算低,真的很难租到满意的房子,房租占据工资一半甚至更多都很有可能。

    4.硬数据采样

    数据的概况与分析
    1、户型分布
    在这里插入图片描述
    租房区域的分布

    租金和单价的分布
    在这里插入图片描述
    通过分析之后得到,租房市场中,比较适合刚毕业不久的学生的房子类型是精装小户型,这样的房子,主要分布在天河、白云、荔湾、海珠,在海珠和天河的该房类型一般为城中村房,相对来说,天河和海珠的居住条件差了些,但好在交通便利,如果不能接受居住条件差一些的,那就需要去到白云和荔湾区区找了,好在现在地铁也有,交通也不算不方便,只是在路上会耽搁一些时间。

    二、涉众分析

    为了房屋管理者更好地管理房屋的合同、租金等一系列问题,也为了让租房者更方便地了解待租房屋的情况。

    租客:选择装修风格,浏览房源,与房东签订合同
    房东:提供房子及装修风格,与租客签订合同
    需求分析员:负责编写需求并传递给开发团队;
    开发人员:设计、实现和维护产品;
    测试人员:确定产品的行为是否与预期的一致;
    文档编制人员:负责编写用户手册,培训资料和系统帮助;
    项目经理:制定项目计划并带领开发人员获得成功;
    法律人员:确保房源负责所有相关法规;
    一个简单的表格是这么创建的:

    涉众编号涉众名称涉众说明期望
    001租客大多数用户希望房子卫生,住的舒服,但对于刚毕业的应届大学生而言,因为工资低、预算低,真的很难租到满意的房子,房租占据工资一半甚至更多都很有可能。用户能够找到卫生干净的房子,同时能够解决预算问题
    002房东出租闲置的房子,但是因为房子老旧问题,不容易出租希望自己的房子能多多租出去,并且收益能最大化

    三、展开用户需求获取

    1.需求规格

    通过计算机网络将客户端与服务器的数据库相连,将从客户端得到的信息进行处理,实现租房查询,添加房子,计算统计,综合信息查询等子系统。以计算机成本核算为中心,实现租房业务的计算机自动化,为房东和装修公司降低成本、提高销售额、经营决策提供及时精确的依据。
    在客户端系统的功能实现上,可以分为以下几个部分:
    1.租客查询房屋信息
    2.租客选择装修风格并选择入住时间
    3.租房信息反映给房东
    5.房东查看房屋状态
    6.后台管理

    2.系统环境

    Windows 10
    web应用

    3.用户需求

    房屋管理系统是一款集房屋租赁合同管理和各种物业收费管理于一身的综合性专业管理软件。系统包含房屋租赁合同管理、租金管理、押金管理、统计报表、系统管理、房屋管理、业主信息、客户管理、租金提醒、合同提示等功能于一体的房屋租赁管理单位日常工作解决方案,实现了出租、收款、统计、提醒等功能的完美结合。

    租客需求模块:
    主要包括登录系统,信息完善,浏览房源,租赁合同管理,我的租房,退房等模块。

    (1)登录系统:以用户名和密码登录系统,如果没有注册,则先去注册再登录。

    (2)信息完善:如果确定要租房,则需要完善信息,如姓名,性别,电话号码等信息,以方便系统管理员和房东联系。

    (3)浏览房源:用户可以查看房屋的出租情况,价格查询,房屋配置,还有日常收费项目(如:收水、电、卫生费等)

    (4)租赁合同管理:本功能模块包括合同终止、合同删除,合同档案按指定条件列示,打印等功能
    1.合同终止:将当前合同列表中选中的“生效”合同设置为已终止合同,合同终止后将不能被修改,合同中所出租的房源将自动设置状态为“未出租”。
    2.删除合同:删除当前合同列表中选中的合同 
    3.合同提醒:用于提醒用户即将到期的合同档案,以便于及时续签合同
    4.打印:系统为用户打印合同收据,作为使用房屋的使用权

    (5)我的租房:可以“我的租房”模块查看租房信息,如租房到期时间,租房地址,是否装修中等信息。如果要续租,也是在这里操作。

    (6)退房:租房期限到了之后,系统会提醒退房。如果是提前退房,则租金是否会退由用户自己与房东商量,本系统对此不负责任。
    需要注意的是,本系统的租房会在线下进行一份统一的合同签字,每个租房的租客都要在这份合同上签字,租房才会有效。所以系统就没有提供合同订单等内容。
    房东需求模块:

    主要包括登录系统,完善信息,上传房源,管理房源,财务管理等模块。

    (1)登录系统:以用户名和密码登录系统,如果没有注册,则先去注册再登录。

    (2)信息完善:如姓名,性别,电话号码等信息,以方便系统管理员和租客联系。

    (3)上传房源:房东上传自己房子的信息到系统,包括地址,出租价格,房子概述等信息,由后台管理员审核,审核通过即可上传到本系统,租客即可浏览。

    (4)管理房源:
    1、查看房源状态:如房子待住待装修、已入住、装修中、未住已装修等。未出租房子数量,已出租房子数量。租客信息。
    2、管理房源模块:房东可以为自己房子选择模块,如放入租客浏览的可定制化装修的房源模块,还是放入不可定制化的已装修房源模块,房东自行选择。
    3、添加或修改对出租房的简介。
    4、撤销房源:房东可以自行撤销还没出租的房源。
    5、定制出租价格:房东自行定制或修改出租的价钱。
    6、退房确认:租客租房到期或租客自行退房都要由房东确认。
    (5)财务管理
    1.押金收款历史档案:显示房屋出租押金的收入历史记录

    2.租金到期提醒 列示租金已到期的收租记录。进入界面后,如果有租金已到期的收租单,系统会显示在系统表格。

    4.项目的接口设计

    交互机制:用户登录我们的系统网站,将请求信息发给系统,系统查证完毕后,调用我们的接口,将查证信息结果反馈给用户。

    接口技术:MySQL管理系统,PHP脚本编程语言,HTML和CSS前端技术,JavaScript编程语言。

    四、参考文献

    需求工程——软件建模与分析(第2版)

    更多相关内容
  • 学生考勤管理系统 需求分析.DOC

    热门讨论 2011-05-24 09:28:06
    作为用户与该系统软件开发维护人员共同遵守的软件需求规范说明,本《软件需求说明书》的主要目的是明确所要开发的软件所应具有的功能、性能,使系统分析人员和软件设计人员能清楚地了解用户的需求,并在此基础上...
  • 考勤系统需求分析

    千次阅读 2019-06-27 16:11:45
    转 考勤管理系统需求文档 版权声明:...

    考勤管理系统需求文档

    版权声明:如需转载,请联系本人获取许可且必须注明出处,详见联系方式。
    https://blog.csdn.net/q547550831/article/details/50473972

    考勤管理系统需求文档

    简介

    背景

          某软件公司,员工人数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

    文档排版、整理




    展开全文
  • 一转眼,2020年的一半以上已经过去。每年这个时候,Adobe都会推出新版本,今年也不例外。日前,一套PS 2021内部测试安装包... Ps2021即将到来1配置要求高!有了更多的功能,配置自然会增加。首先是操作系统。PS 2021...

    一转眼,2020年的一半以上已经过去。每年这个时候,Adobe都会推出新版本,今年也不例外。日前,一套PS 2021内部测试安装包在网上流传。

    与之前的2020版相比,Adobe这次做了很多吸引眼球的作品,比如一键改变天空、智能修改表情、超级变焦、黑白电影的AI着色等等,那么实际效果如何呢

    让我们看看!

    406d27ff6ef310d49870be8eefccc456.png Ps2021即将到来

    1配置要求高!

    有了更多的功能,配置自然会增加。首先是操作系统。PS 2021要求计算机安装win10 x64版本,版本号大于1809(如果不清楚,可以打开“开始”菜单,键入“winver”查看)。

    其次,计算机的配置至少要合理。毕竟,2020年的版本已经很慢了,2021年的要求会更高。

    d96d5e46e63a01078e11036c455e953f.png

    Ps2021只能安装在win10系统上,版本号必须大于1809

    安装过程暂时没有列出。让我们来谈谈图标的新版本。与之前的PS不同,2021版将图标的背景色完全改为白色,再加上新的蓝色字体,使整个图标独树一帜。

    但可能和旧版不同,在日常使用中还是给我带来了一些麻烦……程序通常是“找不到”。

    2d15a58560e5f12135683074804845de.png 新旧图标对比(左:2021年,右:2020年)

    开机画面也进行了调整,由之前的准实物风转为卡通风。当然,这只是测试版的外观。官方版本是否会改变,目前还不得而知。设计毕竟是一个大循环。如果今年不流行,过几年还会再流行一次!

    bf4ce8b2ec691faab2caaaae3ecdf94d.png

    展开全文
  • 网上书店系统需求分析说明书

    万次阅读 多人点赞 2020-12-19 22:53:16
    网上书店系统需求分析说明书 项目组组长:丘佩茵 组员:林其庚、罗猛 1. 综述 1.1前言 传统的书店受时间和空间的限制,导致不能发挥更大的商业价值,所以网上书店已经成为了传统书店必须的经营路线之一。如何更好的...

    网上书店系统需求分析说明书
    项目组组长:
    组员:

    1. 综述

    1.1前言

    传统的书店受时间和空间的限制,导致不能发挥更大的商业价值,所以网上书店已经成为了传统书店必须的经营路线之一。如何更好的对网络书店进行管理已经成为了必不可少的关键部分,而优良的管理离不开优良的管理系统。本管理系统通过学习其他同类型的系统,总结出了更好的设计模式和优化了的系统设计,更加的简洁明了,不仅提供方便了管理人员的操作页面,也提供了方便各年龄层使用的系统提供的界面。
    系统提供了图书出入库管理功能、客户管理功能、基于大数据给网站用户的分类推荐功能、网站在线交易功能、图书预览功能,用户、管理员交互界面等多种基本功能,含盖了传统书店和一般网络书店的基本功能并有新的优化和新的功能,使用起来更加得心应手。

    1.2项目目的

    在移动互联网的普及下,网上书店可以让众多读者更加方便的寻找到自己所需要的书籍,可以随时查阅、购买,更加便捷和快速,而且网上书店可以为读者节约大量时间,网上书店具有良好的发展潜力,可以为书店和读者带来双赢的局面,制作出合适管理员管理和用户交互感良好的网上书店系统。

    1.3项目背景以及发展趋势

    背景:
    在当今社会,全民素质和科学技术的不断提高下,知识更新的越来越快,人们此时更加迫切的需要学习知识。人们由于种种原因难以到书店挑选自己想买的书,并且有可能有些书店没有他们想要的书,便要跑多家书店,这极大的浪费了时间,因此传统书店在网络浪潮的冲击下,销售量低迷,所以网络书店的建立已经成为了传统书店的一种销售路线。网络书店不仅克服了传统书店抓不住不同用户对图书喜好不同而导致的书目订货的盲目性和局限性,还客服了订单管理难的不足,而且网上交易方便易管理。用户购买图书在一家店买不到时,换另一家店点点鼠标即可完成,极大的节省了时间。因此网上书店很有前景。

    发展趋势:
    当今社会逐渐数字化的趋势下,无纸化阅读将会是读者群体的首选,不仅是处于环保还是出于资金方面,书店也将从出售实体书慢慢转换为电子书。中国人均读书时间逐年递增,人们对知识的需求有增无减,在网络发展迅速的现在,网上书店极具发展潜力。

    2. 任务概述

    2.1市场定位分析

    网上书店商务网站构建目标主要是面向广大消费者。由于图书消费属于知识型消费类,人们求知欲望没有阶层与年龄差别,因而书店网站应在具有自己特色的同时应适合不同人士的需要。因此,网上书店网站定位于面向广大消费者。(对新兴事物接受度普遍较高的客户群体)

    2.2系统设计的特点

    (1)简单。用户可以在本系统实现从看到买的一体化购物方式。
    (2)美观。简洁的操作界面,没有冗余的网站设计。
    (3)便捷。统一、集中管理终端,保护用户财产、信息不受威胁。
    (4)稳定。系统拥有自主知识产权,充分满足国内用户本地化需求。
    (5)干净。无任何具有广告推广性质的弹窗和捆绑等打扰用户行为。
    (6)基于大数据,精准用户标签 助用户完成品效合一的投放目标。

    2.3结构规划

    网上书店系统分为前台、后台两大模块。总体结构如下:
    在这里插入图片描述
    在这里插入图片描述

    2.4系统数据规划

    创建了一个名为BookSell的数据库用来保存本系统的所有数据。该数据库包含5张表:用户表Users、管理员表Managers、留言管理表Massages、订单表Orders、图书信息表Books。

    用户表Users用来保存用户信息,结构如下:
    Users:
    在这里插入图片描述

    管理员表Managers用来保存管理员信息,结构如下:
    在这里插入图片描述

    留言管理表Massages用来保存留言,结构如下:
    在这里插入图片描述

    订单表Orders用来保存订单信息,结构如下:
    在这里插入图片描述

    图书信息表Books用来保存图书信息,结构如下:
    在这里插入图片描述

    3. 系统分析

    3.1总体需求

    1、建立对图书提供能够全面的管理新消息系统;
    2、对所有的图书、用户提供全面管理;
    3、对图书详细信息提供全面管理。

    3.2功能需求

    网上书店系统是一个典型的JSP数据库开发应用程序,由前台、后台两部分组成。

    3.2.1前台:

    该部分主要包括用户管理、订购服务、图书浏览等功能。
    在这里插入图片描述

    3.2.2后台:

    该部分主要对商城内的一些基础数据进行有效管理,包括网站维护、管理用户、图书管理、留言管理、订单管理等。
    网上书店系统层次图:
    在这里插入图片描述
    后台管理员操作用例关系图
    在这里插入图片描述

    3.3性能需求

    为了保证系统能够长期、安全、稳定、可靠、高效的运行,网上书店系统应该满足一下性能需求:
    (1)系统处理的准确性和及时性
    系统处理的准时性和及时性是系统的必要性能。在系统设计和开发过程中,要充分考虑系统当前和将来可能承受的工作量,使系统的处理能力和响应时间能够满足大多数客户对信息处理的需求。
    (2)系统的开放性和系统的可扩充性
    网上书店系统在开发过程中,应该充分考虑以后的可扩充性。例如用户查询的需求也会不断的更新和完善,都要求系统提供足够的功能的调整和扩充。而要实现这一点,应该通过系统的开放性来完成,即系统应该是一个开放系统,只要符合一定的规范,可以简单的加入或减少系统的模块。
    (3)系统的易用性和易维护性
    网上书店系统是直接面对使用人员的,而使用人员往往对计算机并不是非常熟悉。这就要求系统能够提供良好的用户接口,易用的人机交互界面。要实现这一点,就要求系统应该尽量使用用户熟悉的术语和中文信息的界面。
    (4)系统的标准性
    系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。所有这些都要符合国家和行业标准。

    3.4系统技术可行性分析

    功能 :对书店的图书信息和用户(书店工作人员,网站注册用户即潜在购书者)信息的进行有效的管理;对图书的进存销等环节进行信息化管理;实现读者网上浏览图书,网上购书的可能;处理用户网上的投诉和建议。

    性能:数据库的录入;图书检索;用户信息查询;图书信息查询;网上购书;

    安全与保密要求 :书店中所有的图书能够供用户随时查阅;用户的个人信息可以由用户自己修改,添加;书店图书的信息只能由书店管理人员添加,修改;所有注册用户信息只能由书店管理人员查询。

    操作系统 :Windows,Linux/Unix及任何能运行Java虚拟机的平台;
    Java Runtime Environment :version6.0以上。
    Web Server:Tomcat 6.0以上。
    操作系统 :任何pc平台;
    浏览器 :Internet Explorer,Google Chrome等。

    决定可行性的主要因素:
    技术因素、硬件因素、软件因素、经济因素、团队合作精神等。
    对现有系统的分析 (缺乏原型系统)
    处理流程和数据流程 :暂时不考虑
    工作负荷 :暂时不考虑
    费用支出:如人力、设备、空间、支持性服务、材料等项开支 :暂时不考虑
    人员:列出所需人员的专业技术类别和数量 :暂时不考虑
    设备 :暂时不考虑
    局限性:暂时不考虑

    4. 运行需求

    4.1用户界面

    用户界面应具备以下功能:
    (1)用户注册、登录、修改:新用户需要注册成为会员,老用户直接登录,然后可轻松查看自己的信息并进行修改。
    (2)图书搜索栏:若用户已有自己想买的书可方便直接查找。
    (3)图书推荐:根据用户喜好定期推送相关书籍。
    (4)图书种类分类栏:把图书分门别类进行排序,方便用户根据喜好进行选择购买。
    (5)图书预浏览:可以试读一些章节以便读者选择心仪的图书。
    (6)购物车:用户可将喜欢的书放入购物车进行下单的处理。

    4.2管理员界面

    管理员界面应具备以下功能:
    (1)图书上新下架管理:对新入库的图书进行上新,对已售罄或销售低迷的图书下架。
    (2)图书出入库处理:把新入库的图书数据存放到数据库中。
    (3)图书订单管理:对用户下单的图书进行订单处理。
    (4)网站公告、留言管理:对图书上新的广告和一般通告进行告示,处理读者的留言,
    方便获取读者的需求。
    (5)接受用户反馈管理:对已下单的用户进行服务。

    4.3故障处理

    根据系统的需求分析报告、项目负责人、软件分析人员以及编程人员对系统进行检查、维护,和整修。

    5. 系统管理流程及模块功能分析

    5.1网上书店管理系统的整体规划

    网上书店管理系统分为前台和后台两个管理系统。前台管理系统分为图书浏览检索子系统、购物车子系统和用户访问子系统以及留言子系统。后台管理系统分为图书管理、订单管理,留言管理和客户管理子系统。下图为前台和后台管理系统以及各个子系统之间的关系。
    在这里插入图片描述

    5.2网上书店前台销售管理系统的整体网页设计

    下图描述了客户从Internet上访问网站,完成浏览、购物、注册等过程所访问的网页的彼此关系。
    在这里插入图片描述

    5.3各个子系统模块的功能

    网上书店管理系统中,前后台管理系统的各个子系统功能如下:

    5.3.1用户注册登录子系统

    本系统采用用户名和密码相结合的验证方式,以用户登陆后直接进入前台操作界面(即用户专用界面);当验证登陆管理员页面操作时,则进入后台管理员专用页面,会对顾客信息保密的机制。要实现该模块功能,先要建立一个用户注册信息表,其包括以下字段:用户名、用户姓名、密码、地址、联系号码、邮箱。
    要实现功能,先建立JSP动态网页,插入相应字段,在建立另外一个JSP动态页面,接受前一个JSP页面的信息,当用户的信息输入信息错误时,则返回第一个注册页面,重新填入信息,待正确填写信息正确时,系统会自动弹出提示成功并跳转登录页面。
    在这里插入图片描述

    5.3.2图书浏览检索子系统

    主要是对不同种类的书信息分类的浏览可以对站内所售图书查询,查询可以通过书名,作者等内容进行精确查询。为此,要建立书籍管理系统,其包括以下字段:图书分类、书号、出版社、作者、页数、出版时间、价格、剩余数量、图书封面、简介。
    找到用户的书籍后,用户可以选择直接购买或者放入购物车内,未登录的用户会提示登录,登陆成功后可以查询订单,并确认购买。
    用户登陆后所查询到的图书可以直接放入购物车,未登陆系统的用户只可以查询图书,如果要放入购物车,则显示登陆页面,如果未注册的用户则显示注册页面。
    在这里插入图片描述

    5.3.3管理员子系统

    管理员登录子系统的功能,对图书进行增删改查、管理用户信息、查看留言并回复或删除留言、查看并确认订单以及更新物流信息。
    在这里插入图片描述

    5.3.4购物车子系统

    电子商务站点的核心就是购物车。用户登录后可在这个区域内建立他们的订单,只要选择各种自己需求的商品,并将它们添加到自己的预购信息中。也可以查看物流,数目查询,修改购物车,生成订单并付款后可以查看该订单的物流信息。
    在这里插入图片描述

    6. 特别说明

    6.1安全性

    保证管理者和注册用户的密码安全,分权限管理,数据库访问控制;管理员应具有一定网络安全及防黑知识。

    6.2可维护性

    网站管理者必须懂得一定的服务器应用、ACCESS数据库应用、硬件维护、IIS配置等方面的技能。

    6.3灵活性

    系统应该具有良好的功能可扩充性,以应对未来用户更高的要求。

    7. 总结

    电子商务是利用现代信息网络进行商务活动的一种先进手段,作为创新的经济运行方式,其影响已经远远超过了商业领域。为了跟上世界电子商务的发展潮流,缩短与发达国家之间的差距,每个人都应该从不同的角度积极了解电子商务、参与电子商务,尽快适应飞速发展的信息社会的需要。
    针对当前蓬勃发展的电子商务,本文从理论和实践两个角度出发,利用Java技术以及数据库技术来架构新型电子商务平台。
    该系统虽然只是一个简单的小系统,但是在设计过程中让我学会了很多。会做一个系统前期中期后期各需要做什么,不仅提高了我们对专业知识的见解,还让我们更加了解了电子商务的优点。
    由于时间有限,以及软、硬件设施的配置等限制因素,这个系统还不同成熟,还有许多地方有待改进与完善;世界上电子商务的内涵、标准及技术也日新月异,处于不断地变化发展之中,将会不断有观点、技术和实践的创新与突破,需要我们加以学习和改进。

    展开全文
  • 人力资源管理系统需求分析说明书

    千次阅读 2021-02-18 16:17:09
    人力资源管理系统 需求分析说明书 组名 : K2 组员 : 罗猛、丘佩茵 2021年1月12日 目录 综述 2 1.1前言 2 1.2项目目的 2 1.3项目背景以及发展趋势 2 任务概述 2 2.1市场定位分析 2 2.2系统设计的特点 2 2.3结构...
  • 那么这个应用对windows的需求是啥呢? 以下是在我之前的windows企业版(以下简称旧版windows)的测试: 1、查看windows系统的内部版本号如下: -a.按住键盘上的“开始键+R键”,然后在弹出的对话框中输入“CMD...
  • 基于校园图书管理系统需求分析

    千次阅读 2021-04-05 20:37:26
    基于校园图书管理系统需求分析   基于校园图书管理系统的建设是满足图书管理者对用户的管理以及对图书的借阅、归还等提供便捷的管理方式,同时也能方便广大用户以线上方式对馆内图书进行借阅、归还、续借、查询等...
  • 酒店管理系统需求分析

    千次阅读 2021-06-03 18:41:07
    一、系统概述 1.1背景 随着计算机技术的飞速发展,信息时代的到来,信息改变了我们社会,各类行业在日常经营管理方面也悄悄的走向规范化和网络化,酒店业作为一个前景广阔同时又竞争激烈的行业,它的内容对于经营的...
  • 在线考试系统需求分析

    千次阅读 2017-02-02 18:19:29
    在线考试系统能够很大程度上提高标准化测试的测试效率。但目前没有便于使用的考试系统,已有在线考试系统需要注册或联网使用,不能在网域网内直接使用。 2开发目标 此次开发的目标是实现一个局域网内能够使用的、...
  • 医院信息管理系统需求分析

    万次阅读 多人点赞 2019-10-04 01:44:22
    需求说明文档描述了医院管理系统项目的要求,作为系统设计、项目目标以及项目验收的依据。需求分析详细描述了用户对功能的需求、对性能的需求以及对运行环境的需求。 软件开发小组的每位成员应该阅读本需求说明,...
  • 成绩管理系统需求说明书

    千次阅读 2019-05-28 18:05:32
    成绩管理系统需求说明书 1 引言 1.1目的 首先给出了整个系统的整体网络结构和功能结构的概貌,试图从总体架构上给出整个系统的轮廓,然后又对功能需求、性能需求和其它非功能性需求进行了详细的描述。其中对功能...
  • XX大学学生选课系统需求规格说明书

    万次阅读 多人点赞 2019-04-09 20:30:19
    该文档是关于用户对于河北经贸大学学生选课系统的功能和性能的要求, 重点描述了选课 系统的功能需求 系统的主要目的是为了方便学校对教师信息、学生基本信息、课程信息、学生成绩录入、修改、查询,提高学校的工作...
  • 学生学籍管理系统需求规格说明书

    千次阅读 多人点赞 2020-05-07 18:37:34
    需求分析是软件系统生存期中定义阶段的最后一个步骤,是作为整个软件开发范围的指南,是软件开发人员开发出正确的符合用户要求的软件的重点;是为了明确软件需求、安排项目规划与进度、组织软件开发与测试;该说明书...
  • 系统需求分析 1.可行性分析 本次可行性分析是按照规范步骤进行,即按复查项目目标和规模,研究本系统,导出新系统的高层逻辑模型,重新定义问题这一循环反复的过程进行。然后提出系统的实现方案,推荐最佳方案进行...
  • 网上商城系统需求分析报告,内容很具体,完成是按照软件工程上面的需求分析报告要求设计的,很实用
  • 展开用户需求获取 2 问题域 2 涉众 3 项目系统环境 3 三、需求获取 3 硬数据采样 3 用户需求 4 项目目标 5 系统功能范围 5 四、需求分析 6 涉众分析 6 系统前景与范围 6 五、附录 7 一、引言 ...
  • 火车票售票系统需求分析

    千次阅读 2018-12-16 12:18:00
    火车票售票系统 需求分析报告 1.引言 (1)1.1编写目的 (1)1.2项目背景 (2)1.3定义 (2)1.4参考资料 (2)2.任务概述 (2)2.1目标 (2)2.2运行环境 (3)2.3条件与限制 (3)3.数据描述 (3)3.1静态数据 (3)3.2动态数据 (3)3.3...
  • 一卡通管理系统需求分析

    千次阅读 2018-10-28 19:31:01
    一卡通管理系统需求分析 业务需求 1.业务目的:将校园的各类消费与身份认证功能集成在一卡通,实现“一卡在手,走遍校园”。为在校的师生和教学管理人员提供具有开放性的、灵活性的管理平台。 2.业务目标:实现...
  • 学生管理系统需求分析

    万次阅读 多人点赞 2019-10-05 10:22:49
    本文档描述了学生管理系统的功能和性能的要求,将作为对该项目在概要设计阶段的设计输入。 本文档的预期读者包括: 设计开发人员 项目管理人员 测试人员 用户 1.2 项目范围 该文档的目的是解决整个项目系统中“做...
  • 博途V16 (提取V16百度云下载链接)TIA Portal v16 Adv简称博途v16终极版,是一款由西门子打造的全集成自动化编程软件,多用于PLC编程与仿真操作,新版本增强了性能,提高了兼容性,完美支持windows10操作系统,...
  • 需求分析——系统需求和软件需求

    万次阅读 2019-05-26 07:53:27
    系统需求:是指为了完成既定目标而相互协作的构建集合,包括硬件、软件、人员、信息、技术、设施、服务、其它支持构件。系统需求是把系统作为一个整体进行描述。 软件需求:是由系统需导出,系统需求也被称为用户...
  • 本篇我们介绍图书管理系统需求分析和系统设计 目录 系统分析: 背景和意义 可行性分析 需求分析 1.功能需求 2.性能需求 3.软件质量要求 4.灵活性 系统设计 系统总体设计 系统数据库设计 数据库概述 ...
  • 系统需求分析示例

    千次阅读 2019-06-18 19:12:08
    系统软件非功能性需求分析 1存储容量两年内最大100TB,主要为图纸文档之类的非结构化的资源数据。 2并发性指标:QPS峰值10万,平时5千左右 3高可用性要求,需要有异地灾备系统。保证在系统故障发生时,可以实时切换到...
  • 库存管理系统需求分析说明书

    热门讨论 2010-04-18 13:21:17
    课程实验共分为“项目启动、需求获取、需求分析与建模、需求规格说明与验证”四个阶段,每个阶段要求产生一个文档: 项目启动阶段产生“客户需求清单”文档; 需求获取阶段产生“需求获取结果”文档; 需求分析与...
  • 医院管理系统需求分析

    热门讨论 2006-07-25 00:00:00
    医院管理系统需求分析 一. 药库管理系统 系统 包括 重新登陆(责任追查)、修改密码、退出 数据维护包括药典维护(表)、供应商维护(表) 库房工作 包括药品入库...
  • ps cc 2018直装版系统要求

    千次阅读 2019-09-25 11:25:14
    pscc2018直装版系统要求 求具有 64 位支持的多核 Intel 处理器 macOS 版本 10.13 (High Sierra)、macOS 版本 10.12 (Sierra) 或 Mac OS X 版本 10.11 (El Capitan) 2 GB 或更大 RAM(推荐使用 8 GB) 安装需要 4 GB...
  • 考勤管理系统需求文档

    万次阅读 2016-01-07 09:30:36
    考勤管理系统需求文档 简介 背景  某软件公司,员工人数100人左右,大部分员工是软件研发人员,包括项目经理、软件设计师、程序员、测试工程师、实施工程师等,除此之外还包括行政人员、财务人员。公司在软件研发...
  • 餐厅点餐系统需求分析

    千次阅读 2019-05-07 15:00:00
    点餐系统需求分析 背景说明: 在现代社会中,餐饮业是一个永远不会衰败的行业,当由于受到空间大小影响,盈利几乎不会有太大提高,想要增加更多盈利就必须提高服务效率,同时带动消费效率的提高,这时就需要考虑一...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,936,652
精华内容 1,574,660
关键字:

系统需求

友情链接: 111161-10-张志涛.rar