我对需求分析与建模的认识与应有内容建议

1.什么是软件需求呢
目前，世界上几乎所有的国家都在使用复杂的计算机系统，越来越多的产品把计算机和控制软件以一定的方式结合起来，软件工程作为一门工程学科，他的目标在于使软件系统往更好的更高性价比的方向发展。
所有的软件工程都具有以下的基本活动：
（1）软件描述：软件的功能以及软件操作上的约束必须定义；（2）软件设计与软件实现：软件一定要按照描述来生产；（3）软件有效性验证：软件要被确定是有效的，能做客户想要做的事情才可以；（ 4）软件进化：软件一定要按照客户的变化与跟进来进化。
其中，软件描述，目标是确定软件系统需要哪些服务以及开发和运行期间受到哪些约束。对服务和约束的发现、分析、建立文档、验证活动现在常称为需求工程。
需求工程对于软件过程是一个特别关键的阶段，这个阶段的错误将不可避免地带到后续的系统设计和实现阶段中。需求工程阶段的独特之处在于很少有现成模式或特制的文档可供参考。后续阶段可以建立在前期所做工作基础上（各种相关模型至少在一定程度上可以衍生导出），而需求工程阶段的成果却是靠创建而来的———几乎就是从无到有。
2.需求的过程
需求工程本身就是一个过程，这个过程产生用以描述系统的需求文档。通常需求在这个文档中被分成两个层次描述：最终用户和客户需要高层次的需求描述；而系统开发人员需要比较详细的系统描述。
需求过程的四个主要阶段：
1．可行性研究 指明现有的软件、硬件技术能否实现用户对新系统的要求。从业务角度来决定系统开发是否划算以及在预算范围内能否开发出来。可行性研究是比较便宜和省时的。结果就是要得出结论，该系统是否值得进行更细致的分析。
2．需求的导出和分析 这是一个通过对现有系统分析、与潜在用户和购买者讨论、进行任务分析等导出系统需求的过程。也可能需要开发一个或多个不同的系统模型和原型。这些都会帮助分析员了解所要描述的系统。
3．需求描述 需求描述就是把在分析活动中收集的信息以文档的形式确定下来。在这个文档中有两类需求。用户需求是从客户和最终用户对系统需求的抽象描述；系统需求是对系统要提供的功能的详尽描述。
4．需求有效性验证 这个活动检查需求实现、一致和完备。在这个过程中，不难发现需求文档中的错误，然后必须加以改正。
当然，需求过程中的各项活动并不是严格按顺序进行的。在定义和描述期间，需求分析继续进行，这样在整个需求工程过程中不断有新的需求出现。因此，分析、定义和描述是交替进行的。

