AndroidAPP开发需求文档范本是什么样的(软件开发需求文档范例)

软件需求文档格式的标准写法

1．引言

1．1编写目的

·阐明开发本软件的目的；

1．2项目背景

·标识待开发软件产品的名称、代码；

·列出本项目的任务提出者、项目负责人、系统分析员、系统设计员、程序设计员、程序员、资料员以及与本项目开展工作直接有关的人员和用户；

·说明该软件产品与其他有关软件产品的相互关系。

1．3术语说明

列出本文档中所用到的专门术语的定义和英文缩写词的原文。

1．4参考资料（可有可无）

列举编写软件需求规格说明时所参考的资料，包括项目经核准的计划任务书、合

同、引用的标准和规范、项目开发计划、需求规格说明、使用实例文档，以及相关产品

的软件需求规格说明。

在这里应该给出详细的信息，包括标题、作者、版本号、发表日期、出版单位或资

料来源。

2．项目概述

2．1待开发软件的一般描述

描述待开发软件的背景，所应达到的目标，以及市场前景等。

2．2待开发软件的功能

简述待开发软件所具有的主要功能。为了帮助每个读者易于理解，可以使用列表或

图形的方法进行描述。使用图形表示，可以采用：

·顶层数据流图；

·用例UseCase图；

·系统流程图；

·层次方框图。

2．3用户特征和水平（是哪类人使用）

描述最终用户应具有的受教育水平、工作经验及技术专长。

2．4运行环境

描述软件的运行环境，包括硬件平台、硬件要求、 *** 作系统和版本，以及其他的软

件或与其共存的应用程序等。

2．5条件与限制

给出影响开发人员在设计软件时的约束条款，例如：

·必须使用或避免使用的特定技术、工具、编程语言和数据库；

·硬件限制；

·所要求的开发规范或标准。

3．功能需求

3．1功能划分

列举出所开发的软件能实现的全部功能，可采用文字、图表或数学公式等多种方法

进行描述。

3．2功能描述

对各个功能进行详细的描述。

4．外部接口需求

4．1用户界面

对用户希望该软件所具有的界面特征进行描述。以下是可能要包括的一些特征：

·将要采用的图形用户界面标准或产品系列的风格；

·屏幕布局；

·菜单布局；

·输入输出格式；

·错误信息显示格式；

建议采用RAD开发工具，比如Visio，构造用户界面。

4．2硬件接口

描述系统中软件产品和硬件设备每一接口的特征，以及硬件接口支持的设备、软件与硬件接口之间，以及硬件接口与支持设备之间的约定，包括交流的数据和控制信息的性质以及所使用的通信协议。

4．3软件接口

描述该软件产品与其有关软件的接口关系，并指出这些外部软件或组件的名字和版本号。比如运行在什么 *** 作系统上，访问何种类型的数据库，使用什么数据库连接组件，和什么商业软件共享数据等。

4．4通信接口

描述和本软件产品相关的各种通信需求，包括电子邮件、Web浏览器、网络通信协议等。

4．5故障处理

对可能的软件、硬件故障以及对各项性能而言所产生的后果进行处理。

5．性能需求

5．1数据精确度

输出结果的精度。

5．2时间特性

时间特性可包括如下几方面

·响应时间；

·更新处理时间；

·数据转换与传输时间；

·运行时间等。

5．3适应性

在 *** 作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，软件的适应能力。

6．其他需求

列出在本文的其他部分未出现的需求。如果不需要增加其他需求，可省略这一部分。

7．数据描述

7．1静态数据

7．2动态数据

包括输入数据和输出数据。

7．3数据库描述

给出使用数据库的名称和类型。

7．4数据字典

对于数据流图、层次方框图中出现的所有图形元素在数据字典中都要作为一个词条加以定义，使得每一个图形元素都有唯一的一个清晰明确的解释。

数据字典中所有的定义必须是严密的、精确的，不可有二意性。

