烦。。。。 - Web 开发 / Ajax
需求分析怎么写啊！！！！！！！！！！！！！！！！
[解决办法]
软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
[解决办法]
需求提出 主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。用户、开发人员和用户确定一个问题领域，并定义一个描述该问题的系统。这样的定义称作系统规格说明，并且它在用户和开发人员之间充当合同。
需求描述 在问题分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。
需求评审 在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。
[解决办法]
目录
1业务需求3
1．1功能需求3
1．1．1功能需求13
1．1．2功能需求24
1．2外部接口需求4
1．2．1用户接口4
1．2．2硬件接口4
1．2．3软件接口4
1．2．4通信接口4
1．3性能需求4
1．4设计约束5
1．4．1其他标准的约束5
1．4．2硬件的限制5
1．5属性5
1．5．1可用性5
1．5．2安全性5
1．5．3可维护性5
1．5．4可转移/转换性5
1．5．5警告5
1．6其他需求5
1．6．1数据库6
1．6．2操作6
1．6．3场合适应性6
网上商城前景文档
组长：李小二
组员：李志标，李钊，李馨浩，张嘉宁，田霖，张冠武
虚拟用户：李志标，李馨浩
虚拟分析员：张嘉宁，李钊，田霖，张冠武
前景文档的目的:
文档目的是收集、分析、定义高层用户需要和产品特征。集中于目标用户所需要的能力以及为什么存在这些需要。有关系统如何满足这些需要的特定需求应该放在“软件需求规格说明”和“用例规格说明”中。
项目概述
本章应描述影响产品和其需求的一般因素，本章不说明具体的需求，而仅使需求更易于理解。
1．1产品描述
这一条是把一个产品用其他有关的产品或项目来描述。
a.如果这个产品是独立的，而且全部内容自含，应在此说明；
b.如果SRS定义的产品是一个较大的系统或项目中的一个组成部分，那么本条应包括如下内容：
(1)要概述这个较大的系统或项目的每一个组成部分的功能，并说明其接口；
(2)描述所使用的计算机硬件、外围设备。这里仅仅是一个综述性描述。
在本条的描述中，用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部接口是非常有帮助的。
1．2产品功能
本条是为将要完成的软件功能提供一个摘要。例如，对于一个记帐程序来说，SRS可以用这部分来描述：客户帐目维护、客户财务报表和发票制作，而不必把功能所要求的大量的细节描写出来。
有时，如果存在较高层次的规格说明时，则功能摘要可直接从中取得，这个较高层次的规格说明为软件产品分配了特殊的功能，为了清晰起见，请注意：
a.编制功能的一种方法是制作功能表，以便客户或者第一次读这个文件的人都可以理解；
b.用方框图来表达不同的功能和它们的关系也是有帮助的。但要牢记，这样的图不是产品设计时所需求的，而只是一种有效的解释性的工具。
产品综述
陈述该应用系统的目的、版本以及要交付的新特征。这一部分应该做以下几件事：
1）确定要创建或增强的产品或应用系统；
2）提供有关产品将做什么以及需要时不做什么的一般性描述；
3）描述产品的应用，包括与相关的利益、目的、目标。
1．3用户特点
本条要描述影响具体需求的产品的最终用户的一般特点。
许多人在软件生存周期的操作和维护阶段与系统相关。而这些人中有用户、操作员、维护人员和系统工作人员。这些人的某些特点，象教育水平、经验、技术、专长等，都是施加于系统操作环境的重要约束。
如果系统的大多数用户是一些临时用户，那么就要求系统包含如何完成基本功能的提示，而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。
1．4一般约束
本条对设计系统阳限制开发者选择的其他一些项作一般性描述。而这些项将限定开发者在设计系统时的任选项。这些包括：
a.管理方针；
b.硬件的限制；
c.与其他应用间的接口；
d.并行操作；
e.审查功能；
f.控制功能；
g.所需的高级语言；
h.通信协议；
i.应用的临界点；
j.安全和保密方面的考虑。
1．5假设和依据
本条列出影响SRS中陈述的需求的每一个因素。这些因素不是软件的设计约束，但是它们的改变可能影响到SRS中的需求。例如：假定一个特定的操作系统是在被软件产品指定的硬件上使用的，然而，事实上这个操作系统是不可能使用的，于是，SRS就要进行相应的改变。
具体需求
1．1功能需求
1．1．1功能需求1
1．1．1．1引言
本条描述软件产品的输入怎样变换成输出。即软件必须完成的基本动作。
对于每一类功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求。这通常由四个部分组成；
这部分描述的是功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景。
1．1．1．2输入
这部分应包括：
(1)详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、有效输入范围（包括精度和公差）；
(2)操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。例如：当打印检查时，要求操作员进行格式调整；
(3)指明引用接口说明或接口控制文件的参考资料。
1．1．1．3加工
定义输入数据、中间参数，以获得预期输出结果的全部操作。它包括如下的说明：
(1) 输入数据的有效性检查；
(2) 操作的顺序，包括事件的时间设定；
(3) 异常情况的响应，例如，溢出、通信故障、错误处理等；
(4) 受操作影响的参数；
(5) 降级运行的要求；
(6) 用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）；
(7) 输出数据的有效性检查。
1．1．1．4输出
这部分应包括：
(1)详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息；
(2)有关接口说明或接口控制文件的参考资料。
此外，对着重于输入输出行为的系统来说，SRS应指定所有有意义的输入、输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态作出响应。也就是说，这种情况犹如有限状态机。
1．2外部接口需求
1．2．1用户接口
提供用户使用软件产品是地的接口需求。例如，如果系统的用户通过显示终端进行操作，就必须指定如下要求：
a.对屏幕格式的要求；
b.报表或菜单的页面打印格式和内容；
c.输入输出的相对时间；
d.程序功能键的或用性。
1．2．2硬件接口
要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜：支撑什么样的设备，如何支撑这些设备，有何约定。
1．2．3软件接口
在这里应指定需使用的其他软件产品（例如，数据管理系统，操作系统，或者数学软件包），以及同其他应用系统之间的接口。
对每一个所需的软件产品，要提供如下内容：
a.名字；
b.助记符；
c.规格说明号；
d.版本号；
e.来源。
对于每一个接口，这部分应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，这里不必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。
1．2．4通信接口
这里指定各种通信接口，例如，局部网络的协议等等。
1．3性能需求
从整体来说，本条应该具体说明软件、或人与软件交互的静态或动态数值需求。
a.静态数值需求可能包括：
(1) 支持的终端数;
(2) 支持并行操作的用户数;
(3) 处理的文卷和记录数；
(4) 表和文卷的大小。
b．动态数值需求可能包括：
欲处理的事务和任务的数量，以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量。所有这些需求都必须用可以度量的术语来叙述。例如，95%的事务必须在小于1s时间内处理完，不然，操作员将不等待处理的完成。
1．4设计约束
设计约束受其他标准、硬件限制等方面的影响。
1．4．1其他标准的约束
本项将指定由现有的标准或规则派生的要求。例如：
a.报表格式；
b.数据命名；
c.财务处理；
d.审计追踪，等等。
1．4．2硬件的限制
本项包括在各种硬件约束下运行的软件要求，例如，应该包括：
a.硬件配置的特点（接口数，指令系统等）；
b.内存储器和辅助存储器的容量。
1．5属性
在软件的需求之中有若干个属性，下面指出其中的几个（注意：对这些决不应理解为是一个完整的清单）。
1．5．1可用性
可以指定一些因素，如检查点、恢复和再启动等，以保证整个系统有一个确定的可用性级别。
1．5．2安全性
这里指的是保护软件的要素，以防止各种非法的访问、使用，修改、破坏或者泄密。这个领域的具体需求必须包括：
a.利用可靠的密码技术；
b.掌握特定的记录或历史数据集；
c.给不同的模块分配不同的功能；
d.限定一个程序中某些区域的通信；
e.计算临界值的检查和。
1．5．3可维护性
这里规定若干需求以确保软件是可维护的。例如：
a.软件模块所需要的特殊的耦合矩阵；
b.对微型装置指定特殊的数据/程序分割要求。
1．5．4可转移/转换性
这里规定把软件从一种环境移植到另一种环境所要求的用户程序，用户接口兼容方面的约束等等。
1．5．5警告
指定所需属性十分重要，它使得人们能用规定的方法去进行客观的验证。
1．6其他需求
根据软件和用户组织的特性等，某些需求放在下面各项中描述。
1．6．1数据库
本项对作为产品的一部分进行开发的数据库规定一些需求，它们可能包括：
a.在3.1.1条中标识的信息类别；
b.使用的频率；
c.存取能力；
d.数据元素和文卷描述符；
e.数据元素、记录和文卷的关系；
f.静态和动态的组织；
g.数据保存要求。
注：如果使用一个现有的数据库包，这个包应在“软件接口”中命名，并在那里详细说明其用法。
1．6．2操作
这里说明用户要求的常规的和特殊的操作。
a.在用户组织之中各种方式的操作。例如，用户初始化操作；
b.交互作用操作的同期和无人操作的周期；
c.数据处理支持功能；
d.后援和恢复操作。
注：这里的内容有时是用户接口的一部分。
1．6．3场合适应性
这里包括：
a.对给定场合、任务或操作方式的任何数据或初始化顺序的需求进行定义。例如，栅值，安全界限等等。
b.指出场合或相关任务的特点，这里可以被修改以使软件适合特殊配制的要求。
[解决办法]
http://baike.baidu.com/view/671802.htm#5
[解决办法]
这么多了，我也借鉴下。
[解决办法]
根据客户需求分析可行性并文档化出来:能实现的,不能实现的都标注好.
