如何做好软件需求分析？_csdn异性匿名配对软件需求分析

最新推荐文章于 2024-06-25 15:48:43 发布

2401_84265634

最新推荐文章于 2024-06-25 15:48:43 发布

阅读量608

点赞数 10

分类专栏：程序员文章标签：需求分析数据挖掘人工智能

本文链接：https://blog.csdn.net/2401_84265634/article/details/137729119

版权

程序员专栏收录该内容

17 篇文章 0 订阅

订阅专栏

具体分为功能性需求、非功能性需求与设计约束三个方面：

1. 功能性需求

功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。

功能性需求是软件需求的主体，开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。

2. 非功能性需求

作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。

主要包括软件使用时对性能方面的要求、运行环境要求，软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。

3. 设计约束

一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。

例如：要求待开发软件必须使用Oracle数据库系统完成数据管理功能，运行时必须基于Linux环境等。

五、软件需求分析过程

需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。

1. 问题识别

就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。

这些需求包括：功能需求（做什么）、性能需求（要达到什么指标）、环境需求（如机型、操作系统等）、可靠性需求（不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求（软件运行是所需的内存、CPU等）、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。

2. 分析与综合

逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。

最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型（做什么的模型）。

3. 制订规格说明书

即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。

4. 评审

对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作，否则重新进行需求分析。

六、软件需求评估方法

需求评估分析方法通常有：模糊聚类分析、质量功能展开、KANO模型分析、A/B测试。其中以卡诺（KANO）模型最常用。

1. 聚类分析法

聚类分析指将物理或抽象对象的集合分组为由类似的对象组成的多个类的分析过程。它是一种重要的人类行为。

聚类是将数据分类到不同的类或者簇这样的一个过程，所以同一个簇中的对象有很大的相似性，而不同簇间的对象有很大的相异性。

在聚类分析的时候，要根据变量的性质选择聚类模型。如果关键属性是使用问卷收集的分类变量，一般选择两步聚类法，因为用户的人口学特征和使用某产品行为偏好等特征一般都是分类变量。检验聚类变量差异性：如下

2. 质量功能展开

是指把用户对产品的需求进行多层次的演绎分析，转化为产品的设计需求、工程部件特征、工艺要求、生产要求，用来指导产品设计并保证产品的质量，是一种以用户为导向的质量管理工具。

由于该方法所使用的主要图形就像房屋，所以它也被称为“质量屋”，如下图：

3.卡诺KANO 模型

是 Noriaki Kano 博士提出的与产品性能有关的用户满意度模型，该模型能对用户需求进行很好的识别和分类，是对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

Noriaki Kano 将影响满意度的因素划分为五个类型，包括：必备需求、期望需求、魅力需求、无差异需求、反向需求。

兴奋（魅力）需求：用户意想不到的，如果不提供次需求，用户满意度不会降低，但是提供次需求，用户满意度会有很大的提升；
期望（意愿）需求：当提供此需求，用户满意度会提升，当不提供此需求，用户满意度会降低；
基本（必备）需求：当优化此需求，用户满意度不会提升，当不提供此需求，用户满意度会大幅下降；
无差异需求：无论提供或者不提供此需求，用户满意度都不会有变化，而且根本不会在意；
反向（逆向）需求：用户根本没有这个需求，提供之后用户满意度反而会下降。

利用KANO模型进行需求评估主要集中于对用户需求类型的分类讨论。为了便于分析可以设计相应的调研问卷。

问卷中需要对产品的某项功能分别设置正向和负向两个问题：“如果产品有这个功能，您觉得如何？” 、“如果产品的这个功能不存在，您觉得如何？”

每个问题采用态度量表的形式设计选项，即“我喜欢这样”、“我期望这样”、“我没有意见”、“我可以忍受”、“我讨厌这样”，具体形式如下表：

经过访谈调研后，根据归类矩阵，将调研问题进行归类来确定需求的类型，KANO模型需求归类矩形如下表：

将问题结果术语模型矩阵中，就能够比较明确地看到，哪些用户需求是必须有的，哪些是用户期望的，哪些是可有可无的，哪些需求又是用户自己不确定的。

将用户需求进行分类，在产品开发时，功能优先级的排序一般是：基本属性>期望属性>兴奋属性>无差异属性，去掉可疑结果的需求和相反的需求。

4. A/B测试

是为Web或App界面或流程制作两个或多个版本，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本并且实现的综合成本低，正式采用。

比较常见的案例是对网站注册页进行A/B测试，确定哪一个方案的注册率高，更加满足用户的需求，实现的商业利益最大化。

需要注意在进行A/B测试时，每次必须只测量一个变量，多个变量测试，则无法判断是哪个变量导致的结果；测试的环境应当一直，例如测量时间应一致。

因为在不同的时间段，用户的访问量会有变动；测量的样本量要具有统计学意义，样本流量太小时，无法体现在线用户的真实行为。