7．5数据采集

·列出提供输入数据的机构、设备和人员

·列出数据输入的手段、介质和设备；

·列出数据生成的方法、介质和设备。

8．附录

包括分析模型，待定问题图表等。

代理商和旅游景点管理系统项目开发背景 消费劵管理系统是一个面向广大客户来源以及一个和代理商的业务流程的一个项目，由于该系统涉及的客户面和业务较广，系统的各项功能与各项管理消费劵息息相关，因此做好项目系统需求分析显得至关重要。根据实际情况采用各种技术手段对消费劵的管理，争取代理商、景点和客户之间得到最大限度的需求。编写的目的 为了让开发人员能够很快的了解该项目，了解该项目的需求，知道该项目的具体实现的功能，通过文档信息知道了该项目所涉及到的数据库表和每个表有哪些字段。项目系统需求分析 代理商：1、 代理商以5折优惠从景点出购买消费劵（消费劵有面值不等的，目前未知）。2、 代理商预付一定的预付款（如5万元）从景点处购入2倍的消费劵（就是10万元）。3、 代理商卖出给客户均以7折卖出4、 代理商预付款余额不得低于一定的金额（未知。如：预付款余额不低于2000等）。5、 代理商在预付款余额低于一定的金额后，需要及时补充（如：几个工作日内景点收到补充的预付款）。景点：1、 景点对客户使用的消费劵进行消费劵验证（如：消费劵卡号验证，是否已过期等）。2、 景点对客户所使用的消费劵不得以任何方式返还（如：消费劵1000，用去900，那么也不得返还100元金额）。客户：1、客户使用消费劵必须在消费劵能使用的范围2、客户在使用消费劵必须在消费劵的有效期内使用，预期作废。3、客户使用消费劵消费时，若消费金额＞实际消费金额，应付实际消费金额—消费劵金额。共同补充：1、 预付款余额=预付款当前余额—客户实际消费金额（备注：若客户使用1000元的消费劵消费了800，那么客户实际消费金额=800）功能分析描述 根据登陆人员的权限不同，页面不同所执行不同的 *** 作登陆功能 1、 经理登陆管理2、 员工登陆 *** 作登陆功能描述 1、 代理商经理登陆，经理有权限完善资料，建立工作组，员工信息的录入。添加景点以及景点的相关信息（如：景点的名称，景点的地点，景点经理的****）。管理财政，查看每个景点消费劵的售出量和使用量，对账单，对账表，根据实际情况，打印各个景点的消费劵和消费劵的面值，打印消费劵的数目、该消费劵的折扣，信息都录入数据。根据消费劵的售出情况计算所得的利润。查看预付款余额，不足的及时补充。2、 代理商员工登陆，登陆出售消费劵界面，激活消费劵的金额，记录每个景点的出售的消费劵的面额（激活的），各个景点的消费劵的出售数量。3、 景点经理登陆，经理完善资料，建立工作组，员工信息的录入，添加代理商以及代理商的信息（如：代理商的名称，代理商的地点，代理商经理的****）。查看每个代理商在我们景点销售情况及使用情况。查看每个代理商的预付款余额是否已不足（不足提示该代理商），对账单，对账表。4、 景点员工登陆，登陆收费系统，验证客户所使用的消费劵是否已激活，该客户使用的消费劵是哪个代理商出售的，该消费劵的金额是多少，哪一天消费的，都记录下来。项目涉及数据的分析代理商和景点数据分析 1、代理商和景点的角色分析：经理，员工，涉及到的就是用户名（username），先不用管它是经理还是员工，后面有该用户的权限的，我分析的数据：代理商用户表（AgentUser）主键AIDNumber用户名AUserNameVarchar（10）用户密码AUserPasswordVarchar（20）用户权限（角色表外键）AUserRightsNumber↓角色表主键RIDNumber角色RoleVarchar（12）2、景点信息表：景点信息表主键SIDNumber景点名称ScenicSpotNameVarchar（30）景点地址ScenicSpotAddressVarchar（100）景点联系电话ScenicSpotNOVarchar（15）景点折扣ScenicSpotDisCountNumber消费劵数据分析 消费劵信息表主键CCIDVarcher（20）消费劵面值CCMoneyNumber消费劵属于哪个景点（景点信息表外键）SIDVarchar（20）消费劵折扣SDiscountNumer详细账单表 账单表主键ZidVarcher（20）金额MoneyNumber属于哪个景点（景点信息表外键）SIDNumer对账单，对账表分析 1、 按一定的是时间（比如一个月）会生成一个具体的账单以便于在管理人员的查看和管理，代理商对每个景点的销售消费劵的情况和景点对每个代理商销售的情况都记录保存。2、 按一个月算每个月双方要对账单。打印消费劵分析 1、 不能打印任何面值两个相同的卡号，用一个软件以一个数字开头进行递增。2、 打印每个景点的消费劵，根据该景点在我们代理商的销售情况，按实际情况进行打印（面值，张数）最后补充一个，客户是不是可以上网查询自己的消费劵真假面值，目前在考虑

