软件需求十步走 阅读笔记02
树立正确的软件需求的概念，信息化普及的当代，人们大都着重于软件开发，很轻易的就会忽略开发的最初需求分析，这样导致最后的开发受阻或终止等问题时，就会在时间、人力、物力方面造成大量浪费，那对于开发过程十分重要的需求分析过程，我们有什么好方法可以应用呢？我们一直在寻找真正的“完整、准确、清晰、变化可控”方法。
对需求分析工作事前千夫所指是有益的，而事后千夫所指是无谓的。“软件危机”的解决之道是软件工程，“需求危机”的解决之道是需求工程。需求工程将整个工程分为需求开发和需求管理两部分，其中需求分析是需求开发的其中一个环节。需求工程是确保软件需求质量的，软件工程是确保软件开发质量的，一个软件项目要想成功，必须握有需求工程和软件工程这两把利剑在手。
近年来，人们利用了大量的需求分析方法、工具在软件项目中，有成效但仍然存在问题（工具不支持对项目范围和目标的定义工作），方法和工具主要定位基于软件需求分析成果向后端的系统设计和代码的软化，如果软件需求分析是准确的、完整的，那就可以完成成功的需求分析，但现实仍存在误差。所以，当下的需求工程应该在继承原有需求工程成果的基础上将客户业务研究纳入到需求工程，这才是需求工程的全部，向客户业务和系统设计延伸。反思软件开发的失败原因，进行确定范围和目标清晰的项目开发。需求分析由业务需求分析开始，在用户需求分析的基础上进行的功能需求分析和非功能需求分析，软件需求规格说明主要是说明软件需求是什么。软件需求的核心是业务需求，而软件需求规格说明书是软件需求工作的目标。如果说实践是检验真理的唯一标准，那么业务是检验软件的唯一标准，离开了业务的软件什么都不是。
用户的需求是不稳定的，不准确的，不完整的， 用户的真正需要是一个软件系统，用户所描述的是自己在一个具体业务系统中的事，用户只负责提出问题，而关于问题的深入研究是需求分析人员，也就是我们的工作。是我们应该根据用户提出的问题，在用户业务资料和现场调研的基础上，用逻辑思维方法和系统科学方法对用户业务分析研究，找出业务的内在要素、结构、关系，然后告诉用户该业务的整体情况。
应用情况和所在时间的变化和需求增减的变化导致了需求的变化。变化的根源在于错把客户作为变化根源，不知客户的服务对象才是变化的真因。变化可以是客户或开发组织两方中任意一方的直接提出。如何控制需求的变化或为此变化预留充足的余量？客户直接接触的变化是其服务对象，服务对象的变化必然带来客户业务的变化，客户业务又会影响信息系统，所以溯其根源，将服务对象、客户业务，软件系统同时作为研究对象，这样可有效控制需求的变化。
软件需求的描述方式：自然语言（虽其具有二义性，但可通过表格、图形等方法加以补强，减少其二义性）
软件需求是天平，业务和软件是这个天平上的两个砝码，要想平衡业务和技术就要整体思考。需求分析首先是业务研究，核心是业务研究，其次才是技术研究。技术是支撑业务的，是满足业务需要的，对业务研究充分，技术才能发挥其作用。软件需求的完整性=业务需求的完整性+用户需求的完整性+系统需求的完整性。
业务向系统的映射：映射存在着 映射不完整、不深入，对业务研究的不深入导致的疏漏等这样的问题。
业务系统和软件系统是一体两面，是同一个抽象体在两个世界的投射。
软件需求的验证和测试：验证的目的：保证需求分析结果的完整性和正确性 主要工作：自我验证、系统验证、技术验证、专家验证。存在的问题：大量依赖于人工检测，形式化方法的可操性不高。改善方法：1.在验证内容上提出要求。2.分析上应对业务和系统功能进行量化分析。测试内容：功能和性能 测试方法：人工方式（编写测试用例）和机器方式（模拟一个运行环境来测试）两种。
软件需求是在现实可见业务的抽象的基础上面向未来软件系统的再抽象，而软件系统只是将未来软件系统的再抽象在信息世界进行具体抽象化的成果。
软件需求既然是千夫所指，那就大胆点让软件需求成为软件开发活动的圆心。（需求开发工作）星环模型上圆环中心是需求获取（客户业务的分析），客户业务的分析的圆心（客户业务的问题和目标）软件开发活动整体模型如下：
需求分析人员的主要工作：用户描述的业务转换成用户需求和系统需求。
新一代软件需求工程的重要理念：从“轻业务、重系统”转变到“重业务、重系统”。