03实例化需求阅读笔记之三

这本书给出了做到实例化需求的关键过程模式: 从目标中获取范围——协作定制需求说明——举例说明——提炼需求说明——不需要修改需求说明的自动化验证——频繁验证——演化出一个文档系统。

从目标中获取范围:交付团队不应该指望用户直接给出范围或者解决方案,因为客户大部分时候并不具备提供良好需求的专业能力,且团队拥有的项目知识可能也被浪费了。因此需要帮助用户找出真正的目标,并通过协作共同界定项目范围。 分工是这样:用户提供需要的

功能以及开发软件的目的,团队根据用户给出的信息提出解决方案。

协作制定需求说明:成功的团队不会依赖于某个人独自去收集正确的需求,而是会与商业用户一起制定解决方案。不同背景的人拥有不同的想法,他们会凭借自己的经验解决问题。能够让每个人更大程度的参与到交付活动中去。

举例说明:自然语言会有歧义,会有上下文相关内容,有些内容则需要有专业知识做背景才能懂,会造成客户与团队、团队内部理解不一致,因此需要某种编程语言来描述需求。 对于成功的团队,不会一上来实现全部需求,而是先确定出那些描述预期功能的关键实例。如

果关键实例容易理解和沟通,就可以被有效用作清晰和详细的需求。成功的团队不会一开始就将所有需求精确的用某种编程语言表达出来,他们会举例来描述需求。

提炼需求说明:提炼从集体收集到的信息,滤去杂质。为开发和测试创建一个具体的、精确的上下文。以适量的细节来定义目标,以便实现和验收。可以当做交付的验收条件。只有当所有实例在系统中都可以正常工作时,开发才算完成了。

频繁验证: 通过频繁检查所有可执行的需求说明,团队能够快速的发现系统和需求说明之间的任何差别。由于可执行的需求说明容易理解,团队可以与商业用户讨论这些改动,并决定如何处理。他们可以不断的同步系统和可执行的需求说明。

原文地址:https://www.cnblogs.com/qq1499632156/p/8303558.html

时间: 2024-11-25 01:15:23

03实例化需求阅读笔记之三的相关文章

你的灯还亮着吗?阅读笔记之三

06你的灯还亮着吗?阅读笔记之三 问题最难以处理的部分恰恰是去意识到它们的存在. 如果在你对问题的理解中,你想不出至少 3 样可能出错的东西,那么你并没有真正的理解这个问题. 每种解决方法都会带来新的问题,我们永远都不能消灭问题.问题.解决方法以及新的问题交织成一条无穷无尽的锁链.我们能期望的最好结果就是新的问题没有我们“解决了”的那个那么棘手.我们使问题变得不那么棘手,其实只是把问题放在“别人家的后院儿里”.这种技巧叫做转嫁问题.新的问题常常是在无意识的情况下产生的. 当我们把我们的设计或定义

03软件构架实践阅读笔记之三

在上一次的阅读笔记当中,提到了很多关于软件构架的东西,例如:软件构架的周期性等,但是大部分的都是系统的说明,现在,下面看的都是详细的介绍. 在刚开始是构架的产生:在刚开始的第一句话就说:"构架也是若干商业和技术决策的结果",从这句话就可以看出构架对于软件技术的重要性,而正如我们所知道的不管什么事情都会受很多因素的干扰,同样的,架构会受系统涉众的影响,在上一学期,老师就提到了什么是涉众.但是每一种的涉众对于软件的要求就会不相同例如 客户涉众:要求成本低.及时交互.不要改动的太平凡等等:

程序员从小工到专家阅读笔记之三

还没有把<程序员修炼之道:从小工到专家>这本书读完,把第四章的阅读笔记写一下. 本章由五节组成,分别是按合约设计.死程序不说谎.断言式编程.何时使用异常和怎样配平资源. 完美的软件不存在,目前也没有人写出完美的软件.与人打交道是最困难的,与人打交道的方法也可以应用于编程,确保坦率的最佳方案之一就是合约,按合约进行设计,客户和供应者按就责任与权力达成共识,双方履行义务,每个人都从中受益. 死程序不说谎主要讲了程序能按预期的运行,于是我们很容易掉进“某事不可能发生”的心理.但是存在很大的风险,不要

