ibm_doors_get_it_right_the_first_time_中文版.docx-资料库

yongshengfree-3003343-4744302543288819560.docx.pdf-第1页.png

第1页 / 共29页

yongshengfree-3003343-4744302543288819560.docx.pdf-第2页.png

第2页 / 共29页

yongshengfree-3003343-4744302543288819560.docx.pdf-第3页.png

第3页 / 共29页

yongshengfree-3003343-4744302543288819560.docx.pdf-第4页.png

第4页 / 共29页

yongshengfree-3003343-4744302543288819560.docx.pdf-第5页.png

第5页 / 共29页

yongshengfree-3003343-4744302543288819560.docx.pdf-第6页.png

第6页 / 共29页

yongshengfree-3003343-4744302543288819560.docx.pdf-第7页.png

第7页 / 共29页

yongshengfree-3003343-4744302543288819560.docx.pdf-第8页.png

第8页 / 共29页

Get It Right the First Time 中文版 by 赵永胜 2011.01 yongshengfree@163.com

1. 关于这个手册需求工程是一个挑战。它包括工程知识，与人打交道的技巧，和在评估比如竞争力和政治压力方面的经验。好消息是好多让你易上当的陷阱都可以通过实行下面列的关于写出好的需求的简单方针去避免。有一个好的开始，并且对目标和用户需要有着清晰和准确的了解的项目更有可能成功。需求是project成功的关键。设计这本书的目的是帮助开发人员和用户写出好的需求。因为它是关于书写需求的实用技术，它应该在很多不同类型的系统和软件项目中都有用。这本书能使已经参加过需求工具课程的工程师为一个成功的系统写出足够好的需求。这本书特别注重获得好的需求。同时，这本书和相关的课程都把注意力集中在实际收集，书写和组织需求等这些任务上。这本书的信息可以用一句话表述：在试图创建一个解决方案前理解用户想要什么并就此与用户达成一致。找出需要什么而不是仓促假想出一个解决方案是系统开发每一个方面的关键。大部分的技术问题都可以解决，一定的决心，耐心，一个熟练的团队和一个良好定义的待解决的问题。

2. 怎么写出好的需求定义一系列好的需求对project成功是至关重要的。如果你能把需求中做的很好，你可以节省一大笔财富。所以不要对花时间在确保它们是正确的这件事上感到不情愿。这本书的论点是很直截了当的。获得一系列好需求不是一个技术问题－－它包含人际交往和一套有组织的方法。需求是用户和开发人员之间一条重要的沟通线。系统工程是关乎人的问题，只有在参与的每个人都通力合作的情况下才能工作。project只有在它们把注意力放在结果上的时候才能成功，因此不管开发什么仅旨在满足了需要并且交付了用户想要的东西。这些也只有在用户的需要被清晰地定义并且他们的问题被完整地写下来的时候才有可能实现。下面是着手开始的一些提示： * 现在就开始写需求； * 快速产生一个文档，并尽可能快的获得反馈； * 整理需求，删除设计和重复的需求； * 先定一个概要，如果你没有的话，在写需求的时候把这件事完成； * 持续地进行头脑风暴和内部评审； * 把它展现给用户并快速地修正比让专家分析要好得多。以下是需要你记住的方针： 1、在开发工作的过程中关注结果，特别是在大型的工程中－－目标就是解决用户遇到的问题。用户并不想系统拥有多么精细的控制。他们并不需要它看起来多少好看，或者使用了最新的技术，亦或者提供了与一些标准保持一致的容易理解的文档或者其它什么的。用户想要的结果就描述在用户需求里边。用户想要的结果就是开发人员的目标。他们驱动着开发，并且他们是系统的主要测试人员。如果系统传递了[用户]想要的结果那么它就是可接受的。 2、满足需要，并且关注什么是你的用户需要的。用户也是人，一定会随着时间的流逝改变他们的观点。他们的工作环境也在发生着不断的变化。如果你的系统确实是成功的话，也一定会改变他们的工作方式，因而进一步地，也会改变他们的需要。保持对新需求的探索。这样做可能会为你的产品带来新的商机。 3、在展示结果前就去证明成功，而不是等到项目结束时。从第一天开始就证明你与你的客户的想法和需要保持一致。在早期的时候，做一些presentation 和原型来展示进展，同时检验你的理解。把你的project分成一些小而成功的步骤。那样的话，就不会有大的和令人不快的惊人之事。

