需求分类

business requirement : 事情的目标。应用到整个企业或业务领域的业务/商务需求。

stakeholder/user requirement: 哪些人会用到或受到影响，他们具体的要求是什么。敏捷项目利用用户故事呈现，包含actor/action。瀑布性项目需要方案，涉及业务流程，用户体验的设计。

solution requirements: 业务解决方案所有的细节，包含功能/属性。理论上实施团队依靠此实现需求，但实际可能还有需要确认的方面。

需求收集和分析的过程不是一步完成的，需要迭代完成以上三个步骤。建议初步调研时不要调研的特别细节

Transition requirements: 转换/过渡需求，在解决方案部署前的过渡方案（人员培训解决方案/数据迁移）。特点：有一定时效性

解决方案在使用阶段仍产生作用，比如某些需求是持续性的（用户在线率）。在使用解决方案过程中对功能做调整是正常情况。

前三个在解决方案前完成，最后一个在解决方案后完成。

solution requirements:

分成

1. functional requirements 功能性需求

2. non - functional requirements 性能/可用性/安全性，影响需求方案的被接受程度，如果不能满足需求可能导致整体解决方案失去价值

例：

1. 比如12315功能性满足，但性能不满足

2. 登录后的页面数据加载量大，导致用户登录后系统加载慢，用户体验差，导致客户体验差。原因是服务器在外国，国内显示慢。后来在需求方案中加了性能要求即非功能性需求。

Requirements & Design(what & how)

需求是解决方案的团队的输入，解决团队也会做输出（比如测试用例）给BA确认。

Requirements Classification Schema:

• Business requirements: statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.
• Stakeholder requirements: describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.
• Solution requirements: describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories:
     • functional requirements: describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage, and For more
information, see Non-Functional Requirements Analysis (p. 302).

     • non-functional requirements or quality of service requirements: do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.

• Transition requirements: describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity.

Requirements and design:

Needs (Problem Owener)

Requirements (Business Analyst)

Design (Implementation SMEs)

Solutions ()

business requirements

stakehold requirmentes

solution requirments

transition requirments (lifecycle)

1) functional requirments (dashboard)

2)non functional requirments (data accuracy? plaftorm performance?)

requirment is the input of define a design

需求的分类：（四大类）

前三大类，需求的抽线程度

1、商务需求，整个企业和组织层面期望达成目标的所作的一个描述，不是某一个人或者某一类人所提的需求。

2、干系人需求，在了解整个组织的需求后，需要站在总体目标的前提下，进一步到具体组织和个人有哪些目的需要满足的，就是解决方案的用户。那不同的部门和干系人需要通力合作和协作。

关键按问题在于这类需求交付给开发团队，是否能够有成熟的方案直接实现，那么就存在以敏捷的方式还是瀑布的方式，瀑布的方式需要更详细的内容，包括用户业务流程

3.方案需求，解决方案的功能的能力和属性的总的集合，那么这样的方案交给实现团队，就能进一步实现需求的功能

前边的三个分类的界限在哪里，不好判断，视环境而变，最主要的是需求的收集、分析、定义不是一次性完成的，而是通过一种滚动、迭代逐步细化，最终完成一个详细的需求，刚开始可能是商业需求，例如刚开始收集需求的时候，如果过早的跳入到详细的解决方案的细节上面，就有可能之间树木不见森林，刚开始把关注点聚焦的整体的目标上，再进一步细化收集需求（干系人需求），再进一步分析方案需求

4、转换需求/过渡期需求：在解决方案的确认后，需要一些具体的方法，比如对人员进行一些培训，来适应设个方案，再例如一些数据的迁移的工作在解决方案的过渡过程中要实现的

4 的问题在于一般发生在转换和过渡后，后便再也不会用到，可以对一揽子过度需求进行打包，统一去实现

solution Requirement可分为：

功能性需求/非功能需求

----------------------------------------------

问题：需求/设计

Needs--Requirement<-->Designs--solution

Problem Owner--Business Analyst<-->Implementation SMEs--Solutions

例如：防盗系统接受密码输入，那么在设计过程中标表示成功，那么可以每输入一个数字是发出声音，这个声音有75赫兹，持续0.5秒钟

就是这样需求逐步过渡到设计，其中需求写到什么程度就算合适的标准，也要视情况而定

---------------------------------------------

需求作为设计的输入，但是在设计过程中也需要收集额外的信息，因此会产生一些迭代，实现团队也需要输出一些设计，再返回给BA进行确认，比如测试人员和开发人员在测试和开发设计的时候也会把输出成果反馈给BA进行确认，因此BA可能也需要一些技术背景，更好的理解开发设计和测试内容，不同的团队对于工作边界的定义不同

Business Requirement: why a change has been initiated?

Stakeholders Requirement: a bridge between business and solution requirement.

Solution Requirement: capabilities and qualities of a solution that meets stakeholders' requirements.

--Fuctional Requirement

--Non-Fuctional Requirement

Transition Requirement:

需求类型

Business Requirement：整个企业或组织层面所提出的总的目标和结果。

Stakeholder Requirements：反应某一个或某一群干系人在解决问题,，达成目标时，有哪些目标需要我们满足。也可以称作User Requirements。用户故事基本上可以认为是Stakeholder Requirements。敏捷可能在Stakeholder层次的需求就足够了。

Solution Requirements：解决方案所需要满足的所有的细节、条件或内容。交付给解决方案团队之后，解决方案团队是可以直接依照它进行设计和交付的（理论上）。

Stakeholder和Solution Requirement的区别并不好做。

答题时，区分前三类需求，最重要先看主语是什么，即谁提出的。基于描述方式进行判断。

传递一个理念：需求的收集、分析和定义并不是一次顺序执行完，可以不停的重复，细化。

Transition Requirement：转换或过渡期需求。在某个解决方案过度阶段。某些项目需要数据迁移 。特点：需求时效性，一般发生在过度期。必须以解决方案为前提。其他三类需求不需要确认解决方案，因为他们是解决方案的输入。

Requirements reuse：Business、Stakeholder和Solution Requirements需求被重用可能性较大

Requirement和Design是needs于solution之间的桥梁，他们也能出现循环

Requirements到Designs的划分，哪步是需求哪步是设计，较难有明显的区分

requirement schema

1. business

2.stakeholds

3.solution

4.transition

由整体到细节，先花时间把整体定义清楚再逐步到细节，不要过早的陷入到细节的讨论。

考试技巧：分析需求属于哪个层级的，可以先根据提出需求的句子中的主语来辅助判断。

Transition Requirements：针对某个需求，前期已有部分工作准备或者不完整的方案和数据，新设计的方案需要对该部分进行继承和迁移。

transition requirement过渡需求

6. Solution Requriements中功能性需求会被客户重点提到，而非功能性需求被有意无意忽略。比如饭店番茄炒蛋，番茄/蛋/炒熟是功能性的。餐厅环境/上菜速度/。是非功能性的。

7. 非功能性描述也是要可衡量的。

8. Requirements和Design，并没有清晰界限。左图示意的从需求过渡到设计，很好的说明了Requriements和Design有没有清晰界限。

9. Design有可能是领域专家负责解决。

10. 左图示意的从需求过渡到设计，很好的说明了Requriements和Design有没有清晰界限。

requirements Classification Schema

需求分类】

business requirements 业务需求、商业需求【总体目标

stakeholder requirements 干系人需求【user 】

首先干系人分析，那些人能用到系统，那些人收到相关影响

solution requirements 解决方案

transition requirements 转换需求、过渡期需求 

非功能需求也需要被写入需求文档中，需要能被衡量和测试