《软件需求》阅读笔记之三

这几天读的书,主要是讲解的如何降低风险 可以利用软件原型这种技术减少客户对产品不满意的风险.一个软件原型是所提出的新产品的部分实现.使用原型有三个主要目的: ? 明确并完善需求   原型作为一种需求工具,它初步实现所理解的系统的一部分.用户对原型的评价可以指出需求中的许多问题,在你开发真正产品之前,可以最低的费用来解决这些问题. ? 探索设计选择方案   原型作为一种设计工具,用它可以探索不同的用户界面技术,使系统达到最佳的可用性,并且可以评价可能的技术方案. ? 发展为最终的产品原型   作为

03重构_改善既有代码的设计阅读笔记之三

这本书的主要特点为: 重构技术就是以微小的步伐修改程序,如果你犯下错误,很容易便可发现它. 任何一个傻瓜都能写出计算机可以理解的代码.唯有写出人类容易理解的代码,才是优秀的程序员. 重构(名词):对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本. 重构(名词):使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构. 事不过三,三则重构. 不要过早发布接口.请修改你的代码所有权政策,使重构更顺畅. 当你感觉需要撰写注释时,请先尝试重构,试着让

梦断代码阅读笔记之三

今天我看到了本书的第九章,本章主要讲了关于软件开发的方法论.同时作者为我们介绍了软件缺陷编年史上数量不多但是足以警示世人的惊人灾难. 1962年6月,水手一号探测飞船在发射5分钟后偏离轨道,为避免坠入居民区,飞行控制人员只好将其引爆.问题在哪?导航控制程序中少了一个连字符.1996年6月欧洲航天局投入5亿美元建造的阿丽亚娜5号无人运载火箭发射后40分钟爆炸,原因是在控制其导航系统的程序中有一个缺陷.(代码要将64位变量转换为16位变量,但是数字太大,出现缓存溢出,系统停滞了.)从1985年到19

你的灯亮着吗阅读笔记之三

我们可以告诫那些写注释的人,对于问题表述来说清晰好懂是多么的重要,直到他们被这废话的海洋淹死.我们也可以敦促问题解决者们阅读的时候更加仔细,然后他们都会变成瞎子.按照以往的经验,这些都没什么用.不管人们多么真诚地去努力,单靠增加投入精力的数量是不够的.你永远都不能确信这里的每个人对于同一个词都和你有相同的理解. 现在我们需要通过一次联谊活动把文字的含义从字面上剥离下来,并且牢记在心中.有一种方法就是文字游戏:一旦你用文字来表述一个问题, 请仔细推敲这些文字以使这种表述在每个人的头脑中都是一个意思

《需求分析与系统设计》阅读笔记之三

第七章主要讲的是图形用户界面设计,这一部分在<人机交互>这门课中也讲到过,其中图形用户界面设计的原则是比较清楚的,所以这一章看起来比较简单.GUI的设计在其他几本书中是没有提到的.而且这一部分跟<人机交互>中讲到的又不一样.这一章介绍了UML的配置文件(剖面)——UX故事情节.图形用户界面的设计要从用户的角度出发. 第八章介绍了数据库的重要性.数据库在软件开发中起到至关重要的作用.数据库模型由3个层次:外部模型.逻辑模型和物理模型.本章重点讨论了逻辑模型.对象到数据库的映射其实就是

程序员修炼之道阅读笔记之三

对于我们这些人来说知道客户的需求是十分重要的,在书中,了解到达到客户的期望,才是软件真正的成功.这一点,其实又涉及到“万恶的”需求.刚刚完成的工程,直接被客户否定.其实这一切,如果能从一开始就得到客户的期望,就不会如此的糟糕.而事实却是客户的期望,客户的需求却并非可以得到.虽说这不是好的软件工程的典型,但是至少,我们现在知道了什么是客户期望的. 无处不在的自动化 : 程序的目的之一就是让原本繁琐复杂的重复劳动自动化的处理,而软件开发过程中也一样需要自动化.我一直坚信别人说过的一句话:凡是有人参与