自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(15)
  • 资源 (3)
  • 问答 (1)
  • 收藏
  • 关注

原创 第十四章 需求工程之功能以外的需求

记录下每个质量需求的来源,如果不是很明确,还应该写下描述的每个质量目标背后的理论依据。某个明确的目标是否有必要或者说实现成本是否合理类似的问题出现时,质量目标的理论依据会很重要。

2024-01-05 09:57:09 937 1

原创 第十三章 需求工程之对数据关系进行建模

在设计阶段创建ERD时,其实也是在定义系统数据库的逻辑结构或物理(实现)结构。从分析阶段开始完成的视图能够扩展或者完善对系统的理解和优化系统实现。

2024-01-04 17:30:48 964 1

原创 第十二章 需求工程之一图胜千言

在0层数据流图中,以相互独立的圆圈来表示的每一个处理都可以进一步扩展称为一个独立的数据流图,经过扩展的视图可以展示更多的工功能细节。在各个流程(加工)之间的数据、数据存储里面的数据以及外部实体也应该在实体-关系图(DRD)中进行建模,还要在数据字典中描述。作为单一的模型技术来使用,数据流图的功能还不够强大,更好的方式是使用用例图或者泳道图中的流程步骤来表示数据加工机制的细节。数据流图用于标识一个系统中的加工处理、系统所操作的数据集合(存储)或者物理介质以及在处理、存储和系统外部之间的数据流。

2024-01-03 09:17:40 539 1

原创 第十一章 需求工程之写出优秀的需求

下面列出在理想状况下每一个业务需求、用户需求、功能性需求和非功能性需求应该具备的特点。

2024-01-02 09:21:49 1270

原创 第十章 需求工程之记录需求

假设就是在没有确凿的证据或明确知识的情况下假定为真的说明,如果假设是错误的、过时的、不能共享或发生了变化,问题就会随之而来,因此某些假设会给项目带来风险。列出系统必须与之共存的其他软件组件或应用程序,如果还要做一些额外的技术基础设施工作以便于开发中的新系统相结合,就要考虑创建一个单独的基础设施需求规范说明来细化工作。质量需求必须是确定的、定量的并可验证的。如果有设计,就要描述数据是如何获取和保存的,例如,当开始填入库存数据时,可能首先要将所有库存数据“导入”接收系统之中,后面无须填入有变化的数据。

2023-12-31 10:00:00 1179

原创 第九章 需求工程之照章办事

业务规则每个组织的运营都要遵守很多政策、法规以及行业标准,这样的控制原则统称为业务规则或业务逻辑。业务规则通常通过人工的政策和流程来保证。需要软件应用强化这些规则大多数业务规则起源于任何特定的软件应用之外。业务规则是业务的属性,业务规则本身并不是软件需求业务规则是需求的来源,它们决定着协同必须具备哪些属性才能符合规范。业务需求描述了组织期望的产出或概要目标,支出要构建或采购一个软件。业务需求是项目实施的理由业务过程描述了将输入变为特定的输出以达成特定结果的一系列活动。信息系统通常将业务

2023-12-30 10:00:00 969 1

原创 第八章 需求工程之理解用户需求

用例探索容易诱发数据讨论,思考交互过程中哪些数据元素作为输入和输出。在项目范围级别的数据字典和数据模型中存储数据定义。

2023-12-29 08:54:37 989 1

原创 第七章 需求工程之获取需求

需求遗漏是一种常见的需求缺陷,由于遗漏的需求是不可见的,所以很难发现。引导式必须要保证参加工作坊的人能完成下列任务。

2023-12-28 08:50:54 1472 1

原创 第六章 需求工程之如何获得用户心声

- 每个产品代言人都是某个用户群与项目业务分析师之间的主要接口- 产品代言人从用户群其他成员那里收集需求并消除冲突- 需求开发活动是业务分析师与这些挑选的用户的共同责任,业务分析师负责写需求文档。- 最好的产品代言人对系统有个清晰的愿景,并对此充满热情,他们明白系统会给同事们带来诸多好处- 产品代言人应当是受同事尊敬的,并且有高效沟通能力的人。- 产品代言人他们必须对应用领域与解决方案的运行环境有全面的认识。- 当每个代言人拥有充分的授权足以替其代言的用户群做出有约束力的决策时,产品代言人这种方

2023-12-27 10:39:45 839 1

原创 第五章 需求工程之建立业务需求

业务需求是指一组信息,描述的是需要,再次需要的指导下,一个或多个项目 交付一个解决方案和符合预期的最终业务成果。业务机会、业务目标、成功标准和一个愿景声明共同构成了业务需求。业务需求业务机会业务目标成功标准愿景申明在完全制定功能和非功能需求之前,必须先解决业务问题。项目范围和限制申明在很大程度上有助于后期对提议特性和发布目标的讨论。业务需求为体验的需求变更和提供决策参考。建议在每个需求获取工作坊上重点展示业务目标、愿景和范围,以便让团队可以快速判断某个提议的需求是否在项目范围内。

2023-12-26 09:20:07 1295 1

原创 第四章 需求工程之业务分析师

首要任务是帮助业务或者出资方、产品经理或市场经理定义项目的业务需求。提供一份愿景和范围的文档模板与愿景负责人协同工作,帮助他们清晰的表达愿景。

2023-12-25 09:24:52 1003

原创 IT软件特性

特性单个或多个为用户提供价值的、有逻辑关系的系统性能,可以通过一个功能需求集合进行描述客户预想的产品特性清单与描述客户的任务相关的需求不能画等号。特性包含多种用户需求

2023-12-25 09:19:07 333

原创 第三章 需求工程之优秀实践

