最近看了这本书，和实际的结合比较紧密，对实际的需求有一定的指导作用，特别市对于国内的特色需求，有很好的指导。
《软件需求最佳实践:SERU过程框架原理与应用》
首先从软件需求实践中出现的主要问题和困难入手，指出了改进的主要方向；然后逐一说明了需求定义、需求捕获、需求分析与建模、编写规约、需求验证等需求开发活动的任务、要点和具体手段；并提出了一个可操作性强、易于上手的SERU过程框架，能够帮助读者清晰地了解整个过程，理解各阶段的关键产物和产物之间的关系。
还对包括需求基线、变更管理、需求跟踪在内的需求管理活动的操作要点进行了阐述，给出了具有很强实践性的具体建议
SERU过程框架模型将需求过程分解为了三个阶段，第一个阶段是需求定义，重点是主题域划分和业务事件识别。第二个阶段是理清需求框架和脉络，重点是通过业务流程图转到具体的领域类图和用例图。到了第三个阶段重点就是填充需求细节，包括用例的详细编写，界面和交互设计等。
http://product.china-pub.com/209259 图书地址
http://book.douban.com/review/2258630/ 这个评论有意思
如下的诫语很有意思，可以实际中参考。
SERU诫语目录
第1章 需求实践现状分析 2
SERU诫语1-1：需求规格说明书应该采用业务导向的树型层次结构来组织。 6
SERU诫语1-2：对于需求分析员而言，真正的专业主义是基于业务利益
SERU诫语1-2：（解决问题、创造机会、提高管控力等）的沟通。 6
SERU诫语1-3：缓解沟通失真最有效的方法是及时复述。 9
SERU诫语1-4：需求分析的本质在于业务分析，而非技术分析。 11
SERU诫语1-5：业务场景是需求之魂。 12
SERU诫语1-6：需求分析人员对于技术方法论的评价重在适用性。 16
SERU诫语1-7：对预设计的需求是评判敏捷方法论是否适用的关键。 18
第2章 不同软件项目的需求视图 20
SERU诫语2-1：流程分析（业务事件）是OLTP系统的关键线索和主要视图。 23
SERU诫语2-2：报表分析是MIS系统的关键线索和主要视图。 26
SERU诫语2-3：决策场景是DSS系统的关键线索和主要视图。 29
SERU诫语2-4：工作场景是专家系统的关键线索和主要视图。 30
SERU诫语2-5：并行工作流是OA系统的关键线索和主要视图。 30
SERU诫语2-6：高层管理人员的关注点往往在问题和机会。 33
SERU诫语2-7：对于面向用户的嵌入式系统，行为分析是要点。 35
SERU诫语2-8：面向特定设备的嵌入式系统，外部接口和事件分析是要点。 36
SERU诫语2-9：信息系统类软件产品的需求重点在于针对不同目标客户群体的
SERU诫语2-9：不同商业模式分离变化点；经常需要减出通用性，再通过插接
SERU诫语2-9：解决扩展性。 39
SERU诫语2-10：基于使用场景的困难点分析是工具软件的需求要点。 40
第3章 软件需求与需求工程 41
SERU诫语3-1：业务需求是需求定义的产物，用户需求是需求捕获的产物，
SERU诫语2-9：软件需求是需求分析与建模的产物。 43
SERU诫语3-2：功能需求的要点在于如何组织。 44
SERU诫语3-3：非功能需求的要点在于保证信息的有效传递和注意其局部性。 44
SERU诫语3-4：设计约束包括非技术因素的技术选型、预期的软硬件环境和预期的
SERU诫语2-9：使用环境三大类型。 45
SERU诫语3-5：业务导向的层次结构是保障完整性的关键。 46
SERU诫语3-6：需求有时会戴上“高优先级”的面具，实际上就是担心
SERU诫语2-9：你不去实现它。 48
SERU诫语3-7：满意/不满意度模型是需求必要性评价的有效手段。 49
SERU诫语3-8：在需求捕获活动中，化被动为主动是关键。 52
SERU诫语3-9：需求分析就是向下分解+向上提炼，外加一些规格化。 53
SERU诫语3-10：需求分析是目标，需求建模是手段。 54
SERU诫语3-11：在编写需求规格说明书时，应确保一类信息只在一处描述。 55
SERU诫语3-12：划分出大小合适、粒度均匀的需求项是需求管理的前提。 57
SERU诫语3-13：需求优先级与工作量估算是基线管理的关键。 57
SERU诫语3-14：SERU模型是需求分析的工作指南。 60
第4章 需求定义最佳实践 64
SERU诫语4-1：清晰的项目目标和范围定义，能够引导需求工作顺利进行。 65
SERU诫语4-2：对混沌不清的目标，可以通过内部寻根或外部溯源来破解。 65
SERU诫语4-3：对问题进行了正确的定义，意味着成功解决了一半。
SERU诫语2-9：而在问题定义时应该善于使用转换和本源两个技巧。 68
SERU诫语4-4：需求定义阶段要善于将未知解问题转换成已知解问题。 68
SERU诫语4-5：在确定某问题的解决方案时，一定要思考是否会引发新问题。 70
SERU诫语4-6：直接修改错误，不要用其他方案来弥补错误。 71
SERU诫语4-7：鱼骨图为解决问题找到了靶子，帕累托图则标上了环数。 76
SERU诫语4-8：范围是涉及的事、物，边界是人与系统的职责边界。 79
SERU诫语4-9：用户永远会希望花同样的钱，获得尽可能多的功能。 79
SERU诫语4-10：需求阶段描述的是用户的能力特点，旨在提高可用性。 86
SERU诫语4-11：你可以不做一件事，但一定不能不知道为什么需要做这件事。 86
SERU诫语4-12：在分解系统时，应该按业务的脉络来划分成不同的主题域。 89
SERU诫语4-13：各个主题域之间的服务接口是需求变更的防火墙。 91
SERU诫语4-14：确保能做的事和知道的事相匹配是职责驱动设计的要点。 93
SERU诫语4-15：目标决定范围。 96
SERU诫语4-16：绘制上下文关系图，先考虑Customer再考虑Worker是要点。 98
SERU诫语4-17：业务事件应该是主动触发的，并且将会产生一系列后续行为。 103
SERU诫语4-18：业务事件是直接作用于系统的，也就是将触发系统行为。 103
第5章 需求捕获最佳实践 109
SERU诫语5-1：需求捕获是撒网打鱼，不是休闲钓鱼。 109
SERU诫语5-2：善于聚焦访谈话题是需求捕获人员成功的关键。 111
SERU诫语5-3：尝试理解业务场景是合格需求分析人员的良好习惯。 112
SERU诫语5-4：善于利用技术为用户创造全新体验是优秀需求人员的特质。 113
SERU诫语5-5：通过比较用户代表的表述来识别言过其实，利用差异展现、
SERU诫语2-9：瓶颈分析法来缓解影响。 114
SERU诫语5-6：针对越俎代庖心理现象最有效的方法是识别正确的被访谈者。 114
SERU诫语5-7：离开办公室、对访谈进行计划是避免非正事现象的主要手段。 115
SERU诫语5-8：化敌为友是缓解抗拒心态的主要方向。 116
SERU诫语5-9：倾听对方的抱怨是化敌为友的有效手段之一。 116
SERU诫语5-10：突破推卸责任心理的简单手段是让被访谈者介绍工作场景。 117
SERU诫语5-11：需求捕获时不要忽视对变更可能的了解。 117
SERU诫语5-12：在需求捕获时要善于使用“？”之箭，找到真正的需求。 120
SERU诫语5-13：“拨开立场，寻找利益诉求”是需求协商的要点。 122
SERU诫语5-14：不要孤立地看待需求项，应该将所有需求视为一个整体。 123
SERU诫语5-15：“环境”将改变结果，切换不同的视角会得到不同的认识。 124
SERU诫语5-16：善于打比方是提高跨专业沟通效果的好方法。 125
SERU诫语5-17：占用时间长和信息的片面性是用户访谈的两大敌人。 126
SERU诫语5-18：访谈的线索是因“人”（用户类型）而异的。 126
SERU诫语5-19：尽量将访谈问题事先发给被访谈者，让他打一场有准备之战。 128
SERU诫语5-20：在需求捕获时别忘了“一图抵千言”这句经典提示。 132
SERU诫语5-21：用户访谈是一个有计划的、科学的过程。 135
SERU诫语5-22：用户调查能够有效克服用户访谈中存在的片面性。 137
SERU诫语5-23：在需求捕获过程中，先访谈再调查是更合理的方式。 137
SERU诫语5-24：大样本用户、跨地域用户的存在就是使用用户调查的时机。 138
SERU诫语5-25：分析文档资料时应该思考新流程对其的影响。 143
SERU诫语5-26：收集文档时，应该尽可能让用户提供带有真实数据的样本。 143
SERU诫语5-27：需求捕获人员要善于根据流程分析的结果主动收集相关文档。 144
SERU诫语5-28：情节串联板是消除用户盲区的有效技术。 144
SERU诫语5-29：情节串联板应该以业务场景作为展示的主线索。 145
SERU诫语5-30：交互才是情节串联板的本质，不要只关注于界面的静态效果。 145
SERU诫语5-31：现场观摩技术是消除开发团队认识盲区的有效手段。 146
SERU诫语5-32：现场观摩技术能够使开发团队实现对业务场景“感同身受”。 146
SERU诫语5-33：联合开发是突破双方需求盲区的有效手段。 147
SERU诫语5-34：出现“上面开大会，下面开小会”现象，一半责任在组织者。 148
SERU诫语5-35：沟通决定内容，内容决定格式。 150
第6章 需求分析与建模最佳实践 156
SERU诫语6-1：需求分析就是先分解，再提炼，在这个过程中消除矛盾。 156
SERU诫语6-2：需求建模的过程远比建模的结果更重要。 159
SERU诫语6-3：模型是用来沟通的，因此仅当需要时才构建它。 160
SERU诫语6-4：建模的要点是根据要完成的任务选择合适的建模工具。 161
SERU诫语6-5：UML本身不是方法论。 163
SERU诫语6-6：业务流程是对信息系统进行“庖丁解牛”的核心线索。 165
SERU诫语6-7：流程有组织级、部门级、岗位级三个层次，其中部门级是
SERU诫语2-9：需求分析的主线索，岗位级是需求细节填充时的工作内容，
SERU诫语2-9：组织级是对部门级流程的抽象概括。 170
SERU诫语6-8：应该根据项目的特点和团队的技能情况选择合适的模型。 172
SERU诫语6-9：模型最有效的方式是在交流中演化出来的。 176
SERU诫语6-10：流程图绘制完成之后，花些时间进行瓶颈和利益分析会有意
SERU诫语6-10：想不到的收获。 185
SERU诫语6-11：在需求建模时，应该大胆地用中文命名类和类的属性。 194
SERU诫语6-12：需求阶段的类建模应该尽可能保持简单，引入过多的辅助建模
SERU诫语6-10：元素反而会降低图的可读性。 199
SERU诫语6-13：领域模型是自底向上合并出来的。 205
SERU诫语6-14：领域模型的要点是拒绝实现、保持简单、忠于问题域。 207
SERU诫语6-15：领域建模时应遵循“拒绝实现细节、大类不分拆、子类不合并、
SERU诫语6-10：同类不抽象”的原则。 207
SERU诫语6-16：团队的分工不明确往往是导致视图交叠的原因，了解不同视图的
SERU诫语6-10：关注点，是理解不同模型的关键。 214
SERU诫语6-17：仅在需求规格中出现用例图并不意味着应用了用例技术。 216
SERU诫语6-18：千万不要为了使用扩展、包含关系而使用它们。扩展用例
SERU诫语6-18：建模的通常是优先级较低的扩展事件流，包含关系建模的
SERU诫语6-18：通常是多个用例所包含的公共子事件流。 222
SERU诫语6-19：在访谈现场，就流程图讨论出用例图是高效的建模方法。 226
SERU诫语6-20：如果说用例有粒度，那么它取决于业务流程和任务分工。 230
SERU诫语6-21：系统动作（诸如新增、删除之类）和业务名词在用例名称中
SERU诫语6-18：相遇时，就是一个十分危险的信号。 230
SERU诫语6-22：对不影响泳道间协作的判断、活动均属于细节信息。 234
SERU诫语6-23：对于报表而言，并不一定非得按用例模板来组织需求描述。 238
SERU诫语6-24：诸如Rose之类的建模工具，对模型抽象的支撑是最重要的。 249
SERU诫语6-25：前、后置条件出现的频度并不高，不要画蛇添足。 254
SERU诫语6-26：避免在用例事件流描述中出现实现细节、分支结构、
SERU诫语6-18：循环结构；特别是不应该出现多路分支结构，如果出现
SERU诫语6-18：要反思用例抽象是否正确。 261
SERU诫语6-27：界面原型部分是约束、是建议，目的是支持有效的UI设计。 266
SERU诫语6-28：建议使用不同的字体风格约定，以表达出数据的结构特点。 276
SERU诫语6-29：历史记录的标准也是数据需求的一部分。 276
SERU诫语6-30：哪里有分解，哪里就有接口。 292
第7章 需求描述最佳实践 302
SERU诫语7-1：需求规格的格式取决于开发团队的特点及所选的开发方法论。 324
SERU诫语7-2：用户需求说明书是为生成软件需求规格说明书服务的。 328
SERU诫语7-3：文字的歧义可能与其长度成正比。 330
SERU诫语7-4：要使需求描述更加清晰，就应该转用“结构化文本”式描述。 332
SERU诫语7-5：在你被逼在需求描述中增加How的信息之前，先确认自己已经
SERU诫语7-5：尝试过为需求添加了Why。 334
SERU诫语7-6：对于非功能需求而言，应该抛弃定性，改用场景化描述；
SERU诫语7-5：并通过选取指标、积累经验值的方法过渡到定量描述。 335
第8章 需求验证最佳实践 336
SERU诫语8-1：需求验证的目标是尽可能暴露问题，而不是证明无错。 341
SERU诫语8-2：在企业中推行即时评审、同级桌查等正式化程度不高的评审手段，
SERU诫语7-5：是创建企业评审文化的有效手段。 342
SERU诫语8-3：在评审会中，不要用“评价者”的口气谈论你的观点。 343
SERU诫语8-4：参加需求评审的人不是越多越好，一定要保证同级、适合。 343
SERU诫语8-5：评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每
SERU诫语7-5：小时30～40页的速度来准备，缺陷检查表尽量在9条之内。 344
第9章 需求基线操作实务 348
SERU诫语9-1：优先级是相对的，要在同一级中进行比较。 355
SERU诫语9-2：评价具体功能点的优先级时，应将其放到业务场景甚至是业务
SERU诫语7-5：流程环境中考虑。 356
SERU诫语9-3：软件估算是随着工作任务的细化不断提高精确度的。 357
SERU诫语9-4：不同阶段进行软件估算时，应该采用不同的计数单元。 357
SERU诫语9-5：悲观估计、乐观估计应和“风险”理由对应起来。 362
第10章 变更管理操作实务 365
SERU诫语10-1：需求变更管理的目标是控制变更，而非避免变更。 365
SERU诫语10-2：控制变更的目标是减少变更对开发工作的影响。 365
SERU诫语10-3：需求团队的贡献在于“尽早标识变更”，设计团队的贡献在于
SERU诫语10-3：“尽可能以弹性的设计来减少变更的影响”。 366
SERU诫语10-4：建立统一的渠道让客户意识到变更的成本，减少“来路不正”
SERU诫语10-3：的变更，记录“变更的工作”。 366
SERU诫语10-5：CCB的核心人员只有两个，分别代表用户团队和开发团队，
SERU诫语10-3：其他组成人员都是协作者和决策者。 367
SERU诫语10-6：基于业务驱动的需求项（树型）列表，是对变更进行业务
SERU诫语10-3：影响分析的有效方法。 372
SERU诫语10-7：对变更进行分类、再分类，是管理变更的重中之重。 375
第11章 需求跟踪操作实务 376
SERU诫语11-1：需求跟踪是高阶管理活动，所需的工作量很大，特别是软件需求
SERU诫语11-3：到设计元素的跟踪，因此一定要考虑投入与产出是否成正比。 377