需求规格说明书草稿.doc

模块名称如：机票文件版/次1.0生效日期YYYY-MM-DD总页数21上海*公司 需求规格说明书 模块名称编写： 本文档模板为双面打印设计，请采用双面打印请保护环境，注意纸张的回收利用*公司需求规格说明书页码：5/22正文目录1修改说明72项目概述82.1项目背景82.2项目愿景82.3项目目标82.4项目干系人82.5约束条件82.5.1需求限制条件82.5.2设计的约束92.5.3相关模块约束此部分放在设计考虑还是放在需求考虑有待斟酌92.6相关事实（可省略）93相关业务说明93.1组织结构及职责说明93.2业务详述113.2.1业务目标113.2.2业务用例113.2.3业务流程说明113.2.4业务状态说明133.3业务实体说明143.3.1业务实体图143.3.2业务实体说明143.4待解决的问题143.5业务解决方案154系统功能需求说明154.1系统边界（可省略）154.2系统功能结构154.3用例模型概述164.4用例清单175用例详细描述175.1用例名称175.2预控措施维护186非功能性需求206.1系统接口需求206.1.1用户界面206.1.2硬件接口206.1.3软件接口206.1.4通讯接口206.2系统性能需求206.3系统安全性206.4可靠性需求206.5可维护性需求216.6可移植性需求216.7数据存储需求216.8数据转入说明217产品组件需求列表218附件：228.1技术术语解释228.2附件：参考资料228.3附件：需求承诺22模板版次：3.0第 21 页 共 22 页图表目录图表 1-组织机构图10图表 2-业务流程图11图表 3-状态图12图表 4-业务实体图13图表 5-系统功能结构图15图表 6-预控措施维护界面18*公司需求规格说明书页码：21/22 1 修改说明日 期版 本 号修改类型修 改 摘 要修改链接用户对进度要求作 者2012/5/91.0初稿2012年2月底可运行张丽新增删除、修改内容描述变更1用例名称 修改删除2 项目概述2.1 项目背景该模块现状描述对手系统现状描述（可列举多个对手）对比分析：该模块现状优势、不足。对手系统现状优势、不足。2.2 项目愿景根据项目背景分析，希望给用户带来哪些利益？2.3 项目目标具体描述为实现项目愿景，系统需要实现哪些目标？2.4 项目干系人包括用户关键负责人、相关项目经理、需求分析师等人员信息，项目计划完成后可适合补充技术经理、开发、测试、美工人员信息项目角色：用户部门：姓名：电话：手机：邮件：负责内容：描述负责哪些功能模块项目角色：项目经理部门：姓名：电话：手机：邮件：负责内容：项目角色：需求分析师部门：姓名：电话：手机：邮件：负责内容：2.5 约束条件2.5.1 需求限制条件系统运行环境、是否存在与其他系统接口、硬件约束等信息2.5.2 设计的约束如报表格式、数据保留字段要求等信息2.5.3 相关模块约束此部分放在设计考虑还是放在需求考虑有待斟酌对其他相关模块可能造成的影响2.6 相关事实（可省略）补充说明，双方的一些相关义务，便于项目更好的开展1、 由用户方提供服务器，由于服务器的提供会影响产品上线时间，要求用户在上线前准备好服务器，避免不必要的工期延误。2、 在系统上线前，需要进行一次性的数据初始化工作。第一次的初始化数据由我方进行维护工作，用户方需将初始化数据及时提供给我方。之后的数据维护、录入工作由用户方自己完成。3、 系统上线前，我方将组织用户方进行一次集中培训，并将用户手册交付用户方。3 相关业务说明3.1 组织结构及职责说明模块使用人的组织机构图如：图表 1-组织机构图描述模块使用人所属部门，主要职责签发人、负责人所在部门为运行部、照明公司各班组，主要负责作业内容如下：签发人： 根据上海市路灯管理中心工作票使用和填写规定（试行）中的规定，在工作票中录入负责人、许可人、危险点、采取措施等相关内容。 检查负责人提交的工作票，并盖上合格或者不合格章后存档保存一年。负责人： 根据上海市路灯管理中心工作票使用和填写规定（试行）中的规定，完善签发人填写的工作票中的相关内容。 工作票执行完毕后，工作负责人对工作票审核后盖上已执行章并交还工作票签发人。管理人员所在部门为安监部，主要负责工作如下： 检查从各班组收集的工作票是否存在问题，并将存在问题反馈给相关人员，以不断改进施工安全性，提高工作票执行的合格率。 3.2 业务详述3.2.1 业务目标描述本系统希望实现哪些业务目标3.2.2 业务用例识别业务用例，描述业务用例的目标3.2.3 业务流程说明图表 2-业务流程图节点名称描述角色输入输出对应系统系统功能描述下达任务下达工作任务计划部无无无目前无，以后在系统外执行。开工作票根据上海市路灯管理中心工作票使用和填写规定（试行）中的规定，在工作票中录入负责人、许可人、危险点、采取措施等相关内容。签发人工作票工作票无目前无，将在此系统中实现。3.2.4 业务状态说明图表 3-状态图3.3 业务实体说明3.3.1 业务实体图图表 4-业务实体图3.3.2 业务实体说明3.3.2.1 实体名称（英文名）中文名称英文名称字段类型是否主键业务主键字段描述主键PRODUCT_INFO_IDBIGINT是产品名称PRODUCT_NAMEVARCHAR(100)3.4 待解决的问题主要存在问题的描述在日常工作中经常会发生开出的工作票由于作业内容发生突然变化或填写有误等原因而被随便篡改，以致班组保存的工作票与安监部最初获取的工作票存在不一致的问题。另外纸质凭证存在保存问题，提交的工作票经常存在破损现象。这样的管理方式造成了职责追究的难度，加大了工作票管理人员的管理难度，统计难度。3.5 业务解决方案根据问题，提出解决方案通过系统对日常工作票中关键信息的保存，并通过状态控制，控制已存档的工作票无法再被修改，解决了工作票在提交给安监部后仍旧可随便篡改和纸质工作票破损后无法查看填写内容的问题。另外系统通过作业内容与危险点、预控措施的关联方式，方便工作人员通过选择方式填写工作票，减少了工作票填写时的工作量。4 系统功能需求说明4.1 系统边界（可省略）确定哪些内容包括在本次实现范围内，哪些内容不包括在本次实现范围内。本系统只实现业务环节中的开工作票、工作票检查两个环节。对于开工作票环节只记录危险点、预控措施等需打印在工作票上的关键字段信息。对于工作票信息完善、执行盖章、检查盖章、问题反馈等业务环节在系统中不做实现，只在系统外执行。在开工作票时，如果工作票未存档，录入人员可随时修改、删除工作票。一旦存档则不允许对此工作票做修改、删除操作。系统中不对工作票做变更、报废等操作，一旦存档即使是错票、报废票也将一直保留在系统中不做任何更正。对于工作票的检查可通过工作票查询模块实现，但工作票统计结果不记录在系统中。4.2 系统功能结构与系统菜单相对应图表 5-系统功能结构图4.3 用例模型概述4.4 用例清单用例包次级包用例编号用例名称优先级别用户期望完成时间信息维护5.1预控措施维护低信息维护5.2危险点、预控信息维护低工作票管理5.3工作票、预控卡登记高第一种工作票5.3工作票、预控卡登记高第二种工作票5.3工作票、预控卡登记高5 用例详细描述5.1 用例名称编号：级别：用例目标： 主角： 前置条件：触发事件： 主成功场景：扩展：发生频率： 业务规则及算法说明：非功能需求： 其他说明：页面原型：如果程序已进行开发，而需求发生了变化，请不要在原用例上做修改，请参照以下做法：1、 可将原用例复制到其下方，并对复制的用例进行修改。2、 需求变化部分用红色字体凸显出。3、 将其标题设为此用例的子标题，并列出变更次数。4、 在1修改说明中加入变更标题的链接。变更1用例名称编号：级别：用例目标： 主角： 前置条件：触发事件： 主成功场景：扩展：发生频率： 业务规则及算法说明：非功能需求： 其他说明：主要变更内容说明：页面原型：5.2 预控措施维护编号：级别：用例目标： 通过录入方式或Excel导入方式将预控措施基本信息维护到系统中。主角：工作票管理人员 前置条件：无触发事件：无主成功场景：(1) 新增：1. 点击“新增”按钮，在列表中新增一栏。2. 用户在新增列表中录入详细信息，并点击“保存”按钮。3. 系统保存新增信息。(2) 编辑：1. 用户直接在列表中修改某记录，并点击“保存”按钮。2. 系统保存修改信息。(3) 删除：1. 用户选择单条或多条记录，并点击“删除”按钮。2. 系统提示用户“确认删除选中记录？”3. 用户点击“确认”，系统删除选中记录。(4) 导入：1. 用户点击“导入”，系统弹出导入界面。2. 用户选择导入文件，点击“确定”。3. 系统将预控措施信息导入系统。(5) 模糊查询：1. 用户在列表第二行的相应列中输入查询信息，点击回车。2. 系统以模糊查询方式显示与查询信息匹配的信息在其下。扩展：3a、删除操作中，如果选中记录已与危险点记录绑定，则不允许删除，并提示用户“选中的记录已被使用，无法进行删除操作。”3b、删除时支持全选功能。4a、导入时不做唯一性判断，用户可将所有记录删除后再导入。发生频率：一般业务规则及算法说明：非功能需求：无 其他说明：页面原型：图表 6-预控措施维护界面 6 非功能性需求6.1 系统接口需求6.1.1 用户界面描述用户对界面要求，如：风格、颜色、按钮位置等类似CS的界面风格，更符合人性化的操作方式。6.1.2 硬件接口无硬件接口6.1.3 软件接口无软件接口6.1.4 通讯接口无通讯接口6.2 系统性能需求根据实际情况描述(1) 时间特性 要求操作界面切换的响应时间一般在3秒以内。如果由于查询、报表导入导出等功能数据量过大或计算过于复杂，而响应时间较长时，应提供等待框或进度条等良好的交互方式。一般常规数据查询响应时间控制在10s以内；模糊查询响应时间控制在15秒以内。(2) 灵活性 设计时采用松耦合的方式，当操作方式、运行环境、精度、计划发生变化时，当构成应用程序的各个服务的内部结构和实现不断发生变化时，可以做到随需应变，可以尽量方便地用来集成、复用、组装。避免接口中增加额外的耦合性，造成接口的适用范围降低。6.3 系统安全性根据实际情况描述在业务处理中，配置角色及审核是普遍采用的最有效的安全性机制，它可以保证系统的合法用户能完成他们应该从事的工作，同时又可以限制他们权限的滥用。通过审核，企业可以跟踪用户的活动，从而保证安全性安全运行。6.4 可靠性需求 根据实际情况描述除了系统的硬件需要具备必要的稳定性外，系统需要提供较强的故障监测能力和故障处理能力。正式上线后主机系统故障停机时间小于4小时每100天每服务器（可靠率99.83%）。正式上线后客户端功能故障不可用时间小于4小时每100天（可靠率99.83%）。6.5 可维护性需求根据实际情况描述提供基于网络的可视化的配置与维护管理界面，能进行集中的系统配置，支持下列配置项目：1） 启动和停止应用服务；2） 监视服务器的健康状况和性能情况；3） 监视应用的性能情况；4） 实现查看服务器日志；5） 配置应用服务器；6） 提供对数据库、应用服务器等关键组件进行性能优化的手段；7） 提供关键数据与文档备份手段；6.6 可移植性需求根据实际情况描述 采用Java语言开发，提供了一种简单的可移植方式，可将程序移植到任何操作系统，运行时都将产生同样的结果。6.7 数据存储需求 根据实际情况描述数据库采用物理备份和逻辑备份并存。通过备份方法，即使计算机发生故障，如介质损坏、软件系统异常等情况时，可以通过备份进行不同程度的恢复，使数据库系统尽快恢复到