阅读笔记（三）——《需求工程——软件建模与分析》三

        采用了面向对象方法学的世界观，将系统看作是一系列对象的集合，每个对象具有独立的职责，完成独立的任务，对象之间通过消息机制相互协作，共同实现系统的目标。在需求分析中涉及的UML技术有对象模型，用例模型，行为模型，状态机模型和对象约束语言OCL。对象模型中强调了一个事物可以被抽象为对象的两个条件是独立可确认和有明确的角色；类是共享相同属性和行为的对象的集合，它为属于该类的所有对象提供统一的抽象描述和生成模板；类之间的关系有关联，泛化和依赖关系。用例模型的基本元素有用例，参与者，关系和系统边界。行为模型有三种：交互图，状态图和活动图；交互图又包括顺序图，通信图，交互概述图和时间图，天是依据交换行为进行的用例实现；活动图是依据处理流程进行的用例实现；状态图是以状态机模型的方式进行的用例实现。OCL是用来定义UML模型元素的四类约束：不变量，前置条件，后置条件和监护条件。面向对象的建模方法有技术路线，建立领域模型(发现对象和类，建立类之间的关联)，建立行为模型(建立交互图，建立状态图，建立活动图，添加契约说明)，以及居于CRC卡的职责驱动方法(CRC卡，基于CRC卡的职责驱动方法)。

        活动是将需求及其软件解决方案进行定义和文档化，并传递给开发人员的需求活动。需求规格说明文档可以清晰明确的将软件系统的需求信息和解决方案更好的传递给所有的开发者，另一方面可以拓展人们的知识记忆能力。在开发过程中会产生不同类型的需求规格说明文档，它的描述手段为非形式化语言，半形式化语言和形式化语言；需求规格说明文档的写作原则有写作是一门艺术文档化的目标是交流，优秀的需求规格说明文档应具备正确性，无歧义等特性。

        软件工程中系统验证和需求工程中的需求验证；需求验证的方法有需求评审(包括参与者，过程和检查方法，以及类型)，原型与模拟，开发测试用例，用户手册编制，利用跟踪关系和自动化分析；常见的问题修正行为有需求澄清，发现缺失需求，解决需求冲突和修正不切实际的期望。第17章<需求管理>是在需求开发结束后保证后续的系统开发活动依照需求的基线进行展开，从而保证系统的质量。需求基线是是项目团队需要在某一特定产品版本中实现的特征和需求集合，它需要从配置管理和状态维护2方面进行维护；需求跟踪是描述需求以及跟踪需求变化的能力，分为前向跟踪和后向跟踪。需求变更控制是以控制，一致的方式进行需求基线中需求的变更处理，包括对变化的评估，协调，批准或拒绝，实现和验证。实践中的需求管理包括需求的变更，需求跟踪信息和需求管理工具。

        需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。需求工程包括需求开发（需求获取、需求分析、需求规格说明、需求验证）和需求管理两个方面。需求工程师需要具备认知学和社会学等方面比如认知心理学，人类学，社会学，语言学，哲学知识等理论指导和专业、分析、交流、观察、建模、写作、创新和协调等技能。      

        当软件系统被用来解决某些问题时，这些问题的问题集合域就是问题域，而软件系统通过影响问题域能够帮助人们解决问题成为解系统。通过映射建立的共同知识就是问题域和解系统之间的共享现象，也就是两者之间实现交互和互相影响的途径与接口。      

        需求分为功能需求、性能需求、质量属性、对外接口。约束。功能需求包括业务需求、用户需求和系统（级）需求。其他四项可划为非功能需求。其中性能需求常见的包括速度、容量、吞吐量、负载和实时性。约束主要有系统开发及运行的环境、问题域内的相关标准和商业规则。优秀的需求应该具备完整性、正确性、精确性、可行性、必要性、无歧义和可验证的特性。需求并没有反映用户的真实需要、模糊和歧义的需求、信息遗漏、不必要的需求、不切实际的期望等是常见的需求定义错误。      

        从这部分的需求绪论可以看到许都需求方面的整体定义，但并没有具体的步骤指导。从整体定义上来看，需求工程是一个庞大而繁琐的过程，如何抓住软件的功能重点是需求工程的最终目的。