掌握需求过程-(第2版) 本书特色
本书论述了软件开发中的重要课题—如何得到正确需求,书中用一个接一个的步骤、一个接一个的模板、一个接一个的例子,向读者展示了经过业界检验的需求收集和验证过程。本书针对不同的敏捷环境,为精确地发现顾客所需所想提供了技巧和深刻见解。 .
| 本书可作为计算机专业高年级本科生及研究生的教材,也可作为软件开发人员在开发过程中随时参考的手册。... | 掌握需求过程-(第2版) 内容简介
本书论述了软件开发中的重要课题—如何得到正确需求,书中用一个接一个的步骤、一个接一个的模板、一个接一个的例子,向读者展示了经过业界检验的需求收集和验证过程。本书针对不同的敏捷环境,为精确地发现顾客所需所想提供了技巧和深刻见解。
本书可作为计算机专业高年级本科生及研究生的教材,也可作为软件开发人员在开发过程中随时参考的手册。
掌握需求过程-(第2版) 目录
第1章什么是需求.1 | 1.1需求收集与系统建模3 | 1.2敏捷软件开发4 | 1.3为什么需要收集需求8 | 1.4什么是需求9 | 1.4.1功能性需求9 | 1.4.2非功能性需求9 | 1.4.3限制条件10 | 1.5需求演进10 | 1.6模板11 | 1.7需求项框架13 | 1.8Volere需求过程14 | 第2章需求过程15 | 2.1敏捷指南17 | 2.2需求过程的上下文18 | 2.3需求过程18 | 2.4案例分析19 | 2.5网罗需求21 | 2.6为需求制作原型23 | 2.7场景24 | 2.8编写需求24 | 2.9质量关25 | 2.10对需求的复用26 | 2.11复查规格说明27 | 2.12迭代和增量过程27 | 2.13需求工作事后分析28 | 2.14定制需求过程29 | 2.15小结30 | 第3章项目启动31 | 3.1敏捷指南33 | 3.2IceBreaker项目34 | 3.3范围.风险承担者和目标35 | 3.4设定范围35 | 3.4.1感兴趣的领域36 | 3.4.2首次分析工作上下文范围38 | 3.5风险承担者39 | 3.5.1客户41 | 3.5.2顾客42 | 3.5.3用户:理解他们43 | 3.6其他风险承担者44 | 3.6.1顾问45 | 3.6.2管理者45 | 3.6.3主题事务专家45 | 3.6.4核心团队45 | 3.6.5检查人员46 | 3.6.6市场力量46 | 3.6.7法律专家46 | 3.6.8消极的风险承担者46 | 3.6.9业界标准制定者46 | 3.6.10公众意见46 | 3.6.11政府47 | 3.6.12特殊利益团体47 | 3.6.13技术专家47 | 3.6.14文化利益47 | 3.6.15相邻系统47 | 3.7发现风险承担者48 | 3.8目标:想达到什么目的48 | 3.9需求限制条件52 | 3.9.1解决方案限制条件52 | 3.9.2项目限制条件53 | 3.10命名惯例与定义53 | 3.11估算产品的成本54 | 3.12风险55 | 3.13继续还是终止56 | 3.14项目启动替代方案57 | 3.15小结57 | 第4章事件驱动的用例59 | 4.1敏捷指南59 | 4.2理解工作59 | 4.3用例及其范围61 | 4.4工作62 | 4.5工作的上下文范围62 | 4.6业务事件64 | 4.7业务事件和业务用例是好想法的原因67 | 4.8发现业务事件68 | 4.9业务用例70 | 4.10相邻系统的角色71 | 4.10.1主动的相邻系统72 | 4.10.2自治的相邻系统74 | 4.10.3合作的相邻系统76 | 4.11业务用例和产品用例77 | 4.12小结80 | 第5章网罗需求82 | 5.1敏捷指南82 | 5.2职责83 | 5.3网罗与业务用例85 | 5.4当前状况扮演的角色86 | 5.5做学徒89 | 5.6观察结构和模式91 | 5.7风险承担者访谈92 | 5.8找出工作的本质94 | 5.9解决正确的问题97 | 5.10创新的产品98 | 5.11业务用例研讨会100 | 5.11.1成果101 | 5.11.2场景102 | 5.11.3业务规则102 | 5.12创造性研讨会102 | 5.13头脑风暴104 | 5.14用户代表105 | 5.15思维图107 | 5.16墙纸109 | 5.17录像和照相109 | 5.18wiki.blog和论坛110 | 5.19文档考古学111 | 5.20其他需求收集技巧113 | 5.20.1家庭治疗113 | 5.20.2软系统和视角114 | 5.21确定产品应该是怎样的114 | 5.22技术是否重要116 | 5.23选择*佳网罗技巧117 | 5.24小结119 | 第6章场景和需求120 | 6.1敏捷指南120 | 6.2场景121 | 6.3正常用例场景124 | 6.4场景图示126 | 6.5可选情况127 | 6.6异常情况128 | 6.7假设场景129 | 6.8误用场景和负面场景129 | 6.9场景模板131 | 6.10产品用例场景132 | 6.11小结134 | 第7章功能性需求135 | 7.1敏捷指南136 | 7.2功能性需求136 | 7.3发现功能性需求137 | 7.4细节程度或粒度139 | 7.5异常和可选方式140 | 7.6避免二义性141 | 7.7技术需求142 | 7.8需求不是解决方案143 | 7.9需求分组143 | 7.10功能性需求的替代方式144 | 7.11小结147 | 第8章非功能性需求148 | 8.1敏捷指南149 | 8.2非功能性的需求149 | 8.3用例与非功能性需求151 | 8.4非功能性需求类型151 | 8.5观感需求:类型10152 | 8.6易用性和人性化需求:类型11154 | 8.7执行需求:类型12157 | 8.8操作和环境需求:类型13158 | 8.9可维护性和支持需求:类型14160 | 8.10安全性需求:类型15160 | 8.10.1保密性161 | 8.10.2可得性161 | 8.10.3完整性161 | 8.10.4审计162 | 8.10.5没有其他162 | 8.11文化和政策需求:类型16163 | 8.12法律需求:类型17165 | 8.12.1萨班-奥西利法案(Sarbanes-OxleyAct)166 | 8.12.2其他法律要求166 | 8.12.3标准167 | 8.13发现非功能性需求167 | 8.13.1用Blog记录需求167 | 8.13.2用例167 | 8.13.3模板169 | 8.13.4原型和非功能性需求169 | 8.13.5客户170 | 8.14不要编写解决方案170 | 8.15小结171 | 第9章验收标准173 | 9.1敏捷指南173 | 9.2验收需要标准的原因174 | 9.3测量的尺度175 | 9.4理由176 | 9.5非功能性需求的验收标准177 | 9.5.1产品是否失败179 | 9.5.2主观测试179 | 9.5.3观感需求180 | 9.5.4易用性和人性化需求180 | 9.5.5执行需求181 | 9.5.6可操作性需求182 | 9.5.7可维护性需求182 | 9.5.8安全性需求183 | 9.5.9文化和政策需求183 | 9.5.10法律需求184 | 9.6功能性需求的验收标准184 | 9.7用例和验收标准185 | 9.8项目目标的验收标准186 | 9.9解决方案限制条件的验收标准186 | 9.10小结187 | 第10章编写需求189 | 10.1敏捷指南189 | 10.2将潜在需求变成书面需求191 | 10.3知识与规格说明书192 | 10.4Volere需求规格说明书模板193 | 10.5第1部分——项目的目标..194 | 10.6第2部分——客户.顾客和其他风险承担者197 | 10.7第3部分——产品的用户198 | 10.8第4部分——强制的限制条件199 | 10.9第5部分——命名惯例和定义201 | 10.10第6部分——相关事实和假定202 | 10.11第7部分——工作的范围203 | 10.12第8部分——产品的范围204 | 10.13需求项框架204 | 10.13.1白雪卡205 | 10.13.2自动化的需求工具206 | 10.14原子需求206 | 10.14.1需求编号207 | 10.14.2需求类型207 | 10.14.3事件/用例编号207 | 10.14.4描述208 | 10.14.5理由208 | 10.14.6来源208 | 10.14.7验收标准208 | 10.14.8顾客满意度和不满意度208 | 10.14.9优先级209 | 10.14.10冲突210 | 10.14.11支持材料210 | 10.14.12历史210 | 10.15编写需求规格说明210 | 10.16第9部分——功能性需求211 | 10.17非功能性需求213 | 10.18项目问题214 | 10.19第18部分——开放式问题214 | 10.20第19部分——立即可用的解决方案215 | 10.21第20部分——新问题215 | 10.22第21部分——任务216 | 10.23第22部分——迁移至新产品216 | 10.24第23部分——风险216 | 10.25第24部分——费用217 | 10.26第25部分——用户文档和培训218 | 10.27第26部分——后续版本需求218 | 10.28第27部分——解决方案的设想219 | 10.29小结219 | 第11章质量关220 | 11.1敏捷指南221 | 11.2需求质量222 | 11.3使用质量关223 | 11.4测试完整性224 | 11.4.1测试是否存在遗漏的部分224 | 11.4.2测试是否对所有风险承担者都有意义225 | 11.5测试可追踪性226 | 11.6统一使用术语227 | 11.7确定是否与目标相关228 | 11.8测试验收标准230 | 11.9确定在限制条件下是否可行231 | 11.10区分是需求还是解决方案232 | 11.11顾客价值234 | 11.12镀金需求235 | 11.13需求蔓延235 | 11.14实现质量关238 | 11.15小结240 | 第12章制作需求原型241 | 12.1敏捷指南243 | 12.2原型与事实243 | 12.3低保真原型245 | 12.4高保真原型249 | 12.5故事板251 | 12.6对象生命历史252 | 12.7原型循环254 | 12.7.1设计与构建254 | 12.7.2在用户环境中测试255 | 12.7.3分析结果256 | 12.8小结257 | 第13章复用需求258 | 13.1什么是复用需求258 | 13.2可复用需求的来源260 | 13.3需求模式262 | 13.4业务事件模式263 | 13.4.1事件响应的上下文264 | 13.4.2事件响应的处理264 | 13.4.3事件响应的数据265 | 13.5通过抽象形成模式266 | 13.5.1特定领域的模式267 | 13.5.2跨领域的模式269 | 13.6领域分析270 | 13.7复用的趋势271 | 13.7.1复用和对象271 | 13.7.2复用现在是否是一项工作272 | 13.8小结273 | 第14章复查需求规格说明274 | 14.1敏捷指南275 | 14.2复查规格说明书275 | 14.3审查276 | 14.4发现遗漏的需求277 | 14.5确定是否已发现所有的业务用例277 | 14.6顾客价值283 | 14.7排列需求优先级284 | 14.7.1影响优先级的因素285 | 14.7.2何时确定优先级285 | 14.7.3需求优先级等级286 | 14.7.4优先级电子表格287 | 14.8冲突的需求288 | 14.9二义性的规格说明290 | 14.10风险分析290 | 14.10.1项目驱动291 | 14.10.2项目限制条件292 | 14.10.3功能性需求292 | 14.11度量所需的工作量292 | 14.12小结293 | 第15章需求向何处去294 | 15.1调整需求过程294 | 15.2需求工具296 | 15.3工具对应目标297 | 15.4发布规格说明书299 | 15.4.1合同化文档299 | 15.4.2管理层总结300 | 15.4.3市场人员总结300 | 15.4.4用户复查300 | 15.4.5复查规格说明书301 | 15.5需求可追踪性301 | 15.6处理变化304 | 15.6.1变化的世界305 | 15.6.2需求反馈306 | 15.7需求事后分析307 | 15.7.1复查的内容308 | 15.7.2进行事后分析308 | 15.7.3事后分析报告309 | 15.8记事本310 | 15.9小结310 | 附录AVolere需求过程模型312 | A.1Volere需求过程模型312 | A.2定义项目启动目标(过程说明1.1.1)315 | A.3计划物质上的安排(过程说明1.1.2)316 | A.4与参加者沟通(过程说明1.1.3)316 | A.5确定产品目标(过程说明1.2.1)317 | A.6确定工作上下文范围(过程说明1.2.2)318 | A.7进行“**刀”风险分析(过程说明1.2.3)318 | A.8确定风险承担者(过程说明1.2.4)319 | A.9分解工作上下文(过程说明1.2.5)320 | A.10考虑“无事件(Non-event)”(过程说明1.2.6)320 | A.11确定业务术语(过程说明1.2.7)320 | A.12定义项目限制条件(过程说明1.2.8)320 | A.13确定感兴趣的领域(过程说明1.2.9)321 | A.14编写项目启动报告(过程说明1.3.1)322 | A.15复查启动阶段成果(过程说明1.3.2)322 | A.16跟进启动会议(过程说明1.3.3)323 | A.17做出初步估计(过程说明1.3.4)323 | A.18复查当前状况(过程说明2.1.1)325 | A.19做用户的学徒(过程说明2.1.2)325 | A.20确定本质需求(过程说明2.1.3)325 | A.21需求头脑风暴(过程说明2.1.4)326 | A.22用户访谈(过程说明2.1.5)326 | A.23文档考古学(过程说明2.1.6)327 | A.24制作需求录像带(过程说明2.1.7)328 | A.25召开用例研讨会(过程说明2.1.8)329 | A.26构建事件模型(过程说明2.1.9)329 | A.27构建场景模型(过程说明2.1.10)330 | A.28举行创造性研讨会(过程说明2.1.11)330 | A.29研究相邻系统(过程说明2.2.1)331 | A.30定义用例边界(过程说明2.2.2)331 | A.31收集业务事件知识(过程说明2.3.1)332 | A.32选择合适的网罗技术(过程说明2.3.2)333 | A.33询问澄清问题(过程说明2.4)334 | A.34确定潜在需求(过程说明3.1)335 | A.35确定功能性需求(过程说明3.2)335 | A.36确定组合需求(过程说明3.3)336 | A.37将需求规范化(过程说明3.4)336 | A.38将系统限制条件规范化(过程说明3.5)336 | A.39确定非功能性需求(过程说明3.6)336 | A.40编写功能性验收标准(过程说明3.7)337 | A.41编写非功能性验收标准(过程说明3.8)337 | A.42确定顾客价值(过程说明3.9)338 | A.43确定依赖关系和冲突之处(过程说明3.10)338 | A.44复查需求验收标准(过程说明4.1)339 | A.45复查需求相关性(过程说明4.2)340 | A.46复查需求的切实可行性(过程说明4.3)340 | A.47识别镀金需求(过程说明4.4)341 | A.48复查需求完整性(过程说明4.5)341 | A.49计划制作原型(过程说明5.1)342 | A.50构建低保真的原型(过程说明5.2.1)342 | A.51构建高保真的原型(过程说明5.2.2)343 | A.52与用户测试高保真的原型(过程说明5.3.1)344 | A.53与用户测试低保真的原型(过程说明5.3.2)345 | A.54确定新的需求和有变化的需求(过程说明5.3.3)345 | A.55评估原型工作量(过程说明5.3.4)345 | A.56进行单独的个人复查(过程说明6.1.1)346 | A.57分别进行小组会议(过程说明6.1.2)347 | A.58项目协调人复查事实(过程说明6.1.3)348 | A.59举行事后复查会议(过程说明6.2.1)348 | A.60得到事后分析报告(过程说明6.2.2)349 | A.61确定过滤标准(过程说明6.3.1)350 | A.62选择相关需求类型(过程说明6.3.2)351 | A.63增加新的过滤标准(过程说明6.3.3)351 | A.64确定遗漏的需求(过程说明7.1.1)352 | A.65确定顾客价值评分(过程说明7.1.2)352 | A.66确定需求的相互作用(过程说明7.1.3)353 | A.67确定制作原型的机会(过程说明7.1.4)353 | A.68发现遗漏的保管人需求(过程说明7.1.5)354 | A.69寻找可能的风险(过程说明7.2.1)355 | A.70量化每个风险(过程说明7.2.2)355 | A.71确定估算输入信息(过程说明7.3.1)356 | A.72针对事件估算工作量(过程说明7.3.2)357 | A.73估算需求工作量(过程说明7.3.3)357 | A.74设计需求规格说明书的形式(过程说明7.4.1)358 | A.75汇编需求规格说明书(过程说明7.4.2)359 | A.76需求过程模型中用到的术语359 | 附录BVolere需求规格说明书模板370 | 附录C功能点计数简介414 | C.1度量工作414 | C.2功能点计数快速入门415 | C.2.1工作上下文范围416 | C.2.2工作存储的数据416 | C.2.3业务用例418 | C.3针对业务用例计算功能点418 | C.3.1计算输入型业务用例418 | C.3.2计算输出型业务用例419 | C.3.3计算时间触发型业务用例421 | C.4计算存储的数据422 | C.4.1内部的存储数据422 | C.4.2外部的存储数据423 | C.5针对未知信息进行调整424 | C.6功能点计数的下一步425 | 附录D项目社会关系分析模板427 | D.1风险承担者图示模板427 | D.2风险承担者分析模板428 | 词汇表431 | 参考文献...435 | 掌握需求过程-(第2版) 作者简介
Suzanne Robertson与James Robertson多年来已帮助了数百家公司改进需求技术,进入系统开发的快车道。他们关于需求、分析和设计的课程和讲座采用了创新的方式,受到了广泛的赞誉。 Robertson夫妇是Atlantic SystemS Guild公司的主要成员,该公司是知名的顾问公司,擅长处理复杂系统构建中人员方面的问题。他们也是是Requirements-LedProjectManagement(Addison—wesley,2005)一书的合著者。