http://blog.csdn.net/truewaylee/archive/2006/05/20/746232.aspx

5 软件需求 

SRS中每一个软件需求是要求开发软件产品的某些基本功能和性能的一个陈述。 

5.1 表达软件需求的方法 

软件需求可以用若干种方法来表达： 

a. 通过输入、输出说明； 

b. 使用代表性的例子； 

c. 用规范化的模型。 

5.1.1 输入、输出说明 

用输入输出序列来描述一个软件产品所要求的特性是很有效的。 

5.1.1.1 途径 

根据被描述的软件的性质，至少有三种不同的途径： 

a. 有些软件产品（如报表系统）要求着重说明输出。一般情况下，致力于输出的系统主要是在数据文卷上操作。用户的输入通常是致力于提供控制信息和启动数据文卷的处理； 

b. 有些软件产品需要着重说明输入、输出特性。关注输入、输出的系统主要是在当前的输入上操作，要求生成与输入相匹配的输出（类似于数据转换例行程序或一个数学函数包）； 

c. 还有一些系统（如过程控制系统）要求记忆它们的状态。可以根据本次输入和上一次输入进行应答。也就是说，它的行为如同一个有限状态机。在此种情况下，既要关注输入/输出对，又要关注这些输入/输出对的次序。 

5.1.1.2 困难 

多数软件产品可能接收无限的序列作为输入，于是，为了通过输入输出序列完整地说明产品的特性，就要求SRS包括一个无限长的输入和所需的输出充列。然而，用这样的途径不可能完整地描述软件所要求的一切特性。 

5.1.2 典型例子 

一种选择是用典型例子来说明要求的特性。例如，假设一个系统中当接收“0”时用“1”来回答。显然，要列出全部输入和输出序列是不可能的。然而，用典型的序列可以十分清楚地理解系统的特性。下面是一组四种对话的典型的例子，用它描述系统特性。 

0101 

010101010101 

01 

010101 

这些对话仅提供了要求的输入和输出之间的关系，但是不能完全描述系统的特性。 

5.1.3 模型 

另一种表达需求的方法是模型的方式，这是表达复杂需求的精确和有效方法。 

至少可以提出三种可供使用的通用模型：数学型、功能型、计时型。 

应注意区别各种模型的应用场合，参考5.1.3.5。 

5.1.3.1 数学模型 

数学模型是使用数学关系描述软件特性的模型。数学模型对某些特殊应用领域是特别有用的。例如，导航、线性规划、计量经济、信号处理和气象分析等。 

用数学模型能够对5.1.2中所讨论的典型例子描述如下： 

（01）*。 

这里，“*”号表示括号内的字符串可以重复一次或多次。 

5.1.3.2 功能模型 

功能模型是提供从略语以输出映象的模型。象有限状态机或Petri网，这些功能模型可以有助于标识和定义软件的各种特点，或者可以表示系统所要进行的操作。 

对前面用数学模型描述的例子。可用图1所示的有限状态机形式的功能模型来描述。图中进入的箭头表示启动状态。双线的方框表示接收状态。在各线记号x/y的含义是：x代表接受的输入，而y是产生的输出。 

5.1.3.3 计时模型 

计时模型是一种增加了时间限制的模型。这种模型对于表达软件特性的形式和细节特别有用。尤其是实时系统或考虑人为因素的系统。 

计时模型可以把下列限制加到图1的模型中去： 

a. 激活因素0将在进入S1状态30S之内出现； 

b. 响应1将在进入S2状态2S之内出现。 

5.1.3.4 其他模型 

队了上面提及的模型外。对一些特殊的应用还有一些特别有用的模型。例如，编译程序的说明可以使用属性文法，工资单系统可以使用表格。要注意的是，对SRS使用形式需求语言，通常含有使用特殊模型的意思。 

5.1.3.5 警告 

无论使用哪一类型的模型，都要： 

在SRS中或在SRS涉及到的一个文件中对它严格定义。这个定义应该规定： 

a. 模型中的参数所要求的范围； 

b. 使用时的限定值； 

c. 结果的精确度； 

d. 负载的能力； 

e. 要求的执行时间； 

f. 缺省或失败时的响应。 

必须注意，在需求的定义域内要保持一个模型定义。每当一个SRS使用一个模型时： 

a. 它意味着此模型提供一个十分有效和精确的方法说明需求； 

