首页 > 代码库 > 构建之法——读书笔记(6)

构建之法——读书笔记(6)

第8章 需求分析

8.1 软件需求

 

寻找需求:

1. 获取和引导需求(Elicitation)

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

 

2. 分析和定义需求(Analysis&Specification)

         这是指对从各个方面获取的需求进行规整,定义需求的内涵,从各个角度将需求量化(需求实现的最后期限,实现需求大致所需的时间和资源成本,各个不同需求的优先级,需求带来的收益,等等)。

 

3. 验证需求(Validation)

         软件团队要跟利益相关者沟通,通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。

 

4. 在软件产品的生命周期中管理需求(Management)

         在软件的生命周期中,需求在发送变化,技术在发展,团队成员的能力在提高。

 

对软件需求的划分:

1. 对产品功能性的需求:要求产品必须实现某些功能。

 

2. 对产品开发过程的需求:要求软件的开发流程必须满足某些约束条件,例如,开发过程必须产生某种类型的文档,必须在某个时间点达到某个状态,必须对源代码施以某种约束(安全性检查、代码版权核查、代码规范和支持文档的核查)。

 

3. 非功能性需求:例如:执行时间限制等。

 

4. 综合需求:可能牵涉到其他系统的情况。

 

 

 

8.2 软件产品的利益相关者

用户:

顾客:购买这个软件或者根据合同或规定接收软件的人。这些人不一定是软件的直接用户。

市场分析师:市场部门要代表“典型用户”的需求。

监管机构:

软件工程师:工程师也是软件需求阶段的一个重要角色,软件的各种约束、特性会影响到他们的工作效率、开发难度和软件维护的难度。他们应积极参与到软件需求阶段中来。

8.3 获取用户需求——用户调查

         用户最需要的>

                   用户表达出来的>

                            软件团队能理解的+团队的商业目的>

                                     软件团队成员具体表达出来的(PM写Spec)>

                                               在各种约束条件下,具体执行表达出来的(Dev写代码)>

                                                        验证通过的(Test)>

                                                                 通过各种渠道告诉用户目标(发布/推广)>

                                                                           用户终于能用上了,但是他们不满意

1. 焦点小组(Focus Group)

2. 深入面谈(In-depthInterview)

         一般是一对一。

3. 卡片分类(Card Sorting)

         讨论->明晰定义->归类->排序

4. 用户调查问卷(User Survey)

5. 用户日志研究(User Diary Study)

6. 人类学调查(Ethnographic Study)

         这种方法听起来学术味很浓,其实可以解释为——和目标用户“同吃同住同劳动”。

7. 眼动跟踪研究(Eye Tracking)

         一些研究发现了F模式。

8. 快速原型调研(Quick Prototype)

9. A/B测试(A/B Testing)

 

 

8.4 竞争性需求分析的框架

大部分普通用户的需求都有好几个互相竞争的机构在提供服务,对于互联网类型的软件来说,更是如此。很多需求并不是用户提出来的,而是技术的突破让产品团队看到了可以让用户做到以前不敢想、不敢做的事情——但这个时候大多数用户并没有意识到自己有这个具体需求。

1. N(Need,需求)

2. A(Approach,做法)

3. B(Benefit,好处)

4. C(Competition,竞争)

5. D(Delivery,推广)

 

8.5 功能的定位和优先级

技术分享

8.6 计划和估计

8.6.1 估计的练习

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

8.7 分而治之(Work Breakdown Structure)


做好WBS的几个要点:

         1.保证所有子节点覆盖了全部父节点包含的内容。

         2.保证各个子节点不要相互覆盖。

         3.叶子节点要保证足够小,能在一个里程碑中完成。

         4.从结果(Outcome)出发构建WBS,而不是从团队的活动(Action)出发

 

构建之法——读书笔记(6)