传统软件需求实践的挑战

传统的做法不得不使用几千行“系统应该”这样的需求描述句，其繁复程度如图1-1所示。这些需求通常是通过与企业项目干系人面谈或者举行工作会议之后产生的。因为一般人都受米勒魔数的制约（参见下一节“人脑的限制”），下面的事情几乎是不可能发生的：人们在阅读了数以千计的需求条款后，突然确信项目的需求是全面的。此外，另一个较大的问题是需求规模会逐渐变化。等你有了上千个需求，如果没有某种方法把这些需求与价值联系起来，力求在解决方案层面上进行比较，将很难决定应该砍掉哪些需求。团队经常把需求进行逻辑分组，但这些分组通常还是过大，无法得到有效的处理。

敏捷方法，如Scrum，有产品工作清单、用户故事和验收标准。许多Scrum布道者说，产品工作清单应该是非嵌套的故事列表，这种做法比传统的需求列表好不了多少。验收标准也要求列出来，有时就列在便条卡的某一面上。做过大型系统的人都知道，在可能会有几百个项目干系人参加的项目上，这种缺乏信息组织结构的做法是行不通的。