软件需求论述

-.z.定义软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义的"需求〞对开发者似乎是一个较高层次的产品概念。而开发人员所说的"需求〞对用户来说又像是详细设计了。实际上，软件需求包含着多个层次，不同层次是从不同角度与不同程度反映着细节问题用户所需要的并能触发一个程序或系统开发工作的说明。从系统外部能发现系统所具有的满足于用户的特点、功能、属性等。指明必须实现什么样的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束IEEE软件工程标准词汇表〔1997年〕中定义需求为：用户为解决问题或到达目标所需的条件或能力。系统或系统组件为符合合同、标准、标准或其他正式文档而必须满足的条件或必须具备的能力。反映上述①或②所描述的条件或能力的文档说明。需求的层次软件需求包括三个不同的层次。业务需求用户需求功能需求〔包括非功能需求〕业务需求(businessrequirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在工程视图与范围文档中予以说明。用户需求(userrequirement)用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求需求层次之间的联系管理人员或市场分析人员会确定软件的业务需求。这使公司运作更加高效〔对信息系统而言〕或具有很强的市场竞争力〔对商业软件而言〕。所有的用户需求必须与业务需求一致。用户需求使需求分析者能从中总结出功能需求以满足用户对产品的要求从而完成其任务。而开发人员则根据功能需求来设计软件以实现必须的功能。软件需求各组成局部之间的关系术语的定义软件需求规格说明〔softwarerequirementsspecification简称"SRS〞〕在软件需求规格说明中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、工程管理以及相关工程功能中都起了重要的作用。非功能需求作为功能需求的补充，描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、标准和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。约束条件指对开发人员在软件产品设计和构造上所具有的选择限制。字处理程序为例业务需求："用户能有效地纠正文档中的拼写错误〞。用户需求："找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词〞。功能需求：找到并高亮度提示错词的操作。显示提供替换词的对话框实现整个文档范围的替换求的重要性在软件工程工程中，所有的利益相关者〔stakeholder〕都感兴趣的就是需求分析阶段。利益相关者包括客户、用户、业务或需求分析员、开发人员、测试人员、用户文档编写者、工程管理者和客户管理者。需求分析奠定了软件工程和工程管理的根底。需求的重要性：开发软件系统最困难的局部就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，则整条河流也就被污染了。国内软件业的痼疾：人们并不清楚终究该做什么，但却一直忙碌不停地开发。需求缺陷造成的本钱增加重新进展需求规格说明重新设计重新编码重新测试改变订单——告诉用户将以一个修正后的版本来替代有缺陷的版本。纠正活动——消除由于不准确的特定系统的错误造成的危害，可能涉及到赔偿客户损失。报废——包括对于已经完成的代码、设计和测试，当发现它们是根据不正确的需求进展的时候，这些工作成果不得不被丢弃。收回有缺陷的软件产品以及相关的用户手册。产品赔偿或保修的本钱。重新安装新版本的本钱。重新建档的本钱。高质量的需求过程带来的好处在开发后期和整个维护阶段的重做的工作大大减少了。让用户积极参与需求收集过程能使产品更富有吸引力，而且能建立起更加忠实的客户关系。用户的参与能弥补用户期望和开发者实际开发之间的"鸿沟〞〔期望差异〕。将确定的系统需求明确地分配到各软件子系统，确保软硬件系统功能匹配适当。有效的变更控制也能降低需求变更带来的负面影响。将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量。优秀需求说明的特征正确性。完整性。无二义性。必要性。可行性。划分优先级。可验证性。正确性。每一项需求都必须准确地陈述其要开发出的功能性。只有用户代表才能确定用户需求的正确性，这就是为何一定要有用户的积极参与的原因。没有用户参与的需求只是是评审者凭空猜想。完整性。不能遗漏任何必要的需求信息。遗漏需求将很难查出。每一项需求都必须将所要实现的功能描述清楚。开发人员可以从需求规格说明中获得设计和实现这些功能所需的所有必要信息。无二义性。对所有需求说明的读者都只能有一个明确统一的解释。尽量把每项需求用简洁明了的用户性的语言表达出来。防止二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。必要性。每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。"必要性〞也可以理解为每项需求都是用来授权你编写文档的"根源〞。要使每项需求都能回溯至*项客户的输入，如使用实例或别的来源。可行性。每一项需求都必需是在系统和环境的权能和限制范围内可以实施的。最好在获取需求过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他来负责技术可行性上的检查。划分优先级。给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。不划分优先级，将导致工程管理者在开发或节省预算或调度