[转]《软件架构设计》学习笔记&摘录(四)
[转]《软件架构设计》学习笔记&摘录(四)
爱看博客 发表于2年前
[转]《软件架构设计》学习笔记&摘录(四)
  • 发表于 2年前
  • 阅读 5
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 技术升级10大核心产品年终让利>>>   

需求分析

       那些没有经验的问题解决者们,几乎无一例外,都是去匆忙地寻找解决办法,而不是先给要解决的问题下定义。

 

       什么是软件需求?什么是需求捕获、需求分析和系统分析?需求描述了系统必须满足的情况或提供的能力,它就可以是直接来自客户需要,也可以来自合同、标准、规范或其他有正规约束力的文档。需求的捕获是获取知识的过程,知识从无到有、从少到多。需求分析是挖掘和整理知识的过程,它在已掌握知识的基础上进行。如果说需求分析致力于搞清楚软件系统要“做什么”的话,那么系统分析已经开始涉及“怎么做”的问题了。系统分析是针对系统所要面临的问题,搜集相关的资料,以了解产生问题的原因所在,进而提出解决问题的方法与可行的逻辑方案,以满足系统的需求,实现预定的目标。需求捕获、需求分析并不是先后进行的两个阶段工作,相反,它们往往是相互伴随、交叉进行的。人们对软件工程中“分析”这个术语的含义有着不同的理解——有时把它作为需求分析(Requirement Analysis)的简称,有时是指系统分析(System Analysis),有时则作为需求分析和系统分析的总称。但迄今为止人们所提出的各种分析方法中,真正属于需求分析的内容所占的分量并不太大;更多的内容是给出一种系统建模的方法,告诉分析员如何建立一个能够满足用户需求的系统模型。分析员大量的工作是对系统的应用领域进行调查和研究并抽象地表示这个系统。确切地讲,这些工作应该叫做系统分析,而不是需求分析,它既是对“做什么”问题的进一步明确,也在相当程度上涉及到“怎么做”的问题。大多数的分析方法(如OOA)应该属于“系统分析”的范畴。需求分析的工作成果是《软件需求规格说明书》(Software Requirements Specification,SRS),它精确地阐述了一个软件系统必须提供的功能、必须达到的质量属性指标以及它必须遵守的约束。对于不同的系统分析方法,其工作成果差异很大。通过结构化分析方法得到的最重要的工作成果是数据流图;而面向对象的分析方法得到的工作成果主要是分析类图、鲁棒图、序列图等——其中分析类图描述设计的静态方面,而鲁棒图和序列图描述设计的动态方面。

       需求分析活动要进一步完善和细化软件需求。需求分析和领域建模是相互支持的关系。要进行领域建模,很大程度上依赖于需求讨论会等内容。领域模型作为领域建模的成果,规定了重要的领域词汇表,并且这些词汇的定义是严格的、大家共同认可的,所以可以成为团队交流的基础,自然也应当作为需求分析活动和《软件需求规格说明书》应当遵循的标准词汇。需求分析活动应该提供功能需求、质量属性需求以及约束性需求等不同需求的明确定义。

       功能需求强调行为,而约束不是行为。约束是设计或项目的某些限制条件,这些限制条件也属于需求,但通常被称为“约束”来强调其限制性,例如:必须使用Oracle;必须在Linux上运行。

       推荐的软件质量属性分类方式:

       运行期质量属性:

       性能、安全性、易用性、持续可用性、可伸缩性、互操作性、可靠性、鲁棒性(健壮性或容错性)。

       开发期质量属性:

       易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性。

       我们可以将运行期质量属性和功能性一起视为“软件的外部质量”,而将开发期质量属性视为“软件的内部质量”。无疑,软件的内部质量制约着软件的外部质量。

       功能需求影响架构,而架构必须适应功能需求。但功能需求并不能决定架构。倒是质量属性需求对软件架构影响更大。反过来,大部分质量属性需求能否被满足,也很大程度上依靠软件架构的设计。约束性需求最特殊,它可能产生的影响有3种:

1、          作为架构设计时必须遵守的限制条件;

2、          导致软件系统必须提供某些功能需求;

3、          导致软件系统必须满足某些约束性需求。

 

需求的变更蕴含着风险,因为不存在不需要成本的需求变更。当然,需求变更也蕴含着机遇。对软件架构设计而言,这个机遇可能意味着设计出稳定的架构,最终这个架构能够支持业务功能在一定范围内“随需应变”。一般而言,功能需求最易变,而质量需求最稳定。功能需求最容易变化,一是功能需求集中存在少量长期稳定的功能。二是虽然功能的行为步骤常常变化,但功能点本身趋于稳定。当采用用例技术进行需求捕获和需求分析时,用例图往往是相对稳定的(它描述了功能体现),而用例规约则可能频繁变化(它以交互序列的形式描述功能执行的步骤)。质量属性需求相对来说最为稳定。

       在需求分析过程中需求不断地和客户进行交流,这时客户非常希望能够看到给他带来实感的界面草图甚至可执行的系统原型。而开发方最担心的问题是客户需求的不断变化,所以他们也希望能够尽早掌握客户的真正需求,并希望需求成果得到客户的确认。在需求分析期间就开始界面设计,并将界面草图等设计成果用于和客户的交流当中,这样可以增加实感、方便交流,并帮助客户“发现”他真正想要的功能。当然,界面设计的成果并不应该放入《需求文档》,因为它们是设计而不是需求。非功能需求的满足程度对软件的成功非常关键,因此《软件需求规格说明书》必须系统地描述非功能需求的具体要求。非功能需求大致分为质量属性和约束两大类。

 