七、需求分析优先级的方法

需求优先级的分析方法大致可以分成两大类：定性分析方法、定量分析方法；

一类是根据分析人员的经验主观地对需求进行优先级分类，称之为定性的分析方法，比如：四象限分析法、波士顿矩阵分析法；另一类是根据调查数据，对调查数据进行分析，得出需求的优先级分类，称之为定量的分析方法，比如：KANO模型。

1. 四象限分析法

根据需求对于业务的影响，以及需求实现的紧迫程度，我们可以按照如下方式将需求归为4个象限，这也是需求归类的经典4分法。四象限分析法是很常见的一种定性分析需求优先级的方法，如下：

重要且紧急的事，影响业务正常进行，需要尽快处理；
不重要但紧急的事，虽然对业务影响不大，但是需要尽快处理；
重要且不紧急的事，对业务影响大，但不需要短期内就完成；
不紧急且不重要的，对业务影响不大，也不需要短期内完成。

2. 波士顿矩阵

波斯顿矩阵是由波士顿咨询公司发明的一种方法，最早用于分析市场增长率和市场份额，现在也被经常用于对需求的分析之中，波士顿矩阵由用户价值维度和公司价值两个维度将需求分成了四个象限：

明星需求：对用户体验有价值，对公司战略也有价值的需求。明星需求是双赢的需求，需要优先得到满足，如一些促进用户活跃、转化的需求，具体的有，活跃度排名、优惠提醒等功能；
问题需求：对用户体验有价值，但对公司战略和目标没价值的需求。此类需求虽然看似对公司没直接价值，但是提升用户体验有助于提升用户的忠诚度，如一些提升用户体验的需求。具体的有，提供多种快捷登陆方式、提供辅助输入功能等；
金牛需求：对用户体验没价值甚至会对用户造成困扰，但是对公司战略有价值的需求。公司价值的体现，此类需求应该尽量考虑避免对用户造成影响。如一些运营需求等。具体的有，收集用户信息等；
瘦狗需求：对用户体验无价值，对公司战略也无价值的需求。此类需求应该过滤掉，例如一些伪需求。

3. 卡诺KANO 模型法

Noriaki Kano 将影响满意度的因素划分为五个类型，包括：必备需求、期望需求、魅力需求、无差异需求、反向需求（详情见上文）。

八、如何确定软件需求

经过大量的需求调研工作之后，手上可能有客户提出的大量的、各种各样的需求。

这些需求有的是技术上可以实现的，有的是技术上不可以实现的；有些是管理上需要的，有的是管理上不需要的；有些是合理的，有些是不合理的，如何处理这些需求呢？

以“实现用户正确的需求”为原则，对于用户提出的需求进行严格的分析、甄别。

为了认清用户的需求，先要认清用户。在进行需求调研的时候，会跟各种各样的人员沟通，他们的技术、只是、性格、职位、工作内容各不相同。

但他们也有相似的地方：他们不是做软件的，也不是分析需求的，他们永远不会像你希望的那样去描述需求，他们的需求是用自然语言描述的，是抽象的、概略的、随性的。

那个这些抽象、概略、随性的用户需求转化成具体、详细、结构化的软件需求，是需求分析的重点，通常从以下几点着手认清和控制需求：

1. 将抽象的需求具体化

在需求调研的时候会发现，用户提出自己的需求时总是不会按照你希望方式去提出来，有的人因为不知道你想要什么，只为了应付领导布置的任务，有的是处于比较高的职位，习惯了从宏观的角度去讲问题，所以我们在整理需求的时候要将抽象的要求具体化。

2. 将自然语言描述的需求结构化

用户描述需求总是非常随意的，他们使用平常正常沟通的语言描述，这种需求的主要特点就是不严谨，容易有其一，这种需求不能直接让开发者处理的，开发者需要的需求是描述明确的、精准的、没有歧义的。

需求分析分析者作为用户与开发者的桥梁，有义务将用户用自然语言描述的需求结构化。将用户的描述转换成更精确的语言，更接近IT人使用的语言。

3. 注意避免理解偏差

理解偏差主要是需求分析者对用户所提的需求没有理解到位，用户明明想表达的是这个意思，却被理解成了另外一个意思。

这是一个沟通问题，说的人觉得自己说的很清楚了，可偏偏双方就是没有真正理解对方，所以下面是我们需要注意的：

提高沟通能力：多从对方的立场考虑问题，当双方描述某件事时，要从对方的角度思考这些描述；
提高沟通频次：一方面要引导对方多说话，另一方面对不理解的或者觉得理解起来有困难的内容，多向对方询问，换成你的表达方式让对方确认是不是这个意思；
学习对方领域的知识：用户有自己的知识领域，需求分析者也有自己的知识领域，前者满脑子是业务术语，后者满脑子是IT术语，有的时候两者真难沟通。每个人的知识面不同，要想沟通顺畅，两个人的知识面重叠的地方越多越好。