迭代需求的整理是敏捷开发的第一步，也是敏捷开发很重要的一步，在这一步中我们需要把客户的业务需求按照优先级的顺序，整理成为一个个的迭代。然后把一个个的迭代拆成一个个可验收的故事卡。
在此需要说说什么是故事卡，故事卡和业务需求之间的关系。故事卡是一个个独立的，可验收的功能，一个业务需求可以拆分为多个故事卡。比如：我们常见的账号管理需求，需要对账号进行增、删，改、查。因为添加、修改、删除、查询都是一个个可单独验收的场景，我们可以把账号管理需求拆分为四个故事卡。因此把需求拆分为故事卡的原则是：
1.故事卡是可以独立验收的场景
2.故事卡包含的点数应该尽量小，一般划分为1、3、5个点，如果超过了应该重新拆分该故事卡。给故事卡评点的标准是什么了？我们可以按照一个查询完成的工作量是1个点，然后衡量该故事卡的工作量而适量的评点。
3. 注意故事卡完成的工作量中包括自我测试和联调的时间。而不是单独的只是开发完成。
敏捷开发强调成员之间的交互而不强调文档，但这并不意味着不需要文档，需求说明的好坏直接影响着客户价值的交替，我们先来看看下面的一张图：
客户 ： 客户高兴的把具有5个价值点的需求交代给需求人员
需求人员： 需求人员由于理解的不同，只从顾客那里接受了3个价值点
程序员 ： 由于需求人员表述的不清晰，最终程序员只理解了1个价值点，并交互给客户
客户 ： 当客户拿到只有1个价值点的产品后，客户哭了！！
因此作为需求人员，当在向程序员解析需求的时候，需要做到以下几点，防止价值点的丢失。
a. 功能点：需求包含了那些功能点
b. 约束条件： 每个功能点有什么约束条件
c. 流程图 ：功能点的业务流程是怎样的
d. 如果有界面的话，需要有页面元素图以及说明。
e. 验收：验收不同于测试用例，主要用来模拟用户的行为以及期望的响应
现在我们就以一个简单的登录界面，来讲讲应该怎样去描叙需求：
功能点：
1. 用户可输入用户名、密码。可选择自动自动登录、记住密码。响应登录按钮
2. 当点击登录时： a. 判断用户名、密码是否有为null，有则提示用户。
b. 记录用户名、密码以及记住密码、自动登录的状态
c. 发起登录请求，并响应登录状态。成功则调转到下一个界面，失败则提示用户
3. 启动登录界面的时候，读取配置文件，访问记住密码和自动登录状态。如果记住密码为true，自动登录为false，则启动登录界面的时候，用户名和密码为上次登录退出时的用户名和密码。如果自动登录为true，则直接执行点击登录的事件。
约束条件：
1. 用户名必须以字母开头，并且包含字母、数字，长度不小于6位，当焦点切换到密码的时候，自动验证输入的用户名的合法性
2. 密码以*号隐藏
流程图：
界面（低保真--界面元素草图）：
验收