愿景和范围文档包含产品的业务需求愿景描述可以使所有干系人对产品的产出有一致的理解范围界定了发布或者迭代中哪些功能应该或不应该出现让用户自己说出来如何判断解决方是否满足自己的需要以及是否可用验收标准包含一系列活动根据用户需求,软件通过一系列验收测试软件能展示出它具备满足特定非功能需求的能力对尚未修复的缺陷和问题进行跟踪记录发布前准备基础设施与培训。

2023-12-22 09:15:00 1019

原创 第二章 需求工程之从客户角度审视需求

一个有意义的基线确定流程可以在以下几个方面为主要干系人带来信心。

2023-12-21 14:57:54 784

原创 第一章 需求工程之软件需求的本质

需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性,可以是一种对系统开发进程的约束。

2023-12-21 14:04:06 1168

第七章 需求工程之获取需求

需求开发的核心是需求获取,是为软件系统确 定各类干系人的需要和约束的过程 需求获取不等同于“收集需求”,也不是简单地 将用户所说的全部记录下来。 获取是一个综合性协作和分析的过程,其活动 包括收集、发现、提炼和定义需求 获取的目的是为了发现业务需求、用户需求、 功能需求和非功能需求及其他类型信息 需求获取可能是软件开发各个方面最具有挑战 性、最关键、最容易出错和最需要密集沟通 的。 让用户专心参与获取过程,能够为项目赢得支 持和认同。 试着理解用户在陈述需求时的思维过程 通过研究用户执行任务所做决策的过程,提炼 出潜在的逻辑。 业务分析师须营造一种环境,以便对正在拟定 的产品进行彻底、全面的探索。 不能强迫用户理解技术术语 不能想当然地认为所有参与方对产品定义的理 解都是一致的 客户必须明白,即对可能的功能进行讨论并不 代表必须将其纳入产品之中。 需求开发的目的是使各类项目干系人对需求达 成共识。 参与需求获取的人避免在理解问题本质之前就 开始设计系统 我们要强调用户任务而非用户界面 关注真正的用户需求而非口头诉求

2023-12-28

需求工程之倾听用户心声

1. 用户声称他们需要的[[0第一章 软件需求的本质#特性|特性]]并不等于他们使用新系统完成任务时需要的功能。 2. 业务分析师必须广泛收集用户的收入,分析和澄清这些信息,明确提出需要实现什么的功能才能帮助用户完成他们的工作 3. 业务分析师对记录新系统所需要的能力和[[0第一章 软件需求的本质#特性|特性]]并将这些信息传达给其他干系人负主要责任。 4. 这是个迭代的过程,并且很耗时。 5. 如果不花时间达成这样的共识(对在建产品的共同愿景),后果自然是返工、延期、超支以及客户的不满。

2023-12-28

根据GB/T 36687-2018标准整理的保险术语

本标准界定了商业保险业务常用的基础术语、保险产品术语、投保和承保术语、保险合同管理术语、 赔偿和给付术语、市场和营销术语、保险中介术语、精算术语、再保险术语、保险组织与监管术语及定义。 本标准适用于保险企业保险业务活动的开展和管理

2023-12-27

第五章 需求工程之建立业务需求

- 业务需求代表的是需求链的顶部 - 业务需求定义解决方案的愿景和实现该方案的项目范围 - 用户需求和功能需求必须与业务需求建立的背景和目标保持一致 - 任何无助于项目达成业务目标的需求都不宜实现。 - 如果项目没有清晰的定义和充分的沟通方向,肯定会带来灾难性的结果 - 参与者如果不能保持目标和优先级一致性,工作方向就会不自觉地南辕北辙 - 如果对项目的业务目标缺乏共同的理解,干系人永远无法就需求达成一致意见 - 团队如果不能提前意识到这一点,即使劳神费力交付合格产品,项目也很可能超期,预算也可能超支。

2023-12-26

第四章 需求工程之业务分析师

- 业务分析师的首要职责是获取、分析、记录、验证项目干系人的需要。 - 业务分析师要将客户群体的需求传递到软件开发团队 - 分析师是一种角色而不是头衔 - 如果项目中既有业务分析师,又有产品经理,则产品经理主抓外部市场和用户请求,再由业务分析师将其转换为功能需求。 - 在敏捷团队中设置一名业务分析师好处多多。 - 才华横溢的业务分析师能使项目团队气死回升。 - 经验丰富的业务分析师缩写的需求规范说明书,差错更少,可读性更高。

2023-12-25

第三章 需求工程优秀实践

第三章 需求工程优秀实践

2023-12-22

需求工程之从客户角度审视需求

干系人共同的目标:构件一个实现业务价值又可以使所有干系人受益的产品。 卓越的软件产品来自卓越的需求卓越的设计。卓越的需求根植于开发人员与客户的协作。

2023-12-21

软件工程之软件需求的本质

需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性,可以是一种对系统开发进程的约束。

2023-12-21

axis2 安装使用教程

图文教程,一步步安装配置axis2插件,配置服务端,客户端。

2012-01-10

扫雷V2.0版 源码 有三个等级

注:本人是将他人的修改了一下 为了学习交流 添加了三个等级 在第一次点击时时间开始 结束时时间停止至于右键标记后左键无法点击还没想出来办法

2010-08-22

== and equals() 的比较 绝对值得看

值类型是存储在内存中的堆栈(以后简称栈),而引用类型的变量在栈中仅仅是存储引用类型变量的地址,而其本身则存储在堆中。 ==操作比较的是两个变量的值是否相等,对于引用型变量表示的是两个变量在堆中存储的地址是否相同,即栈中的内容是否相同。 equals操作表示的两个变量是否是对同一个对象的引用,即堆中的内容是否相同。

2010-08-12

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除