系列图书推荐
Microsoft核心技术丛书
- Windows Server 2008网络互联和网络访问保护参考..
- LINQ编程技术内幕..
- Windows CE 6.0开发者参考(原书第4版)..
- Windows Server 2008 TCP/IP协议和服务参考手册..
- ASP.NET 3.5编程循序渐进..
- 代码之道(china-pub 10.22日首发)..
- Windows SharePoint Services 3.0步步通[赠品]..
- ASP.NET 3.5编程循序渐进[赠品]..
- SharePoint 2007精粹(赠品)..
- Windows SharePoint Services 3.0步步通..
- SharePoint 2007精粹..
- Microsoft Silverlight 2 导学 (迈入web新时代第..
- SharePoint 2007精粹[赠品]..
- Microsoft .NET Micro Framework嵌入式编程..
- Microsoft .NET Micro Framework嵌入式编程[赠品..
- Web应用程序性能测试指南..
- Web应用程序性能测试指南[赠品]..
- JavaScript编程循序渐进[赠品]..
- JavaScript编程循序渐进..
相关图书推荐
同类热销商品
您的浏览历史
软件需求模式
|
促销活动
|
点击看大图
基本信息
- 原书名： Software Requirement Patterns
- 原出版社： Microsoft Press
- 作者： (美)Stephen Withall [作译者介绍]
- 译者： 曹新宇[同译者作品]
- 丛书名： Microsoft核心技术丛书
- 出版社：机械工业出版社
- ISBN：9787111242093
- 上架时间：2008-6-26
- 出版日期：2008 年6月
- 开本：16开
- 页码：334
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 >
软件需求
编辑推荐
《人月神话》作者软件大师Rederick P.Brooks先生写序推荐："本书是充满智慧和见解的需求学习图书”。
微软核心技术丛书，探究微软件核心技术。
内容简介回到顶部↑
本书描述了37个真实的、可重用的模式，为编写软件需求提供了特定情形下的框架。每种模式详细描述需要包括哪些信息，提醒常见的缺陷，以及建议需要考虑的额外需求。无论使用传统的分析方法还是敏捷方法，都可以学习如何使用需求模式，从而为成功的软件开发编写一致的、有效的需求。本书提供了模板和实例，帮助分析师编写出更好的需求。读者可以应用本书中的概念开发自己的行业、应用领域或者产品线的特殊需求模式。.
本书适合软件分析人员、软件架构师和项目管理人员等参考。
本书描述了37个真实的、可重用的模式，为编写软件需求提供了特定情形下的框架。每种模式详细描述需要包括哪些信息，提醒常见的缺陷，以及建议需要考虑的额外需求。无论使用传统的分析方法还是敏捷方法，都可以学习如何使用需求模式，从而为成功的软件开发编写一致、有效的需求。
需求模式可以帮助你：..
识别系统间的接口、技术以及文档需求。
定义详细的信息需求，包括归档、数据类型以及数据实体。
指定系统的可用性、容量、伸缩性、扩展性以及易用性。
定义访问控制，包括用户注册、认证以及授权。
指定查询、报表、计算公式以及费和税的需求。
获得400多个实际的需求实例，学习如何编写自己的需求模式。 ...
本书适合软件分析人员、软件架构师和项目管理人员等参考。
本书描述了37个真实的、可重用的模式，为编写软件需求提供了特定情形下的框架。每种模式详细描述需要包括哪些信息，提醒常见的缺陷，以及建议需要考虑的额外需求。无论使用传统的分析方法还是敏捷方法，都可以学习如何使用需求模式，从而为成功的软件开发编写一致、有效的需求。
需求模式可以帮助你：..
识别系统间的接口、技术以及文档需求。
定义详细的信息需求，包括归档、数据类型以及数据实体。
指定系统的可用性、容量、伸缩性、扩展性以及易用性。
定义访问控制，包括用户注册、认证以及授权。
指定查询、报表、计算公式以及费和税的需求。
获得400多个实际的需求实例，学习如何编写自己的需求模式。 ...
作译者回到顶部↑
本书提供作译者介绍
Stephen Withall 有近30年开发和定义软件系统的经验，曾经为全球多个行业组织工作。在其职业生涯中，他扮演了很多角色，包括程序员、业务分析师、架构师以及首席技术官。...
.. << 查看详细
.. << 查看详细
目录回到顶部↑
译者序.
序
前言
第一部分准备开始
第1章需求概述
1.1什么是需求
1.2需求在总体方案中的位置
1.3一些基本原则
1.4传统需求流程
1.5敏捷需求流程
1.5.1极限需求流程
1.5.2增量需求流程
第2章需求规格的内容
2.1介绍部分
2.1.1系统目的
2.1.2文档目的
2.1.3需求格式
2.1.4词汇表
2.1.5参考书目
2.1.6文档历史
序
前言
第一部分准备开始
第1章需求概述
1.1什么是需求
1.2需求在总体方案中的位置
1.3一些基本原则
1.4传统需求流程
1.5敏捷需求流程
1.5.1极限需求流程
1.5.2增量需求流程
第2章需求规格的内容
2.1介绍部分
2.1.1系统目的
2.1.2文档目的
2.1.3需求格式
2.1.4词汇表
2.1.5参考书目
2.1.6文档历史
译者序回到顶部↑
软件大师Frederick PBrooks在他的著名著作《人月神话》中有一句话：“The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification(软件任务的最艰难之处在于取得完全和一致的规格说明，构建程序的主要核心实际上是调整和完善规格说明)。”本书就是关于如何更好地完成软件开发中最艰巨部分的一本书。.
业务和软件技术是两个完全不搭界的东西。怎样能够使技术发挥作用，为业务服务，需求正是弥补业务和技术之间的差距的一种方法。现在很多项目的需求存在的普遍问题是业务和技术完全脱节，要么是过于偏向业务，要么过于偏向技术，如何在业务和技术之间取得折衷，本书提出了需求模式的概念，为这一问题提供了很好的答案。需求是平衡的艺术，既要对开发人员有指导意义，又要能帮助业务解决问题，如何在两者之间取得平衡，本书中的大量实例对此有自己的独特见解。或许你对本书中的一些内容会有不同的看法，可能会觉得啰嗦，不实用，但是需求模式这个概念绝对是未来软件需求分析发展的方向。..
翻译一本书类似做一个庞大的软件系统的开发，作者是设计师，我是开发人员，而读者就是测试人员。作为开发人员，我与作者就原著进行了大量的沟通，并且尽量忠实地翻译原文，但绝对不能保证完全反映了设计人员的意图，没有任何bug。作为测试人员的读者在阅读过程中一定会发现一些不合适的地方，有任何不妥当的地方还请您见谅。
本书翻译过程中，Stephen Withall先生总是非常及时、耐心地回答我的所有问题，甚至有些“啰嗦”，我想这是一个优秀的业务分析师的“通病”。
感谢机械工业出版华章分社给我机会翻译这部优秀的著作。另外清华大学的杨经纬帮助审校了部分章节，在此一并感谢。...
曹新宇
2008年6月
业务和软件技术是两个完全不搭界的东西。怎样能够使技术发挥作用，为业务服务，需求正是弥补业务和技术之间的差距的一种方法。现在很多项目的需求存在的普遍问题是业务和技术完全脱节，要么是过于偏向业务，要么过于偏向技术，如何在业务和技术之间取得折衷，本书提出了需求模式的概念，为这一问题提供了很好的答案。需求是平衡的艺术，既要对开发人员有指导意义，又要能帮助业务解决问题，如何在两者之间取得平衡，本书中的大量实例对此有自己的独特见解。或许你对本书中的一些内容会有不同的看法，可能会觉得啰嗦，不实用，但是需求模式这个概念绝对是未来软件需求分析发展的方向。..
翻译一本书类似做一个庞大的软件系统的开发，作者是设计师，我是开发人员，而读者就是测试人员。作为开发人员，我与作者就原著进行了大量的沟通，并且尽量忠实地翻译原文，但绝对不能保证完全反映了设计人员的意图，没有任何bug。作为测试人员的读者在阅读过程中一定会发现一些不合适的地方，有任何不妥当的地方还请您见谅。
本书翻译过程中，Stephen Withall先生总是非常及时、耐心地回答我的所有问题，甚至有些“啰嗦”，我想这是一个优秀的业务分析师的“通病”。
感谢机械工业出版华章分社给我机会翻译这部优秀的著作。另外清华大学的杨经纬帮助审校了部分章节，在此一并感谢。...
曹新宇
2008年6月
前言回到顶部↑
本书的目的.
太阳下没有任何新东西，所有东西以前都做过了。
——阿瑟·柯南·道尔，《福尔摩斯：血字的研究》
本书的目的是帮助决定和定义新的软件系统需要做什么，建议添加哪些额外的特性，使系统更好或者更卓越。通过详细地指导如何定义一个需求，它将节省你的工作量，使你能更精确。需求模式是技术的结晶，方便将来重用。本书包含37个需求模式，每一种模式描述一种方法，解决在所有系统中反复出现的一种特定的情况，主要关注于商业业务系统。任何系统都只有一小部分属于特定的业务范围，不管系统是做什么的，大部分是反复出现的。这些模式覆盖了一些系统中超过一半的需求（如果添加模式建议的额外需求，会覆盖更多）。
如果你对“需求”这个词敏感，那大可不必；它并不意味着要卷入乏味的文档工作。使用传统分析方法的业务分析师和使用敏捷方法的架构师和工程师都可以使用本书。即使不需要编写正规的需求文档，使用需求模式也可以帮助识别和定义系统需要做什么。
软件系统的需求定义它要解决的问题：它的意图和目的。如果需求遗漏或者做的很糟糕（遗憾的是，这是非常常见的情况）系统就不可能是合适的，不管系统实现得如何完美。相当比例的计算机系统被认为是不合格的；很多甚至没有交付使用；更多的是延期或者超预算。很多研究都表明最大的一个原因就是拙劣的需求定义：没有完全地确定系统的意图和它必须做的事。甚至稍微改进需求就可能节省商业上浪费的大量投资。
为了确保构造更好的系统，需要一系列的改进。几乎各个领域已经（而且将继续）进行大量的投入。但是其中最基础的是需求本身表达什么（同样重要的是不能表达什么）。这点被忽略了，而这正是本书所关注的。如果想定义一种特定类型的需求，需要写什么？如何着手？需要考虑哪些额外需求？其他还有什么应该考虑？本书指出很多方面（大的或小的）的需求经常不充分，不准确，或者完全遗漏，并针对这些问题提出建议。模式本身希望是脚踏实地和实用的多年以来积累的经验（主要来自个人的经验）。
本书是一本参考书，当你需要处理一种特别的情况的时候帮助你摆脱困境——解释需求需要传达的内容，帮助提出问题，指出可能的缺陷，提示额外的需求，提供需求实例，以及提供实用的建议。你不需要通读本书就可以开始使用需求模式。
本书包括很多需求实例（超过400个），很多都可以不用修改就应用于任何系统，其他则可以作为适应读者的各种需要的需求的出发点。这些例子是本书的核心。本书中所有的需求模式来自于实际需求的研究。实际需求中存在的遗漏、含糊以及其他的问题为需求模式提供了很多内容。
本书也指导如何编写需求规范中其他种类的信息（例如，系统范围、假定、词汇表、文档历史和参考）以及如何组织需求规范。本书不做什么
本书不涉及定义需求的流程，分析技术以及需求管理。有很多关于这些方面的优秀的书籍，本书可以作为它们的参考书。不过本书可以很好地单独使用；它包括一节“定义需求速成课程”，（参见第1章）可以帮助没有经验的读者。
本书不关注任何特定的方法论、办法，或者定义软件的工具。不管你选择如何工作，本书都提供相关的建议。本书不是规定：它不会说“你必须这么办。”本书避免使用行话，并尽可能不引入自己的术语。
你不必同意本书的所有观点，也不需要完全照需求模式的建议去做。但是无论是在编写需求的时候还是在之后，如果它帮助你节省了时间，如果它物超所值，那么就值得保留。希望这些模式是足够有用的、引发思考的材料，引导建立更好的系统，从而可以以某种方式证明它是有用的。
谁将从本书中受益
本书的主要读者是涉及决定一个新的软件系统需要做什么的任何人。这就是定义一个软件系统的需求要完成的工作，即使你不喜欢“需求”这个词，或者你不以编写完整的需求规格为目的。为了方便，对任何定义需求的人，我们称之为分析师；他们可能是业务分析师、系统分析师、系统架构师，或者软件工程师；他们可以是业务人员，也可以是技术人员。他们以前可能有定义需求的经验，或者他们没有。他们可以分为两种人：使用传统的分析流程和使用更敏捷一些的方法：
a）业务分析师，或者任何完成这个角色的人。本书不对读者的经验做任何假设：它既适合经验欠缺或经验丰富的业务分析师，也适合以前从没有定义过需求的业务人员和软件工程师。需求模式可以迅速付诸实践。
b）软件架构师和工程师，所负责的系统的需求还没有确定——必须弥补这块空白，不管它使用什么样的方式。无论谁决定系统需要做什么，本书的建议都是有用的。即使组织内部没有专职的分析师，特别是采取敏捷方法开发的组织，它的建议是同样有价值的。敏捷方法不注重（如果有）编写需求规格，但还是要确定系统的功能——无论使用敏捷方法还是传统的方法，本书中的需求模式提供同样的帮助。特别是在极限编程中，需求模式可以帮助编写用户故事，解释用户故事，并为开发人员建立良好的实践规则。熟悉设计模式的软件架构师和工程师应该很容易接受需求模式。
本书的其他读者：
c）任何被要求评审需求规格的人，这包括技术、管理、销售人员以及新系统的用户团体。本书帮助评审人员判断规格的质量和完整性，以及发现遗漏。
d）实现需求的软件开发人员，每个需求模式都包括“开发考虑”部分帮助开发人员。
太阳下没有任何新东西，所有东西以前都做过了。
——阿瑟·柯南·道尔，《福尔摩斯：血字的研究》
本书的目的是帮助决定和定义新的软件系统需要做什么，建议添加哪些额外的特性，使系统更好或者更卓越。通过详细地指导如何定义一个需求，它将节省你的工作量，使你能更精确。需求模式是技术的结晶，方便将来重用。本书包含37个需求模式，每一种模式描述一种方法，解决在所有系统中反复出现的一种特定的情况，主要关注于商业业务系统。任何系统都只有一小部分属于特定的业务范围，不管系统是做什么的，大部分是反复出现的。这些模式覆盖了一些系统中超过一半的需求（如果添加模式建议的额外需求，会覆盖更多）。
如果你对“需求”这个词敏感，那大可不必；它并不意味着要卷入乏味的文档工作。使用传统分析方法的业务分析师和使用敏捷方法的架构师和工程师都可以使用本书。即使不需要编写正规的需求文档，使用需求模式也可以帮助识别和定义系统需要做什么。
软件系统的需求定义它要解决的问题：它的意图和目的。如果需求遗漏或者做的很糟糕（遗憾的是，这是非常常见的情况）系统就不可能是合适的，不管系统实现得如何完美。相当比例的计算机系统被认为是不合格的；很多甚至没有交付使用；更多的是延期或者超预算。很多研究都表明最大的一个原因就是拙劣的需求定义：没有完全地确定系统的意图和它必须做的事。甚至稍微改进需求就可能节省商业上浪费的大量投资。
为了确保构造更好的系统，需要一系列的改进。几乎各个领域已经（而且将继续）进行大量的投入。但是其中最基础的是需求本身表达什么（同样重要的是不能表达什么）。这点被忽略了，而这正是本书所关注的。如果想定义一种特定类型的需求，需要写什么？如何着手？需要考虑哪些额外需求？其他还有什么应该考虑？本书指出很多方面（大的或小的）的需求经常不充分，不准确，或者完全遗漏，并针对这些问题提出建议。模式本身希望是脚踏实地和实用的多年以来积累的经验（主要来自个人的经验）。
本书是一本参考书，当你需要处理一种特别的情况的时候帮助你摆脱困境——解释需求需要传达的内容，帮助提出问题，指出可能的缺陷，提示额外的需求，提供需求实例，以及提供实用的建议。你不需要通读本书就可以开始使用需求模式。
本书包括很多需求实例（超过400个），很多都可以不用修改就应用于任何系统，其他则可以作为适应读者的各种需要的需求的出发点。这些例子是本书的核心。本书中所有的需求模式来自于实际需求的研究。实际需求中存在的遗漏、含糊以及其他的问题为需求模式提供了很多内容。
本书也指导如何编写需求规范中其他种类的信息（例如，系统范围、假定、词汇表、文档历史和参考）以及如何组织需求规范。本书不做什么
本书不涉及定义需求的流程，分析技术以及需求管理。有很多关于这些方面的优秀的书籍，本书可以作为它们的参考书。不过本书可以很好地单独使用；它包括一节“定义需求速成课程”，（参见第1章）可以帮助没有经验的读者。
本书不关注任何特定的方法论、办法，或者定义软件的工具。不管你选择如何工作，本书都提供相关的建议。本书不是规定：它不会说“你必须这么办。”本书避免使用行话，并尽可能不引入自己的术语。
你不必同意本书的所有观点，也不需要完全照需求模式的建议去做。但是无论是在编写需求的时候还是在之后，如果它帮助你节省了时间，如果它物超所值，那么就值得保留。希望这些模式是足够有用的、引发思考的材料，引导建立更好的系统，从而可以以某种方式证明它是有用的。
谁将从本书中受益
本书的主要读者是涉及决定一个新的软件系统需要做什么的任何人。这就是定义一个软件系统的需求要完成的工作，即使你不喜欢“需求”这个词，或者你不以编写完整的需求规格为目的。为了方便，对任何定义需求的人，我们称之为分析师；他们可能是业务分析师、系统分析师、系统架构师，或者软件工程师；他们可以是业务人员，也可以是技术人员。他们以前可能有定义需求的经验，或者他们没有。他们可以分为两种人：使用传统的分析流程和使用更敏捷一些的方法：
a）业务分析师，或者任何完成这个角色的人。本书不对读者的经验做任何假设：它既适合经验欠缺或经验丰富的业务分析师，也适合以前从没有定义过需求的业务人员和软件工程师。需求模式可以迅速付诸实践。
b）软件架构师和工程师，所负责的系统的需求还没有确定——必须弥补这块空白，不管它使用什么样的方式。无论谁决定系统需要做什么，本书的建议都是有用的。即使组织内部没有专职的分析师，特别是采取敏捷方法开发的组织，它的建议是同样有价值的。敏捷方法不注重（如果有）编写需求规格，但还是要确定系统的功能——无论使用敏捷方法还是传统的方法，本书中的需求模式提供同样的帮助。特别是在极限编程中，需求模式可以帮助编写用户故事，解释用户故事，并为开发人员建立良好的实践规则。熟悉设计模式的软件架构师和工程师应该很容易接受需求模式。
本书的其他读者：
c）任何被要求评审需求规格的人，这包括技术、管理、销售人员以及新系统的用户团体。本书帮助评审人员判断规格的质量和完整性，以及发现遗漏。
d）实现需求的软件开发人员，每个需求模式都包括“开发考虑”部分帮助开发人员。
序言回到顶部↑
需求开发是困难的！很多需求分析师缺乏训练或者经验不足，他们没有必要的编写高质量需求的知识，只是尽力做好。分析师们经常提出一些问题，比如：“我从哪里开始？”，“我怎样知道什么时候我做完了？”，“需求应该详细到什么程度？”，“我遗漏需求了吗？”，以及“我写的需求里忽略了一些关键信息吗？”遗憾的是，对于理解和定义需求这种沟通密集型的挑战没有公式化的方法。.
本书可以帮助分析师编写出更好的需求。这些模式提供了一种方法表达关于不同类型需求的全面的结构化知识。需求开发是探险之旅，不只是简单地收集或抄写的过程。Steve提出的模式可以帮助分析师询问合适的问题，以恰当的详细程度正确地理解和定义很多类型的需求。从需求使用者角度来看，模式协助开发人员和测试人员在开发阶段了解需求。人们通常从实例中学习，而且模板可以使他们的工作更有效。基于这个目的，Steve的需求模式提供了模板和实例。..
这些需求模式适用于多种多样的项目和产品。你可以应用本书中的概念开发你自己的行业、应用领域或者产品线的特殊的需求模式。太多的项目从零开始定义需求，而需求模式使开发组织可以有效地重用以前项目获得的需求知识。
本书传达了大量的编写高质量需求的智慧和洞察力。Steve指出使用模式以一致的风格编写需求的价值，它可以增强每个分析师的能力。即使不想严格地使用模式，本书包含的几百个实用提示也可以帮助定义更好的需求。还可以使用本书作为参考：阅读相关的模式，尝试它们，吸收Steve提出的思想和建议。透彻理解模式适用的情况后，你会自觉使用它们探索、分析、记录和使用软件需求。
需求模式可能代表了未来软件需求思考的方向。本书或许将是未来几年关于需求模式的最权威的著作。...
Karl Wiegers
2007年4月
本书可以帮助分析师编写出更好的需求。这些模式提供了一种方法表达关于不同类型需求的全面的结构化知识。需求开发是探险之旅，不只是简单地收集或抄写的过程。Steve提出的模式可以帮助分析师询问合适的问题，以恰当的详细程度正确地理解和定义很多类型的需求。从需求使用者角度来看，模式协助开发人员和测试人员在开发阶段了解需求。人们通常从实例中学习，而且模板可以使他们的工作更有效。基于这个目的，Steve的需求模式提供了模板和实例。..
这些需求模式适用于多种多样的项目和产品。你可以应用本书中的概念开发你自己的行业、应用领域或者产品线的特殊的需求模式。太多的项目从零开始定义需求，而需求模式使开发组织可以有效地重用以前项目获得的需求知识。
本书传达了大量的编写高质量需求的智慧和洞察力。Steve指出使用模式以一致的风格编写需求的价值，它可以增强每个分析师的能力。即使不想严格地使用模式，本书包含的几百个实用提示也可以帮助定义更好的需求。还可以使用本书作为参考：阅读相关的模式，尝试它们，吸收Steve提出的思想和建议。透彻理解模式适用的情况后，你会自觉使用它们探索、分析、记录和使用软件需求。
需求模式可能代表了未来软件需求思考的方向。本书或许将是未来几年关于需求模式的最权威的著作。...
Karl Wiegers
2007年4月
媒体评论回到顶部↑
“本书是充满智慧和见解的需求学习图书。”
—Karl E. Wiegers，《Software Requirements》作者.
“本书以一种新颖的方式编制优质需求，并对它们进行实例封装。本书是任何业务分析人员的必备工具。”
—Roxanne Miller，Requirements Quest首席顾问...
—Karl E. Wiegers，《Software Requirements》作者.
“本书以一种新颖的方式编制优质需求，并对它们进行实例封装。本书是任何业务分析人员的必备工具。”
—Roxanne Miller，Requirements Quest首席顾问...
评论交流
共有10人开贴评论 13人参与评论 8人参与打分 查看
评价等级：
发表于：2008-7-24 9:03:00
Stephen Withall 的这本《软件需求模式》能帮助任何一位分析师写出很好的需求来。而史蒂夫模式设计能够帮助分析师提出正确的问题去理解不同层次、不同类型的需求。这本书为如何写主要的需求传递了丰富的智慧和洞察力。模式方法也为探索和记录需求提供可参考价值。即使你不太会使用模式，史蒂夫提供数以百计的实用技巧，指明更好的要求。
这本书没有讲叙整个需求和发展的全过程。你不会坐下来看完全书。因为这本书是你在遇到困难时可能随意参查的。他的每个部分都能解决你工作的的实际问题。所以我强烈推荐！
这本书没有讲叙整个需求和发展的全过程。你不会坐下来看完全书。因为这本书是你在遇到困难时可能随意参查的。他的每个部分都能解决你工作的的实际问题。所以我强烈推荐！
评价等级：
发表于：2008-7-2 10:07:00
Stephen Withall应该祝贺自己完成了这本300多页的需求模式书籍。这些需求模式都是不错的。对于所有想要知道什么是较好的书面需求，以及这种需求看起来可能会像什么样的人,我只推荐这本书。。 如果你想知道什么是一个很好的书面需求，那么你应该尝试去读Tom Gilb的书《Competitive Engineering》。我说尝试的原因是因为那本书并不容易阅读。
Withall开门见山地从一开始就在本书的例子中使用模式语言。我并不热衷于模式语言，因为它们使我感到迷惑，但这可能是个人问题。很少有资料解释什么需求或如何获得它们。本书的目的是记录它们 。在网站上，他对需求有一个很简短（非常、非常简短）的简介，并承诺以后会增添相关内容。不过，我没有看过网上的东西。
我所了解的以及对本书整体的看法是，需求的工作定义集中在缓和功能需求。是的，本书对非功能要求做了稍许的改变。坦白说，功能需求并没有那么有趣。是的，它们有必要的，但它们通常是很容易 得到的。真正让团队陷入麻烦的是非功能需求。这并不是说软件没有完成你想要的功能，它只是以它的方式、你不喜欢的方式来完成的。
用户功能需求部分（甚至他很早就告诉我们，明确问题，并非解决方案）的例子有很多种解决方案，这一点是明确的。“该系统将刷新自身”和“无论什么时候为了提醒用户发出声音，此时也应该唤醒 视觉提示” 。为什么我询问你？因为这是有关解决方案的谈话。
现在变得较为公平了，问题和解决方案是一个相对的区域。所以，在没有一个明确说明的背景下，我不能说这两个例子都是真实的，但我的钱是对的解决方案。对于上面来说，一个有问题的用户界面需 求更像是“用户在x秒的时间内将正确识别95%的警报”或类似的东西。
如果您想要有一本具有大量例子的书，本书刚刚适合你。这些例子中有一些好的问题，但有更多的事情需要记下来。
Withall开门见山地从一开始就在本书的例子中使用模式语言。我并不热衷于模式语言，因为它们使我感到迷惑，但这可能是个人问题。很少有资料解释什么需求或如何获得它们。本书的目的是记录它们 。在网站上，他对需求有一个很简短（非常、非常简短）的简介，并承诺以后会增添相关内容。不过，我没有看过网上的东西。
我所了解的以及对本书整体的看法是，需求的工作定义集中在缓和功能需求。是的，本书对非功能要求做了稍许的改变。坦白说，功能需求并没有那么有趣。是的，它们有必要的，但它们通常是很容易 得到的。真正让团队陷入麻烦的是非功能需求。这并不是说软件没有完成你想要的功能，它只是以它的方式、你不喜欢的方式来完成的。
用户功能需求部分（甚至他很早就告诉我们，明确问题，并非解决方案）的例子有很多种解决方案，这一点是明确的。“该系统将刷新自身”和“无论什么时候为了提醒用户发出声音，此时也应该唤醒 视觉提示” 。为什么我询问你？因为这是有关解决方案的谈话。
现在变得较为公平了，问题和解决方案是一个相对的区域。所以，在没有一个明确说明的背景下，我不能说这两个例子都是真实的，但我的钱是对的解决方案。对于上面来说，一个有问题的用户界面需 求更像是“用户在x秒的时间内将正确识别95%的警报”或类似的东西。
如果您想要有一本具有大量例子的书，本书刚刚适合你。这些例子中有一些好的问题，但有更多的事情需要记下来。
)
加载中...| 我要写评论 |
| 查看所有评论交流(共10条) |