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

架构设计实践二:需求分析

时间:2015-03-09 23:51:53      阅读:379      评论:0      收藏:0      [点我收藏+]

标签:

1.1 三个问题

掌握好需求分析,需要掌握三个问题的解决方式。

  • 需求如何获得?需求开发=愿景分析+需求分析
  • 如何判断需求全不全?功能、质量、约束三类需求
  • 如何从需求转换为设计?功能、质量、约束对架构产生不同的影响。

1.2 软件研发与交付过程总图

 技术分享

其中概念化阶段一般都要完成愿景分析、风险评估、可行性分析及项目进度和成本的粗略估算,输出《愿景与范围文档》;需求分析阶段则完成需求捕获、需求分析,得到《软件需求规格说明书》,一个关键的思路是需求捕获与需求分析是迭代着进行的,完成需求捕获之后再统一进行需求分析的思路是不具备可信性的;架构设计阶段完成通过关键需求确定、概念架构设计、细化架构设计和架构验证,得到架构设计说明书。

1.3 愿景分析(简要)

愿景分析的目的是明确愿景,即针对系统目标、功能范围、主要特性及成功要素等进行构思并达成一致。产出为《愿景与范围文档》,有的产品型公司会称之为《市场需求文档》MRD,有的产品型公司则称之为《产品需求文档》PRD,项目型公司则可能称之为《项目立项书》。

愿景=业务目标+范围+特性+上下文图。

  • 业务目标是客户组织应用系统所需要达到的目标,例如提升组织的某种能力,简化组织的某种过程。
  • 范围则是则是对需求的面状刻画,说明为实现业务目标,系统需要提供哪些主要的功能块。
  • 特性是对需求的点状刻画,列举系统大致支持哪些功能组(比范围的功能块要细),强调说明某些具有特色的功能项,点出功能项的更细节优势,技术特色、其他特色的强调。
  • 上下文图用于刻画系统的边界,将系统置于中央,周围环绕所有与系统相关的所有外部事物,关注本系统及与本系统相关的外部因素,但不关注本系统内部,保持本系统为黑盒,其主要目的是为保证需求发现过程中的全面性。

1.4 需求分析(简要)

需求分析的过程是需求捕获和需求分析迭代进行的过程,而不是“需求捕获->需求分析”的线性过程。

需求捕获是获取知识的过程,要求理解用户所从事的工作,并了解用户和客户希望软件系统在哪些方面帮助他们。需求捕获的输出是一系列的“需求采集卡”,记录需求类型、需求描述、需求北京、需求提出者等信息。

需求分析则是挖掘和整理知识的过程,在通过需求捕获所掌握的知识基础上进行,使得需求更系统、全面、有条理。需求分析的输出是《软件需求规格说明书》,精确阐述一个系统必须提供的功能、必须达到的质量属性及必须遵守的约束。一般使用用例技术来进行需求分析,对于重要需求,除用例图外,还需给出详细的用例规约。

1.5 如何判断需求是否全面

1.5.1       需求层次-方面矩阵

使用二维需求矩阵来判断需求是否全面。这个是目前我见到的最具可操作性的方法。

一方面,需求是分层次的,根据涉众的不同,可将需求分为三个客户级需求(也称组织级需求)、用户级需求和开发级需求;另一方面,需求可分为功能、质量和约束三个方面。通过检查层次-方面的二维矩阵,即可较好的判断需求是否全面。

 

功能

质量

约束

客户需求

业务目标

快、好、省

技术性约束

标准性约束

法规性约束

遗留系统集成

技术趋势

分批实施

竞争因素与竞争对手

用户需求

实现某某功能

运行期质量

用户群特点

用户水平

多国语言

使用环境

开发需求

行为需求(这个不太懂)

开发期质量

开发团队技术水平

开发团队磨合程度

开发团队分布情况

开发团队业务知识

管理的保密要求

安装

维护

 

1.5.2       软件质量的分类

软件质量涉及众多,但是从关注者的角度将其划分为运行期质量开发期质量,可将其划分的很清楚。

所谓运行期质量,指系统运行期间,最终用户可以感受到的质量属性,包括性能、易用性、安全性、健壮性、可靠性、可用性、可伸缩性、互操作性。

开发期质量则指的是系统开发、维护、移植过程中所体现出来的属性,是软件的开发、构建、部署人员所关心的质量属性,包括:

  • 开发人员关注的:易理解性(这个很容易被忽视)、可扩展性、可重用性、可维护性、可移植性
  • 测试人员关注的:易测试性
  • 部署人员关注的:易部署性

关键质量属性说明

  • 性能:性能包括速度、吞吐量和持续高速型,速度使用平均响应时间来衡量,吞吐量使用单位时间交易数来衡量,持续高速性指系统保持持续高速处理速度的能力,则与实时系统有关,实时系统对每次系统响应时间都有严格要求。需要注意的是,速度快一般意味着高吞吐量,但是速度慢不见得吞吐量就低,这与网络延时与带宽的关系相似。
  • 安全性:同时兼顾向合法用户提供服务,以及阻止非法用户使用的能力。高安全性意味着“同时兼顾”。
  • 可用性与可靠性:可靠性是指系统在一定时间内无故障运行的能力,一般用平均无故障时间来衡量,而高可用性则指的是“系统长时间为用户提供可用服务的能力”(原书中为“系统长时间无故障运行的能力”,应当不太准确)。经常使用集群的方式来提高系统的高可用性,但是显然,如果将整个集群视为一个整体,任意一台机器宕机,则整个系统都不能判定为“无故障运行”,所以其可靠性相比于单机是下降的,但是只要集群中足够多的机器正常工作,则系统“为用户提供可用服务”的能力并不受影响,因此集群提高了系统的可用性。
1.5.3      约束

可从客户、用户、开发三个层次来分解约束,确保约束条件的完整。另一个角度,约束=业务环境因素(来自客户)+使用环境因素(来自用户)+构建环境因素(来自开发、维护人员)+技术环境因素(业界技术约束)。

 

1.6 如何从需求过渡至设计

  • 使用功能来划分子系统、模块:功能是发现职责的依据,每个功能均由一条职责链来完成,通过为功能规划职责链,将职责划分到子系统,为子系统制定接口,确定基于接口的交互机制,来推动架构设计的进行。
  • 使用质量来完善架构:必须基于当前的中间架构,进一步考虑质量要求,对中间架构进行调整、细化。
  • 约束:一部分约束直接制约设计决策,例如团队成员仅掌握Java相关开发技术;一部分约束可转换为功能,例如银行系统的“本系统执行现行利率”引出“利率调整”的功能;一部分约束转换为质量属性,例如“柜员计算机水平普遍不高”引出易用性需求。

架构设计实践二:需求分析

标签:

原文地址:http://www.cnblogs.com/lidabnu/p/4321646.html

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