_____浮云____
软件需求说明书的主要作用是什么？
软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，需求分析是要决定“做什么，不做什么”。
在一个软件项目中，软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求：业务需说明了提供给客户和产品开发商的新系统的最初利益，反映了组织机构或客户对系统、产品高层次的目标要求。
软件开发，能否获得成功，最重要的是需求分析的工作。
因此，软件需求分析能力和水平，对软件项目至关重要。
一般的分析方法和步骤如下：⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。
由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有： ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准确地理解用户的需求，但比较耗费时间。
⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。
座谈时，参加者之间可以相互启发。
⑶请专人介绍。
⑷询问 对某些调查中的问题，可以找专人询问。
⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
⑹查阅记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。
通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
什么是软件需求,什么是功能需求？
软件需求的定义；IEEE软件工程标准词汇表（1997年）中定义需求为：（1）用户解决问题或达到目标所需的条件或权能（Capability）。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
简单的就是：用户需求；用户需要在应用系统中实现什么东西，为实现这个目标，需要用户提供的全部的详细的业务说明，业务流程，表格样式等。
功能需求；将用户需求归类分解为计算机可以实现的子系统和功能模块，用设计语言描述和解释用户的需求，以达到可以指导程序设计的目的。
...
软件需求分析的作用及如何进行需求分析？
软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。
需求分析是介于系统分析和软件设计阶段之间的桥梁。
一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。
良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。
需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。
后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。
随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。
人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。
80年代中期，形成了软件工程的子领域——需求工程（requirementengineering,RE）。
进入90年代以来，需求工程成为研究的热点之一。
从1993年起每两年举办一次需求工程国际研讨会（ISRE），自1994年起每两年举办一次需求工程国际会议（ICRE），在1996年Springer-Verlag发行了一新的刊物——《RequirementsEngineering》。
一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups)，并开始开展工作。
需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
RE可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。
软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。
需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。
80年代，HerbKrasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理。
近来，MatthiasJarke和KlausPohl提出了三阶段周期的说法：获取、表示和验证。
综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段： （1）需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求； （2）需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义； （3）形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约； （4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性； （5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。
什么是软件需求什么是功能需求
软件需求包括 3 个不同的层次――业务需求、用户需求和功能需求。
除此之外，每个系统还有各种非功能需求。
业务需求（Business requirement）表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。
使用前景和范围（ vision and scope ）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（ project charter 或 market requirement ）文档。
用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。
用例、场景描述和事件――响应表都是表达用户需求的有效途径。
也就是说用户需求描述了用户能使用系统来做些什么。
功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
功能需求有时也被称作行为需求（ behavioral requirement ），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什么。
系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。
系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。
人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。
业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。
然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。
有时，功能中特定的质量属性（通过功能实现）也源于业务规则。
所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求说明书（ SRS ）中。
SRS 完整地描述了软件系统的预期特性。
SRS 我们一般把它当作文档，其实， SRS 还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。
开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。
除了功能需求外， SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。
质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。
这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。
其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。
约束（constraint）限制了开发人员设计和构建系统时的选择范围。
行业需求：企业在招聘软件测试人员时主要看中应聘者的项目经验、逻辑思维能力、一定的技术能力和综合素质，而对学历、年龄、性别、工作经验等的要求较低，相对于IT行业其他职位而言，软件测试的入行更加容易。
软件工程的意义和作用
软件工程是计算机专业的一门重要的专业基础课，它对于培养学生的软件素质，提高学生的软件开发能力与软件项目管理能力具有重要的意义.1995年，Standish Group针对系统开发成功的研究表明，所有的开发项目中有32%的项目在它们结束之前被中止.此外多于一半的软件项目花费的成本相当于原来预算的2倍.软件工程只有42%的软件项目完成时达到了预期的范围和功能，事实上，许多系统只完成了部分预期的需求.因此，软件的开发是一个很困难的活动，要求很仔细的计划和执行.软件工程就是在这样的背景下，由许多计算机科学家经过多方面的探索和总结而成形的.目前发展十分迅速 近二十年来计算机软件已经成为现代科学研究和解决工程问题的基础，以及管理部门，生产部门，和服务行业中的关键因素，渗透到了各个领域，成为当今世界不可缺少的一部分.展望二十一世纪，软件仍将成为驱动任何事情从基础教育到遗传工程取得新进展的动力.学习研究工程化的软件开发方法，使开发过程更加规范.软件工程（SoftWare Engineering）的框架可概括为：目标、过程和原则。
(1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。
正确性指软件产品达到预期功能的程度。
可用性指软件基本结构、实现及文档为用户可用的程度。
开销合宜是指软件开发、运行的整个开销满足用户要求的程度。
这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。
(2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。
软件工程过程主要包括开发过程、运作过程、维护过程。
它们覆盖了需求、设计、实现、确认以及维护等活动。
需求活动包括问题分析和需求分析。
问题分析获取需求定义，又称软件需求规约。
需求分析生成功能规约。
设计活动一般包括概要设计和详细设计。
概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。
详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。
实现活动把设计结果转换为可执行的程序代码。
确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。
维护活动包括使用过程中的扩充、修改与完善。
伴随以上过程，还有管理过程、支持过程、培训过程等。
(3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。
需求工程的重要性是什么？
需求工程的重要性主要表现在： 增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解， 增强了项目涉众对需求（ 尤其是复杂需求） 的掌握 ； 增进了项目涉众之间的交流， 减少了可能的误解和交流偏差； 需求管理能够更加有效地处理需求变更，提高了生产效率； 需求跟踪信息能够更加准确地反映项目的进展情况，以便进行更好的项目决策； 使得项目涉众认识到需求在项目工作中的重要性， 使得需求的作用得到重视和有效发挥。
良好的需求分析和管理工作， 才能把系统的功能描述和性能指标转化为具体的软件需求规格说明书，成为系统建设的依据和基础。
需求工程的内容需求获取阶段需求获取首先需要的是技术的支持，其次，在需求获取工作中主要涉及了 3 个至关重要的因素：应搜集什么信息；从什么来源中搜集信息；用什么机制或技术搜集信息。
再次，需求获取的开始，代表着软件项目正式开始实施，正所谓万事开头难。
综合上述 3 个点使得需求获取成为软件开发中最困难、最关键、最易出错也是最需要交流的方面。
在工作开展中，主要是就业务流程、组织架构、软硬件环境和现有系统等相关内容进行沟通，挖掘系统最终用户的真正需求，把握需求的方向。
在需求获取调研会中首先对需求获取方法作了验证。
现行的需求获取方法一般有基于调查的需求获取方法、基于用例的需求获取方法、原型法等几种方法。
各种需求获取方法各有利弊。
需求分析阶段需求分析与需求获取是密切相关的，需求获取是需求分析的基础，需求分析是需求获取的直接表现，两者相互促进，相互制约。
需求分析与需求获取的不同主要在于需求分析是在已经了解承建方的实际的客观的较全面的业务及相关信息的基础上，结合软、硬件实现方案，并做出初步的系统原型给承建方做演示。
承建方则通过原型演示来体验业务流程的合理化、准确性、易用性。
同时，用户还要通过原型演示及时地发现并提出其中存在的问题和改进意见和方法。
需求文档编写阶段需求开发的最终成果是，在对所要开发的产品达成共识后，所编写的具体的文档。
需求文档是在需求获取和需求分析两个阶段任务结束时生成的，所以文档要包含所有需求。
在此阶段先要从软件工程和文档管理的角度出发依据相关的标准审核需求文档内容，确定需求文档内容是否完整。
对需求文档中存留问题进行修改的工作。
需求确认阶段需求确认主要是针对《需求规格说明书》的评审，保证需求符合优秀需求成熟的特征，并且符合好的需求规格说明的特征。
在需求确认阶段需要保证以下几点：（1）软件需求规格说明正确描述了预期的满足各方涉众需求的系统能力和特征。
（2）从系统需求、业务规则或其他来源中正确的推导出软件需求。
（3）需求是完整的、高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行产品设计和构造提供充分的基础。
需求跟踪阶段与需求复用阶段需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，确保产品依据需求文档进行开发，建立与维护“需求——设计——编程——测试”之间的一致性，确保所有工作成果符合用户需求。
需求跟踪是一项需要进行大量手工劳动的任务，在系统开发和维护的过程中一定要随时对跟踪联系链信息进行更新。
需求跟踪能力的好坏会直接影响产品质量，降低维护成本，容易实现复用，同时，需求跟踪还需要建设方的大力支持。
需求复用阶段在软件项目实施过程中，许多不同项目间存在着许多相似的需求，尤其是类型相同的项目在不同的用户群众的实施中，需求的相似性就更加明显、更加普遍了。
有了需求复用，建设方就能快速的形成一个需求的原型，这样，后期的需求工作只需要在此原型的基础上进行修改、扩充和完善即可，大大提高了需求分析的工作进度。
所以，对于需求的复用就需要加以重视。
对于需求复用，首要责任就是要提取可复用的需求，对需求复用的理解和扩充。
其次就是要保证需求复用不存在冲突。
需求变更控制阶段需求变更在软件项目开发中是不可避免的。
无休止的需求变更只会造成各种资源无休止的浪费，但是其中也不乏有许多是必要的、合理的需求变更。
对于需求变更，首先是要尽量及早的发现，以避免更大的损失。
其次，是要采取相应的、合理的变更管理制度和流程，这样同样可以降低需求变更带来的风险。
版本控制阶段版本控制是管理需求规格说明和其他项目文档必不可少的一个方面，也是需求变更文档化管理的最有效办法。
可以详细记录发生需求变更的需求文档版本的版本，发生变更的原因，变更发生的控制记录，并对变更后的需求文档进行唯一版本号的标识。
使得每个成员都能及时访问最新版本的需求文档。
实施版本控制的基础是需求基线，所谓需求基线就是项目组成员一经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合。
需求基线的确定可以保证项目的涉众各方可以对发布的产品中希望具有的功能和属性有一个一致的理解。
软件需求工程有哪些过程？
一、 开始 1. 项目经理根据项目特点，指定对过程表格的具体要求； 2. 项目经理制订项目的标准，包括：DTS（缺陷类型）、TRA（风险类型）、TRS（需求类型）等，在过程表格中按标准引用. 二、 计划 1. 计划经理估算需求开发时间； 2. 计划经理完成：SPT（进度计划）、TPT（任务计划），将计划数据录入PDS（项目计划摘要）. 三、 需求获取 1. 软件需求工程师搜集系统概要信息，填写REQ（需求获取概貌）； 2. 软件需求工程师搜集用户需求，分类并清晰地把需求写入REA（需求获取/分析）、RES（需求获取情节）、UIR（用户交互需求）； 3. 检查需求获取过程，并填写REC（需求获取检查）； 4. 如果检查不通过，从1.重头开始过程； 5. 软件需求工程师填写TRL（时间记录日志）、PIP（过程改进建议）； 6. 计划经理整理本阶段数据，录入SPT、TPT. 四、 需求分析 1. 软件需求工程师进行需求分析，建立分析模型，数据字典及项目词汇表，完成REA（分析模型的具体要求，请分别参见结构化分析和面向对象分析的具体作业指导书）； 2. 软件需求工程师将发现的需求的冲突、交迭、冗余或矛盾，记入NCR; 3. 检查需求分析，完成RAC（需求分析检查）； 4. 如果检查不通过，从1重头开始过程； 5. 软件需求工程师填写TRL、PIP; 6. 计划经理整理数据，录入TPT、SPT. 五、 协商 1. 软件需求工程师利用NCR，与风险承担者协商解决需求分析中发现的问题，将决议录入NCR; 2. 软件需求工程师根据决议，修改REA等相关文档； 3. 如果有新的需求引入，需要重新进行需求分析阶段； 4. 软件需求工程师填写TRL、PIP; 5. 计划经理整理数据，录入TPT、SPT. 六、 需求评审 1. 评审小组负责人拟定检查清单，为成员分派检查任务，制订评审日程表； 2. 评审员各自评审分派的内容，将发现的问题录入DRL（缺陷记录日志）； 3. 评审小组负责人组织评审会议，各小组成员提交DRL并讨论； 4. 评审小组以IRF形式提交检查报表； 5. 软件需求工程师根据IRF修订相关文档； 6. 计划经理整理数据，录入TPT、SPT。
七、 需求文档编写 1. 软件需求工程师综合考虑功能需求和非功能需求，编写《软件需求说明书》 《软件需求说明书》的编写格式与要求，请参见具体的作业指导书。
2. 利用RDC检查《软件需求说明书》是否全面、正确并可执行； 3. 如果检查不通过，从1重头开始过程； 4. 软件需求工程师填写TRL、PIP; 5. 计划经理整理数据，录入TPT、SPT。
八、 需求确认 1. 评审小组，对需求进行确认： l 确认每一个需求及相互关系； l 需求的总体质量达到标准。
将结果写到RVC。
2. 软件需求工程师根据RVC，修订需求文档，并最终通过； 3. 软件工程师为每一个需求设计测试用例，并录入TRF; 4. 相关人员填写TRL、PIP; 5. 计划经理整理数据，录入TPT、SPT。
九、 配置管理 1. RD（需求文档）成为基线后，即纳入到配置管理； 2. 如果需要对基线RD（需求文档）进行修改，填写CCP; 3. 配置管理人员征求需求开发小组和其他相关人员（风险承担者）关于CCP的意见； 4. 如果所有人员通过CCP，则将需求文档的配置管理取出，并填写CCF； 如果否决需求，则填写RRF; 5. 软件需求工程师修改RD以适应新的需求 （可能包括REA等）； 6. 评审小组对修改的RD执行第八步； 7. 相关人员填写TRL、DRL. 十、 事后分析 1. 计划经理将DRL、TRL、需求增长率，整理到PPS; 2. 小组分析SREP过程，找出需要改进的地方，填写PIP，并提交质量经理； 3. 小组建立未来过程的改进目标.