应用软件开发中的需求分析及方法 软件工程一般具有以下基本活动：软件描述：软件的功能以及软件 *** 作上的约束定义；软件设计和实现：软件要按照描述来设计；软件有效性验证：软件要被确定是有效的，能完成预期的应用；软件进化：软件按应用需要的变更来进化。其中，软件描述的目标是，确定软件系统需要哪些服务以及开发和运行期间受到哪些约束，对服务和约束的发现、分析、建立文档、验证活动，现在常称为需求工程。为此，笔者谈谈如何进行需求分析及方法。 一、 需求的过程 需求工程对于软件过程是一个特别关键的阶段，这个阶段的错误将不可避免地带到后续的系统设计和实现阶段中。需求工程阶段的独特之处在于很少有现成模式或特制的文档可供参考。后续阶段可以建立在前期所做工作基础上（各种相关模型至少在一定程度上可以衍生导出），而需求工程阶段的成果却是靠创建而来的。 需求工程本身就是一个过程，这个过程将产生用以描述系统的需求文档。通常需求在这个文档中被分成两个层次描述：最终用户需要高层次的需求描述；而系统开发人员需要比较详细的系统描述。 （一）需求过程的四个主要阶段 1、可行性研究：指明现有的软件、硬件技术能否实现用户对新系统的要求。从业务角度来决定系统开发是否划算以及在预算范围内能否开发出来。可行性研究是初步的，结果就是要得出结论，该系统是否值得进行更细致的分析。 2、需求的导出和分析：这是一个通过对现有系统分析、与潜在用户讨论、进行任务分析等导出系统需求的过程。也可能需要开发一个或多个不同的系统模型和原型。这些都会帮助分析员了解所要描述的系统。 3、需求描述：需求描述就是把在分析活动中收集的信息以文档的形式确定下来。在这个文档中有两类需求。用户需求是从最终用户对系统需求的抽象描述；系统需求是对系统要提供的功能的详尽描述。 4、需求有效性验证：这个活动检查需求实现、一致和完备。在这个过程中，可发现需求文档中的错误，并加以修正。 当然，需求过程中的各项活动并不是严格按顺序进行的。在定义和描述期间，需求分析继续进行，这样在整个需求工程过程中不断有新的需求出现。因此，分析、定义和描述是交替进行的。 （二）需求的进一步认识 1、软件系统需求 常常分为功能需求、非功能需求和领域需求。 功能需求：包括对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。在某些情况下，功能需求可能还需要明确申明系统不应该做什么。理论上，系统的功能需求描述应该既全面又具有一致性。全面意味着用户所需的所有服务都应该给出描述。一致性意味着需求描述不能前后矛盾。在实际过程中，对大型而又复杂的系统而言，要做到需求描述既全面又一致几乎是不可能的。一方面是因为系统固有的复杂性，另一方面是因为观点不同，需求也会发生矛盾。 非功能需求：对系统提供的服务或功能给出的约束。包括时间约束、开发过程约束、标准等。非功能需求源于用户的限制，包括预算上的约束、机构政策、与其他软硬件系统间的相互 *** 作，还包括如安全规章、隐私权利保护等外部因素。 领域需求：这是来自系统的应用程序领域的需求，反映了该领域的特点。他们也可能是功能需求或非功能需求。 2、软件需求文档 也称软件需求描述（SRS），是对系统开发者要求的正式陈述。IEEE标准为需求文档提出了以下结构：引言（目的、范围、缩略词等），一般描述（产品透视、功能、用户特征、约束等），专门需求（功能、非功能、接口），附录，索引。 二、方法 （一）问题域（应用领域） 是指问题所存在的现实世界中的那个部分。问题域是需求分析员所要研究的首要对象。例如，对一个电梯控制系统来说，它将包含任何现存的硬件（电梯、指示器、传感器、按钮等）、建筑物特征（楼层和电梯井的数目）、预期的使用模式、用户特征、使用约束（如限制短途搭乘）等等。在这个问题域内，问题可以确定为“让电梯在建筑物中更有效使用的控制系统”。为了解决问题，‘解系统’显然有必要在问题域内产生某些效果，构成软件需求的正是这些想要获得的效果，也就是为何做软件需求的原因和目的。 到现在为止，我们得到初步论点。在构建一个新软件系统之前，最好先决定它应当能够做些什么又不要做些什么；从问题域的研究入手，获得问题的描述，以及新的解系统在其中将产生效果的陈述（即需求）；确定新系统所需的行为，以便让它在问题域内产生所需要的效果。 （二）需求分析 通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明。需求分析旨在揭示一个现有的系统（问题域）的结构，而内部设计则是要创建出一个尚未存在的软件系统（解系统）的结构。对于这一重要任务其特性如下： 分析关注问题域及对其建立的模型，而不是解系统； 主要目标是要获得对问题域及存在于其中的问题本质的理解； 分析在本质上先于解系统行为的规格说明（尽管有重叠和反复的过程）。 （三）方法论 方法不只是一种技术，它是解决任务的一种途径，并且通常由一组技术组成。任何分析方法，要使它得到很好的利用，都应当要求并且做到便于描述以下几个方面： 问题域的结构，根据其子域及其相互间的关系； 问题域数据，语法和语义方面 问题子域的内在属性和行为； 问题域中的重要事件及现象； 需求，解系统在问题域中应产生的效果。 具体有以下三个方法： 1、结构化分析（SA） 结构化分析（SA）是一种具有相当长历史的分析方法，其演化的方式既微妙又显得很重要。如同结构化编程一样，它致力于系统范围内的事物处理，数据流以及存储数据结构的建模。建模主要包括数据流模型（DFD），数据字典（DD），实体关系图（ERD）。 结构化分析所用的原型，无论是对开发者还是客户都显得直观易懂，若将初始重点放在对原有系统的建模是对实现理解问题域这一基本的分析目标的有力支持。 结构化分析方法和人们的思维方式很相似，注重的是事物的过程和方面。利用结构化分析很容易去理解一个刚刚接触的问题域，适合对比较生疏领域做软件需求。 2、 面向对象分析（OOA） 面向对象方法最初只是一种系统的结构进行建模的方式，后来扩展到了内部设计，如今也已经开始广泛应用于分析阶段。面向对象分析基本思想是：如果把对象类的建模限定在需求问题域，那么面向对象的基本原理、模型以及表示法均可以用于分析。 OOA（面向对象分析）算不上一种真正的需求方法，OOA的起点是一份原有的需求文档，或者甚至是一份行为规格说明，并且OOA隐含的假设问题域分析已经完成，即分析员已经了解了所要研究的事物。OOA的真正本质意义是作为解系统的高层体系结构的设计，并且有利于系统的下一步开发设计（如果是OOD开发的话）。 OOA的大致方法是：标识出问题域中的对象类；定义这些类的属性和方法；定义这些类的行为；对这些类间的关系建模。 3、 面向问题域分析（PDOA） 面向问题域的分析（PDOA）是一种新技术。PDOA更多的强调描述，而较少的强调建模。描述大致划分为两个部分：一部分关注于问题域，而另一部分关注于解系统的待求行为。一般建议同时有两个单独文档：第一文档含有对问题域相关部分的描述以及一个需求在该域中求解的问题列表（即需求）；第二文档（规格说明书）包含的是对解系统的待求行为的描述以解决需求。其中第一文档才是通过做分析产生的；第二文档推迟到后续的规格说明任务中。 PDOA整个方法过程的基本步骤： 搜集基本的信息并开发问题框架（一种模型），以建立问题域的类型 在问题框架类型的指导下，进一步搜集详细信息并给出一个问题域相关的特性描述 基于以上两点，收集并用文档说明新系统的需求问题框架。问题框架是将问题域建模成一系列互相关联的子域。一个子域可以是那些可能算是精选出来的问题域的任一部分。问题框架的目标就是大量地捕获更多有关问题域的信息。基于不同问题子域的本质及存在于问题子域间的关系，可以把问题框架分类为： 工件系统——系统必须完成针对只存在于系统中的这些对象的直接 *** 作。 控制系统——系统控制部分问题域的行为，包括待求行为框架和受控行为框架。 信息系统——系统将提供有关的问题域的信息，包括信息是自动提供的和信息只在响应具体的请求时提供。 转换系统——系统必须将某种特定格式的输入数据转换成相应的、另一种特定格式的输出。 连接系统——系统必须维持那些相互没有直接连接的子域间的通信。 问题框架法在应用时，建议采用直截了当的策略： 抽象问题域：标识子域；标识子域间的交互；刻画每个子域的特征；生成一个上下文图识别出相关的标准框架；调整框架，尽可能使之适用于问题；使用关于相关框架的内容技术表来指导进一步的分析与文档编制任务。 问题域的描述与必须满足的需求二者之间有着明显的区别，对新的解系统的行为创建与定义应单独处理并且推迟到下一步的规格说明阶段。 4、方法的对比 结构化分析（SA）及其相应的派生方法，曾一度风行了许多年。它最初的版本主要是围绕对数据流以及问题域的数据结构进行建模，而现代的SA则直接将重点放在开发解系统的模型。描述问题域的SA可以算是想当不错的，所产生的功效可见一斑。然而，它对其他方面的支持却不够完善，在处理一些其他类型问题时显得有些笨拙。 面向对象分析（OOA）是当今主流的方法。OOA要求所有的系统均可以按照对象的特点来建模。它也继承了很多结构化分析的思想体系。OOA不能对问题域有个清楚的了解，因而它的起点若是有一份原需求文档，便可大大简化问题域的分析。OOA并不区分问题域描述与解系统描述之间的差异，而是直接交付出新的解系统的高层设计。 SA和OOA还有几点相同特性：主要模型是结构模型；通常焦点集中在对解系统的建模上；两中方法都较少地应用于需求获取领域；分析与内部设计之间没有明显差异。 面向问题域分析（PDOA）被认为是一种较为理想的方法。PDOA特点是重新将重点定位在问题域及需求上，通过对问题域的分类，向分析人员提供具体问题的相关指南。并且它将规格说明作为另行的任务处理，它的成果只是一份问题域的全面描述和一份需求列表而已。PDOA丰富和完善了现今的“分析”方法，然而人们对它的了解和掌握还有一定距离。 因地制宜的应用三种方法，不仅能够如实的认识问题域，创建出健全的解系统，还能够向用户和设计人员都提供满意的需求文档。 三、 总结 在做软件需求的时候，我们完全没必要去限定要用或将要使用何种方法。我们的目的在于分析软件的需求，通常情况是都用到了所介绍的三种方法。首先我们用面向问题域的方法把问题分成几个部分。接下来用面向结构或面向对象的方法对各个部分进行逐步分析细化。在逐步分析过程运用各种建模技术对问题各部分建立合适的模型来细化需求。随着需求的进一步进行，我们越来越清晰的认识了软件系统的需求。 虽然应用方法使我们能够清楚地去了解软件需求，但是，大部分的需求文档和规格说明书都是以文本的形式记录的，因此，如何去表达我们所了解的需求也是很值得注意的。

