zoukankan      html  css  js  c++  java
  • 《软件需求与分析》阅读笔记03

     UML其中的一项核心思想——与客户形成统一的、能够相互理解的语言

      做信息化管理,不是要加重人的负担,而应是降低人的负担。以这样的思路去进行流程分析才能设计出优秀的、人见人爱的管理系统出来。

      当我们进行业务流程分析时,只空对空而不落到纸面上是不可以的。在面向对象的时代,我们则是绘制行动图、状态图,以及编写用例说明来完成这部分工作。在这部分工作中,编写用例说明应当是最主要的工作

      任何事物都有两面性,用例图也不例外,也有自己不利的一面。在我看来,这集中体现在两个方面:只见树木不见森林、不生动形象。用例说明中对业务流程的描述,过早地将系统的整体流程,分散到了各个用例中了,丢失了对业务流程的整体描述。不生动形象,则是说用例说明中对流程的描述都是用枯燥无味的文字来表述的,缺乏生动形象的图形表示。针对这些不足,UML的另外两种视图,可以有效地弥补用例图的缺陷。它们就是行动图与状态图。

      在需求分析工作中,最后一项分析工作就是业务领域分析啦。业务领域分析,就是对需求分析中涉及到的业务实体,以及它们相互之间关联关系的分析。业务领域分析不仅出现在需求分析阶段,还应当贯穿与设计阶段、开发阶段、测试阶段,甚至延续到后期的维护与升级。进行业务领域分析,就是通过与用户进行交流,掌握领域知识,然后绘制成业务领域模型,去指导我们软件开发的过程。原文分析法(Textual Analysis),是在用例说明与流程分析的基础上进行的业务领域分析,是一项在需求研讨会后整理和分析需求的工作。

      需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术,是设计,是实现,是架构师关注的内容,是需求人员最不擅长的方面,这也是非功能需求为什么常常被忽略的重要原因。正因为如此,架构师应当尽早参与到项目中,参与到需求分析中,尽早分析需求的技术可行性,尽早考虑性能、安全性、可靠性等非功能需求,尽早开始架构设计。需求分析是一个撒大网的过程,而不是姜太公钓鱼的过程。功能需求固然重要,非功能需求同样重要。我们在进行非功能需求的分析时,除了制订整体的原则以外,还要落实到各个具体的功能中,将这些功能所潜在的、特殊的非功能需求挖掘出来,提前进行分析设计,对于可行性不高的应及时与客户商讨,才能有效地避免日后存在的这些方面的风险。

      不论我们如何分析与设计,我们都要如实记录原始的需求,并以此来验证我们最终的软件。这个如实记录原始需求的文档,就是需求列表。需求列表,又称之为需求跟踪表,是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计,而是以简短扼要的语句,以业务人员的口吻表述的,今后要开发的这个系统应当提供给他们的各项功能。

  • 相关阅读:
    HDU 2236 无题Ⅱ
    Golden Tiger Claw(二分图)
    HDU 5969 最大的位或 (思维,贪心)
    HDU 3686 Traffic Real Time Query System (图论)
    SCOI 2016 萌萌哒
    Spring Boot支持控制台Banner定制
    构建第一个Spring Boot程序
    Spring Boot重要模块
    Java fastjson JSON和String互相转换
    BCompare 4 Windows激活方法【试用期30天重置】
  • 原文地址:https://www.cnblogs.com/1234yyf/p/13954874.html
Copyright © 2011-2022 走看看