b. 并不意味着软件产品的实现必须基于这个模型。 

一个模型用于解释文件所写的需求是有效的，但是对于实际软件的实现可能并不是最适宜的。 

5.2 软件需求的注释 

有关软件产品的所有需求，并不是同等重要的。某些需求可能是基本的，例如是对于生命攸关的应用。而另一些可能并不那么重要。 

SRS中每一个需求必须进行注释，以便区别其重要的程度。 

有这种方法注释需求，可以： 

a. 帮助客户对每一个需求给予更周密的考虑，通常可以在需求中澄清隐藏的假设； 

b. 帮助开发者做出正确的设计决定，并对软件产品不同部分作出相应的努力。 

5.2.1 稳定性 

注释需求的一种方法是使用稳定性量纲。当一个需求在软件预期的生存期间内描述不改变的话，可以认为该需求是稳定的，否则可以认为是易变的。 

5.2.2 必要性等级 

注释的另一种方法是把需求分成必须保证级、期望级和任选级。 

a. 必须保证是指软件必须和这些需求相一致，否则该软件不可能被接受； 

b. 期望是指这些需求将提高软件产品的功能，但是如果缺省的话也是可接受的； 

c. 任选是给开发者一个机会，可以提供某些超出SRS规定的目标。 

5.2.3 注意事项 

在注释需求之前，必须彻底理解这种注释的实质性含义。 

5.3 在表达需求时遇到的共同弊病 

SRS的基本点是它必须说明由软件获得的结果，而不是获得这些结果的手段。 

编写需求的人必须描述的基本问题是： 

a. 功能——所设计的软件要做什么； 

b. 性能——是指软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等； 

c. 强加于实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准； 

d. 属性——可移植性、正确性、可维护性及安全性等方面的考虑因素； 

e. 外部接口——与人、硬件、其他软件和其他硬件的相互关系。 

编写需求的人应当避免把设计或项目需求写入SRS之中，应当对说明需求设计约束与规划设计两者有清晰的区别。 

5.3.1 在SRS中嵌入了设计 

在SRS中嵌入设计说明，会过多地约束软件设计，并且人为地把具有潜在危险的需求放入SRS中。 

5.3.1.1 SRS必须描述在干什么数据上、为谁完成什么功能、在什么地方、产生什么结果。SRS应把注意力集中在要完成的服务目标上。通常不指定如下的设计项目： 

a. 把软件划分成若干模块； 

b. 给每一个模块分配功能； 

c. 描述模块间的信息流程或者控制流程； 

d. 选择数据结构。 

5.3.1.2 把设计完全同SRS隔离开来始终是不现实的。安全和保密方面的周密考虑可能增加一些直接反映设计约束的需求。例如： 

a. 在一些分散的模块中保持某些功能； 

b. 允许在程序的某些区域之间进行有限的通讯； 

c. 计算临界值的检查和。 

5.3.1.3 通常应考虑到，若要为软件选择高层次的设计，就可能需要大量的资源（可能占整个产品开发成本的10%-20%以上）。有两种选择： 

a. 不顾本指南的警告，在SRS中描述了设计。这意味着，或者将一个潜在不适当的设计作为一个需求进行描述（因为，若要得到好的设计，所花费的时间是不够的），或者在需求阶段花费了过多的时间（因为在SRS完成之前整个设计分析都要完成）； 

b. 采用本指南中5.1.3条中的建议，用模型设计描述需求，这种模型设计只用于辅助描述需求，而不使之成为实际的设计。 

5.3.2 在SRS中嵌入了一些项目要求 

SRS应当是描写一个软件产品，而不是描述生产软件产品的过程。 

项目要求表达客户和开发者之间对于软件生产方面合同性事宜的理解（因此不应当包括在SRS中）例如： 

a. 成本； 

b. 交货进度； 

c. 报表处理； 

d. 软件开发方法； 

e. 质量保证； 

f. 确认和验证的标准； 

g. 验收过程。 

项目需求在另外的文件中描述。在SRS中提供的只是关于软件产品本身的需求。

给你一个地址，自己参考这个去做吧！！
    我以前也不爱学习，现在很痛苦****……
          希望你不要步我后尘…………
http://blog.csdn.net/nonsenser/archive/2006/01/07/573011.aspx

VC真的好难啊，希望各位高手帮帮我们啊，谢谢了啊....