需求规格说明标准规范.docx

XXX产品需求规格说明书文档编号产品名称：【博金贷APP】文件编号：博汇九洲-【博金贷APP】-PRD-V【1.0】版 本 号：【1.0】密 级： 内部公开 秘密 机密 绝密归属部门/项目：产品部所属阶段：【正在编撰】创 建 人：彭绍明创建日期：【2015.10.10】批 准 人：批准日期：【2015.10.10】文档变更版本号修订日期修订人修订摘要1.02015.10.10彭绍明退出账户提示，账户总览可视化界面，UI优化目 录 目录XXX产品需求规格说明书1文档编号1文档变更1目 录21.引言31.1 编写目的31.2参考资料31.3术语定义42.需求概述42.1产品描述42.2功能概要52.3用户特征62.4一般约束72.5实现语言83.功能详细需求83.1xx功能需求93.1.1简要说明93.1.2需求分析图93.1.3各用例说明133.1.4表单字段163.1.4领域模型（暂不用）173.1.5 UI界面174.外部接口需求174.1用户界面174.2硬件接口184.3软件接口184.4通信接口195.非功能性需求195.1性能需求195.1.1 静态数值需求195.1.2动态数值需求195.2设计约束205.2.1硬件限制205.2.2其他约束205.3属性205.3.1可使用性205.3.2安全性205.3.3可维护性215.3.4可移植性215.4其它需求215.4.1数据库215.4.2操作215.4.3故障处理216.数据需求226.1数据描述226.2数据采集226.2.1要求与范围226.2.2处理236.3数据词典237.附录231. 引言1.1 编写目的说明编写需求规格说明的主要目的。例：博金贷APP V1.0需求规格说明书，全面细致定义APP1.0产品目标、功能、性能、数据、故障及交互体验需求，为产品设计、开发、测试、用户交流提供标准依据。1.2参考资料列出下列资料的作者、标题、编号、发表日期和出版单位，必要时说明如何得到这些资料：a. 本项目经核准的计划任务书、合同和上级机关的批文；b. 项目开发计划；c. 本文档中引用的文件、资料，其中应包括软件开发规范。1.3术语定义列出本文档中用到的可能会引起混淆的专门术语和缩写词的原文。例：名称解释有效投资人指在平台账户有待收余额的投资人。年化投资额投资金额 *（投资期限/360) * 1%2. 需求概述本章描述软件产品的特性及影响其需求的一般因素。必须注意到：本章不罗列具体的需求，而仅设法使需求更加易于理解。2.1产品描述 a. 用一个名字标识要生产的软件产品。例如，宿主数据库管理系统、报表生成器等； b. 说明软件产品将干什么，如果需要的话，还要说明这个软件产品不干什么； c. 说明此软件产品的应用情况及开发意图，其中应当：尽可能精确地描述所有相关的利益、目的以及最终目标：如果有较高层次的规格说明存在（例如，已存在系统需求规格说明），则应使这里的陈述与高层次规格说明中的类似陈述一致； d. 列出开发项目的委托单位、承办单位及其主管部门； e. 如果被开发软件是独立的，则应在本节描述被开发软件的概况； f. 如果需求规格说明定义的软件是一个较大的系统或项目中的一个组成部门，那么本节应当：概述这个较大的系统或项目的每一个组成部分的功能，并标识其接口；标识被开发软件的主要外部接口。注意，这里仅仅是一个综述性的描述。 用图形表达一个较大的系统或项目的主要组成、相互联系和外部接口是非常直观的。 本节不应当具体的进行设计方案的描述，也不应当描述解决问题时的具体设计约束。本节应对在需求规格说明具体需求一章中列出的设计约束提出理由。例：博金贷APP V1.0是一个综合展示投资项目、进行在线投资、发布和参与在线活动、查询和管理投资账户、发布好友邀请的APP在线理财应用，PC、WAP与APP及各个环节之间数据能够共享。APP 需要开发Android手机 、ios手机版本，ipad版本，交互体验力求一致，iphone与ipad本力求版本合并，UI能自适应。1.0版本优先推出android手机版本。2.2功能概要 本节应简单叙述被开发软件的功能。例如，对于一个财务管理系统，需求规格说明可以在这节描述帐目维护、财务报表等的基本要求，而不必把为完成这些功能所要求的大量细节描写出来。有时本节内容可以直接从较高层次的规格说明中引用（如果存在）。为了清晰起见，要注意： a. 应当给出一个使用户、委托单位或者第一次读这个文档的人易理解的功能清单； b. 可以用图形表达不同的功能和它们之间的关系。但要注意，这样的图形不是产品设计时需要的，而只是一个有效的解释性工具。本节不应当陈述具体需求，而只应对需求规格说明具体需求一章中要描述的需求给出理由。例如：博金贷androidAPP功能清单：功能类别/系统子功能/模块编号功能摘要项目投资投资项目展示1.0_001进行投资1.0_002主要面向投资人对选中的项目进行投资，能够查询投资合同，输入金额，选择卡券，判断金额有效性，提示投资成功查询投资记录回款查询回款管理账户登录注册修改密码实名认证银行卡管理充值提现查询交易明细信息交互发布平台公告公告展示2.3用户特征 本节描述影响具体需求的该产品最终用户的特点。 软件生存周期的运行和维护阶段，许多人员与系统有关。这些人员中有用户、操作员、维护人员和系统工作人员。这些人的某些特点，如教育水平、经验、技术专长等，都对系统运行有重要影响。 如果系统的大多数用户是临时用户，那么他们的具体需求可能是要求系统包含有许多如何完成基本功能的提示，而不是记忆许多繁琐的细节。本节不陈述具体需求或针对某些特殊需求而考虑的若干具体设计约束，本节应对在需求规格说明的具体需求一章中描述的某些具体需求或设计约束提供理由。例：净值标项目根据用户对产品使用权限等级的不同，可将用户角色定义为以下几类：角 色权限描述借款人发布借款，查询借款记录，提前还款净值借款管理员设置系统参数（如净值系数，），垫付逾期款项，代理还款，2.4一般约束 本节给出对一些条款的概括描述，这些条款将影响承办单位在设计阶段的工作和计划，这些条款包括： a. 管理方针； b. 硬件的限制； c. 与其他应用的接口； d. 并行操作； e. 实时性能； f. 检查功能； g. 控制功能； h. 信号交换协议； i. 应用的临界点； j. 安全和保密方面的考虑。本节不列举具体的需求或具体的设计约束。但是，应对具体需求一章中描述的某些具体需求和设计约束提供理由。例如：与其他应用的接口APP 应与WEB，WAP数据保持实时一致，能够共享，注意做好相关接口。2.5实现语言 本节要列出所采用的编程语言。Android ：JAVA .3. 功能详细需求 本章包括软件开发者进行设计时所需要的全部细节。通常本章是需求规格说明中篇幅最长和最重要的部分。 a. 必须按照本标准第4.4条描述的标准（可验证的、无歧义的等），对需求规格说明中的每个具体需求给出详细定义； b. 应当利用引言、概述和附录部分中的有关讨论及交叉引用关系，提供每个具体需求的背景及注释内容； c. 具体需求的一种分类方法为：功能需求，性能需求，设计约束，属性，外部接口需求，其他需求。 必须注意到： a. 具体需求应当按逻辑可读的方式组织； b. 每一个具体需求应使用指定的方法进行客观的验证。3.1xx功能需求这里用功能清单上的功能/模块名称，有多少个功能模块列多少章节。本节描述软件产品的输入经过什么处理，产生什么输出，它描述在软件中发生的基本操作。对于每一类功能或者有时对于每一个功能，需要描述其输入、处理和输出等需求。3.1.1简要说明在本节中应当描述完成本功能的目的，所使用的方法和技术，还应当包括可以清楚说明本功能意图的来源或背景材料以及有关需求的注释内容。3.1.2需求分析图用例图/活动图/状态图 /交互图什么是用例：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。用例将系统的功能范围分解成许多小的系统功能陈述。一个用例代表了系统的一个单一的目标，用例是一个行为上相关的步骤序列。用例图是指由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的静态视图。例如：借款人还款模块1）用例图/流程图用例图说明：借款人：可手动提前还款，逾期还款。平台虚拟人：平台自动对到期项目进行还款，还款资金来源于借款人账户余额。2）活动图类似流程图，在强调业务操作流程的功能模块使用。还款活动图说明：提前还款：如果当前日期早于项目计划还款日期，且借款人选择了提前还款，则启动提前还款程序。到期还款：如果当前日期=项目计划还款日期，则不用借款人手动还款，平台（虚拟人）自动从借款人账户余额还款。3）状态图状态图，在状态比较多的功能模块使用。还款模块分7种状态，状态转移条件如下图：4）序列图序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。除记录组织的当前事件外，一个业务级的序列图能被当作一个需求文件使用，为实现一个未来系统传递需求。在项目的需求阶段，分析师能通过提供一个更加正式层次的表达，把用例带入下一层次。那种情况下，用例常常被细化为一个或者更多的序列图。逾期且提前还款的顺序图3.1.3各用例说明用例1：逾期还款用例名称例如：逾期还款用例标识1.0_002_01创建人创建日期版本1.0用例类型业务操作类：重点是操作流程和交互信息展示类：重点是展示信息；子用例：扩展用例：用例描述例：主要是还款状态的判断，还款的计算与操作。优先级无执行者/参与者用例图中该用例的参与者，通常是业务操作的触发者和施与对象（如外部系统）。如：区总管理系统的执行者是经系统登记注册的区总账户，或系统管理员触发条件谁干了什么，触发了这个用例。如：用户在单个项目投资页面单击了“确认投资”按钮前置条件在触发该用例相关操作前必须达到的条件。比如:进入区总管理界面，必须先获得区总的权限。输入本栏应包括： a. 对本功能全部输入数据的详细描述，它们包括：输入源，数量，度量单位，时间关系，有效输入的范围，精度和公差； b. 操作员具体的控制要求，其中包括操作员活动的描述，控制台或操作员的位置等。例如，在打印表格时，要求操作员调整打印纸位置的需求； c. 指明引用的接口规格说明或相应的接口控制文档。例如：立即投资的输入信息包括：投资金额，卡券需求描述/操作序列/事件流本节陈述为获得期望的输出，而对输入数据和中间参数进行的全部操作。它可包括如下内容： a. 输入数据的有效性检查； b. 操作的精确顺序，包括事件的时间设定； c. 非正常情况的处理，例如对溢出、通信故障、错误处理的响应； d. 操作对参数的影响； e. 降级运行的需求； f. 把系统输入变换为相应输出的方法（如方程式、数学算法和逻辑操作）。例如可以列出：在工资管理软件包中关于房租计算的公式，求解微分方程的算法，天气预报软件包使用的气象学模型； g. 输出数据的有效性检查。这是用例说明中最重要的部分，它详细描述了该用例可能出现的所有流程。基本流程：另一个名称更能表达它的意义：最佳流程（The Best Flow）。它描述的是该用例以最佳的、最正常的方式流转，没有出现任何异常，并且最终成功完成操作的流程。基本流程在编写时，应当通过数字对流程中的每一步进行编号。扩展流程：或者叫“分支流程”，它描述的是基本流程在流转过程中可能出现的所有分支。扩展流程最大的特点就是，它应当是在基本流程的某一步骤发生的分支，因此它的编号规则是“基本流程号+序号”。基本流程号就是发生分支的那一个基本流程的编号。在同一个基本流程上发生多个分支时，它们的序号从1依次开始编号。 另一种情况是，某个扩展流程本身拥有多个步骤，这时应当在“基本流程号+自身序号”的基础上再添加序号，如“2.1.1”。 扩展流程在描述时，应当首先描述进入这个分支的条件，即“如果则”、“当时”。异常流程：就是发生异常情况时的处理流程。注意，用例说明是站在用例角度进行的说明，因此这里并不是我们通常一样的发生程序异常的处理流程，而是用户在处理业务操作时发生的异常情况，如：如果顾客不能提供身份证，则例如：订货流程S1：进入订货合同信息的界面，默认订货合同的录入界面，选择以下操作(、)； S2：选择转入S2.1；选择转入S2.2；选择转入S2.3；选择转入S2.4；选择转入对当前记录进行打印并返回S1；（打印的表单见附录：表单2）操作：S2.1：选择后系统进入订货合同信息的录入界面，首先录入合同编码、合同名称后，进行操作，在弹出窗口选择供应商名称双击后信息接收到增加界面。录入信息后，选择以下操作、S2.1.1：选择后系统进行录入/修改信息的约束判断，如果违反约束的提示信息，返回S2.1，否则进行保存当前记录并把当前记录置为只读状态对该记录进行增加、删除、修改、查询操作；S2.1.2：选择后，清空信息。操作：输出这一栏应包括：该功能所有输出数据的详尽描述，包括： a输出的目的地； b数量； c度量单位； d时间关系； e有效输出的范围，包括精度和公差； f非法值的处理； g错误信息。有关接口说明或接口控制文档的参考资料。对于非标准输出设备此部分内容尤其重要。后置条件又称为“成功保证”，就是执行基本流程获得成功以后所达到的状态（条件）。后置条件往往体现的是执行该用例的最终目的。如：完成用户投资金额的填写并提交。数据记录提交成功或失败的处理。假设与约束就是隐藏于业务功能中的各项规则与条件，如各种逻辑条件、计算公式、环境限制等等。例如：输入的投资金额必须大于最低投资金额，小于个人剩余投资金额账户余额须大于输入的投资金额非功能需求简称为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。要求界面美观、简捷。补充说明1、供应商信息来源于供应商信息表2、产品信息来源于供方产品信息表1、 该表单需要部门经理审核、主管付经理审批。需求变更列表创建人版本描述创建日期1.0_1.0用例2：标准模块模板收件地址模块用例说明：所在地区的选项卡模型包含世界区域、省份、城市、县区、街道。地址输入规范：收件人地址：建议您如实填写详细地址，例如街道名称，门牌号码，楼层和房间号等信息。收件人/单位地址示例：江西省南昌市新建县丽景路XXX号XXXX楼XXX室单位名称示例：例如：中国建设银行XX省分行XX市XXX支行3.1.4表单字段3.1.4领域模型（暂不用）（即概念类模型）为用例绘制领域模型，并编写领域模型说明，对每个实体进行说明。对实体的说明包括对实体的定义、属性说明、行为说明、实体关系说明等等。如果实体间关系复杂，还要使用对象图说明实体关系的所有情况。3.1.5 UI界面给出本功能模块界面图及辅助文字说明。UI要素描述要包括：布局字体大小颜色行距对齐图形大小，形状，颜色动画效果演示（其他功能单元继续按上述要求撰写）4. 外部接口需求4.1用户界面 本节应当描述： a. 用户使用软件产品时的界面需求。例如，如果系统的用户通过显示统筹终端操作，就必须指定如下需求：对屏幕格式的要求，报表或菜单的页面显示格式和内容，有关输入和输出的时间，用户命令的形式； b. 界面的优化问题。可以简单的用一个表列出系统用户做什么或不做什么。例如，要求的是长的还是短的出错信息。与其他需求一样，这种需求也应该是可验证的。需求名称详细要求界面友好要求能方便的输入、输出数据，减少非法数据的输入，有固定分类的地方采用选择方式，替手工录入，减少出错率。操作简单能够明确的标明操作的界面，多处使用文字提示，以方便非计算机人员的使用。级联菜单不能太多界面风格要求界面风格统一、美观大方，不要使用特别夸张的色彩。统一为蓝色风格。4.2硬件接口本节应当陈述软件产品与系统硬件设备之间每一个接口的逻辑特点。还可能包括如下事宜：要支持什么样的设备，如何支持这些设备。APP 需要支持的设备：4.0,4.7,5.5寸的手机，mini ipad。4.3软件接口 在这里应当陈述其它有关软件（如数据库管理系统、操作系统、或者数学软件包）的使用方法，以及同其它相连接软件的接口。 对每一有关的软件产品，必须提供如下内容： a. 名字； b. 助忆符； c. 版本号； d. 源程序。 对于每个与其它软件接口，本部分应： a. 描述与本软件产品相联接的软件的基本功能，以及达到的目的；b. 描述传递信息的内容和格式定义接口。对已有完整文档的接口，只需要引用描述该接口的文档。应用需要支持的操作系统：android 3.0以上版本；iphone ipad4.4通信接口本节应说明各种通信接口。例如，局部网络协议等。5. 非功能性需求5.1性能需求本节应从整体上说明该软件、人与该软件相互作用的静态或动态数值需求。5.1.1 静态数值需求包括： a. 支持的终端数； b. 支持的同时操作的用户数； c. 处理文件和记录数； d. 表和文件的大小；e. 对数据的精度要求，包括数学的、逻辑的传输的精度等。5.1.2动态数值需求包括诸如处理和任务的数量，以及在正常情况下和峰值工作条件下在一定时间周期中要处理的数据总数。有关响应时间、更新处理时间、数据转换和传输时间也在本节陈述。5.2设计约束说明其它需遵守的硬件限制等标准和设计约束。5.2.1硬件限制 a. 硬件配置的特点（接口数、指令系统等） b. 主存贮器和辅助存贮器的容量；c. CPU速度。5.2.2其他约束 本节描述除硬件限制外的其它约束。它们有： a. 报表格式； b. 数据命名；c. 检查追踪。5.3属性在软件的具体需求中可以有若干属性。下面仅列出其中的一部分，应注意它们不是一个完整的清单。5.3.1可使用性 列出保证软件的可使用性达到预定要求的需求。如检测点、恢复和重启动性等。5.3.2安全性 本节指出保护软件的要求，以防止突然或非法的访问、使用、修改或者泄密。本节的具体需求包括： a. 利用某些密码技术； b. 掌握特殊的记录或历史数据； c. 给不同的模块分配不同的功能； d. 限定一个程序中某些区域间的通讯。标准要求：5.3.3可维护性 本节指定若干需求，以确保软件是可维护的。5.3.4可移植性本节列出确保用户程序和用户界面的兼容方面的需求（如果有的话），以及为把被开发软件从一种运行环境移植到另一个运行环境的需求等。5.4其它需求由于软件的类型、用户的特点等，某些特殊的需求在下列各节描述。5.4.1数据库 说明作为产品一部分被开发的数据库的需求。例如：使用的频率，访问的能力，数据元素、记录和文件的关系，数据保留需求等。5.4.2操作说明用户要求的常规和特殊的操作，例如：用户初始的操作，数据处理支持的功能，后援和恢复操作等。5.4.3故障处理列出可能发生的软件和硬件故障，并指出这些故障对各项性能指标所产生的影响以及对故障处理的要求。6. 数据需求6.1数据描述 数据分静态数据和动态数据两类。静态数据指在运行过程中一般不改变的数据。动态数据则指运行中要输入、输出的数据，以及在运行过程中要改变的数据。 a. 静态数据 列出作为控制和引用而使用的静态数据元素； b. 动态输入数据 列出动态输入数据元素，包括在常规操作和特殊操作中要输入的数据元素； c. 动态输出数据 列出动态输出数据元素，包括在常规运行中和特殊情况下输出的数据元素； d. 内部生成数据 列出对用户软件之内部生成的数据元素；e. 说明对数据元素的约束 列出