作 者:(美)卡尔·魏格斯(Karl Wiegers),(美)乔伊·贝蒂(Joy Beatty) 著;李忠利,李淳,孔晨辉 等 译 定 价:99 出 版 社:清华大学出版社 出版日期:2016年03月01日 页 数:546 装 帧:平装 ISBN:9787302426820 ●第Ⅰ部分软件需求的3W(什么、为什么和谁)
●第1章软件需求的本质
●第2章从客户角度审视需求
●第3章需求工程实践
●第4章业务分析师
●第Ⅱ部分需求开发
●第5章建立业务需求
●第6章倾听用户的心声
●第7章需求获取
●第8章理解用户需求
●第9章照章办事
●第10章记录需求
●第11章写出的需求
●第12章一图胜千言
●第13章具体指定数据需求
●第14章功能需求以外
●第15章通过原型来减少风险
●第16章要事优先:设定需求优先级
●第17章确认需求
●第18章需求的重用
●部分目录
内容简介
作为经典的软件需求工程畅销书,经由需求社区两大知名结对全面修订和更新,覆盖新的主题、实例和指南,多方面讨论软件项目所涉及的所有需求开发和管理活动,介绍当下的所有实践。书中描述实用性强的、高效的、经过实际检验的端到端需求工程管理技术,通过丰富的实例来演示如何利用很好实践来减少订单变更,提高客户满意度,减少开发成本。书中的用例、业务规则和商业工具全面修订以体现现状和未来的趋势。
本书尤其适合具备一定软件开发过程经验的业务分析师、需求分析师、项目经理和其他软件项目涉众。 (美)卡尔·魏格斯(Karl Wiegers),(美)乔伊·贝蒂(Joy Beatty) 著;李忠利,李淳,孔晨辉 等 译 Karl Wiegers(卡尔·魏格斯)博士,优选认可的软件需求工程、过程改进和软件质量专家,享有盛誉的技术作家,他发表过很多文章,他的经典著作《软件需求》系列版本对需求领域有着举足轻重的影响。
Karl在伊利诺大学获得有机化学博士学位。除了计算机,他的爱好还包括品酒、弹吉他、写歌录歌和参与公益活动。Joy Beatty(乔伊·贝蒂),软件需求社区的,曾经协助财富500强中很多企业建立很好业务分析中心。Joy是ITBA《BABOK指南》的主要贡献者,CBAP(认证业务分析师)。她具有丰富的培训经验和表达能力.培训过几千名业务分析师,曾经发表很多文章和演讲。她还是《软等
《软件需求(第3版)》内容简介 引言 在当今快速发展的技术领域,软件已渗透到我们生活的方方面面,成为推动社会进步和商业创新的核心动力。无论是支撑企业运营的复杂系统,还是为大众提供便利的移动应用,软件的成功与否,在很大程度上取决于其是否能够准确地满足用户和利益相关者的真实需求。然而,软件需求工程(Software Requirements Engineering,SRE)作为软件开发生命周期中的关键环节,长期以来一直困扰着行业内的从业者。需求的不准确、不完整、不一致或频繁变更,是导致软件项目失败的头号元凶。 《软件需求(第3版)》正是一部旨在系统性解决这一挑战的权威著作。本书并非简单罗列各种需求工程的技术和方法,而是深入剖析了需求活动的本质,以及如何在实际的项目实践中有效地管理和实现软件需求。它将需求活动视为一个贯穿软件生命周期的、动态的、协作的认知过程,强调理解、协商、阐述和验证需求的重要性,而非仅仅将其视为一份静态的文档。 核心理念:需求作为一种认知活动 本书最核心的理念是将需求视为一种认知活动。这意味着,需求并非凭空产生,也不是简单地收集和记录。相反,它是一个理解、探索、分析、推理和达成共识的过程。开发者、分析师、用户以及其他利益相关者,都需要通过积极的互动和深入的沟通,来共同构建对“问题领域”和“期望解决方案”的理解。 理解与探索: 在这个阶段,目标是深入理解业务领域、用户目标、业务流程以及现有的问题。这需要积极地提问、倾听、观察,并利用各种侦查技术来揭示隐藏的假设和隐含的需求。 协商与共识: 需求往往涉及多个利益相关者,他们可能拥有不同的视角、优先级和期望。需求工程的重要任务就是促进这些不同声音之间的协商,找到能够满足最广泛利益相关者需求的共同点,达成共识。 阐述与建模: 将模糊的想法转化为清晰、准确、无歧义的描述。这涉及到使用各种建模技术(如用例、用户故事、流程图、数据模型等)来可视化和结构化需求,使其更易于理解和分析。 验证与确认: 确保所定义的需求确实是“正确”的需求,即它们能够解决真正的问题,并满足用户和业务的期望。这包括评审、原型演示、用户验收测试等多种验证手段。 本书强调,需求活动不是一次性的任务,而是一个持续演进的过程。随着项目进展、环境变化和用户反馈的积累,需求会不断地被 refine、补充、修正甚至推翻。因此,需求管理(Requirements Management)的重要性不亚于需求获取(Requirements Elicitation)和需求规格说明(Requirements Specification)。 需求工程的体系结构 《软件需求(第3版)》构建了一个全面的需求工程体系结构,涵盖了从战略规划到具体实施的各个层面。 需求战略(Requirements Strategy): 任何软件项目都应有一个清晰的需求战略,它决定了需求活动如何在项目整体框架中定位,以及将采用何种方法论、工具和流程。战略的制定需要考虑项目的规模、复杂性、团队能力、交付周期以及风险容忍度。 需求过程(Requirements Process): 这是一个更具操作性的框架,它定义了需求活动的主要阶段、步骤、可交付成果以及各个角色之间的协作关系。本书探讨了不同的需求过程模型,例如瀑布模型下的需求活动,以及敏捷开发模式下如何适应和优化需求流程。 需求技术(Requirements Techniques): 这是实现需求活动的具体工具和方法,包括: 需求获取技术: 面谈、问卷、焦点小组、观察、文档分析、头脑风暴、原型法等。 需求建模技术: 用例模型、用户故事、活动图、状态图、类图、流程图、数据流图、领域模型等。 需求分析技术: 冲突检测、优先级排序、可行性分析、影响分析、根本原因分析等。 需求验证技术: 需求评审(静态和动态)、原型演示、用户验收测试、走查(walkthroughs)等。 需求管理技术: 版本控制、变更控制、需求跟踪、基线管理、度量与报告等。 核心内容详解 本书对需求工程的各个方面进行了深入的探讨,以下是其中几个核心部分的详细介绍: 1. 需求获取:深入理解“问题领域” 需求获取是需求工程的起点,也是最容易出现问题的环节。本书强调,获取高质量的需求,关键在于真正理解“问题领域”(Problem Domain),而不是急于提出解决方案。 侦查式获取(Elicitation as Discovery): 软件需求并非总是显而易见的,很多需求隐藏在用户的日常工作流程、潜在的痛点、未曾表达的期望以及行业的潜规则中。本书介绍了多种侦查式技术,帮助分析师深入挖掘这些信息。例如,通过长时间的现场观察,模拟用户的操作流程,甚至扮演用户的角色,来体验真实的业务场景。 利益相关者分析(Stakeholder Analysis): 识别所有可能受软件影响的个人或群体,理解他们的需求、期望、影响力和潜在冲突。有效的利益相关者分析是成功需求获取的基础,可以避免遗漏关键需求,并减少项目后期因利益冲突而产生的阻力。 场景与用例(Scenarios and Use Cases): 本书详细阐述了用例建模的原理和实践。用例描述了系统如何与外部参与者(用户或外部系统)进行交互,以实现特定的业务目标。通过构建详细的用例模型,可以清晰地展示系统的功能边界、用户角色以及主要的业务流程。场景则是用例的实例化,描述了在特定条件下,参与者与系统交互的完整序列。 用户故事(User Stories): 特别是在敏捷开发背景下,用户故事成为了一种流行的需求描述方式。本书探讨了用户故事的编写原则(如 INVEST 原则:Independent, Negotiable, Valuable, Estimable, Small, Testable),以及如何将用户故事转化为更详细的验收标准(Acceptance Criteria),使其具备可执行性。 2. 需求阐述:清晰、准确、无歧义的描述 获取到的原始信息往往是零散、模糊甚至矛盾的。需求阐述的任务是将这些信息转化为清晰、准确、无歧义的规格说明。 建模的艺术: 本书强调建模在需求阐述中的重要性。不同的模型能够从不同的维度揭示需求的本质。例如,活动图(Activity Diagrams)可以清晰地展现业务流程的流转;状态图(State Machines)则能有效地描述对象的生命周期和状态变化;数据模型(Data Models)则关注数据的结构和关系。通过组合使用这些模型,可以构建一个全面而易于理解的需求视图。 非功能性需求(Non-functional Requirements,NFRs): 除了描述系统的“做什么”(功能性需求),更重要的是描述系统“如何做”(非功能性需求)。这包括性能(Performance)、安全性(Security)、可用性(Usability)、可靠性(Reliability)、可维护性(Maintainability)、可伸缩性(Scalability)等。本书提供了识别、描述和度量这些非功能性需求的有效方法,强调它们与功能性需求同等重要,甚至在某些情况下更为关键。 模糊性与不确定性管理: 需求很少是完美的,总会存在模糊和不确定性。本书介绍了如何识别这些模糊点,并通过提问、探索或引入约束来逐步消除它们。当完全消除不确定性不可行时,则需要记录并管理这种不确定性,以便在后续阶段处理。 3. 需求验证:确保“正确”的需求 验证需求是防止需求蔓延和减少返工的关键步骤。本书提供了多种验证技术。 评审与走查: 通过组织不同角色的团队成员、利益相关者对需求文档进行系统性的审查,发现潜在的错误、遗漏、不一致和歧义。本书提供了不同类型的评审方法,以及如何有效地组织和执行评审会议。 原型演示(Prototyping): 交互式原型是验证用户界面和用户体验的强大工具。通过构建可操作的原型,用户可以直观地体验系统的部分功能,并提供及时的反馈。这比阅读静态的文档更容易发现用户体验方面的问题。 用户验收测试(User Acceptance Testing,UAT): 在项目接近尾声时,让最终用户在实际或模拟的环境中对软件进行测试,以确认软件是否满足他们的业务需求。本书强调 UAT 的重要性,并提供了如何规划和执行 UAT 的指导。 4. 需求管理:应对变化与维护一致性 软件需求在整个生命周期中都会发生变化。有效的需求管理是应对这些变化、保持项目轨迹、确保最终交付的软件与最初设定的目标一致的关键。 变更控制(Change Control): 建立一个正式的流程来评估、批准或拒绝需求变更请求。这包括对变更的影响进行分析(例如,对成本、进度、资源、其他需求的影响),并对变更的批准进行记录和追溯。 需求跟踪(Requirements Traceability): 建立需求与其来源(例如,业务目标、用户反馈)以及其实现(例如,设计文档、代码、测试用例)之间的链接。这使得在需求发生变化时,能够快速识别受影响的组件,并在必要时更新相关的文档和代码。 需求基线(Baselines): 在项目的关键节点,对需求进行冻结,形成一个稳定的基线。在此之后,任何对基线的变更都需要经过严格的变更控制流程。基线为项目的进展提供了明确的参考点。 度量与报告(Metrics and Reporting): 跟踪需求过程中的关键度量指标,例如需求变更的数量、需求稳定性、需求实现率等,并定期生成报告,为项目管理提供决策依据。 面向未来:敏捷环境下的需求工程 随着敏捷开发方法的兴起,《软件需求(第3版)》也深刻地探讨了在敏捷环境下如何进行需求工程。敏捷方法强调迭代、增量交付和持续反馈,这要求需求活动必须更加灵活和响应迅速。 持续的需求反馈: 在敏捷项目中,需求不是在项目开始时一次性确定的,而是在每个迭代(Sprint)开始前进行细化和规划。用户和业务代表持续参与到开发过程中,提供即时反馈,帮助团队不断调整和优化需求。 用户故事和待办列表(Backlog): 敏捷项目通常使用用户故事来描述需求,并将这些故事组织成一个动态的产品待办列表。这个列表会根据优先级、业务价值和技术可行性进行不断地排序和调整。 “完成”的定义(Definition of Done): 敏捷团队需要明确“完成”的定义,包括对需求的理解、开发、测试以及文档等所有方面的要求。这有助于确保每个交付的增量都达到了预期的质量标准。 结论 《软件需求(第3版)》并非一本仅仅列举技术和方法的工具书,它是一部关于如何思考和实践软件需求工程的指南。它以深刻的洞察力,将需求活动提升到“认知活动”的高度,强调了理解、协商、阐述和验证的重要性。无论是经验丰富的软件工程师,还是初涉此道的分析师,亦或是需要管理软件项目的管理者,都能从本书中获得宝贵的知识和实用的指导,从而更有效地应对软件开发中的核心挑战,提高软件项目的成功率。掌握了本书所阐述的需求工程原则和技术,将能够更精准地把握用户期望,构建出真正有价值、能够解决实际问题的优秀软件。
这本书的理论深度和实践指导性都做得非常出色。它不只是停留在“是什么”的层面,更深入地探讨了“为什么”和“如何做”。对于如何处理模糊不清的需求,如何解决需求冲突,以及如何进行需求评审,书中都提供了非常实用的方法和技巧。我尤其欣赏它关于“建模”的讲解,比如用例图、流程图、状态图等,这些可视化工具能够帮助我们更清晰地理解复杂的业务逻辑,并且有效地将这些逻辑传达给团队成员。书中还提到了敏捷开发中的需求管理,如何与 Scrum 等框架结合,将需求分析和迭代开发有机地结合起来。这对于我们这类需要快速响应市场变化的项目来说,具有非常重要的指导意义。我不再是那种“闭门造车”式的需求分析,而是能够真正地与团队进行协作,共同打磨产品。这本书就像一位经验丰富的导师,在我成长的道路上,给予了宝贵的指导和启示。