[架构之路-95]:《软件架构设计:程序员向架构师转型必备》-5-需求分析之需求列表(功能需求质量需求约束条件)
Posted 文火冰糖的硅基工坊
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[架构之路-95]:《软件架构设计:程序员向架构师转型必备》-5-需求分析之需求列表(功能需求质量需求约束条件)相关的知识,希望对你有一定的参考价值。
前言:
在业务需求分析领域,主要完成三个输出:
需求列表:功能需求、质量需求、约束条件 =》 第5章
用例图 =》 第6章
概念架构 =》 第7章
上述工作,通常是由需求分析工程师或系统工程师SE完成,也可以由架构师完成。
第5章 需求分析
架构师要想知道需求是如何影响架构,首先要懂得如何进行需求分析,或者说,需要懂得需求分析的主要行为动作与主要的输出结果,这些输出结果,是架构设计的输入。
需求开发:业务愿景分析 + 业务需求分析
需求分析:功能列表 + 用例图
领域建模:领域模型
5.1 需求开发(上)—— 愿景分析 =》愿景与范围文档/市场需求文档/产品需求文档/项目立项建议书/可行性研究报告/项目立项书
5.1.1 从概念化阶段说起
5.1.2 愿景:环境?背景?好处?目的?为什么要做?
备注:
项目型公司与产品型公司的区别
项目型公司:使用市面上成熟的产品、原配件做方案和系统集成,赚取的方案集成的利润
产品型公司:研发自己的产品,用自己的产品提供解决方案,赚取的是产品研发的利润和方案利润
混合型:研发自己的产品、同时为用户提供解决方案(可以是自己的产品,也可以是第三发产品)
5.1.3 Context上下文图
上下文图把目标系统看成是一个黑盒子,阐述目标系统与外部系统的交互以及目标系统呈现的外部功能行为。
5.1.3.1 与物理架构视图的比较
5.1.3.2 与逻辑架构图的比较
5.1.3.3 Context上下文图与用例图的比较
Context上下文图:关注的外部环境。
用例图:关注为外部不同用户提供的不同功能。
5.1.4 愿景分析实践要领(如何描述业务愿景)
业务目标:简短的文字描述目标系统的业务目标、好处、原因。
feature:功能特征
范围:明确目标系统的边界,哪些是目标系统的职责,哪些不是目标系统的职责。
上下文图:明确目标系统边界外的环境,即上下文。
5.1.5 愿景分析的输出
5.2 需求开发(下)—— 需求分析 =》 需求列表
5.2.1 需求捕获vs.需求分析vs.系统分析
需求分析和系统分析,相同点都是分析,但分析的对象不同,导致结果不同。
所谓分析:就是先解构,然后再综合的过程,称为分析。
需求分析,分析的是用户的需求,属于做“什么“的问题。对用户的需求进行解构,然后结构化。
系统分析,分析的待实现的软件系统,属于”怎么做“的问题。对软件系统进行结构,然后结构化。
5.2.2 需求捕获及成果
5.2.3 需求分析及成果 =》 SRS和需求列表
用例图和需求规格说明书SRS,都是对用户的需求进行解构和综合的结果。
5.2.4 系统分析及成果
《面向对象的编程》:用面对对象的方法进行软件编程
《面向对象的分析》:设计范畴,把现实领域转换成对象的方法。
系统分析的本质就是根据用户的需求进行初步的架构设计。
5.3 掌握的需求全不全 =》 架构师需要全面了解各种层面、各个维度的需求
5.3.1 二维需求观与ADMEMS矩阵
为了确保需求的完备性,需要从如下的矩阵模型中收集需求。
5.3.2 功能性需求(最常见的需求)
5.3.3 质量性需求
软件的质量,取决于如下的因素:
软件质量属性的需求收集与需求分析
软件架构设计
软件程序设计
程序员的编码能力
程序的态度
公司的软件开发流程
项目管理
业务部门的管理
所有上述这些因素共同决定了软件的质量属性。
5.3.4 约束
5.4 如何把"需求"转换成“架构设计”
5.4.1 “理性设计”还是“拍脑袋”
备注:这里有一个基本观点,把需求转换成架构设计,不是靠拍脑袋,也不仅仅靠经验,把需求转换成架构设计有方法可循。
5.4.2 功能:职责协作链
备注:
用户给定的是功能需求,架构师需要为不同的用户功能设计职责协作链,即为了满足某种功能,需要哪些子系统参与,相互协作才能完成才功能,不同子系统的职责是什么?并为子系统的职责定义相关的接口、协作方式。
因此,功能设计相对比较直观,架构师的主要任务:
定义子系统的个数、各自的职责
把用户的功能需求,进行职责链分解
把职责分配到不同的子系统中
为子系统的对应的职责定义新的接口
为子系统之间交互定义协作方式
5.4.3 质量:完善驱动力
备注:
在完成需求的基础之上,进一步完善软件架构,完善质量需求。
质量需求是对现有系统不断精进的过程 。
质量需要开始于需求分析,构建于架构设计,贯穿于开发流程和项目管理流程的每个环节。
5.4.4 约束:设计并不自由
5.5 实际应用(3)——PM Suite贯穿案例之需求分析
5.5.0 基本思路:用三横、三纵替代三纵两纵
三横,即三个层次的需求:业务目标、高层次级需求、用户级需求(用例)
三纵,即三个维度的需求:功能性需求、非功能性需求、约束性需求
5.5.1 PM Suite案例背景介绍
5.5.2 第1步:第一纵第一横(层次)需求:明确系统业务目标
系统业务目标是组织运营服务的。
5.5.3 第2步:第一纵第二横(层次)需求:范围 + Feature + 上下文图
(1)需求范围
备注:
scope:英语单词,名词、动词,作名词时意为“范围;余地;视野;眼界;导弹射程”.
需求范围 requirment scope:就是目标系统特征的大的特征,大的框架。框架内属于需求范围,框架之外需求范围之外。
需求范围是可以分层次、分组、分阶段的。
需求框架和架构框架并不是一回事
需求框架:是组织目标系统需求的一种架构化、图形化的方式。
软件架构:是代码实现软件系统需求的一种架构化、图形化的方式。
可以把软件架构设计成与需求框架一致的架构,也可以设计成不一致的架构!!!
(2)需求特征/特性Feature
(3)需求上下文Context图
5.5.4 第3步:第一纵第三横(层次)需求:画用户用例图
5.5.5 第4步:第一纵第三横(层次)需求:写用例User Case/senario)规约
用例User Case/senario)规约是对用户用例图的详细描述,需求文档中需要定义各种大量的User Case/senario以及对应的详细流程描述。
备注:
每个用例有包含数据处理流程,用例User Case规约用于描述用例的输入、处理、输出等信息。
开发人员用此用例规约实现代码。(类似测试用例或业务场景senario)
测试人员用词用例规约验证代码的实现情形(类似测试用例或业务场景senario)
5.5.6 插曲:第一纵(功能性需求迭代):原型开发、需求启发与需求验证
5.5.7 插曲:第二纵(非功能性)需求:非功能需求
5.5.8 输出:《需求规格》与基于ADMEMS矩阵的需求评审
以上是关于[架构之路-95]:《软件架构设计:程序员向架构师转型必备》-5-需求分析之需求列表(功能需求质量需求约束条件)的主要内容,如果未能解决你的问题,请参考以下文章
[架构之路-100]:《软件架构设计:程序员向架构师转型必备》-10-细化架构设计
[架构之路-94]:《软件架构设计:程序员向架构师转型必备》-4-软件架构设计的通用过程
[架构之路-94]:《软件架构设计:程序员向架构师转型必备》-4-软件架构设计的通用过程
[架构之路-92]:《软件架构设计:程序员向架构师转型必备》-2-解析软件架构的概念