软件开发总结--需求与开发

需求不是越多越好，也不是越详细越好。

• 一个好的需求属于一系列关联需求的一部分。
• 这一系列需求关联一个要发布的版本，这个版本要有自己希望达到的目标，这个目标的一个主要表现就是为一个或多个用户提供实用，重要或紧迫的价值。
• 这个需求要有验收条件，达到这些验收条件，该需求也就完成了。
• 该需求应该有允许讨论（妥协）和不允许讨论（妥协）的两部分。

用户价值是不允许讨论（妥协）的，具体实现方案是允许讨论（妥协）的。 实现和预想之间可能存在差距（例如时间，复杂度，难度，可能性）， 所以开发人员应该也是需求参与者， 负责向需求提出者反馈这些问题，以利于需求提出者做出进一步决策。

• 需求有几个特点

1. 一是完备性

需求需要明确为什么样的用户提供什么样的价值， 需求还要明确验收条件，达到什么样的程度就认为需求已经完成，

1. 二是生动

一个需求不生动，很难在需求的各类参与者之间达成一致。这里的生动主要是指应用场景。

1. 三是简洁

当前很多需求规格说明书或PRD中，内容太多，不简洁，导致这些需求不明确。

1. 四是有度  

在做需求时，一定要注意，哪些是需求该做的，哪些是需求不该做的，如果越界，过犹不及。我认为一个需求应该包括： 用户故事，表明用户和价值；应用场景： 生动描述需求是怎么应用的，容易在各类人员之间达成一致的理解；验收条件： 完成到什么程度，需求就完成了； 依赖，假设和限制： 明确这个需求依赖什么，基于什么假设，有哪些限制；最多在加上风险。

1. 五是持续完善

一个需求从不是很了解开发，到逐渐明晰，是正常的，我们不能期望一开始就有人将一切都想明白，设计好，这也是以前需求规格说明书和PRD过界的地方。我们冗余别人经历从不明晰到明晰的过程，包括所有人员。也允许应用场景逐渐增加或减少，验收条件的变动，依赖假设和限制的修改等，但是最好用户和价值不要改动（是否允许增加可以讨论）。

1. 六是留白

需求中有想不清楚，需求要进一步思考讨论的问题是正常而且有益的，在需求中指出这些问题，对日后完善需求，展开沟通有好的作用。所以开放性问题也是需求的一个重要的方面。

基于如上的理解，我们期望QA人员对业务需求从版本目标和用户价值，验收标准三个方面对需求进行测试和审核，开发人员，QA人员对业务场景方面进行沟通，以期达成一致。

 

• 一个需求是否达标：

1： 发布版本有明确的目标

2: 有多个需求支撑发布版本

3： 需求能为用户提供价值，且能描述出来

4： 需求的验收条件明确且可测试

5： 需求有生动的应用场景，能够对理解需求提供帮助

6： 指出需求的依赖，假设和限制

7： 需求在业务，QA和开发人员之间真正达成一致，且有手段确保一致

8： 不明确的问题，要指出，最好是列为开放性问题

9： 有持续完善的机制

10： 指出需求的责任人和客户代表，要指出沟通方式

 

• 开发人员如何实现需求：

1： 确保对需求达成一致

2： 需要将需求拆分为大致的任务，注意不要漏掉哪些非开发的任务，非开发的任务可以反馈到需求人员。

3： 如果需求比较大，需要将需求的实现拆分为多个版本， 按照一定的节奏开发这些版本

这些版本不要时间太长，应为可能存在对需求理解不一致的情况，可以通过尽快发布版本来察觉这些不一致并改正。 版本的划分要以用户价值为指导。

4： 根据需求（特别是业务价值），列出各版本的验收条件， 并确保达成一致

5：对任务，版本进行估算，得出初步的计划。（我们有初步的计划，但是估算这一块做的不好）

6： 编写功能的测试用例，或者叫功能设计，需求规格说明书或PRD中都有这一块，现在想来，还是放在开发这边做比较好，因为开发需要知道做到什么程度，这个功能就算完成了。还有一点，开发人员有能力自动化这些测试用例，其他人员可能不具备这个能力，所以建议将功能测试放在开发这边。（因为我的开发中，与交互设计打交道比较少，所以没有将交互设计考虑进去， 当前将交互设计人员也理解成开发的一员）

7： 一个任务或版本只有对客户代表(或需求人员)演示完成且演示人员认可才算完成。 如果客户代表认为不满意，即使满足前面列的验收条件也不行，因为前边列的验收条件是为大家理解达成一致的，而不是为了推卸责任的，这时候可以有两种方法： 1： 与客户代表进行沟通，让他认可这一版，在下一版中，将新的验收条件添加上去， 个人推荐这种方法， 2： 在本版中就将这些验收条件添加进去。

需要注意的是，演示需要在开发人员测试完成且有把握的条件下，才可以进行，否则会消耗客户代表对团队的信任。