之1：需求不再是传统的SRS文档，而是一条一条的，能够逐条查询，编辑，修改，状态跟踪。比如scrum提出的Backlog中的user story。
之2: 需求条目的层级划分，一级的划分往往是不够的。第一级需求往往收集原始需求素材，难以控制其范围和规模，所以不便于直接开发；第二级需求经过第一级的过滤整理，适合提供给程序开发。在敏捷里常见划分出epic和story，在cmmi中分成了客户需求，产品需求，组件需求。
不同组织在第一级和第二级之间还会安排中间的级别，这是为了更贴合组织情况。但是从精益的角度讲，中间产物是潜在的浪费，除非的确有必要，建议二级需求表达是足够了。
之3: 需求碎片化是非常明显的趋势，应当是现实了，条目化是解决需求碎片的唯一高效解。
之4:条目化需求的状态管理能够将需求的最初识别，采纳，确认，实现，验证，上线融合在一起，尤其是变更也能融合在一起，得到目前为止最高效的需求管理。而且支持产品的全生命周期，超越项目级别的生命周期。
之5: 条目化需求获得了逐条全程校验的机会，对比瀑布型需求打包阶段评审，相当于两个层面的切分，1是横向，把大块需求切成了条目，2是纵向，从识别，初步采纳，确认需求，实现，核对，测试等等步步校验，各个角色参与。更加高效更加精准
之6: 对于第一层需求条目的表达形式，常见的有epic，云朵、风筝级用例，业务用例，原始需求等等，其最要点不在于指导后续实现，而是在于捕获干系人真实的期望，要求，所以在表达中尽量采用干系人的语言
之7: 对于第二层需求条目的表达形式，常见的有user story，系统用例，用例，需求用例，其最要点就在于交待并确认软件要实现的特性，要指导后续的实现。如果程序员直接来写第二层需求，那么就可以相对简化。而场景化表述成为当前流行的做法，不再追求传统的提炼归纳或者形式化表达。
#条目化需求# 我现在对条目化和结构化的观点是：碎片式需求不是一个个发现完全没有关系的需求碎片，而是以碎片式一个个发现需求。碎片不是名词，也不是形容词（修饰“需求”），而是副词（修饰“发现”）。需求内在的关联和结构不是敏捷开发或互联网能打破的。
展翅飞_2012：有什么工具？感兴趣！ 回复@展翅飞_2012:许多条目化工具都可以，比如redmine，mantis，jira，polarion，rally，trello，vsts，等等