《需求工程——软件建模与分析》阅读笔记之一

　　软件需求的获取和分析是软件系统开发中的一项重要任务，正确获取软件需求是软件技术人员必须掌握的基本技能。此书从软件需求工程的角度出发，以需求开发过程为主线，完整描述了需求获取、需求分析、需求验证、需求规格说明和需求管理等需求工程活动。此书站在开发者的立场，侧重于实践者的技术与方法，系统全面地介绍了软件需求工程的各项进展，努力促进需求工程领域理论、方法和技术的全面融合应用，以指导需求工程各阶段的系统化实践。

　　对于我们这种在校大学生来说，工程项目的概念是十分抽象的，一个项目开发的前提自然是有需求，那需求的获取以及如何根据需求来构建项目，这些都是十分重要的环节。若是我们一门心思埋头研究敲代码，那终归也只是会敲代码，而项目的需求获取以及模型的构建相关的知识可以帮助我们提升眼界，提升我们的层次，而这本书就可以助我们一臂之力。简单来说，这本书中的知识可以帮助我们学习到更专业的知识，帮助我们从码农的角度提升到设计师开发者的角度。

　　首先开篇看到的是需求原：需求分析基本原则：

　　1 定义问题，而不是解决方案。需求定义“做什么，而不是怎么做”，意思是需求的目的不是企图定义任何的解决方案。这是重要的特点，是不可违反的规则。

　　2 定义系统，而不是项目。需求定义了系统需要做什么：他们是一组目标。项目是在一段时间内动员一组人来完成这些目标。需求不涉及系统如何完成目标，这意味着不要涉及实现一个解决方案的项目的任何事情，而且编写每个需求规格应该是长期有效的，适用于多个系统，这些系统可能在不同的时间以不同的方式开发：需求可能被束之高阁，然后一两年后拿出来，或者几年时间内我们可能开发一个替代系统。

　　3 区分正式和非正式部分。需求规格像一个合同，它定义了系统的供应商或开发者必须交付的东西。但是大量的合同约束声明远远不能让我们正确的理解它，它需要背景知识、前后关系、流程以及结构。这些材料都不是合同约束。它帮助把规格分为约束部分和非约束部分。需求本身由需求规格的正式部分组成，是系统必须做什么的正式定义。其他的都是非正式的。

　　4 避免重复。如果可行，每一项信息只表述一次。重复产生了额外的工作而且加大了不一致的可能性。敏捷需求流程的原则：区分问题和解决方案是最重要的，定义需求后，一定要记录他以便别人可以找到。需求模式剖析：基本细节、适用性、内容、模板、实例、额外需求、开发考虑、测试考虑。需求规格的内容可以分为四部分：“介绍部分”，“上下文部分”，“功能域部分”和“主要非功能要求部分”。

　　这些原则还是多的但并不难理解，我们做软件毕竟不是给自己用，而是最终要交给客户，因此有了这些原则我们便可以在需求分析中少走许多弯路，更接近问题的本质。