1.需求分析的演变

　　在需求分析方面，敏捷ACP相对于传统PMP项目管理有其显著的改变，从冗长的需求文件演变成短小精悍的用户故事。用户故事的目的是以更快的速度、更少的消耗应对现实世界需求的快速变化。用户故事的描述只要足够（Enough）就好，细节描述可以通过与客户或用户进一步讨论确认。每个用户故事可以以用户故事卡片的形式写到开发团队的任务看板上。用户故事卡片的背面会记录该用户故事的验收条件和可以确定故事完成的所谓定义或标准。

　　2.用户故事的要点

　　用户故事的基本格式是“作为（角色），我想要（功能），以此实现（商业价值）”。角色即为使用这个待开发系统的角色，功能是该角色的具体需求（Requirement），商业价值是最根本或深层次的需要（Need）。每个用户故事要限制其大小，理想的情况是所写的故事能够让一两个程序员花半天到两周时间完成代码和测试。通常通过故事所对应故事点的多少来衡量完成每个故事的可能工作量。故事点是一个相对估计的方法，表明一个故事相对于其他故事的大小和复杂度。不同项目团队的故事点的设定不尽相同，不具备彼此工作量的比较意义?？⑼哦痈葑陨淼乃俾剩疵看蔚瓿晒适碌愕哪芰Γ├春饬堪讯嗌俑鲇没Ч适履扇氡敬蔚?。

　　3.用户角色的建模

　　通过传统PMP中涉及的头脑风暴和名义小组会议等形式列出初始的用户角色，通过亲和图来对所有用户角色进行二次分类，最终确定待开发系统的用户角色。通过应用敏捷项目管理的虚拟人物和极端人物的方法来编出可能遗漏的用户故事。比如考虑同时拥有多个男友的女子想要额外的保密需求。

　　4.故事详细的获取

　　用户故事一般是用业务语言写成的句子，通常较好由用户或客户来写。如果用户不愿意写的话，开发团队可以通过访谈、问卷调查、观察和故事编写工作坊等形式来开展实施。故事编写工作坊是快速捕捞故事最有效的方法，建议在开始每个发布计划之前举办。通过工作坊画出待开发系统内部高层级之间的交互关系，并构建可能的系统原型。需求一旦被合理的捕获，产品经理和开发团队可以对一些大的史诗故事（Epic Story）进行进一步裂解，通常分解为可在一次迭代中就可以完成的用户故事，并且根据表征商业价值的不同对用户故事进行优先级排序。最后，通过用户故事地图、发布计划和迭代计划等方法把用户故事纳入不同的发布或迭代中。