《构建之法》学习（8）——需求分析

《构建之法》学习（8）——需求分析

 

1.软件需求

 

1.1如何准确而全面地找到需求

 

　　获取和引导需求

　　软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求

　　需求还可以来自各种管理机构

　　需求不仅来自外界，还可以来自软件企业本身

　　需求还可以来自技术团队本身

　　有些需求的目的是要“更好地了解用户的行为和需求”

　　分析和定义需求

　　验证需求

　　在软件产品的生命周期中管理需求

 

1.2软件需求的划分

 

　　对产品功能性的需求

　　对产品开发过程的需求

　　非功能性需求

　　综合需求

 

2.软件产品的利益相关者

 

　　用户

　　顾客

　　市场分析师

　　监管机构

　　软件工程师

 

　　软件开发不可能一次满足所有利益相关者的要求，但是我们一定要让相关角色在这个阶段有机会提出他们的需求和意见，同时，要弄清楚“他们想从软件中得到什么”。

 

3.获取用户需求：用户调查

 

　　焦点小组

　　讨论者对于他们不熟悉的食物不能表达有价值的想法

　　讨论者容易受到主持人有意或无意的影响

　　研究者往往从不同意见中挑选最符合自己利益的那些条目，然后对外号称这就是大家的共识

 

　　深入面谈

　　请用户来完成一些任务，然后软件项目成员可以在一旁观察，也可以隐蔽在单向玻璃后边，或通过录像观察

 

　　卡片分类

　　讨论→明晰定义→归类→排序

 

　　用户调查问卷

　　常见错误：

　　　　问题定义不明确

　　　　使用含糊不清的形容词、副词描述时间、数量、频率、价格等

　　　　让用户花额外的努力来回答问题

　　　　问题带有引导性的倾向

　　　　问题设计用户隐私、用户所在公司的商业机密或细节等

　　问题方式：

　　　　全开放式问题

　　　　二项选择题

　　　　多项选择题

　　　　顺位选择题

 

　　用户日志研究

　　这一调研方式要求用户记录自己日常工作或生活中与所用软件相关的行为，供软件团队分析

　　

　　人类学调查

　　和目标用户“同吃同住同劳动”

 

　　眼动跟踪研究

　　用户通常浏览通栏标题，然后目光沿着左侧下行，再平行浏览下面的子标题

 

　　快速原型调研

　　拿一些纸张模型，让用户去使用，得到反馈

 

　　A/B测试

　　决定试验哪两种不同的UI，以及衡量标准、数据收集流程、试验运行时间、人数

　　在技术上实现A/B测试

　　收集数据，分析数据，形成结论。

　　弱点：用户的情绪反应你看不到，你只看到交互的行为，但是交互的行为不是用户的全部反馈

 

4．竞争性需求分析的框架

 

　　N（Need，需求）

　　解决了用户的什么需求

　　A（Approach，做法）

　　有什么独特的招数

　　B（Benefit，好处）

　　产品/服务会给客户/用户带来什么好处，以及要花费多少精力、时间、金钱才能得到产品的好处

　　C（Competitors，竞争）

　　这个市场有多大，有多少竞争者

　　D（Delivery，推广）

　　怎样把创新产品交到用户的手中

 

5.功能的定位和优先级

 

　　杀手功能

　　外围功能

　　必要需求

　　辅助需求

 

6.计划和估计

 

　　探询数值背后的假设，这是作为项目经理最重要的能力

　　最后得到的估计数值，也许和某人最初提出的数值很接近，但是这意义并不大，因为最后达成的假设也许和最初的假设大相径庭

　　既然这是一个长期项目，那不可避免地有人员的投入和变动问题。

　　可以参考前人的经验，快速原型法：用一两个先锋去探路。

 

转载于:https://www.cnblogs.com/Yan1970/p/6938122.html