1、对要解决的问题进行需求分析时，是不用考虑用什么语言来实现的。2、需求分析只是要回答你所要开发的系统要向用户提供什么服务，即系统应该具有什么功能。并且还要分析系统的非功能性需求，即系统的可用性、可靠性，可维护性、可支持性等。3、在充分分析了系统的功能性需求和非功能性需求后，才开始设计如何实现系统，在这个阶段也不用过多的考虑如何用具体的语言来实现。4、当软件的设计写成后，就进入了系统构造的阶段，此时才考虑如何用编程语言来实现设计。

规范化软件开发过程中的《需求说明书》的编写，使之成为整个开发工作的基础。

2 适用范围

本规范适用于集团开发项目的（软件）《需求说明书》的编写。

3 编写内容提示

1 引言

311 背景说明

说明被开发软件的名称，任务提出者，用户及实现该软件的计算机网络。

312 参考资料

列出有关资料(名称，发表日期，出版单位，作者等)。

313 术语和缩写词

列出本文件中用到的专门术语的定义，及术语缩写词。

32 软件总体概述

321 目标

软件开发的意图、应用目标、作用范围以及需说明背景材料。

322 系统模型

图示说明该软件的所有功能及其相互关系和数据传递情况。

323 假设和约束

说明影响软件开发、运行环境和系统能力（如预告出错类型的能力）的某些假设和约束。33 详细需求

