zoukankan      html  css  js  c++  java
  • 软件需求与分析——大二下需会知识点

    读了这篇博客后,我大概对软件需求分析有了了解,了解了大概的步骤,明白了其中的利害关系。接下来我就说说我的读后感和这学期关于这门课要掌握的知识点,然后附上关系图。

    博客中通过故事的方式告诉了我们需求分析在软件开发中的重要性。由于软件开发与客户交流太少导致最终结果不符合客户的要求,最后导致软件开发失败;由于客户怎么说软件就怎么做,客户提出的原始需求往往是不考虑技术实现,基于非计算机管理的操作模式提出来的,他们提出的很多需求常常比较理想而不切实际,“有条件要上,没有条件创造条件也要上”的鲁莽行事,结果必然是悲惨的;由于一味地追求快而忘记了基本步骤,漏掉了很多细节,导致失败。需求分析不是一蹴而就的,它应当贯穿整个开发周期,不断的分析确认的过程。

    下面是我通过阅读发现自己需要掌握的,和自己的一些理解。

    需求调研:它既要求我们具有一种理解能力、设计能力,更要求我们具有一种与人交往、沟通的能力。这要求我们需要主动去和客户进行交流,有不明白的地方一定要再问一遍,还要学会复述将客户告诉自己的要求加上自己的理解给客户讲一遍,看自己理解的是否正确。下面有三点建议:1)树立良好的职业威信;2)进行详细角色分析,将与会各方代表对号入座;3)从宏观上制订目标与方案。

    还有就是需要对客户进行拜访,了解客户工作流程,才能更好地完成调研。而且还需要定期进行研讨,与客户交流汇报自己工作。需求分析不是一蹴而就的,是一个反复迭代的过程。在第一次的需求分析阶段,我们在一段时期内需要与客户进行反复地讨论,这个过程往往是这样一个反复循环的过程:需求捕获->需求整理->需求验证->再需求捕获······

    功能角色分析与用例图:需求分析不应当是太公钓鱼,而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此,我们应当采用一套成熟而完整的分析方法,稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异,但一般来说,信息化管理类软件项目通常从这几个方面着手分析:功能角色分析、业务流程分析与业务领域分析。对一个系统进行功能和角色方面的梳理和分析,可以采用的比较主流的方法之一就是绘制用例图。用例图是贯穿整个面向对象分析/设计(OOA/D)的核心视图,它描述的是系统到底为用户提供了哪些功能,以及到底是哪些用户在使用这些功能,是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼,进而形成抽象模型的过程称之为用例建模,而这个模型就是用例模型。用例图是站在用户角度去观察的系统,即系统为用户提供了哪些功能,这就是功能分析。同时,这些功能是为哪些用户服务的,这就是角色分析。我们绘制的用例图应当能够为用户所理解,这也是UML其中的一项核心思想——与客户形成统一的、能够相互理解的语言,这对于需求分析过程中与客户的沟通是大有好处的。

    业务流程分析:分析流程,更好实现功能。

    用例说明:详细的分析,使客户更好地理解。

    报表分析:就是描述参与者使用这个报表做什么。如果有多个参与者,每一个都应当描述。

    子用例和扩展用例:子用例应当是在逻辑上相对独立的一系统流程组成的用例。这个用例应当是抽象的,没有自己的参与者,只有在调用它的用例中,才能真正明确它的使用者。在用例中还存在许多扩展流和异常流。当系统在运行到基本流程中某个步骤时,由于满足了某个分支条件或异常条件,这时系统就从基本流程流转到了扩展流或异常流中。扩展流和异常流其实不那么泾渭分明。

    行动图和状态图:行动图比较类似于我们过去绘制的流程图,是UML中描述流程与分支的视图,在需求分析中,状态图并不是必须的,它仅仅出现在你认为需要对某个对象的状态进行说明的时候。

    业务领域分析:这里包括原文分析法和领域需求设计业务领域分析,就是对需求分析中涉及到的业务实体,以及它们相互之间关联关系的分析。原文分析法(Textual Analysis),是在用例说明与流程分析的基础上进行的业务领域分析,是一项在需求研讨会后整理和分析需求的工作。

    非功能需求:需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术,是设计,是实现,是架构师关注的内容,是需求人员最不擅长的方面,这也是非功能需求为什么常常被忽略的重要原因。正因为如此,架构师应当尽早参与到项目中,参与到需求分析中,尽早分析需求的技术可行性,尽早考虑性能、安全性、可靠性等非功能需求,尽早开始架构设计。

    需求列表

    需求规格说明书:需求规格说明书就应当是一个,不区分用户需求规格说明书和产品需求规格说明书。

    需求评审会:主要目的就是确认需求,以便以此开始我们的设计开发工作。从理论上说,需求评审会应当由用户代表,与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理,还有公司相关领导参加。但实际上,让如此多不同角色的人聚集在一起开会是不现实的。因此,我们可以将需求评审会分为内部评审会与外部评审会两部分来开比较现实。

    以上就是大体的软件需求分析的全部流程。下面是我绘制的各个过程之间的关联关系。

     

     

  • 相关阅读:
    JDBC基础篇(MYSQL)——使用statement执行DML语句(insert/update/delete)
    JDBC基础篇(MYSQL)——自定义JDBCUtil工具类
    JS原生方法实现jQuery的ready()
    windows.onload和body的onload属性的区别
    JS中对象与数组(大括号{}与中括号[])
    javascript面向对象编程
    深入理解JS闭包
    一行神奇的javascript代码
    Object.keys方法之详解
    JavaScript运算符
  • 原文地址:https://www.cnblogs.com/chch157/p/8530505.html
Copyright © 2011-2022 走看看