《软件需求模式》第3、4章阅读笔记
其中第3章描述了需求模式扮演的角色,解释了每个模式的一些具体内容和具体结构。而第4章则介绍了何时以及如何去使用需求模式,如何从原有的模式创造出新的模式或者直接编写新的模式。
第3章首先为我们解释了需求模式的概念:定义一种特定类型需求的方法。需求模式就是为我们提供一种需求定义的方法,我们省去自己去从头定义需求的时间。我们使用需求模式可以1.合理利用它的指导,2.节省开发时间3.可以促进同类型需求的一致性。
而需求模式也是包含一定要素的:
1基本细节:包括模式声明,就是声明一些模式版本号,模式上次修改日期,需求方法等信息;所属领域,就是描述这个需求模式隶属于哪一个领域;相关模式,就是描述和其他相关模式之间的一些关系;预期频率:描述需求规格中这个模式可能需要用到多少次;模式分类,他就是列出模式覆盖的主要需求类型的分类;模式作者。
2适用性:描述需求模式的适用情况,它的语言必须是明确的,并且能够清楚的描述模式的适用环境。
3讨论:这部分主要考虑的如何编写这种需求,以及编写这种需求时需要注意的一些事情。
4内容:要求以条目的形式列出这种类型的需求必须传达那些信息
5模板:需求模板的目的是可以复制它作为需求描述的出发点。
6实例:每个模式必须包含至少一个或多个实例,用来演示在实践中如何使用模式
7额外需求:需求只说了必须要说的是不够的。还需要“额外需求”来描述那些需要额外考虑,以及在什么情况下需要考虑。其中额外需求有两种:跟随性需求,就是扩展原有需求,在原来的后面,定义一些附加的事情。普遍性需求,普遍性需求是适用这种类型的所有需求,并且针对整个系统只定义一次。
8开发考虑:这主要是帮助设计和实现软件的开发人员慢走这类型的需求,他提供了提示和建议,指出了开发人员不要忘记的一些事情。
9测试考虑:它主要是为了用户验收测试而编写,需要注意传达以下信息:评审这类需求需要注意的地方;总体上指导如何测试这种类型的需求;提醒一些需要注意的地方以及如何处理。
另外我们还要注意领域的概念。就是我们的需求模式不是整块的展现出来,我们需要给每一个需求模式分配一个领域,让领域内的所有模式共享它。而为了把需求描述的更清楚,我们则需要用到基础架构,它的角色是指导和建议如何定义一个特定系统的基础架构的需求。
当然当几个需求模式具有共同的特性时,可以建立一个需求模式组,描述他们共同的方面,而不必在每个模式中重复。
需求模式之间的关系主要有两种,引用:一个需求模式可以在定义中提到另一个模式。主要是这个需求可能包含有另一个需求的相关信息。扩展:一个需求可以以另一个需求为依据进行开发。
我们还要学会对需求进行分类,提炼需求,转移需求模式,分心需求模式用例等
第4章就是叫我们如何使用和编写需求模式
那么我们何时需要使用需求模式呢?1当定义需求时,看是否存在需求模式可以指导定义需求。2当考虑需求是否完全时,观察主题覆盖的整套模式,看看是否有遗漏或添加什么东西。3当评审需求规格时,模式可以帮助检查需求的质量,确定还有那些主题没有定义、理解特定需求的意义和内涵。4当评估系统的规模及工作量时,基于需求,使用模式可以对实现的复杂性有更准确的感觉。5当实现需求的时候,模式可以使你更深刻的理解需求的意图,其中“开发考虑”就是为开发人员设计,帮助开发人员更好的编程6当测试需求的时候,模式中的“测试考虑”就是为软件测试人员而写,帮助测试人员做测试。使用需求模式有以下好处:需求更容易阅读、需求更容易与同类型其他需求做比较、可以判断是否有遗漏、编写需求更容易、读者可以参考编写的模式获得更多的信息、编写需求规格时可以参考模式。但是还要注意一些问题:可能被诱导疏于思考、可能滥用模式、很多需求可能措辞相似。
接下来为我们讲的是裁剪需求模式,因为需求的措辞很大程度上取决于个人的偏好,因此没有过多的限制,而且以客户的语言编程编写需求规格是并且永远是最重要的。由于种种原因,需求模板中使用的语言应该与使用模式的需求规格中一致。由于这些原因,我们有必要对需求模式进行裁剪。需要注意的是,模式的基础是一样的:裁剪只是对使用模式产生的需求做一些调整,然后每一次裁剪一个需求模式时要建立一个新的需求模式声明。
编写新的需求模式:在工作中发现一些类型的需求总是反复出现,以一致的方式编写会受益,或者只是有时候定义的很糟糕,那就别再犹豫,不要畏惧为他们编写一个需求模式。
如何发现潜在的需求模式,系统化:研究每一个目标需求并尽量对其分类:是什么类型的需求?如果有模式可以适用,记录下来然后继续。如果现有的模式不是很合适,研究需求看是否可以设计一个新的,更专用的模式。机会化:当定义一个需求时,你可能意识到会有同样类型的需求出现,如果觉得编写这种需求很棘手,也许就值得编写一个模式帮助其他人解决类似的问题——并促进一致性。
如何编写需求模式:1是否足够的价值?在开始编写模式之前,一定要考虑努力是否有回报;2建立模式的骨架,骨架包括所有要求的标题和“基本细节”部分条目;3编写模式的“适用性”部分,描述模式是为了什么,必须尽可能精确。4收集需求实例,构造所有能找到的实例列表。 5检查需求实例,决定他们的共同之处,以及如何变化。 6描述需求可能包含的信息。提炼实例的内容组成一套独特的片段,给每一项信息一个简洁的描述性名称。7编写需求模板 ;8编写剩下的“讨论”和“内容”部分;9开发潜在的额外需求实例的列表;10确定额外需求的候选主题 ;11编写“额外需求”部分;12编写“开发考虑”部分;13编写“测试考虑”部分;14是否值得;15评审模式。
标签:需求,定义,模式,实例,笔记,编写,软件,描述 From: https://www.cnblogs.com/qq2143187807/p/17898058.html