详细描述此软件系统的功能需求和性能需求。

331 功能需求

对系统中每一个功能，要详细描述（图示或文字）。

概述 叙述功能名称，目标和作用。

输入 输入该功能的信息。

处理 描述该功能做什么，如何对输入信息进行加工并转换成输出信息。

输出 列出内部生成的文件。

332 性能需求

定量地描述此软件系统应满足的具体性能需求。可考虑以下方面：

3321精度

说明系统的精度要求，如：

数据的精度要求。

数字计算的精度要求。

数据传送的误码率要求。

3322 时间特性

说明系统的时间特性要求，如：

解题时间。

询问和更新数据文件的响应时间。

系统各项功能的顺序关系。

3323 灵活性

说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。

3324系统容量

包括系统的设计容量和理论（计算）容量。

333 输入和输出

解释各输入输出数据类型，并逐项说明某媒体、格式、数值范围等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

334 数据管理能力

说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作估算。

335 故障处理

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

34 环境

描述所开发软件运行所需的环境。

341 设备环境

描述运行软件系统所需的设备能力，如：

处理器的型号和内存容量。

存储媒体的数量。

通信网络（包括说明网络结构，线路速度及通讯协议等）。

342 支持软件环境

列出与待开发的软件互相配合的支持软件（包括名称，版本号和文件资料），必要时还应列出测试软件，还要指出该软件用的编程语言，编译程序， *** 作系统和数据管理系统。

343 接口

说明本软件与其他软件之间的接口、数据通信协议等。

344其他

说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。

以上就是关于AndroidAPP开发需求文档范本是什么样的(软件开发需求文档范例)全部的内容，包括:AndroidAPP开发需求文档范本是什么样的(软件开发需求文档范例)、软件 开发项目 需求分析 怎么写最好给个案例看看、论文高手进：软件开发需求分析的认识和理解等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！