软件需求模式阅读笔记四

首先,数据实体需求模式。被分为数据类型、标识符、数据结构、计算公式、数据归档、数据寿命六种需求模式。

模式名称-> 活实体 交易 配置 编年史 信息储存基础构架
相关模式(与之有联系的模式) 数据类型,数据结构,配置 数据结构,数据类型 数据类型、数据结构、活实体 交易  
预期频率(预期使用频率) 所有需求的50% 通常少于十个 总需求的10% 在一到二十个之间  
适用性 建立一种实体,信息需要保存,而且有寿命 定义一个活实体中的一种事件或者输入一个交易的功能  定义参数值,控制系统如何运行 系统生命中必须被记录的某种或者某几种事件  
内容(模式包含哪些名词,还有基本概念) 实体名称、实体的解释、实体被唯一确定的方式、父实体的详细内容 交易名称、交易的解释、交易包含的信息、一个交易如何被唯一确定、所有实体详细信息、什么时候交易被认为是发生了、交易的寿命 配置值、配置实体、名称还有目的、代表值、数据类型、级别、配置值什么时候可以修改 记录事件的类型、每件事情记录的信息、严重程度  
开发考虑
对于额外需求部分讨论的主题,即使没有定义普遍性需求,但是也值得考虑

 在交易发生之后就永远修改不了它
考虑系统在运行时修改配置值的影响

性能的考量,考虑每种事件的可能的数量   
测试考虑 对每一个活的实体检查添加修改删除还有查询功能  注意一个交易被认定发生的时间的陈述。  基本上和实体一样,但是要检查更改实体之后的效果 尽可能多的记录系统的活动  
时间: 2024-08-03 11:12:26

软件需求模式阅读笔记四的相关文章

软件需求模式阅读笔记之五

这周我学习的是软件需求模式的第二章------需求规格的内容. 目前为止还没有唯一正确的方法阻止需求规格,但是反复出现在大部分系统中的主题,是我们应该注意和掌握的内容.从大的方面来说,需求规格可以分为四个部分,分别是介绍部分,上下文部分,功能域部分,主要非功能要求部分四个方面,其中功能域部分定义了系统实际上要做的内容. 介绍部分包括系统目的,文档目的,需求格式,词汇表,参考书目以及文档历史.这个板块主要是介绍系统规格.这其中要注意,系统目的是系统本身的目的,而不是项目的目的,是落脚于功能的:文档

软件需求模式阅读笔记04

今天开始阅读<软件需求模式>的第7.8章,其中第7章主要讲的是数据实体需求模式,主要是数据处理的一些需求模式,而第8章讲的是用户功能需求模式,主要是介绍了如何应对用户的一些需求. 第7章数据实体需求模式,系统的开发者常常是以轻视,随意的态度对待信息,没有规则定义什么时候数据可以被删除,对丢失数据很松懈--而本章就是通过引入一种方案把所有的实体分为几个固定种类,增加秩序性和一致性. 活实体需求模式,它用来定义一种实体,它的信息需要保存,并且具有预期寿命.但是不能将它应用于系统配置的实体:而应该使

软件需求模式阅读笔记02

今天我开始阅读<软件需求模式>这本书的第3,4章,以下是从这本书中获得的一些知识. 其中第3章描述了需求模式扮演的角色,解释了每个模式的一些具体内容和具体结构.而第4章则介绍了何时以及如何去使用需求模式,如何从原有的模式创造出新的模式或者直接编写新的模式. 第3章首先为我们解释了需求模式的概念:定义一种特定类型需求的方法.需求模式就是为我们提供一种需求定义的方法,我们省去自己去从头定义需求的时间.我们使用需求模式可以1.合理利用它的指导,2.节省开发时间3.可以促进同类型需求的一致性. 而需求

软件需求模式阅读笔记01

在本学期的学习课程中,我们也学习软件需求分析的相关课程.为了更好地学习该科目,同时也为了拓展自己的知识层面,特意挑选了<软件需求模式>来进行阅读. 在本周的课余时间,我也对<软件需求模式>进行了简单的阅读.对软件需求的相关知识有了更进一步的了解. 需求无处不在,在我们的日常生活当中,我们也会有各种各样的生活需求.而需求放到了软件行业,就成了软件需求.在我们大学生活当中,由于缺少对软件行业的了解,缺少对于软件工程的了解,我们对于软件需求也只能停留在纸面的阶段,只有当我们真正步入软件行

软件需求模式阅读笔记之一

不知不觉就进入了大三的学习,王老师的课还是老样子,要选择一本书进行精读,来支撑和辅助这学期的学习.这次我选择的书是由Stephen Withall编著,曹新宇翻译的<软件需求模式> .这本书包括准备开始和需求模式目录两个部分,主要目的是帮助决定和定义新的软件系统需要什么,建议添加哪些额外的特性,使系统更好或者更卓越. 大致浏览了一下这本书的目录,前四章写的是准备开始,所有这些内容都是为需求模式在打基础.后面的八章则是详细描述了基础需求模式,信息需求模式等八种需求模式. 这周我学习的是第一章--

需求工程-软件需求模式读书笔记1

今天读完这本书<软件需求模式>的第一部分,也就是准备阶段. 需求分析是困难的.需求分析师又往往缺少经验和训练.本书的目的是帮助和决定新的软件应该走什么,建议添加那些额外的特性,使系统更好或更卓越.需求模式是经验的结晶,本书主要建好了37个模式,解决了所有系统中反腐出现的特定问题.适合业务分析师.软件架构师和工程师.软件开发人员.软件测试人员.项目经理等人员阅读.. 软件系统的需求定义他要定义的问题:它的的意图和目的.为了更好地构造系统需要一系列的改进.该书主要可分为两部分:第一部分:解释开始,

软件需求模式 读书笔记三

通过这一个月的阅读,我终于读完了<软件需求模模式>这本书,前两个读书笔记已经把这本书的几种模式介绍了,之前有基础需求模式,信息需求模式,数据实体需求模式,用户功能需求模式.这次介绍的是性能需求模式,适应性需求模式,访问控制需求模式和商业需求模式. 性能需求模式包括五种的性能的需求模式:影响时间(系统需要多少时间完成一个请求).动态容量(系统能够同时处理多少件事).吞吐量(系统处理时间的速率).静态容量(系统可以保存多少某种类型烦的实体)和可用性(什么时候系统对用户是可用的,以及多么可靠). 当

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

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

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

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