目的
不管是程序设计还是需求分析，我们日常开发过程中免不了要对一个业务或需求进行理解与分析，经常会出现与用户的目标牛头不对马嘴的情况出现，为了避免这些情况，我们需要了解一些设计，需求分析，UML工具等相关的知识。
本文意在记录对需求分析的一些学习经验与笔记分享，希望能对你有所帮助。
注：本文较为概念，主要为后续实例理解打下基础，要知道为什么要制作对应示例，制作后要怎么在现实中运用。可能略显枯燥
什么是需求？
一个完整的需求兼具以下特性：
完整性，每个需求都需要能将功能描述完整（不完备的描述可能会出现研发无法理解描述而疯狂反馈等情况）正确性/功能性，需求需要能准确的进行描述，符合用户的功能预期，功能拥有对应价值（不符合用户价值，对用户来说这就是不正确的，不具备功能性）无歧义性，针对读者，该需求描述不能有其他的解释（不能有一千个哈姆雷特）
必要性，针对用户而言，每项需求都要是有必要存在的（没必要的存在比如~。。~给银行24小时提款机加了个打冰淇淋的系统【我觉得还挺不错】）有优先次序，这涉及到具体研发安排时对需求优先级的划分，一般越靠近核心系统业务的需求优先级越高可行性，需求需要在当前已知系统内可实现的可验证性，能够有完整对应的测试方式
如何建立需求工程？
需求工程的建立一般分为两步：
- 定义需求：建立用户可以理解的系统的需求模型
- 分析需求：根据需求模型建立开发者无歧义解释的分析模型
定义需求
要定义用户的需求分为以下几点：
- 对用户系统进行建模
- 从模型中确认业务改进点
- 确认用户远景
- 从远景中获取需求
对用户需求分析的难点
我们经常遇到用户的需求难捕获，易变等问题，例如下面的石头难题
石头难题
用户：我要一块石头
用户：差不多，但我要小一些
用户：很好，但是我不要蓝色的
用户：额，我要的没那么小
用户：咳咳，还是原来那个吧
我：
这种时候我们就需要通过需求分析与建模去了解用户真正的需求：
小一点的蓝色大理石
建模要点
难捕获： 我们需要
从用户的角度看问题易变：利用合理的
设计结构进行适配我们通过上面两点进行需求分析与建模完成后，就需要
对模型进行分析，从模型中获取到真正的需求
从模型中确认业务改进点
现实生活中各种业务系统的运作都是一个个模型，如一个酒店对房客的登记入住，医院的挂号服务模型等等，这些模型长久存在，我们有了这些模型后就可以对其进行分析。
其中存在一些业务改进点可能会被用户要求或者需求发现，而进行业务改进点的分析与功能软件的开发
业务改进点
业务模型描述业务现状，一般有两种情况：
- 这些系统一直
运行的很好，无需改进，不必要当做软件需求进行实现- 一些业务在运转过程中存在这样或者那样的一些问题，成为了待改进点，这些
待改进点就有可能成为软件需求
远景
系统改进点不等于软件需求，原因：
- 用户根据自己的工作特点，支付能力，决定改进哪些业务
- 这就是用户的远景，他表明了用户改进的目标，也就是项目开发的目标
业务模型描述了“现实是什么”，远景描述了“希望的改进”：
- 远景表达了
为什么开发这个系统 - 开发系统是为了
达到什么目标
远景的说明
- 远景可以作为单独文档存在，它说明了
建立一个项目涉及的所有人的共同目标 - 远景说明应该是精确，清晰的描述，一个好的远景确立可以激励团队为达成远景而努力，有如下特性：
具体的：要足够明确，具体可测量的：有衡量标准，而不是用些许，大概等模糊词汇描述可实现的：有实现的可能性与能力相关的：远景内的各个模块都应为远景服务，有所关联基于时间的：有定期的计划与规划
从远景中导出需求
- 对于每个业务改进点观察是否是为了达到
用户的远景而存在- 如果是的话就把它
作为需求存在，相应的模型作为系统模型- 如果不是的话就
不作为需求存在，只作为潜在需求考虑或直接抛弃
