我对需求分析与建模的认识与应有内容建议
作者：互联网
我对需求分析与建模的认识与应有内容建议
需求分析作为软件工程开发的开始，为了能更好的开发一个软件，我们需要努力掌握需求分析与建模这门课程。
软件需求位于软件工程的起始阶段，是软件系统开发中一个重要的独立工作阶段，为软件工程后续阶段提供了工作基础，对软件项目的成败至关重要。20世纪末，随着软件系统规模的扩大和复杂程度的增长，以需求分析为重心的传统需求处理技术已经不能适应现代软件技术发展的要求，完整的需求工程过程应运而生。需求工程是开发者在进一步深入理解软件项目需求处理活动之后提出的一个阶段性活动。同传统的需求分析相比，在需求工程中，软件需求处理不仅仅停留在单纯的分析与建模，需求的获取、建模、文档化、验证及管理等都是其中必需和重要的工作。
到目前为止，学术界与产业界在需求工程领域取得了较大的进展，研发了一系列有效的需求技术、方法和工具，构成了一个完整的需求工程过程框架。但是，尚有大量理论、方法和技术有待于广泛传播和全面应用，特别是需要进行系统化的实践。
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）。
结构化分析所用的原型，无论是对开发者还是客户都显得直观易懂，若将初始重点放在对原有系统的建模是对实现理解问题域这一基本的分析目标的有力支持。
结构化分析方法和人们的思维方式和相似，注重的是事物的过程和方面。利用结构化分析很容易去理解一个刚刚接触的问题域，适合对比较生疏领域做软件需求。
建模技术
系统建模总的来说是软件开发过程中、尤其是需求工程中的一个极其重要的部分。相关建模技术之间的最重要区别在于他们是构成系统的外部模型还是构成系统的内部模型。
外部模型
外部模型可进一步划分为建模系统外观的模型和建模系统行为的抽象模型。
表示建模
表示模型是对系统外观进行的模仿，相当于描述可见的输出，最有效的表示法通常是画图。这种技术特有的优点是易于获得工具支持、模糊性低、不易出错和可理解性高。对软件系统定义而言，它并不是全部的内容，只是一个从中起着有效作用的基本元素。
原型法
原型在其他工程领域有着历史悠久的传统，但在软件工程中，使用原型是最近几年的事情。合算的开发原型需要相对强有力的开发平台，好在现在已经没有了技术障碍，原型开发得到了快速的采用。原型可以为各种目的而购造，与需求工程相关的是那些试图绘制所需系统的外观和一些可能的行为的原型。
对原型一个普遍认同的分类：
探索性原型——帮助需求获取或细化需求，也称为一次性原型，一旦需求工程完成后，它便没有用处。
定义原型——形成部分所需行为的定义，即部分规格说明。
结构原型——用于评价可能的内部设计方案，例如检查性能。虽然是用于设计阶段，但也用于需求阶段可行性的检查。
演化原型——通过逐步求精过程，原型最终成为了产品。
需求工程主要关注的是前两种原型，原型开发隐含着迭代。如在需求获取中：初始原型将向用户演示，获得的反馈将用于细化原型，在实践中这种迭代会出现好几次。迭代中可能会增加新内容，也可能减少内容。
原型在需求工程中主要作用是对用户接口进行建模，尤其是当这些接口相当复杂、关键、新鲜时。原型开发的一个潜在好处是：可以促进潜在用户的参与和客户的承诺，但有个副作用：真实原型的早期外观会误导人们认为该项目比实际情形先进得多，随着最终产品的出现就会感到失望。
行为（功能）建模
行为模型只是系统行为的抽象。行为建模有很多种，我们就较一般的可能用到的简单介绍几个：
- 功能声明与分解
功能声明也许是最简单、常用的行为定义技术。声明使用文本方式，描述输入和输出之间的因果关系。功能分解可以说是一种高级策略，通过许多其他方式实现，如Use-Case 、DFD 、结构图。基本思想相当简单，通常系统功能性的详细定义是按层次结构来实现的，即通过把功能分解为若干低层的、更为详细的功能集。该技术也称为功能求精或功能组合。 - 任务分析
任务分析，涉及的是人的任务性能的分析或外部设计，特别用于人机接口（HMI）。任务分析从人们所希望获得的目标开始。任务是获得这些目标的高级机制，操作是实现任务的交互。 - 用例与脚本
用例（use-case）描述所设计的解系统与一个或多个端子之间的某种特定的交互。
用例在面向对象领域主要作为一种分析和规格说明的技术。对新系统将投入使用的环境进行分析相当于研究该系统所必须满足的要求。事实上，情形可能是客户和潜在用户确实发现用例易于理解，因此，用例就有助于客户/用户与开发者之间的交流。大多数用例都有“执行者”，可以是人，也可能是系统的软硬件设施。用例文档可以用文本或UML图来描述。用例的应用和构造具有相当大的灵活性，人们可能认为它不够严格，但是应用指定的合适的指导原则可以解决这个问题。 - 有限状态机
有限状态机（Finite State Machines，FSM）通过输入与输出之间的因果关系对系统的行为进行建模。
(1)系统可看作有若干个相互区别的稳定状态；
(2)当条件改变时，系统从一个状态改变到另一个状态；
FSM的设计规则
转移总是起始于一个状态并终止于一个状态。
一个转移总是有一个相关的触发器。
一个转移可以有一个或多个相关动作。
同一个触发器可能对多个状态有效。
内部模型
内部模型是对系统内部的构造或体系结构的建模技术。可以很简单的把解系统的内部分成两方面：数据和操作。根据建模所侧重的方面，可以划分为三种内部建模技术。
1.面向处理技术
抽象的把所考虑的系统建模成一组通信子系统，重点放在它们实施的处理上。
(1)通信并发处理
这个模型把子系统看成是并行运行的，现实世界中的各种事物也是通常是如此的，因此它具有相当的直观性。最常采用的方法是“数据流图”，即DFD。DFD的开发需要大量的专门知识，以消除建模中可能导致的二义性和错误。好的DFD后面的解释是较为直观的，因而可理解性是比较良好的。
以下规则可以用来检查DFD的有效性：
数据不能直接在数据存储之间流动；
数据在端子之间的流动不显示；
处理和数据存储通常至少有一个输入和一个输出。
(2)通信顺序处理
虽然真实事物一般都是一个并行的系统，就如同一个人可以同时做很多事情一样。但是，大部分计算机以顺序的方式处理，特别的在软件设计的时候（即使是面向对象设计）。对通信顺序处理建模的常用表示法有树状图或结构图，另一种主要方法是伪码。
2.面向数据结构的技术
数据结构建模是所有信息系统最重要的技术，也常称为数据分析，关注的是静态数据的结构。
实体属性关系建模，则是数据库应用系统的通用方法。当进行数据分析时，通常起始点是搜索需求获取记录，选出候选实体。识别有意义实体的好方法是问问：“哪些相关信息与这个实体相联系？”。与实体相关联的信息即为实体的属性。实体间的关系有三种：一对一，一对多，多对多。
3.处理/数据相结合
该技术集中在对发生的处理和处理的数据的建模上，采用了一种完整的观点，却抽象更加复杂。主要的两种模型是实体生命历史（ELH）和面向对象建模。
实体生命历史建模起的是辅助性的作用，它从数据分析和数据流建模继续而来，实体来自于ERD，实体处理来自DFD，然后为每个实体的有关处理顺序进行建模。ELH的作用是在其他模型之间充当一个交叉的检查和一种集成。
面向对象建模把所考虑的系统建模为一组相互通信的对象。一个对象是存储数据和对其数据上的操作进行抽象。识别和定义对象只是一部分工作。还必须探讨对象间的关系。
获取需求
需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户——开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与软件有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。需要用户去了解一点：对于某些功能的讨论并不意味着即将在软件中实现它。对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。
考虑到合作公司的业务代表的计算机的水平较高，需求调查和需求说明书采用以业务代表为主，IT人员协助的方式。首先，将业务代表集中起来，说明需求调查采用的方法和需求说明书的规范。然后，业务代表梳理本业务领域的业务需求，先粗后细写出需求说明书，交由IT人员整理，双方多次沟通反复，形成需求说明书初稿，交项目工作小组评审。
马上开始第一次的访谈，对方是财务人员，目标描得很准的。由于是老系统的升级，得到的更多的是“抱怨”。尽管如此还是要尽可能的去了解工资的业务领域，因为在次之前对这东西真的一无所知。几天的会议、老文档的阅读、相似系统的试用，也还是瞒有收获的。
下面就用户抱怨作个简单总结：
1.外派和内派船员的工资不容易分清，希望能分开计算。
2.工资数据的excel表希望能改为由财务人员直接导入导出。
3.程序界面需更加友好，设置默认值，并能自动记忆以前的输入。
4.更正一些不合时宜的设定，如船员凭证号改为6位、银行帐号19位。
5.财务员不再设置工资标准等，而由劳资方面设定。
6.新增一些功能，业绩工资、工资封存、报销系统等。
7.完善查询种类和方式。
船员工资业务目前主要存在如下特点：
政策复杂，在工作中容易出现对政策把握不准的情况，在执行政策尺度方面不能完全规范统一；
船员数量多，工作量大，因此漏报、错报的情况时有发生；
情况复杂，工资的晋升原因、变动种类比较多，而且各家公司的政策也不尽相同。船员不仅工作状况复杂，种类繁多，而且职务也是分得特别细致，主要包括：船长，政委，老轨，大副，驾驶，电机，电报，船医，电工，水手，服务员等等30多个类别。而工资本身又分为在岸工资、在船工资、职务工资、级别工资、工龄工资、英语津贴、补扣、医疗保险、加班费、建房贷款、业绩工资等。
审批工作比较困难，工资的审批不仅要基于当前的工资状况，还要审核历次的工资情况，这就给工资的审批带来一定的困难。
船员分布广泛，工资发放难免有不及时或不到位的地方。
需求初始化阶段
这个阶段有三个主要的目的：第一，至少从高层次上确定工资系统的范围，以明确所要做的工作范围；第二，定义工资系统的高层需求；第三，对于需求的含义，在用户和开发项目组间取得一致。很庆幸的是该软件系统是为自家公司设计的，项目组和用户只在同一个地点，能就该系统应该做什么达成比较一致的意见，这个阶段只需要一天的时间；否则的话，有可能会延长至几天或数周。
工资子系统是远洋公司财务科的应用办公系统。它不仅只是工资，还包括津贴，加班费，建房贷款，医疗保险，等等。子系统主要用于船员工资的查询更改、计算声称、发放转账、报销、打印以及公司对船员工资的设置、管理、历史查询与统计。很显然的这是一个信息系统，使用面向问题域分析的方法，可以画出简单的问题框架，如图所示，其中的工资子系统即为解系统。
为了更进一步的深入，我们需要多种模型对各个模块进行补充。功能需求方面，根据我们所取得的资料，可以初步定位这几个行为：
工资主文件查询：一些基本的工资方面的信息查询。
工资主文件维护：必要时能够更正文件数据。
往来帐处理：查询或设置工资发放的情况或方式。
月度处理：统计某几月或日的工资或船员情况。
工资生成：逐项生成各种工资，计算工资，并进行工资发放。
报销处理：对各种报销的纪录存盘、查询和统计、预算等。
报表核算：这个信息希望能支持会计核算的一些要求，如按部室、船型、单船等核算工资及各种保险和补贴，按职务或动态查询平均工资及保险。
要开发的是一个数据库应用系统，数据模型以实体属性模型来表示最为合适的里。可能实体：
船员：工号，姓名，职务，地址，工资，津贴，………
航船：船舶代码，名称，功率，速度，吨位，船籍港，…….
公司：公司标识，名称，地址，电话，船员数，船舶数，…….
由于船员的工资标准跟船员是否在船（出海）、是否外派（这公司的船员到另一公司工作）有紧密关系，所以我们确定至少要有以上三个实体。当然还会有其他实体，就目前来讲，不是很重要，可以先不予考虑。
从总体架构来看，工资系统还涉及到与其他子系统的关联。尽管这方面比较隐蔽，还是要粗略罗列一下。工资子系统还需实现一些功能：
读取劳资标准：劳资是对工资基准和算法的设定；
读取调配情况：船员的工资地点和状况是很不固定的，随时都可能变更；
更改船员信息：只进行小方面的更改；
读取证培情况：有用的证件当然能够提高工资了；
读取基本信息：船员迁移，辞职，晋升等等；
操作人员对工资系统的操作都会得到的回应，可能的结果（非全部）有：
操作失误
信息有误
工资主文件被更改
查询结果
统计预算
生成的excel文件或打印的图表
工资派送
收到工资确认
报销确定
经过以上的逐步分析，对工资系统的问题域信息框架，我们有了比较清楚的了解。工资业务领域要涉及的信息有几大部分：船员基本信息，公司工资标准，往来帐处理，工资计算生成，月度处理，历史核算统计。整体的流程可能会有些复杂，综合在一起只会减低理解性和需求的质量，可以分成几个子流程来研究。
详细需求建模阶段
现在工资子系统的范围和高层需求得到客户认同，基于前一阶段的成果，可以开始为开发工作制定进度，将这些需求带进一个迭代过程。该计划随着对需求的理解的不断发展而演化，由此就开始了真正的开发。
在这个需求迭代过程的开始阶段有两种方式进行建模工作：
1.集中所有小组所得需求在一起进行建模。采用这种方法，整个项目组以及参与的客户会在一起探讨详细的需求，分析这些需求，对已有的系统设计提出修改建议以支持这些需求。注意一旦完成了这个初期阶段的工作，每个需求小组仍然需要对它们所负责的部分进行详细的建模。
2.各个需求小组对各自所负责的需求直接进行建模。简单地就直接让各小组进入到其所负责的部分。这种方式的成功需要有这样的前提：需求间没有联系，或至少联系不是太多；开发人员遵循集体所有制这个做法；基于共有的代码之上。它的优点就是能够使得项目组在迭代过程开始的第一天就进入详细分析建模。
基于各组对各自的需求把握得比较透彻，也没有足够的时间去完全了解其他各组的需求。因此，公司采用第二种方式进行建模。这样也有利于充分利用资源，免得出现人手富余的情况。
除了工资明细表、汇总表以外，系统还提供变动分析表、所得税表等十多种统计报表，且报表的查询可动态调整语种、币种和显示顺序。为了达到更细致的查询，我们增加了数据实体以方便查询，增加查询速度。由于数据实体都将是以文件存储，用文件名代替实体名更显通俗易懂。
心得体会
在做软件需求的时候，我们完全没必要去限定要用或将要使用何种方法或建模技术。我们的目的在于分析软件的需求，通常情况是都用到了所介绍的三种方法。首先我们用面向问题域的方法把问题分成几个部分。接下来用面向结构或面向对象的方法对各个部分进行逐步分析细化。在逐步分析过程运用各种建模技术对问题各部分建立合适的模型来细化需求。随着需求的做下去，我们越来越清晰的认识了工资软件系统的需求。
虽然应用方法和建模技术使我们能够清楚地去了解软件需求，但是，大部分的需求文档和规格说明书都是以文本的形式记录的，因此，如何去表达我们所了解的需求也是很值得注意的。
通过网上的学习，发现要想学以致用真的很不简单。之前对于工资的认识只有是：一个发一个领，完全不懂。既要接受新东西，又要回顾所学过的，我们只有边学边用。如今再回头看书上的内容，感觉还真是不一样。
一些技巧
以下简单列举一些技巧能够帮助需求建模，提高建模的效率：
软件的需求收集和变更贯穿于整个项目中。虽然工资子系统的需求是在我们实习的阶段已经完成了，然而在将来系统的设计和测试过程中，相信还是会有更改的。
要向每一个参与需求的人员解释各种建模技术和各种图形代表的意义，当然也包括客户在内。如果客户或设计人员不了解所作的需求，那等于什么也没做。
了解客户的语言，使用客户的语言。如，在船，外派，基地，农合工，年功工资等等。
保持乐观态度。很多时候我不知道客户在讲些什么，或者他们说的根本不是我们想要听的，但还是得认真地去记录。
要得到用户的认可和支持。虽然是同为中散公司的员工，但我们也是在为他人作软件的，有任何新的想法或更改一定要和客户沟通，特别是取得客户高级管理人员的支持。
优先采用面向问题域的方法分析。这样能在开始时勾勒出工资子系统的轮廓，了解系统的面貌，然后再集中在各个小的部分。这样做，就不会感觉无从下手，选择好切入点。
尽可能的收集需求的来源。在做需求的过程中，我用过很多工资管理系统，读了很多使用手册。
参考文献
[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
标签：需求,认识,工资,系统,建模,处理,应有,软件 来源： https://blog.csdn.net/weixin_47427771/article/details/109992217