客户痛点问题：
1.需求工程过程不清晰，导致项目组成员不知道自己在哪里?应该做什么?用什么方法?应产生什么样的输出... ...
2.需求采集的手段匮乏，导致在项目初期需求与项目边界严重脱节，需求信息量不够;
3.需求分析仍依靠个人经验/能力，导致需求分析的维度不全面，需求确实量增加;
4.需求撰写方法不规范，导致需求描述本身产生歧义、冲突、重复、不可测试等的可能性大大提高，进而产生无效需求;
5.由于需求验证手段匮乏，所以需求验证不执行或靠¤人的经验评审，导致项目的需求文档本身无法保证一致性、全面性，需求规格不合规;
6.需求文档的离散管理，严重影响项目进程中的需求变更、变更影响分析、需求评审等√工作。
需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行♀检查与调整。同时需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析↑活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软◥件质量。恒润科技基于IBM Rational DOORS 和Rhapsody 为用户提供模型驱动的需求工程解决方案。
方案介绍
需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并终在验证的基础上冻结需求。需求工程涵盖了需求开发和需求管理，其活动划分为以下5 个独立的阶段：
1.需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求;
2.需求建模：为终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义;
3.形成需求规格：生成需求模型构件的的形式化的描述，作为用户和开发者之间的一个协约;
4.需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性;
5.需求管理：支持系统的需】求演进，如需求变化和可跟踪性问题。
图示：需求工程过程
主要活动介绍
1. 需求采集和编写
2. 基于DOORS 的需求影响分析和管理
3. DOORS 中需求提取，导入到Rhapsody 需求视图，基于Rhapsody 的需求建模设计和仿真验证过程
4. 基于Rhapsody ATG 的模型元素的测试
5. 基于Rhapsody GateWay 实现需求追溯和覆盖率分析
恒润科技系统工程部经过多年的工程经验，引进国际上的支撑工具，在依托国际上较领先的方法论的基础上，将需求工程各个阶段数据进行抽象建模，建立并提出一整套基于模型的需求∞工程解决方案。本方案从需求采集建模开始贯穿了需求分析、需求撰写、需求形式化建模和验证、全生命周期的需求管理等阶段。并对相关阶段的支撑工具进行了扩展，实现数据的无缝传递和集成应用，为客户打造集方法论指导、咨询服务、工具链提供于一体的解决方案。