3.软件系统需求
软件系统需求常常分为功能需求、非功能需求和领域需求三个方面：
功能需求 ， 包括对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。在某些情况下，功能需求可能还需要明确申明系统不应该做什么。
理论上，系统的功能需求描述应该既全面又具有一致性。全面意味着用户所需的所有服务都应该给出描述。一致性意味着需求描述不能前后矛盾。在实际过程中，对大型而又复杂的系统而言，要做到需求描述既全面又一致几乎是不可能的。一方面是因为系统固有的复杂性，另一方面是因为观点不同，需求也会发生矛盾。
非功能需求 ， 对系统提供的服务或功能给出的约束。包括时间约束、开发过程约束、标准等。非功能需求愿于用户的限制，包括预算上的约束、机构政策、与其他软硬件系统间的相互操作，还包括如安全规章、隐私权利保护等外部因素。
领域需求 ， 这是来自系统的应用程序领域的需求，反映了该领域的特点。他们也可能是功能需求或非功能需求。
软件需求文档
软件需求文档有时叫做软件需求描述（SRS）是对系统开发者要求的正式陈述。IEEE标准为需求文档提出了以下结构：引言（目的、范围、缩略词等），一般描述（产品透视、功能、用户特征、约束等），专门需求（功能、非功能、接口），附录，索引。
4.需求问题具体原因分析
软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或应用不坚决，它会导致软件开发者产生轻视需求的态度问题。除此之外，还有一些技术原因也会导致需求问题的产生。
1.非技术性和 会性因素重视不足
应用型软件的模拟特性使得需求处理具有很突出的特性。相对于软件开发的其他阶段而
言，需求处理阶段涉及更多的非技术性和 会性因素，并且其所受的影响也远远高于其他阶段。
20世纪90年代之前的需求处理往往更专注于技术处理，而对其中的非技术性和 会性因素重视不足。
需求建模与分析是需求处理中的核心活动，它用一些形式化或半形式化的语言进行知识
的描述。一方面，只有通过建模与分析才能将混乱、模糊的用户需求变成清晰、明确的软件需求，所以它是获取需求处理活动的必然后继，它建立的分析模型是需求处理中最为重要的成果；另一方面，建模与分析的理论可以帮助人们系统化地看待问题，它可以根据理论或分析中出现的各种现象指导其他需求处理活动更好地进行。因此，建模与分析活动在需求处理中具有非常重要的地位，以至于人们理所当然地把需求处理工作的重心部署在建模与分析活动中，放在对建模技术的理解和运用上，甚至在传统的软件开发生命周期中用“需求分析”一词指代整个需求处理阶段。
但在需求处理阶段除了需求建模与分析活动之外，还有其他的活动也应得到重视，理解需求处理中涉及的非技术性和 会性因素与理解建模分析技术一样必要，否则同样会导致软件的失败，这些因素包括组织机构文化、 会背景、商业目标、利益协商等。
1)从需求处理的任务来看，需要重视非技术性和 会性因素
需求处理的主要任务是发现问题并解决问题。现实是问题的发生地，软件系统是人们应对问题的手段。但是单纯的软件系统是不能解决问题的，它只有和现实之间形成一种有效的互动才能解决问题。因此，相对于软件系统的构造问题，人们更应该关注软件系统和现实之间的互动效应。也就是说，需求处理不应该以新系统的功能性和内在特征为主要处理目标，而是更应该集中精力于分析环境的构成、现状和它们将来能与软件达成的期望互动效应。因此，作为软件系统环境的组织机构文化、 会背景和系统涉众（stakeholder,是指将会受到软件系统的影响，并能够直接或间接影响系统需求的个人、团体或组织）的目标与利益比软件内部的数据流与状态更应该得到重视。
2)从需求处理的手段来乔，需要重视非技术性和 会性因素
建供与分析技术是进行需求处理的主要手段，这些技术本身都是概念性的，不依赖于
殊的应用环境条件，可以被广泛应用于各种应用场景。但是利用这些技术构建的解决方
是和具体应用环境相关的，不存在不依赖于具体应用环境的解决方案。因此，在利用建检
技术进行需求处理时，不能忽视具体应用环境中的相关因素，例如组织机构的文化、行业
会背景等，都会约束解决方案的构建空间。
3)从需求处理的过程来看，需要重视非技术性和 会性因素
在需求处理的过程中，试图单纯通过技术的运用来建立一个一致、完整的需求模型是不
能的。因为在现实中，因涉众的不同立场而产生利益冲突的情景非常常见，这些冲突是框
的，是无法单纯通过技术手段所能解决的。因此，在需求处理的过程中，要重视非技术性和
性因素所导致的问题的解决，面对冲突要能够分析 会原因和组织机构方面的原因，引导涉
行利益协商，进而建立一个一致、完整的需求模型。
5.问题域（应用领域）
问题所存在的现实世界中的那个部分。问题域是需求分析员所要研究的首要对象。就一个电梯控制系统来说，它将包含任何现存的硬件（电梯、指示器、传感器、按钮等）、建筑物特征（楼层和电梯井的数目）、预期的使用模式、用户特征、使用约束（如限制短途搭乘）等等。在这个问题域内，问题可以确定为“让电梯在建筑物中更有效使用的控制系统”。为了解决问题，‘解系统’显然有必要在问题域内产生某些效果，构成软件需求的正是这些想要获得的效果，也就是为何做软件需求的原因和目的。
定义了三个主要软件开发活动的阶段任务。分析，关注问题域和存在于其中的问题，目的在于真实的了解问题域。 规格说明，关注问题域与解系统之间的相互关系，定义了系统预期的目标。设计，关注解系统内部的运作实现，构建计算机中的“现实世界”即软件（不属于需求工程部分）。
到现在为止，我们得到初步论点。在构建一个新软件系统之前，最好先决定它应当能够做些什么又不要做些什么；从问题域的研究入手，获得问题的描述，以及新的解系统在其中将产生效果的陈述（即需求）；确定新系统所需的行为，以便让它在问题域内产生所需要的效果。
需求分析
通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明。需求分析旨在揭示一个现有的系统（问题域）的结构，而内部设计则是要创建出一个尚未存在的软件系统（解系统）的结构。对于这一重要任务其特性如下：
分析关注问题域及对其建立的模型，而不是解系统；
主要目标是要获得对问题域及存在于其中的问题本质的理解；
分析在本质上先于解系统行为的规格说明（尽管有重叠和反复的过程）。
方法论
方法不只是一种技术，它是解决任务的一种途径，并且通常由一组技术组成。任何分析方法，要使它得到很好的利用，都应当要求并且做到便于描述以下几个方面：
1.问题域的结构，根据其子域及其相互间的关系；
2.问题域数据，语法和语义方面
3.问题子域的内在属性和行为；
4.问题域中的重要事件及现象；
5.需求，解系统在问题域中应产生的效果。
结构化分析（SA）是一种具有相当长历史的分析方法，其演化的方式既微妙又显得很重要。如同结构化编程一样，它致力于系统范围内的事物处理，数据流以及存储数据结构的建模。建模主要包括数据流模型（DFD），数据字典（DD），实体关系图（ERD）。
结构化分析所用的原型，无论是对开发者还是客户都显得直观易懂，若将初始重点放在对原有系统的建模是对实现理解问题域这一基本的分析目标的有力支持。
结构化分析方法和人们的思维方式和相似，注重的是事物的过程和方面。利用结构化分析很容易去理解一个刚刚接触的问题域，适合对比较生疏领域做软件需求。
建模技术
系统建模总的来说是软件开发过程中、尤其是需求工程中的一个极其重要的部分。相关建模技术之间的最重要区别在于他们是构成系统的外部模型还是构成系统的内部模型。
外部模型
外部模型可进一步划分为建模系统外观的模型和建模系统行为的抽象模型。
表示建模
表示模型是对系统外观进行的模仿，相当于描述可见的输出，最有效的表示法通常是画图。这种技术特有的优点是易于获得工具支持、模糊性低、不易出错和可理解性高。对软件系统定义而言，它并不是全部的内容，只是一个从中起着有效作用的基本元素。
原型法
原型在其他工程领域有着历史悠久的传统，但在软件工程中，使用原型是最近几年的事情。合算的开发原型需要相对强有力的开发平台，好在现在已经没有了技术障碍，原型开发得到了快速的采用。原型可以为各种目的而购造，与需求工程相关的是那些试图绘制所需系统的外观和一些可能的行为的原型。
对原型一个普遍认同的分类：
探索性原型——帮助需求获取或细化需求，也称为一次性原型，一旦需求工程完成后，它便没有用处。
定义原型——形成部分所需行为的定义，即部分规格说明。
结构原型——用于评价可能的内部设计方案，例如检查性能。虽然是用于设计阶段，但也用于需求阶段可行性的检查。
演化原型——通过逐步求精过程，原型最终成为了产品。
需求工程主要关注的是前两种原型，原型开发隐含着迭代。如在需求获取中：初始原型将向用户演示，获得的反馈将用于细化原型，在实践中这种迭代会出现好几次。迭代中可能会增加新内容，也可能减少内容。
原型在需求工程中主要作用是对用户接口进行建模，尤其是当这些接口相当复杂、关键、新鲜时。原型开发的一个潜在好处是：可以促进潜在用户的参与和客户的承诺，但有个副作用：真实原型的早期外观会误导人们认为该项目比实际情形先进得多，随着最终产品的出现就会感到失望。
行为（功能）建模
行为模型只是系统行为的抽象。行为建模有很多种，我们就较一般的可能用到的简单介绍几个：

