软件修改需求书

软件修改需求书系统名称:功能模块名称功能组修改类别□字典修改口关联查询修改口审批或工作流程修改口增加文书□数据录入页面增加录入字段口页面显示字段名称修改□平台操作方式修改口系统提示功能口新增查询窗体□新增数据录入窗体口新增统计报表窗体修改意见提供单位涉及角色或岗位修改意见提供人修改意见提供人联系方式登陆用户名登陆口令修改内容简单描述修改需求说明:

填表说明系统名称：填写修改功能的系统名称（如接处警系统，执法监督系统等）功能名称：修改涉及的功能窗体（如接处警登记窗体）功能组名称：修改功能所在功能组（如刑事案件一案件侦查）修改类别：修改功能的分类，见附表一涉及角色或岗位：修改功能涉及的角色，人员，或单位（如派出所领导，法制民警等）修改意见提供单位：修改意见由何单位提供修改意见提供人：意见具体提供人修改意见提供人联系方式：联系电话，便于开发组直接与客户交流需求修改前功能或窗体描述，修改后功能或窗体描述：描述修改前后功能的区别，修改理由，修改后功能描述内容说明见附表一，说明举例见附件：案例说明处理意见：填写需求审核小组对该需求的评审意见，如果需求提出的不完整，功能不清晰，需写明需要补充内容，不予采纳的需求，需写明退回原因反馈给需求提出人。采纳的需求，写明处理办法，处理结果：项目组开发人员根据需求及处理意见，修改相应功能，并将修改结果填写，反馈给用户。修改内容附表：修改类别修改类别描述包含以下内容字典修改1、 描述新增字典的字典名称，字典项名称，字典项编码2、 如果字典中有分级的，写明字典所处分级位置3、 如果新增字典相关业务流程变动（如行政案件审批增加不予处理决定字典，呈请时该处理呈请不通过法制），需写明原有系统流程及修改后新系统流程4、 如果窗体中有字典的过滤条件，需写明该新增字典的过滤条件，即该字典在警员，案件状态，案件类别或其他信息满足何种条件时显示（分级字典中，分级过滤的可以不写）5、 如果子典属于省厅或部颁标准子典，需以word或excel文档方式提供字典详细列表关联查询修改（弹出窗体修改）1、如接处警台帐中增加关联查询案件信息，需写明以列表方式（如案件列表）、图表方式（如柱状图等）、详细信息方式（案件基本信息如）查询出什么信息，查询条件，查询字段列表等审批或工作流程修改1、 写明工作流程修改原因，2、 写明原先工作流程，修改后工作流程，最好以图表方式显示（简单流程可参照案例五中的写法，复杂流程以图形方式显示），并标明流程流向有没有判断条件（如某些措施需法制审核，某些措施不用法制审核，流程流向判断条件中需写明）3、 写明工作流程修改涉及窗体，涉及的部门或岗位数据录入页面增加录入字段4、写明增加字段的名称，字段的默认值，字段是否为必添项，原有系统中是否含有该字典1、增加字段涉及的字典

2、 字段录入前是否需要判断案件状态，时间或其他信息（如继续盘问呈请页面中增加决定时间字段，只有分局领导有权填写或修改）3、 对于修改的页面最好有截图进行说明页面显示字段名称修改1、 字段修改前名称，修改后名称2、 字段默认值是否需要修改，默认值生成条件，生成内容（如简要案情字段自动由发案时间，案由等字段自动合成）3、 字段是否允许手工修改系统提示功能1、 系统提示方式（短消息提示、弹出窗口提示，登陆桌面提示）2、 提示内容（写明提示的内容，内容为列表的写明显示字段，涉及窗体名称，在什么操作后提示）3、 提示条件（根据录入数据进行比对的结果，或操作中的错误提示等）平台使用方式修改1、 使用方式包含数据录入，查询，打印，报表查询的平台操作修改意见2、 需说明修改后希望达到的操作方式以及目前的操作方式，并适当举例，便于开发人员了解新增查询窗体1、 简项查询条件2、 数据来源（数据的出处以及默认的取数条件）3、 查询方式（包括列表查询、单条记录详细信息查询等信息）以及所包含的关联查询（如根据结果是否需要查询案件信息，措施审批记录或关联查询其他汇总统计结果等信息）新增数据录入窗体1、 需要录入的字段2、 哪些字段为必填字段3、 相关字段的字典过滤4、 不允许修改或自动填写数据的字段信息5、 是否需要图像采集增加文书1、 文书生成的窗体（如拘传证在拘传措施呈请窗体中生成）2、 文书生成条件（如拘留释放通知书生成前需检查嫌疑人是否已被拘留）3、 文书表样4、 法律文书的标题新增统计报表窗体1、 统计报表的表样2、 统计的单位范围和时间条件3、 数据行的展开方式（按字典项自动展开还是固定数据行数）注：表中红字为新增功能，包括增加窗体或在已有窗体中增加分页，新增功能必须写明功能名称，功能组名称，涉及的部门和岗位等条件，在已有窗体中增加分页的必须写明分页的显示条件需求调研过程1、 最终用户提交需求到公安局需求组；2、 需求组将最终用户所提需求分类：A、无效需求需在修改需求说明书处理意见中写明无效退回原因;B、 需重新补充内容需求在处理意见中写明需要补充的内容，返回用户，在补充内容完整后，形成有效需求；C、 有效需求在处理意见中写明软件的修改或处理方式，修改时间以及一些特殊说明，同时反馈给用户和开发组;；3、 用户对于无效需求，有效需求的处理意见如果同意的话，签字确认；4、 开发组对有效需求进行软件的修改及开发，并在修改完成后将修改结果填写进处理结果，交项目需求小组测试，并由最终用户对修改后功能进行确认；注意事项1、 需求调研时的，必须首先向最终使用用户了解清楚用户所提需求后希望达到的最终目的，如果不修改就能达到最终目的，可向最终使用用户说明（如用户提出案件基本信息中增加八类案件类别，如果最终目的是为了对八类案件进行统计分析，则系统中目前已经实现，不需要再增加类别字典）2、 需求评审时除对需求本身合理性进行评审外，还需要对需求涉及的其他几方面进行评审，包括：A、 需求是否符合省部级颁布的一些标准，如增删改字典；B、 涉及需求是否违反市级主管部门制定的统一规范，如办案流程的那个；C、 需求修改后是否会对其他业务的数据或统计结果产生影响；D、 需求修改后是否会降低系统使用效率；E、 需求是否涉及警务平台以外的其他系统数据；3、 需求不管被分类为有效需求还是无效需求，都要在处理意见中写明处理意见及处理原因。4、 对于需求合理，但是实现时由于数据完整性及系统效率方面的问题被归为无效需求的，可以向用户提出折中方案。需求有效性判定1、 是否描述清楚了需求修改后希望达到的最终目的2、 是否描述了系统所有涉及的输入，包括输入时间，窗体，涉及岗位，数据准确性、完整性判断，字典过滤条件等3、 是否描述了系统所有涉及的输出，包括取