《软件需求模式》阅读笔记03

在对需求模式的概念和内容方面有了深刻的了解之后,我将学习各类不同的需求模式。

基础需求模式是所有种类的系统都可能需要的一些东西,它包括了:技术、遵从标准、参考需求、文档、系统间接口、系统间交互。系统间需求模式是用来定义被定义的系统和任何与之交互的外部系统或组件之间的接口的基本细节,它包含了以下内容:接口名称、接口标识符、两端的系统、接口的目的、接口的所有者、定义接口的标准、用于接口的技术。在开发测试的时候,我们应该明确交互需求,找到隐含的交互以帮助满足间接陈述的目标。系统间交互需求模式是用来定义穿越系统间接口的特定类型的交互,它包含的内容是:交互类型名称、接口名称和标识符、交互目的、传递的信息。技术需求模式是用来定义开发和运行系统所必须要(或必须不要)的技术,或者系统必须能够与之交互,或者是与之兼容。它应该包括:技术描述、技术的用法、技术的版本、动机。在开发测试的时候,我们应该明确系统的技术与需求是否一致和系统必须兼容的技术。遵从标准需求模式是用来定义系统必须遵从一个特定的标准,它的内容包括:标准的名称、标准的目的、遵从的标准的版本、遵从的标准的某些部分、位置。按照不同的处理方式,遵从标准分为以下几个种类:(1)特定行业的法律、条例和实践准则(2)管辖区域内的所有公司必须遵守的法律(3)公司标准(4)技术标准。参考需求需求模式是用来定义对外部需求规格中一些或全部需求的要求,使这些需求就像本规格里的需求一样,它包括以下信息:被参考的规格的名称、被参考的规格的版本、适用的需求、被参考的规格的位置、优先级信息。文档需求模式是用来定义需求产生的特殊类型的文档,它的内容包括:文档的名称和类型、文档将包含的信息的描述、使用的媒介或格式、这种文档必须遵守的标准的名称、文档编写使用的语言。

信息需求模式是用来描述系统所需的信息的各个方面,定义数据的需求以及如何处理它在系统的定义中扮演至关重要的角色,而这些模式可以帮助得到正确的需求,它包括了:数据类型、标识符、数据结构、计算公式、数据归档、数据寿命。数据类型需求模式是用来定义为了一个特别的业务目标,一个特别的原子信息条目如何被表示或展示,它包含的内容是:数据类型名称、目的、形式、显示格式、约束、特殊处理。数据结构需求模式是用来定义混合数据项,它可以在多个地方出现,或者信息太多不适合定义在一个需求中,它的内容包括:名称、信息项列表(a.以前定义的数据类型b.数据类型的描述c.另外的数据结构d.项目列表)。标识符需求模式定义为一些类型的实体分配唯一标识符的方式或者指定一个数据项作为唯一标识符,它的内容有:所属的实体名称、标识符名称、标识符形式、唯一性范围、如何分配、显示格式、排序顺序、重要的条件。在自由选择一个特定类型标识符的最合适的形式的时候我们需要斟酌的关键因素是:(1)唯一(2)有意义(3)简洁(4)易记忆(5)简单(6)难分配(7)与其他标识符的联系(8)灵活。计算公式需求模式是用来定义如何计算一种特殊的值,或者如何通过一定的逻辑步骤决定一个值,它应该包含以下信息:数值描述、公式本身、所有使用的变量的解释、计算精度、适用性限制、参考、一个例子。数据寿命需求模式是用来定义一个特定类型的信息必须被保留多长时间,或者必须多长时间内保持一定程度的方便性,它包括下列内容:相关的数据、存储的方式、保留数据的时间长度、开始触发的时间、截止时间的动作。数据归档需求模式是用来定义从一个永久存储设备移动或者复制数据到另外一个设备,它包含以下内容:数据描述、移动或拷贝、数据源、目的地、频率、发起者、目的、归档格式。归档通常用于下列目的:(1)历史性(2)性能(3)不干扰(4)安全(5)存在的证据(6)许可的到期。

时间: 2024-08-27 16:56:29

《软件需求模式》阅读笔记03的相关文章

掌握需求过程阅读笔记01

掌握需求过程 第一章什么是需求 阅读笔记 我们为什么要进行需求呢? 这样是为了使效率更高,并且减少错误步骤所不必付出的代价. 在我们构造产品之前就要知道客户的需求是什么,大多数的组织都是通过系统分析来进行的,但是需求过程与系统分析并不是一回事,虽然他们之间有联系,但并不完全相同.除了系统分析以外,需求也是很有必要的.他可以对你的分析师生涯有更进一步的促进.当我们接触到一个新的产品时,业务事件和使用情况逐渐清晰了起来,系统分析可以对产品进行更清楚的建模,并为需求过程提供有价值的反馈.对需求的了解增

《敏捷软件需求》阅读笔记03

