码迷,mamicode.com
首页 > 其他好文 > 详细

《软件需求模式》02

时间:2018-01-17 20:08:56      阅读:151      评论:0      收藏:0      [点我收藏+]

标签:关于   不一致   意思   基础架构   运营   分组   期望   总结   实例   

读完了这本书的第二部分,我感受颇深,总结了许多自己所不了解的知识。需求分析基本原则是 1 定义问题,而不是解决方案。需求定义“做什么,而不是怎么做”,意思是需求的目的不是企图定义任何的解决方案。这是重要的特点,是不可违反的规则。2 定义系统,而不是项目。需求定义了系统需要做什么:他们是一组目标。项目是在一段时间内动员一组人来完成这些目标。需求不涉及系统如何完成目标,这意味着不要涉及实现一个解决方案的项目的任何事情,而且编写每个需求规格应该是长期有效的,适用于多个系统,这些系统可能在不同的时间以不同的方式开发:需求可能被束之高阁,然后一两年后拿出来,或者几年时间内我们可能开发一个替代系统。3 区分正式和非正式部分。需求规格像一个合同,它定义了系统的供应商或开发者必须交付的东西。但是大量的合同约束声明远远不能让我们正确的理解它,它需要背景知识、前后关系、流程以及结构。这些材料都不是合同约束。它帮助把规格分为约束部分和非约束部分。需求本身由需求规格的正式部分组成,是系统必须做什么的正式定义。其他的都是非正式的。4 避免重复。如果可行,每一项信息只表述一次。重复产生了额外的工作而且加大了不一致的可能性。敏捷需求流程的原则:区分问题和解决方案是最重要的,定义需求后,一定要记录他以便别人可以找到。需求模式剖析:基本细节、适用性、内容、模板、实例、额外需求、开发考虑、测试考虑。需求规格的内容可以分为四部分:“介绍部分”,“上下文部分”,“功能域部分”和“主要非功能要求部分”。  

需求模式提供的指导通常比只是“比如说这样”更深入。它可以深入洞察即将发生的问题。它可以帮助提出问题。在一些情况下,它可以引导编写一个(或多个)非常不同于第一印象的需求。解答一个大问题经常引出很多很小的问题。需求模式针对大问题给出答案以及化为更小的问题。一些需求模式要求或者鼓励定义一些额外需求:包括跟随性需求:扩展最初需求的需求,以及系统级普遍性需求:支撑模式本身的需求。这样可以检查每一个需求是否需要额外支撑需求,以及是否已经定义了他们。模式有不同的详细程度和价值。一些类型的需求可以定义得非常详细,它们的实例几乎一样。其他类型的需求虽然有一些普遍有价值的东西,但是这些需求如此多变甚至不能描述应该表达什么。这些变化是正常的。模式只需要证明自己是有价值的;它不必做模式可能做的所有的事。另一方面,反复遇到一种特别需求并不意味这种需求模式自然而然就有价值。如果很难概括这种需求的共性,就很难指导怎样定义这种类型的需求。接下来, 信息是商业系统活力的源泉,习惯称为数据处理,但信息有更广泛的含义,不仅仅是数据;两个名称都反映信息的核心本质——输入、存储、展示、报告等,在大多数的系统中,特别是在商业运营上有一定作用的系统,所以定义数据的需求以及如何处理他,在系统的定义中扮演至关重要的角色。 需求模式可以自由使用其他领域中的基础架构。但是最好避免相互依赖,所以如果一个领域依赖另一个领域,那么后一个领域就不应该依赖前一个领域——如果可以避免的话。一个基础架构也可以依赖另一个基础架构。每个基础架构概述分成下列小节:1)目的 解释基础架构存在的理由,以及扮演的角色。2)调用需求 关于系统与基础架构如何交互的需求定义的建议——基础架构必须提供这些功能给系统——以及系统期望的其他的能力。需要的功能可以被看作是基础架构提供给调用者的接口。3)实现需求 为了使基础架构站得住脚所需要的一些特性的想法。这些是比较简短的,只是在定义基础架构时提醒一些需要考虑的可能的主要功能域。

《软件需求模式》02

标签:关于   不一致   意思   基础架构   运营   分组   期望   总结   实例   

原文地址:https://www.cnblogs.com/clueless/p/8304855.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!