PSP个人软件需求分析和规划文档
1.引言
1.1 编写目的
该文档首先给出了整个软件的整体结构和功能结构的概貌，从整体架构的基础上描述了软件的各个功能。以此来说明软件的根本目的是提高软件开发人员对软件开发的时间和质量等方面估计的准确度。编写此文档可以帮助用户更加了解软件的各个方面信息，通过这份软件产品需求分析报告详尽说明了该软件的需求规格，包括修正和（或）发行版本号，从而对该软件产品进行正确的定义。
1.2 项目风险
该软件开发项目的风险承担者有：
任务提出者：需要承担的风险是软件能否达到软件开发预期的目标。
软件开发者：需要承担的风险是软件是否能满足需求报告说明书里的各种功能需求等。
产品使用者：需要承担的风险是软件是否能满足自己的需求。
软件投资者：需要承担的风险是产品是否能给自己带来收益。
1.3 文档约定
描述编写文档时所采用的标准为：
正文风格：宋体 15px
提示方式：黑色加粗字
重要符号：·
1.4 预期读者和阅读建议
本软件产品需求分析报告可能的预期读者有：
用户，开发人员，项目经理，研发经理，测试人员，文档编写人员和营销人员。
并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
用户：
开发人员：
项目经理：
研发经理：
测试人员：
文档编写人员：
营销人员：
1.5 产品范围
说明该软件产品及其开发目的的简短描述，包括利益和目标。把软件产品开发的目标。描述产品范围时需注意，可以参考项目视图和范围文档，但是不能将其内容复制到这里。
1.6 参考文献
列举编写软件产品需求分析报告时所用到的参考文献及资料，可能包括：
本项目的合同书；
本项目已经批准的计划任务书；
用户界面风格指导；
开发本项目时所要用到的标淮；
系统规格需求说明；
使用实例文档；
属于本项目的其它己发表文件；
本软件产品需求分析报告中所引用的文件、资料；
相关软件产品需求分析报告；
为了方便读者查阅，所有参考资料应该按一定顺序排列。如果可能，每份资料都应该给出：
标题名称；
作者或者合同签约者；
文件编号或者版本号；
发表日期或者签约日期；
出版单位或者资料来源。
2.综合描述
本软件应用于软件开发的过程中，是基于B/S和Java EE体系结构和编程的方法的软件。
2.1 产品的状况
软件开发涉及多个环节，而且分析过程比较复杂，开发前需要对历史数据进行分析以便提高对当前开发软件估算的准确度，同时在软件开发过程中需要对开发过程进行管理，用来对软件开发的开发进度进行分析，更好的掌握软件开发的进度和结束时间。
2.2 产品的功能
基本的功能：用户管理，日程安排表管理，开发人员日志的管理，软件的维护
体系架构方面主要采用B/S结构，即浏览器服务器结构。在B/S结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实现，形成所谓三层3-tier结构。
2.3 产品的状况
描述了在软件产品需求分析报告中所定义的软件产品的背景和起源。说明了该软件产品是否属于下列情况：
是否是产品系列中的下一成员；
是否是成熟产品所改进的下一代产品；
是否是现有应用软件的替代品(升级产品)；
是否是一个新型的、自主型的产品。
如果该软件产品需求分析报告定义的软件系统是： 大系统的一个组成部分；
与其它系统和其它机构之间存在基本的相互关系。
那么必须说明软件产品需求分析报告定义的这部分软件是怎样与整个大系统相关联的，或者（同时）说明相互关系的存在形式，并且要定义出两者之间的全部接口。
2.4 运行环境
开发环境：Eclipse3.7+JDK1.6
应用服务器：TOMCAT7.0.37
数据库软件：MySql数据库
运行平台：Windows 7 ,Android 2.2+
开发工具：JDK、Eclipse3.7
数据库：MySql
规模：中
3.外部接口需求
通过本节描述可以确定，保证软件产品能和外部组件正确连接的需求。关联图仅能表示高层抽象的外部接口，必须对接口数据和外部组件进行详细描述，并且写入数据定义中。如果产品的不同部分有不同的外部接口，那么应该把这些外部接口的全部详细需求并入到这一部分实例中。
3.1 硬件接口
处理器：Intel(R) Pentium(R) Dual E2140 @1.60GHz
内存：1GB DDR2
显卡：256MB
USB 2.0
3.2 软件接口
开发环境：Eclipse 3.7+JDK 1.6
应用服务器：TOMCAT7.0.37
数据库软件：MySql数据库
运行平台：Windows 7.0
开发工具：JDK、Eclipse3.7
数据库：MySQL
4.软件功能需求
本软件主要分为三个模块：用户管理，日程安排表管理，开发人员日志的管理，软件的维护。
4.1 软件重要的E-R图
4.2 软件重要的数据流图
5.其他非功能需求
非功能需求主要包括可靠性、安全性、可维护性、可扩展性、可测试性等。
5.1 性能需求
网络环境下的多用户系统
数据的完整性，准确性
数据完成的时间性， 数据安全性
对开发人员产生的日志自动统计分析及数据的自动处理
5.2 安全措施需求
本软件在使用过程中有可能发生帐号信息外泄，请定期及时修改密码。
5.3 安全性需求
为达到系统安全性，完整性相关问题的需求或者与个人隐私问题相关的需求，需要对软件用户的信息进行安全认证。
5.4 软件质量属性
详尽陈述对客户和开发人员至关重要的在软件产品其他方面表现出来的质量功能。这些功能必须是确定的、定量的、在需要时是可以验证的。至少也应该指明不同属性的相对侧重点。
5.5 业务规则
列举出有关软件产品的所有操作规则，例如：那些人在特定环境下可以进行何种操作。这些本身不是功能需求，但是他们可以暗示某些功能需求执行这些规则。列举业务规则时，可以根据规则的数量，选取合适的编目方式。
5.6 用户文档
列举出将与软件产品一同交付的用户文档，并且明确所有己知用户文档的交付格式或标准，例如：
安装指南
纸质文档，16开本； 用户手册
纸质文档，16开本； 在线帮助
电子文档，与软件产品一同分发、配置；
使用教程电子文档，与软件产品一同分发、配置。
6.词汇表
列出本文件中用到的专业术语的定义，以及有关缩写的定义(如有可能，列出相关的外文原词)。为了便于非软件专业或者非计算机专业人士阅读软件产品需求分析报告，要求使用非软件专业或者非计算机专业的术语描述软件需求。所以这里所指的专业术语，是指业务层面上的专业术语，而不是软件专业或者计算机专业的术语。但是，对于无法回避的软件专业或者计算机专业术语，也应该列入词汇表并且加以准确定义。
7.数据定义
数据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档，其中对每个数据元素和结构都准确描述：含义、类型、数据大小、格式、计量单位、精度以及取值范围。数据定义的维护独立于软件需求规格说明，并且在软件产品开发和维护的任何阶段，均向风险承担者开放。
如果为软件开发项目创建一个独立的数据定义，而不是为每一项特性描述有关的数据项，有利于避免冗余和不一致性。但是却不利于多人协同编写需求分析报告，容易遗漏数据，也不方便阅读。因此还是建议为每个特性描述有关的数据项，汇总数据项创建数据定义，再根据数据定义复核全部数据，使得它们的名称和含义完全一致。必须注意的是，为了避免二义性，在汇总数据项时应该根据数据项所代表的实际意义汇总，而不是根据数据项的名称汇总。
在数据定义中，每个数据项除了有一个中文名称外，还应该为它取一个简短的英文名称，该英文名称应该符合命名规范，因为在软件开发时将沿用该英文名称。可以使用等号表示数据项，名称写在左边，定义写在右边。常见数据项的描述方式如下：
原数据元素
一个原数据元素是不可分解的，可以将一个数量值赋给它。定义原数据元素必须确定其 含义、类型、数据大小、格式、计量单位、精度以及取值范围。采用以星号为界的一行 注释文本，描述原数据元素的定义。
选择项
选择项是一种只可以取有限离散值的特殊原数据元素，描述时一一枚举这些值，并用方括号括起来写在原数据元素的定义前。在两项离散值之间，使用管道符分隔。
组合项
组合项是一个数据结构或者记录，其中包含了多个数据项。这些数据项可以是原数据元 素，也可以是组合数据项，各数据项之间用加号连接。其中每个数据项都必须是数据定 义中定义过的，结构中也可以包括其它结构，但是绝对不允许递归。如果数 据结构中有 可选项，使用圆括号把该项括起来。
重复项
重复项是组合项的一种特例，其中有一项将有多个实例出现在数据结构中，使用花括号 把该项括起来。如果知道该项可能允许的范围，就按“最小值：最大值”的形式写在花 括号前。
8.待定问题列表
编辑一张在软件产品需求分析报告中待确定问题时的列表，把每一个表项都编上号，以便跟踪调查。