4、交付给用户他们想要的东西。如果合同是错误的，与你的客户一起采取措施对更改达成一致。确保系统不管做什么，都与你的用户真正想要的保持可交付性的一致。如果你帮助你的客户得到了他们想要的东西，他们会在额外的时间和资源上尽他们所能帮你。记住需求是为了什么：写需求绝对不是一个目标。它也不是为了确保检验和平衡，或者为了满足一个标准而进行的额外的工作或附加的活动。在开发任何系统的时候都有一个实实在在的目标：它们对于以下内容都是必要的： * 展示用户想从系统中得到的结果。 * 展示到源码的追溯性，和更改历史。 * 展示组织需要什么。 * 展示系统必须做什么。 * 为设计和最优化设计形成一个基础。 * 能够使变更管理的方法富有逻辑。 * 把工作分区并分给承包人。 * 作为测试和交付的基础。 * 在开发的过程中测试系统或其中的任何一部分。 * 对于所有的参与者以非技术的形式交流关于系统的基本。需求是一个“人的问题”[论点] 需求是用户和开发人员之间最主要的沟通方式。在一个大型project中，它们也许是用户能告诉开发者他们想要什么的唯一方式。在一个需求文档的背后有一个合同的强制约束力，但是它表达出来的需要来自人。写需求的人有一个困难的工作。他们必须理解需求，并能把它们组织成连贯的结构。他们必须能理解解决方案[solutions]，但是并不把它们强加给设计人员。也许所有这些之中最难是他们还必须是一个好的writer。他们必须产出一份清晰的、简短的、准确的并且无歧义的，同时还必须可读性强并且完整的文档。总之，为了创建一份更好的需求： * 找出什么是用户想要的。 * 帮助把他们的需要组织成一份清晰的文档结构。 * 用巧妙的分过类的需求填充结构。 * 同用户一起检验它。

* 对它进行正式的评审。 * 确保解决方案在演化的过程中与需求保持一致。

3. 一个需求的定义与结构一个需求必须是一个完整的句子一个单独的，独立的[原子的]需求必须是一个句子。单独的词，短语，缩写组合不能构成一个需求。要想一个需求容易理解[首要的标准]，它必须是一个完整并且正确的句子。一个这样的需求的例子如下： Thereadershallbeabletounderstandtherequirement. 这个需求有一个主语[the reader]和一个谓语[understand the equirement]。短语[shall be able to]把这两者连接在一起形成了一个完整的需求。每个原子性的需求都必须以这种形式写，否则的话它就不能很好地为用户或读者服务。一个主语的用户在于它在讨论中暗示了一个用户，拥有者，系统，或者与需求相关的设计实体。谓语应该是一个动词短语，或者是一些为主语做的，被主语处理的，与主语一起做的，对主语施加的事情的表达。 shall,will和must 适当地使用动词"to be"加固了主语和谓语之间的链接。然而在需求语言中， shall有一个非常有意义的含义。它传达了一个信息：这句话是一个需求，并且必须被遵守。其它的shall词包括"will"和"must"表示在需求周围的一个强制性的条件。例如： Thereadermustcomplywiththisdocumentationconvention. 这个表达与“对用户来说这个需求什么情况下是可接受的”相关。弱强制性的词汇通常用在非强制性或可选的需求中。例如： Thedocumentshouldtakenolongerthanonehourtoread. 当然，如果文档在一小时内是不易读完的，系统也许依然是可接受的。标准仅仅是"需要的"或者"可选的"，因此使用should，may或者像"it is desired that"。剖析一个好需求在一定程度上，每个需求都能被分析，并且分解以执行基本的控制。每一个用户需求应该有： * 一种从需求中获益的用户类型 * 一个对于用户来说要达到的已定义的，想要的状态

* 一个负责实现需求的人 * 一个允许对这个需求写测试的机制需求： Theorderentryclerkshallbeabletocompletetencustomerordersinless thananhour. 能被分解成组成部分。“orderentry clerk”是用户类型。这个用户达到的状态是完成10个顾客订单。该需求是清晰可测的，并且甚至还显示了一些性能上的标准[completetencustomerordersinlessthananhour]。挑战是在每个需求中找出用户类型，结束效果[state]和成功时的测量。

4. 一个好需求的标准好的需求应该都遵循一系列相同的标准，不管写的是哪个领域或者类型。对着下面这个列表检查一下每一个需求是否是有效的。你将很快会发现以后每当你看到一个需求的时候你都会自动地这么做。对于每个需求问以下问题： * 它对吗？[问一些可能的东西，可操作性，合法性] * 它完整吗？[一个完整的句子，就像上面讨论过的那样] * 它清晰吗？[无歧义，无误解] * 它一致吗？[不与其它需求产生冲突] * 它可验证吗？[我们能决定系统满足需求吗？] * 它可追踪吗？[唯一的标识并且能被追踪] * 它可行吗？[在一定的成本和时间内能完成吗？] 其它要达到的标准： * 需求能被模块化并且并独立化吗？[不复杂，不使用一些and/or参考和一些外部参考分段编排需求] * 它是否有一个合理的优先级？ * 它真的是一个用户或系统需求吗？[不是一个设计约束] * 能看到它的来源吗？作为一个系列检查需求接下来，把这一系列需求作为一个整体。你需要确定所有的需求是真实的，完整的，一致的，简明的。相比单个的需求，对于这一系列需求有更苛刻的问题。确保它们被充分地表述的唯一方法是：对你和用户，在你脑中对于问题是什么有一个清晰的图片，对于用户需求结构来说，它准确地反映了这个图片。然后在你检查需求的时候你可以发现它们实际上是完整的。一致和真实性的问题能使你想到每一个需求意味着什么，同时这个需求在真实世界中能否实现，已知其它所有的需求的基础上。正如我们所见，好的文档结构是非常重要的。书写好的需求的方针下面给出的是一些在写任何需求的时候的简单的遵循方针。为了保持连贯，我们使用一个飞行器的例子。 1. 一次定义一个需求 Thepilotshallbeabletocontroltheaircraft'sangleofclimbwithonehand.

资料库

ibm_doors_get_it_right_the_first_time_中文版.docx

相关推荐

课程资源

热门标签

最新资料