1. 功能声明与分解
   功能声明也许是最简单、常用的行为定义技术。声明使用文本方式，描述输入和输出之间的因果关系。功能分解可以说是一种高级策略，通过许多其他方式实现，如Use-Case 、DFD 、结构图。基本思想相当简单，通常系统功能性的详细定义是按层次结构来实现的，即通过把功能分解为若干低层的、更为详细的功能集。该技术也称为功能求精或功能组合。
2. 任务分析
   任务分析，涉及的是人的任务性能的分析或外部设计，特别用于人机接口（HMI）。任务分析从人们所希望获得的目标开始。任务是获得这些目标的高级机制，操作是实现任务的交互。
3. 用例与脚本
   用例（use-case）描述所设计的解系统与一个或多个端子之间的某种特定的交互。
   用例在面向对象领域主要作为一种分析和规格说明的技术。对新系统将投入使用的环境进行分析相当于研究该系统所必须满足的要求。事实上，情形可能是客户和潜在用户确实发现用例易于理解，因此，用例就有助于客户/用户与开发者之间的交流。大多数用例都有“执行者”，可以是人，也可能是系统的软硬件设施。用例文档可以用文本或UML图来描述。用例的应用和构造具有相当大的灵活性，人们可能认为它不够严格，但是应用指定的合适的指导原则可以解决这个问题。

参考文献
[1][英] Ian Sommerville：《软件工程》，中信出版 ，2003年7月
[2]王智学：《ROSE对象建模方法与技术》，机械工业出版 ，2003年7月
[3][美] KARL E.WIEGERS：《软件需求》，机械工业出版 ，2000年7月
[4][英] Ian K Bray：《需求工程导引》，人民邮电出版 ，2003年9月
[5][美] David C.Hay：《需求分析》，清华大学出版 ，2004年5月
[6][丹] Soren Lauesen：《软件需求》，电子工业出版 ，2002年10月
[7]《Rational Unified Process》，电子版，不详
[8] http://law.hr.com.cn/6.php
[9] http://www.sawin.com.cn
[10] http://www.iturls.com/SoftwareEngineering/SE_3d.asp