需求分析与定义-CSDN博客

1. 软件需求：

软件需求分为三大部分：

1)功能需求, 是指该系统所需要达成的那些特定事项, 换而言之也就是朝着用户提供那些既定功能。

2)非功能需求, 是指产品所拥有的品质以及属性, 像是可靠性, 还有扩展性, 包括响应时间, 以及性能等等。

3), 设计约束, 也称为条件约束、补充规则 , 比如用户若要安装该产品 , 就要先明确他需要具备什么样的必备条件 , 就像系统对于操作系统的要求 , 以及硬件环境的要求等等。

2. 需求调查与问题定义：

进行需求调查之际得达成两W一H, 也就是What、Where、How。

1)、What-----应该收集什么信息

2)、Where----从什么地方收集

3)、How-------用什么机制或技术来收集

3.需求分析

需求分析通常包括六个方面：

1)通过精心绘制系统上下文范围关系图, 这一行为主要是用以定义系统跟系统外部实体之间存在的界限以及接口的一种简单模型, 它能够凭借自身特性为需求精准确定出特定范围, 实际上该系统上下文范围关系图对应的就是DFD的0层图。

2)搭建用户与接口之间的初步模型, 此模型可视为用户操作的初始形态, 这意味着什么呢? 即我们平常所讲的界面, 它是用户借助一系列操作达成自身预期效果的特定接口。

3)对需求可行性展开分析: 对于这个需求而言, 我们该运用何种技术去解决它, 待其实现之后性能会是怎样的状况, 是否会与其他需求产生重合或者矛盾的情形, 在这里可要特别留意, 千万别把系统的这个需求如何通过代码来实现这一想法掺和进去。在做需求分析的时候, 应当多地重视需求本身有无作用, 而非去考虑怎样实现它。

4)首先, 确定需求的优先级的时候, 是能够采用满意度以及不满意度指标来进行说明的, 其中满意度是1至5来表示, 意思是当需求被实现的时候, 用户所具有的满意程度, 而说到那个不满意度呢, 其取值的道理是跟满意度相同的。

5)关于为需求构建模型, 在此处能够运用UML去创建用例图, 抑或是采用E-R图, 并再增添少量的文字描述。

6)使用质量功能调配（QFD）, 在此处我的认知是，分析员依据对需求的领会, 发觉那些隐藏着的需求, 并且这些需求是连用户自己都未曾察觉想到的需求, 当系统达成后, 会给予用户一份惊喜, 而要是没达成, 用户也不会产生抱怨。

4.需求分析方法

如今较为流行的软件需求分析方法存在4种, 当中有3种理论相对成熟。

1)具有这样一种情况, 即结构化分析方法, 也就是所称的ＳＡ, 对于此大家想必是非常熟悉的, 所以在此不再进行复述。

2)软件系统方法, 这仅仅是过渡性质的方法论, 它的现身仅仅是证实了结构化分析方法存在的某些不足之处, 因为结构化分析方法所运用的相对形式化的模型, 不但与社会观不相契合, 而且在处理“不确定性”时显得极为乏力。

3)存在一种分析方法, 名为面向对象分析方法, 也就是 OOA, 这正是我下文打算讲述的那种分析方法、。

4)面向问题域的分析, 也就是PDOA, OOA存在诸多不足, 而PDOA因正处于研究阶段所以未被广泛应用。这里要注意, 软件开发中有诸多需求分析方法, 它们不存在好坏之分, 只要运用得当, 一样能够做出很好的系统, 依据个人对某个方法的理解, 选用自己最擅长的方法是最为明智的选择。

5.面向对象需求分析（OOA）

需求分析提示词_软件需求分析_非功能需求定义

关于面向对象这个概念, 它虽简单, 却又复杂, 我在此处不会进行深入探讨。我会从实际情况出发, 与大家一道探讨一下, 于实际开发当中, 我们应当如何去做。

OOA的关键要义在于, 世间的所有事物皆为对象, 运用OOA方法, 在整个流程当中, 涵盖两个工作任务: 构建一个能够反映问题域静态关联的概念模型, 也就是我们平常所说的类图；还有另一个能够反映系统行为的动态模型, 即使用例模型, 那么我们在实际的开发过程当中究竟要如何去做呢？

1）建立域模型

针对寻找类而言, 其存在着不止一类寻觅方式, 有一类较为典型的, 是依据需求文档, 借鉴“名词动词法”去寻觅, 在找出备选类之后, 再从这些当中觅得真正的类。（留意运用此方法之际, 务必谨记, 不要在字句上过度计较、钻牛角尖, 于此耗费过多时间）

先对于类之间关联作出确定: 有一个过程, 它是迭代的, 这一过程里, 我们得清晰理一理这些类各自之间到底存在怎样关系, 诸如关联，还有继承, 以及聚合等等, 之后借助UML将其记录下来。类之间的关系可不是一下子就能够确定下来的呀, 是需要逐步给慢慢完善起来的, 为类增添职责: 在这儿就能够理解成是给类增添所需的属性以及方法。

关于域模型所具备的详细度, 在此处并没有过多的要求来限定书写方式, 是能够写得极为详细的, 同样也能够写得相对简单, 不过需要把控好这样一个原则, 即只要是能够对团队在进行更好的开发方面有所助力的, 那便是好的模型。

2）建立用例模型

什么是用例：

于系统里执行起的一系列动作, 会是用例实例, 这些动作能够产生出对特定参与者而言可见的价值结果, 但值得注意的是常被提及的“使用场景”指的便是用例实例，并且一个用例所定义的乃是一组用例实例, 这没错。

识别参与者：

为了能让客户直观去理解需求, 所以用例是主要的, 那么在此处参与者是绝对不能少的, 因而才能够去形象地勾画出系统在某个特定场景之下的流程。

需留意, 参与的人并非唯一, 其他事物同样能够参与, 像其他系统, 像硬件设备, 像时钟等, 皆是可以参与的事物。

合并需求获得的用例

绘制用例图（如果对用例图不清楚请参考UML相关文章）

细化用例描述

用例描述可以包括以下几个部分：

用例名称