下载文档原格式
软件研发中的需求分析与设计方法在软件研发过程中，需求分析与设计是非常重要的环节。
它们是确保软件开发过程中需求清晰、设计合理的关键步骤。
本文将介绍几种常用的需求分析与设计方法，以及它们在软件研发中的应用。
一、需求分析方法1. 问卷调查法：通过向用户发送问卷，收集他们的需求和期望。
这种方法适用于软件开发项目的初期阶段，能够帮助开发团队了解用户需求、用户习惯和用户期望。
2. 访谈法：开发团队与用户直接进行面对面的交流，详细了解用户需求。
通过访谈，可以深入了解用户对软件功能、界面和性能的需求，进而为软件设计提供参考依据。
3. 观察法：开发团队直接观察用户在使用同类软件时的行为。
通过观察，可以确定用户的操作习惯、使用需求等，从而更好地满足用户的期望。
4. 原型法：创建软件的原型，让用户参与测试和反馈。
通过原型，用户可以更直观地感受到软件的功能和设计，从而提供宝贵的改进意见。
5. 分析法：通过对用户需求进行详细的分析，将其转化为软件功能和性能要求的规格说明。
这种方法适用于需求较为清晰、清楚的情况。
以上是一些常用的需求分析方法，每一种方法都有其特点和适用场景。
在实际应用中，开发团队可以结合项目的实际情况选择合适的方法，以确保需求的准确性和完整性。
二、设计方法1. 结构化设计方法：结构化设计方法强调软件开发的模块化和层次化。
它将整个软件系统划分为几个相互依赖的模块，每个模块都具有独立的功能和职责。
这种设计方法使得软件的管理和维护更加容易。
2. 面向对象设计方法：面向对象设计方法将软件系统看作一组相互作用的对象集合，每个对象都有自己的属性和方法。
通过面向对象设计，可以更好地实现软件的重用性和可维护性。
3. 数据流图设计方法：数据流图是一种图形化的设计工具，用于描述软件系统中数据的流动和处理过程。
通过数据流图设计，可以更好地理解软件系统中各个部分之间的关系，并确定数据的处理逻辑。
4. 用例图设计方法：用例图是一种用于描述用户与系统交互的图形化工具。
软件需求确认之快速原型法常常听到许多朋友跟我埋怨，需求分析之难，就在于用户自身就常常弄不清楚自己的需求。
起初在需求确认的时候说得好好的，一到软件上线的时候就不是那么回事了，这可没法整。
但我们只要坐下来仔细分析就会发现，在需求分析的时候我们跟用户是在空对空地讨论问题。
用户不是专业人士，他也搞不清楚软件到底会做成啥样，所以你跟他确认的时候他就点头了。
但是，用户不是傻子，当你软件上线时，他拿到了实物了，知道软件做成啥样了，一旦不满意他就开始提变更了。
所以，需求分析的症结就在与这个实物。
既然症结在此，毫无疑问，我们就应当在需求分析阶段拿出实物，用实物与用户确认需求，这就是快速原型法的基本思想。
快速原型法，简称原型法（Prototyping），是20世纪80年代提出的一种从设计思想、工具、手段都全新的系统开发方法。
它摒弃了那种一步步周密细致地调查分析，然后逐步整理出文字档案，设计开发，最后才能让用户看到软件结果的繁琐作法。
当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。
再提出一些新的需求以后，再开发一版新的原型。
原型法的关键就是这个快速开发。
不用考虑性能、美观、可靠，原型的目的就是模拟客户的需求，与客户进行确认的。
整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。
原型开发的快速与模拟到什么程度，是一对矛盾，我们要去把握。
要快速开发，必然不可能和最终交付的软件系统一模一样，许多复杂问题被简化，非关键性流程被忽略，这就是所谓的模拟。
因此，模拟到什么程度是关键，既能说明问题，又不耽误时间。
根据我的经验，一般能拿出界面，并可以走通关键性流程就可以了。
一些快速开发平台为快速原型法提供了可能。
当用户拿到原型可以自己操作时，需求研讨的气氛立即变得不太一样了。
当用户享受原型给他们带来体验的快感时，需求被源源不断地被提出来。
这时候的需求，就不再是枯燥无味的文字游戏，而是生动形象的图形界面。
常用需求分析方法
常用的需求分析方法包括：
1.面谈：与用户进行面对面的交流，了解用户的需求和问题，以便更好地理解和分析。
2.问卷调查：通过编制问卷并向用户发放，收集用户的意见和反馈，了解他们的需求和期望。
3.观察法：通过观察用户在实际工作环境中的行为和操作，来推导出他们的需求和问题。
4.文档分析：分析用户提供的文档，如公司规章制度、业务流程等，以了解业务需求。
5.头脑风暴：通过团队成员的集体讨论和大量构思，来收集和梳理需求。
6.原型设计：根据用户的需求和反馈，设计出一个简化的产品原型，以便用户更好地理解和确认需求。
7.用例分析：通过编写用例来描述用户对系统的使用场景和功能需求，以便准确地了解用户的需求。
8.数据分析：利用用户的历史数据和行为数据，通过各种统计分析方法，挖掘出用户的需求和问题。
9.竞争分析：分析竞争对手的产品和服务，了解市场需求和用户体验的趋势，以确定用户的需求。
10.用户故事：通过编写用户故事，描述用户在特定情景下的需求和期望，以便更好地理解用户需求。
以上是常用的需求分析方法，根据具体的项目和情况，可以选择合适的方法或结合多种方法进行需求分析。
简述需求分析的方法需求分析（Requirements Analysis）是软件工程中的一个核心环节，是指对系统或软件的需求进行细致而全面的调查、分析和定义，以明确用户对系统的期望和要求。
在软件开发过程中，需求分析的准确性和全面性直接影响着后续的系统设计和开发工作。
本文将简述需求分析的方法。
需求分析的方法主要分为以下几种：一、访谈法：访谈法是需求分析中最常用的方法之一，通过与用户或相关利益相关者进行面对面的询问和交谈，以深入了解他们对系统或软件的需求和期望。
在访谈过程中，分析人员需要仔细听取用户的意见和建议，并且准确记录下来，以便后续的需求整理和分析。
二、问卷调查法：问卷调查法适用于需求范围较广、用户众多的情况下。
通过向用户发放问卷，让用户填写对系统或软件需求的评价和建议，以获得更广泛的意见和反馈。
在设计问卷时，需要注意问题的合理性和准确性，以确保收集到的信息具有较高的可信度和代表性。
三、观察法：观察法是通过观察用户在实际环境下的行为和操作来获取需求信息的方法。
通过观察用户在日常工作中的表现和需求，可以更直观地了解他们对系统或软件的要求。
具体观察的手段可以是实地观察、视频录像等。
观察法能够从真实的使用情况中发现用户的隐含需求，提高需求分析的准确性。
四、原型法：原型法是通过建立系统或软件的初步模型来明确需求的方法。
通过构建可交互的原型，用户可以更直观地感受到系统的功能和界面，从而提出更具体和准确的需求。
原型可以是草图、手绘图或者基于工具的屏幕原型等形式。
在原型法中，分析人员需要与用户密切合作，及时修正和改进原型，以满足用户的需求。
五、文档分析法：文档分析法是通过对已有的相关文档进行分析和归纳，提取其中的需求信息。
这些文档可以是需求规格说明书、用户手册、市场调研报告等。
通过文档分析，可以了解到项目的背景、现状、目标和约束等信息，为需求分析提供有力的支持。
分析人员需要仔细研读和理解各种文档，并将重要的信息进行整理和总结。
原型法的开发方法原型法是一种软件开发方法，它通过创建原型来确定和验证软件系统的需求和设计。
原型是一个简化版本的系统或部分系统，它可以用来展示系统的功能和用户界面。
原型法的开发流程通常包括以下几个步骤：1. 需求收集：在这一阶段，开发团队与用户进行讨论和沟通，以了解他们的需求和期望。
这可以通过面对面的会议、问卷调查、用户访谈等方式进行。
收集到的需求将作为开发原型的基础。
2. 原型设计：在这一阶段，开发团队会根据需求设计系统的原型。
原型可以是一个简单的模型、一个草图或者是一个可交互的界面。
根据需求的复杂程度和开发团队的技术能力，原型的设计可以采用不同的方式，比如手工绘制、电子绘图工具、原型工具等。
3. 原型开发：根据设计的原型，开发团队开始实际开发系统。
在这一阶段，开发人员需要根据原型设计的要求编写代码，并进行测试和调试。
原型开发可以采用敏捷开发的方法，迭代地进行开发和测试，以确保系统的功能和性能达到预期。
4. 原型验证：在原型开发完成后，开发团队需要与用户一起验证原型的功能和用户界面。
用户可以通过使用原型系统来了解和验证其功能是否满足需求。
开发团队可以根据用户的反馈和建议进行调整和改进，以确保系统最终满足用户的需求和期望。
5. 系统开发：在原型验证通过后，开发团队将根据原型系统的设计和反馈，进一步进行系统的开发。
在这一阶段，开发人员会根据需求和设计文档编写代码，并进行测试和调试。
系统开发的过程中，可以采用各种软件工程的方法和技术，比如结构化编程、面向对象编程等。
6. 系统测试：在系统开发完成后，开发团队会进行系统测试。
这包括对系统的功能、性能、安全性等方面进行全面的测试。
系统测试可以采用白盒测试、黑盒测试、压力测试等不同的方法和工具。
通过系统测试，可以发现和修复系统中的问题，并提高系统的稳定性和可靠性。
7. 系统发布：在系统测试通过后，开发团队会将系统发布给用户使用。
系统发布可以使用不同的方法和工具，比如安装程序、网站上线等。
简述需求分析的方法需求分析是软件开发过程中至关重要的一步。
它涉及对需求进行收集、分析和定义，以确保产品能够满足用户的期望和需求。
本文将简要介绍一些常用的需求分析方法，以帮助开发人员更好地理解和应用这些方法。
一、用户访谈用户访谈是需求分析中最常见的方法之一。
通过与用户直接交流，开发人员可以深入了解用户的需求和期望。
访谈可以采用面对面的方式，也可以通过电话或在线方式进行。
通过询问用户的问题，并仔细聆听他们的回答，开发人员可以获取关键的需求信息，并了解用户的痛点和需求的优先级。
二、文档分析在需求分析过程中，开发人员可以对现有的文档进行分析，以获取对系统需求有关的信息。
这些文档可以包括用户手册、操作手册、业务规范等。
通过仔细阅读和分析这些文档，开发人员可以较全面地了解用户的需求，以及系统所需具备的功能和性能要求。
三、场景模拟场景模拟是一种通过设定特定场景并让用户参与其中的方法。
通过模拟真实的使用场景，开发人员可以观察用户在特定情况下的行为和反应，并从中获取用户需求的洞察。
例如，可以设置实验室环境，让用户在特定的操作流程下测试软件，并倾听他们的反馈。
通过这种方法，开发人员可以更加准确地了解用户的需求和期望。
四、原型开发原型开发是通过制作一个简化版的产品原型，以获取用户反馈和需求的方法。
开发人员可以通过软件工具或手工制作一个简单的界面原型，以模拟待开发产品的功能和交互流程。
然后，开发人员可以邀请用户测试原型并提供反馈意见。
通过这种方法，开发人员可以迅速获取用户的需求，以便在后续的开发过程中进行相应的调整和优化。
五、焦点小组讨论焦点小组讨论是一种集中用户参与的需求分析方法。
开发人员可以组织一组来自用户群体的代表，共同参与讨论产品需求和期望。
通过集思广益的方式，开发人员可以获取来自不同用户的不同意见和建议，并最终形成一个更加全面和准确的需求规格。
六、需求优先级排序在需求分析过程中，开发人员常常需要面对多个需求，并对其进行优先级排序。
软件需求分析的方法软件需求分析是软件工程中的一个重要环节，它的目的是明确软件系统的需求和规格，为后续的开发、测试和维护工作提供基础。
软件需求分析的方法有很多，下面分别介绍几种常用的方法。
1. 需求采集方法需求采集是软件需求分析的第一步，它的目的是获取用户的需求和期望。
常用的需求采集方法包括访谈、问卷调查、观察和原型演示等。
访谈是最常用的需求采集方法之一，通过与用户、客户或领域专家的面对面交流，了解他们对软件系统的需求和期望。
问卷调查可以通过编写调查问卷，让用户填写问题并收集结果，找出用户的需求和偏好。
观察是通过观察用户工作现场或业务流程，了解其需求和行为模式。
原型演示是通过构建简单的原型系统，供用户体验和反馈，从而找出需求和改进点。
2. 需求建模方法需求建模是将用户需求抽象为精确、无歧义和可验证的表示形式，以便于进一步分析和设计。
常用的需求建模方法有数据流图、用例图和状态转换图等。
数据流图是一种直观的表示方法，通过表示系统的功能、数据流和数据存储，可以全面地捕捉用户需求和系统功能。
用例图是一种描述系统功能和用户行为的方法，通过表示系统的参与者、用例和关系，可以清晰地展现系统的需求和用例场景。
状态转换图是一种描述系统状态和事件之间转换关系的方法，通过表示系统状态、事件和转换，可以详细地表达系统的行为和需求。
3. 需求验证方法需求验证是确保需求规格正确、完整和一致的过程，常用的需求验证方法有故事卡、原型演示和验收测试等。
故事卡是敏捷开发中常用的需求验证方法，通过编写简单的用户故事，描述用户需求和场景，以便开发团队理解和实现。
原型演示是通过构建系统的原型或模型，供用户评审和验证，以便及时改进和调整需求。
验收测试是在软件开发完成后的一系列测试，通过与用户或客户一起参与，验证软件是否满足用户需求。
以上只是需求分析的一些常用方法，实际上需求分析方法还有很多，如面向对象方法、正式方法、领域建模等。
不同的方法适用于不同的项目和需求，可以根据具体情况选择合适的方法。
需求分析之原型分析法原型法（Prototyping）的理念是指在获取一组基本需求之后，快速地构造出一个能够反映用户需求的初始系统原型。
让用户看到未来系统的概貌，以便判断哪些功能是符合要求的，哪些方面还需要改进，然后不断地对这些需求进一步补充、细化和修改。
依次类推，反复进行，直到用户满意为止并由此开发出完整的系统。
简单的说，原型法就是不断地运行系统的“原型”来进行揭示、判断、修改和完善需求的分析方法。
原型需求分析法的特点原型法是一种循环往复、螺旋式上升的工作方法，它更多地遵循了人们认识事物的规律，因而更容易被人们掌握和接受。
原型法强调用户的参与，特别是对模型的描述和系统需求的检验。
它强调了用户的主导作用，通过开发人员与用户之间的相互作用，使用户的要求得到较好的满足。
不但能及时沟通双方的想法，缩短用户和开发人员的距离。
而且能更及时、准确的反馈信息，使潜在问题能尽早发现并及时解决，增加了系统的可靠性和适用性。
简单的说，原型法是将系统调查、系统分析和系统设计合而为一，使用户一开始就能看到系统开发后是一个什么样子。
而且用户参与了系统全过程的开发，知道哪些是有问题的，哪些是错误的，哪些需要改进等，就能消除用户的担心，并提高了用户参与开发的积极性。
同时，用户由于参与了开发的过程将有利于系统的移交、运行和维护。
但需要注意的是，原型法的适用范围是比较有限的。
它只对于小型、简单、处理过程比较明确、没有大量运算和逻辑处理过程的系统比较合适。
它的局限性是对于大型的系统不太适合，因为对于需要大量的运算、逻辑性较强的程序模块，原型法是很难通过简单的了解就构造出一个合适的模型，供用户评价和提出修改建议。
使用原型法进行需求分析的流程（1）快速分析，弄清用户的基本信息需求需求分析原型法的第一步是在需求分析人员和用户的紧密配合下，快速确定软件系统的基本要求。
也就是把原型所要体现的特性（界面形式、处理功能、总体结构、模拟性能等）描述出一个基本的规格说明。
做需求分析时常用的方法论需求分析是软件开发过程中的重要环节，在项目开始之前，了解并明确用户的需求是非常关键的。
需求分析的方法论有很多，下面将介绍几个常用的方法论。
1.问卷调查法：问卷调查法是需求分析中常见的方法论之一、通过设计问题并发放问卷，收集用户的观点和意见。
可以通过问卷了解用户的需求、偏好、期望以及对现有产品或系统的评价等信息。
问卷调查可以定性、定量分析用户需求，对于大规模用户的需求分析尤为有效。
2.用户访谈法：用户访谈法是通过面对面或远程通讯的方式与用户进行交流，了解用户的需求。
访谈可以是结构化的，即按照一些框架和指标进行，也可以是非结构化的，让用户自由表达。
通过访谈可以深入了解用户的需求、期望以及使用场景，获取具体的反馈和建议。
3.场景模拟法：场景模拟法是通过模拟用户在实际使用中的场景，来评估用户需求。
可以通过布置任务，观察用户在特定场景下的行为和反应。
这种方法可以及时发现用户需求中的问题和不足，从而进行优化和改进。
4.原型演示法：原型演示法是通过制作一个或多个功能简化的原型系统，展示给用户来获取用户反馈。
原型可以是静态的，如界面设计图，也可以是动态的，如交互模拟。
通过原型演示，可以很快地理解用户需求，确定交互方式和界面设计，并及时调整和改进。
5.场景重现法：场景重现法是通过用户的实际使用情况，来重现用户需求。
可以观察用户在真实环境下的操作和问题，记录用户的行为和反馈。
通过场景重现分析，可以从用户的角度出发，深入理解用户需求，发现潜在问题，进行优化和改进。
6.用例分析法：用例分析法是一种以用户需求为中心的需求分析方法论。
通过分析用户的使用场景、行为和需求，整理出一系列的用例，描述了用户与系统之间的交互过程和功能需求。
用例可以帮助开发人员更好地理解用户需求，并进行系统的设计和开发。
以上是几种常用的需求分析方法论，每种方法论都有其适用范围和优缺点。
在实际项目中，可以根据实际情况选择适合的方法论或者结合多种方法论进行需求分析，以获取更准确和全面的用户需求。
需求分析的主要方法
需求分析的主要方法主要包括以下几种：
1. 访谈法：通过与用户、客户、相关利益方的交流，了解他们对产品或系统的需求和期望，并获取详细的信息和反馈。
访谈可以包括个别访谈、焦点小组讨论、问卷调查等形式。
2. 观察法：直接观察用户在实际情境下使用产品或系统，观察他们的行为、反应和需求。
观察法可以通过原型演示、用户测试、田野观察等方式进行。
3. 文档分析法：对相关文档、资料进行分析和解读，包括用户手册、市场调研报告、技术文档等。
通过分析这些文档，可以获取相关需求和要求的信息。
4. 原型法：制作出可视化的虚拟原型或模型，通过用户与原型的互动反馈来获取需求信息。
原型法可以帮助用户更清楚地表达需求，同时也可以帮助需求分析人员更好地理解用户的需求。
5. 噪声分析法：通过对用户反馈的噪声（不完全或模糊的需求信息）进行分析，提取其中的有用信息。
噪声分析法可以帮助发现用户未能明确表达的需求和潜在的问题。
6. 人员交互法：将需求分析人员直接融入用户或客户的工作团队中，与其一起
参与项目的开发和改进。
通过与用户的紧密合作，需求分析人员能够更深入地理解用户需求，并及时进行需求调整和变更。
以上是需求分析中常用的主要方法，根据具体情况和需求，可以选取相应方法或结合多种方法来进行需求分析。
采用简化原型法进行需求分析
1 前言
需求分析阶段是治理信息系统（MIS）开发最重要的阶段。
MIS开发的需求阶段首先是了解和澄清用户的需求，然后严格地定义被开发的软件系统的需求规格说明书。
常用的软件需求分析方法有面向数据流的结构化分析方法、面向数据结构的Jackson方法、面向对象的方法和原型法等。
原型法由于改变了系统的分析、设计和实现三个顺序阶段的观点，改变了传统的自顶向下的开发模式，降低了软件需求的风险，因此得到了广泛的应用，非凡是在致力于某一领域MIS开发的软件公司，如致力于电力MIS开发的公司。
但作者在长期的MIS 需求分析过程中，发现原型法有以下缺陷：
1）原型的设计和修改工作量大，增加了系统的开发成本；
2）由于用户不关心或不理解原型的概念和实现，而且存在较大期望，使得与实际系统差别较大的原型增加了需求分析人员与用户的交流难度；无论是水平原型，还是垂直原型都不能反映实际系统的全貌；
3）软件需求主要包括：功能需求、界面需求、性能需求、环境需求、可靠性需求、安全保密需求、资源使用需求、软件成本消耗与开发进度需求和目标需求。
原型法中的原型难以表达软件的后七项需求；
4）原型法强调用户和开发人员不断对原型进行不断修改和补充，直到用户感到满足为止。
在时间紧和任务重的大型MIS项目中，这种情况实际难以保证，非凡是在用户单位和开发单位距离较远时。
本文结合治理信息系统项目实施的实践，提出一种新的需求分析方法-简化原型法。
这种方法根据数据库应用的特点，将需求分析分为两个阶段，并简化了作为需求分析工具的系统原型。
2 简化原型法需求分析的第一个阶段
治理信息系统属于数据库应用。
数据库应用需求分析应该围绕数据，而不是功能展开，因此应该首先解决"有什么"，然后再明确"做什么"。
第一个阶段就是要解决"有什么"，即由项目经理与用户进行协商，确定系统的技术协议，因此可以称为技术协议阶段。
技术协议需要开发方的项目经理与用户单位的技术主管签字并盖章，并以合同附件的形式存在。
技术协议的主要内容有：系统的边界、系统处理的业务、与其它系统的接口、工程的进度控制、培训安排和技术服务承诺。
2.1 系统的边界
系统的边界规定系统覆盖的作业范围，主要有地理边界（规定系统运行的部门、分支单位等）、操作员范围（规定操作系统的所有操作员身份、分布和大致权限）和业务范围（规定系统处理的业务，对于不处理的边沿业务非凡明确指出）。
2.2 系统处理的业务
系统处理的业务涵盖系统处理的所有业务，包括各种业务的描述、数据来源、实现要求。
但是业务规定不要求过细，可以对应实际系统中的一个模块。
如：电力MIS中输电设施治理子系统中的线路设备治理，不具体描述线路设备治理中的所有功能。
2.3 与其它系统的接口
与其它系统的接口明确规定接口的系统、功能和实施单位。
在接口的实施单位中明确是由开发方完成，还是由开发方协助第三方完成。
2.4 工程的进度控制
工程的进度控制规定工程的开始、结束日期和具体工程项目的名称、完成时间、地点、完成标志及责任分工。
具体项目一般包括：采购设备到达现场、采购设备安装调试、完成网络布线、开发预备阶段、业务需求调查、系统分析和设计、软件编制、现场调试、数据预备及录入、功能确认、试运行和系统验收。
责任分工规定双方对于具体项目的工作内容和配合方式。
在配合方式中规定人员组织方式、人员素质要求、提供的设备和场所。
完成标志规定具体项目完成提供的文件名称和要求，如：网络布线验收报告和硬件设备验收报告等。
2.5 培训安排
训包括操作员和系统维护人员的培训。
培训安排包括每种培训的人员数量、培训内容、培训时间、地点、组织方式和教材，并规定教员和学员的素质要求，及培训后学员达到的水平。
3 简化原型法需求分析的第二个阶段
假如说第一个阶段解决"有什么"的问题，那么第二个阶段解决"做什么"的问题。
主要工作有需求调查预备、到用户单位进行需求调查分析和进行需求评审。
3.1 需求调查预备
需求调查预备工作，在系统的技术协议签订后，严格依照技术协议进行，主要有向用户单位发放业务调查表、建立需求分析文档原型和建立系统简化原型。
业务调查表在系统的技术协议签订后，立即通过传真发送到用户单位，要求用户单位在需求调查人员到达现场之前完成。
业务调查表内容包括：具体业务的名称、上级业务、下级业务、发生条件、处理的数据和具体流程（处理岗位、处理方式和审核细节等）。
需求分析文档原型是根据技术协议编写的需求分析说明书原型，它的格式与标准的需求分析说明书相同。
其中的状态迁移图和各种表证单书等不明确的内容，采用相似系统的或由系统分析人员根据技术协议和以往经验设计。
系统的简化模型根据技术协议的要求，仿照相似系统设计。
简化模型采用可视化的数据库编程语言设计，一般采用数据库应用开发人员熟悉的PowerBuilder(PB)或Delphi。
简化模型的主要设计要求有：1）充分考虑系统的设计与实现，不得与实际系统脱节；2）尽量仿真实际系统的操作界面，与实际系统的操作过程完全相同；3）可以单机安装运行，不与实际数据库连接；4）演示数据的存储可以通过文本文件、单机的数据库或PB外部数据源的数据窗口；5）对于界面中轻易误解或难以理解的操作，在功能帮助按钮中给出说明；6）界面中难以实现或工作量很大的功能，以标注方式具体说明；7）运行稳定，并比实际系统对硬件要求低。
3.2 需求调查分析
需求调查分析在确认需求调查预备的三项工作完成后，由开发单位的系统分析人员到用户单位进行。
系统分析人员与用户单位安排的业务主管共同讨论业务调查表和系统简化原型，并不断修改完善系统简化原型和文档原型，最终形成共识，并要求业务主管在需求分析说明书上签字。
最终系统简化原型和源代码留在用户现场，便于系统的操作员进一步理解分析，直到最终把握；而且有利于提出进一步的改进意见。
改进意见可以随时通过邮件或传真直接发到开发单位，或由用户单位的系统维护人员修改简化原型后，随时发到开发单位，从而便于开发人员及时修改系统的设计和编码。
3.3 进行需求评审
需求评审一般由用户单位组织，评审团成员由同行专家、系统分析、设计和测试人员组成。
评审的依据不仅有需求分析说明书，还有系统简化原型；同时在评审过程中，系统简化原型不断进行优化。
评审的目标是要求需求分析说明书具有正确性、可行性、必要性、具有优先级属性、可验证性和无二义性。
需求评审报告作为对需求分析的补充和修正，由双方负责人签字，以需求分析说明书附件的形式存在，同样指导下一步的系统设计工作。
4 几点说明
1、此方法适合各种MIS工程的需求分析，非凡适合致力于某一领域MIS开发的软件公司。
采用此方法，开发同类项目越多，需求分析工作的效率越高。
2、在需求分析过程中，由于需要设计系统简化原型和文档原型，并充分考虑到系统的设计与实现，因此与其它需求分析方法向比，提高了对需求分析人员的要求。
在实际工作中，一般由资深的软件分析和设计人员进行。
3、此方法不仅适合MIS软件工程，同样适合其它大型软件工程。
4、由于需求分析工作本身的难度和重要性，此方法同样要求用户单位和需求分析人员对需求分析所有工作内容，引起足够重视；科学安排需求分析工作步骤，某些步骤可以同时进行；所有工作步骤不得应负或疏忽。
5 结束语
目前简化原型法已经在多个电力MIS工程中应用，大大提高了需求分析的工作效率。
实践证实，简化原型法具有以下特点：1）简化的系统原型开发工作量大大降低，修改和补充方便；2）简化原型大大缩短了需求分析人员与业务主管之间的距离，便于交流；并大大加强了需求分析人员与业务主管对系统的熟悉，有利于发现和解决问题；3）简化原型的设计提前考虑了系统的设计与实现，大大降低了软件工程的风险；4）简化原型增加了系统操作员对实际系统的熟悉，大大简化了工程实施后系统的操作培训；5）简化原型可以直接指导工程的设计和编码，便于系统开发的组织。
这种方法也可以用于其它软件工程，对于其它需求分析方法的改革也具有指导意义。
参考文献
毋国庆，朱立松等.嵌入式实时系统的软件需求检测. 软件学报,2002.5(13).
吕梦雅，陈晶. 面向对象的原型法在需求分析中的应用. 河北省科学院学报, 2002.3(19).
王继成，高珍. 软件需求分析的研究. 计算机工程与设计, 2002.8(23).
张峰岭. 数据库应用的需求分析研究. 计算机工程与应用, 2002.18.
李师贤，张珞玲. 需求分析的常见问题及其对策分析. 计算机工程, 2002.1(28).。