用例技术及应用

       我们掌握的知识本身和我们的实践能力并不成正比。因为如果不能根据经验使“头脑中的知识”和“实践”真正“匹配”起来,知识就无法转化成真正的实践能力。

       用例图描述软件系统为用户或外部系统提供的服务。用例图最重要的元素是参与者(Actor)和用例(Use Case)。用例的名称应该从参与者的角度进行描述,并以动词开头。用例图通过确定与本系统的交互的角色或外部系统、描述系统必须提供的功能的方式,清晰地界定了系统的功能范围(Scope)。用例图不仅是可视化的,而且是结构良好的、有利于从宏观上反映系统功能的大局观。所谓用例描简述,就是通过简短的文字对用例的功能进行描述:一般而言,用例简述应包含成功场景的简单描述。用例简述是一项非常轻便的技术,很多敏捷方法都通过类似用例简述的技术捕获和交流需求。用例规约是对用例的详细描述,一般包括简要说明、主事件流、备选事件流、前置条件、后置条件(后者条件应覆盖所有可能的用例结束后的状态。即,后者条件不仅仅是用例成功结束后的状态,还应该包含用例因发生错误而结束后的状态。)和优先级等。用例规约的主要目的是界定软件系统的行为需求(需求可以划分为业务需求(组织要达到的目标)、用户需求(用户使用系统来做什么)和行为需求(开发人员需要实现什么)三个层次,所谓行为需求是指系统软件为了提供用户所需要的功能而必须执行哪些行为)。用例简述和用例规约都是对用例进行说明的技术,但用例规约要比用例简述复杂10倍以上。

       在面向对象的理论系统中,协作被定义为“多个对象为了完成某种目标而进行的交互”。而用例实现的是协作的具体运用:即为了实现用例定义的功能,我们必须考虑需要哪些类,这些类又如何交互来完成最终的功能。用例实现是从功能需求向设计方案过渡的纽带。通过分析一组关键用例的用例实现,可以获得未来系统的思想化和职责模型,它的重点是识别组成软件系统的高级职责块、规划它们之间的关系:这个职责模型是规划架构机制、满足高质量属性要求的武器。

       用例图从总体上反映了用户需求,而用例简述和用例规约分别是行为需求的简化描述和详细描述。至于用例实现,已经属于设计的范畴了。

       用例方法是以客户为中心的。用例方法比传统的SRS更易于被用户所理解,是开发人员于用户之间进行沟通的有效手段之一。用例图可以从大局上反映系统的功能结构,并且用例图在很大程度上不会受到需求变更的冲击——因为它不涉及需求细节。传统需求方法采用功能分解方式,非常容易混淆需求和设计的界限,而用例方法有利于解决这个问题。

       一个软件系统,它应当提供哪些功能往往是和业务目标相一致的,而一个企业的业务目标还是相当稳定的。对软件开发影响巨大的需求变更其实更多地发生在行为需求层面——用例规约的主事件流和备选事件流正式反映行为需求。

       需求捕获是知识采集的过程,致力于收集用户对未来软件系统的期望和具体要求。有如下的一些技术和手段:“需求采集卡”、“用户故事卡”、“用例图+用例简述”。

       需求分析的目的是以比较规范的形式,明确定义软件系统的要求,显然用例规约正是一项规范、明确的技术——它通过特定格式的文本来记录参与者和系统之间的各种情况下的交互场景,以此来明确对软件系统的行为需求。需求分析还必须去伪存真、查漏补缺。用例规约技术能帮助需求分析员以用户为中心进行思考,定义不同场景下的软件系统应有的行为需求。

       架构设计不应等到所有用例被细化到用例规约程度才开始。对架构设计起关键作用的功能需求只占功能需求的一小部分,这部分用例应该已经被细化到用例规约的程度,它们和其他非功能需求一起决定架构设计方案。必须聪明地应付需求变更。需求变更对用例图和用例简述的影响比较小,而对用例规约的影响很大。因此我们应该“推后用例细化、激发需求变更”。不是对软件架构起关键作用的用例,可以推迟到要实现该用例所定义的功能之前才进行细化,过早地为这些用例制定用例规约会增加“需求变更管理”的开销,使需求变更的影响增大。必须通过不断增加功能、发布小版本、提供给用户试用、接受用户反馈等一系列的活动。在项目前期不将所有用例细化,而是将大部分用例保持在“用例图+简短描述”的水平——这样做并不影响开发出原型来启发和确认用户需求,并可能尽早激发需求变更的发生——直到变更的几率较小的时候甚至到了程序小组要实现该用例的时候,再深入到小组的系统分析员对用例进行细化。(但笔者认为,这样做的只时候使用敏捷开发的时候,使用瀑布模型时是显然不适合的。另外,这样做也同样有将问题推迟发生的风险,我们应该尽早的发现问题,和让问题方式。需求变更的方式,往往是在细节的交流过程中,或用户看到原型之后出现的。笔者认同识别出关键需求就进行架构设计的观点,但此时应该同时开始其他需求的细化工作)

共有 人打赏支持
粉丝 6
博文 103
码字总数 23887
×
爱看博客
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: