157 lines
7.7 KiB
Markdown
157 lines
7.7 KiB
Markdown
---
|
||
title: 如何做需求分析
|
||
date: 2020-06-08 20:31:52
|
||
tags: [需求分析]
|
||
categories: [功能测试]
|
||
author: Anges黎梦
|
||
---
|
||
> 本篇文章仅为个人思路和方法，不喜勿喷
|
||
|
||
## 为什么要做需求分析
|
||
|
||
每一个需求都会进行评审，从设计、研发、测试等角度，对需求进行评审。评审需求是否可行。
|
||
|
||
在测试阶段也是一样，只不过区别是测试人员分析的对象不仅仅是需求，还有研发所出的详细设计。
|
||
|
||
分析过后的需求，条理更清晰，分支更明显，对测试人员编写测试用例有特别大的帮助和好处。
|
||
|
||
## 目标
|
||
|
||
需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，
|
||
|
||
该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。
|
||
|
||
需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，
|
||
|
||
确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。
|
||
|
||
此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。
|
||
|
||
## 原则
|
||
|
||
(1)理解问题的数据域和功能域。对新系统程序处理的数据，其数据域包括数据流、数据内容和数据结构。而功能域则反映它们关系的控制处理信息。
|
||
|
||
(2)需求问题应分解细化，建立问题层次结构。可将复杂问题按具体功能、性能等分解并逐层细化、逐一分析。
|
||
|
||
(3)建立分析模型。模型包括各种图表，是对研究对象特征的一种重要表达形式。通过逻辑视图可给出目标功能和信息处理间关系，而非实现细节。由系统运行及处理环境确定物理视图，通过它确定处理功能和数据结构的实际表现形式
|
||
|
||
## 内容
|
||
|
||
需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。
|
||
|
||
具体分为功能性需求、非功能性需求与设计约束三个方面。
|
||
|
||
- 功能性需求
|
||
|
||
即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。
|
||
|
||
功能性需求是软件需求的主体。
|
||
|
||
- 非功能性需求
|
||
|
||
作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。
|
||
|
||
主要包括软件使用时对性能方面的要求、运行环境要求。软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。
|
||
|
||
- 设计约束
|
||
|
||
一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。例如，数据约束、功能约束、逻辑约束等。
|
||
|
||
## 分析与综合
|
||
|
||
逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。
|
||
|
||
最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。
|
||
|
||
## 方法
|
||
|
||
目前，软件需求的分析与设计方法较多，一些大同小异，而有的则基本思路相差很大。
|
||
|
||
从开发过程及特点出发，软件开发一般采用软件生存周期的开发方法，有时采用开发原型以帮助了解用户需求。
|
||
|
||
在软件分析与设计时，自上而下由全局出发全面规划分析，然后逐步设计实现。
|
||
|
||
从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。
|
||
|
||
(1)功能分解方法。
|
||
|
||
将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。
|
||
|
||
便可得到系统的雏形，即功能分解——功能、子功能、功能接口。
|
||
|
||
(2)结构化分析方法。
|
||
|
||
结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。
|
||
|
||
此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。
|
||
|
||
结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。
|
||
|
||
(3)信息建模方法。
|
||
|
||
它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。
|
||
|
||
模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。
|
||
|
||
实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。
|
||
|
||
有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。
|
||
|
||
建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。
|
||
|
||
信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。
|
||
|
||
此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。
|
||
|
||
(4)面向对象的分析方法。
|
||
|
||
面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。
|
||
|
||
面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。
|
||
|
||
类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)。
|
||
|
||
`当然对于各种图的阅读和编写能力是要掌握的。`
|
||
|
||
`若时间不允许，没有办法做详细的需求分析，也可使用思维导图的形式，把重要的点罗列出来。`
|
||
|
||
## 特点
|
||
|
||
需求分析的特点及难点，主要体现在以下几个方面。
|
||
|
||
(1)确定问题难。
|
||
|
||
主要原因：
|
||
一是应用领域的复杂性及业务变化，难以具体确定；
|
||
二是用户需求所涉及的多因素引起的，比如运行环境和系统功能、性能、可靠性和接口等。
|
||
|
||
(2)需求时常变化。
|
||
|
||
软件的需求在整个软件生存周期，常会随着时间和业务而有所变化。
|
||
|
||
有的用户需求经常变化，一些企业可能正处在体制改革与企业重组的变动期和成长期，其企业需求不成熟、不稳定和不规范，致使需求具有动态性。
|
||
|
||
(3)交流难以达到共识。
|
||
|
||
需求分析涉及的人事物及相关因素多，与用户、业务专家、需求工程师和项目管理员等进行交流时，不同的背景知识、角色和角度等，使交流共识较难。
|
||
|
||
(4)获取的需求难以达到完备与一致。
|
||
|
||
由于不同人员对系统的要求认识不尽相同，所以对问题的表述不够准确，各方面的需求还可能存在着矛盾。难以消除矛盾，形成完备和一致的定义。
|
||
|
||
(5)需求难以进行深入的分析与完善。
|
||
|
||
需求理解对不全面准确的分析，客户环境和业务流程的改变。
|
||
|
||
市场趋势的变化等。也会随着分析、设计和实现而不断深入完善，可能在最后重新修订软件需求。
|
||
|
||
分析人员应认识到需求变化的必然性，并采取措施减少需求变更对软件的影响。对必要的变更需求要经过认真评审、跟踪和比较分析后才能实施。
|
||
|
||
## 补充
|
||
|
||
作为一名合格的测试人员，需求分析能力是不可或缺的。
|
||
|
||
它可以帮助你织好一张非常精细的"渔网"，辅助我们对测试用例的编写。
|
||
|
||
也可以更好的提升我们的工作质量。
|