今天我阅读了<敏捷软件需求>的第三章<团队的敏捷需求>.在敏捷方式中,对需求工作的组织和对团队本身的组织不是彼此独立的.相反,敏捷团队是围绕需求进行组织的,以便优化代码的定义.构建与测试以及向终端用户交付价值的效率.敏捷团队的基本工作单位是用户故事,团队的目标是在迭代时间盒内,定义.构建和测试一定数量的用户故事,在迈向发布的过程中逐渐实现更大的价值.  对每个故事的实现可以采用相同的模式:定义故事.编写代码和测试用例.针对代码运行测试. 在每支敏捷项目团队中有三种角色:产品负责人.

掌握需求过程阅读笔记—2

通过对事件驱动的用况.网罗需求.功能性需求这三个章节的阅读.使我们明白了在事件的驱动用况上,我们需要通过一些经验法则来定义用况,发现合适的用况:在网罗需求上,我们最需要做的就是进我们的一切可能去罗列用户的需求,并能及时的与用户沟通交流,确保产品符合最新的要求:在功能性需求方面上我们应当明白它是因为产品的存在的根本原因而存在的需求,它描述的是产品的动作,并能够形成一份完整的尽量避免二异性的功能描述. 事件驱动的用况是业务实践相应(活动和数据)的一部分,这些事件响应有产品来执行.用况成为了需求的锚,

《掌握需求过程》阅读笔记03

我们都知道要站在用户的角度考虑问题,可是作为用户的我们也是存在思考的缺口的,那些根深蒂固的东西会使我们忘记了它们的存在,这就是未意识到的需求.还有未梦想过的需求,我们习惯了类似软件拥有的功能,未曾想过一些新的功能,在我们看来,技术还没有成熟.作为软件工程师,我们一定要在初期让这种需求浮现出来,否则后续阶段发现会付出太多代价. 开始阶段我们会画上下文范围图,输入输出流表示数据的流向,如果画图过程中有不知去向何处的数据流,那正是我们需要向用户询问的地方.需求调研是主动的,用户在工作的时候才能精确描述

《探索需求》阅读笔记二

在任何相当规模的开发项目当中,孤军奋战显然是像是一种幻想,为了获得一个团队所能提供的容量和差异性,我们必须放弃任何个人英雄主义的幻想,为和他人合作付出代价.而这种人际的花费在会议中体现的最为明显,会议也是一种工具,一种社交工具.很多人都会感觉会议是很可怕的,它有的时候并不会产生什么效果,但是我们离不开它,一旦离开会议,就只能开发出最简单的产品.每一个会议能达到的结果是度量需求工作的健康状态,一个糟糕的会议,说明了需求过程的不完善.要想每一个参与者都完全的参与进会议中,这个会议就必须是稳定的,我们

《探索需求》阅读笔记一

这本书主要讲述关于开发项目的问题,讨论的主题是问题陈述或需求集合,需求在很多方面都是非常重要的.我们通常使用的是需求映射图而不是需求本身,所以我们需要探索许需求. 一旦在探索需求过程中使用了忽略了人的因素的工具,就不可能完美的描述需求,这会造成含混性,同时当需求被明确说明,但是使用了含混的词语也导致含混性问题的出现.含混性需要成本而且对于我们解决问题产生巨大影响,即可以发现需求含混性的重要性,所以在探索需求过程中要及时尽早地消除含混性,使用一些可以很好的抑制含混性的探索需求工具.许多含混性不一定

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

这次阅读的是这本书的第二部分,这部分内容相对较多,所以还没有看完.这部分介绍了一些文档的主要内容.首先是项目视图和范围文档的模板,书中一一介绍了这个文档中应该包括的内容.主要就是业务需求,项目视图的解决方案,范围和局限性,业务环境,产品成功的因素.所以,我们在做项目的时候,无论如何都要注意这个项目的范围,所想到的不要超出范围.有时候你感觉好的功能用户可能并不需要.所以,明白项目范围,并在范围内进行工作相当重要.我们所用到的需求基本全部来自于用户,获取用户需求的方式也相对较多,在获取某用户群体的需

构建之阅读笔记03

1.我认为在团队合作的过程中,编写程序之前,应该要首先规范命名,通过第四.五章我知道了,作为一个软件工程师不仅要有出色编程能力还要有对代码注释的意识,因为在团队工作中,你如果不注释你写的代码,那么当你有事,别人接手你的代码时,就会遇到很大的问题,他需要一点一点读懂你的代码,这会对团队的进程造成影响.我们还要在编写程序前先要对代码的命名和缩进等问题进行同一的规定,这样会使得团队的进程得到很快的发展. 2.在团队合作中,刚开始也许我们并不知道应该怎样进行合作,通常我们都是自己编程,没有和其他人合作的

《构建之法》阅读笔记03

我一直认为软件工程就是用很好的方法设计出很好的软件.那么这个过程从头到尾都要好好研究,然而刚开始的阶段并不是软件开发的开端,而是对用户的需求分析,是想,如果我们都没有把用户内心里真正想要的东西搞清楚,怎么能够开发出来令用户满意的软件呢? 软件的需求共有三类: 获取和引导需求:软件团队要找到软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求. 分析和定义需求:对各个方面的需求进行规整,定义需求的内涵,从各个角度将需求量化. 验证需求:软件团队用各种形式向用户验证软件团队对需求