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