概述

作者认为这套需求过程可以适用于多种软件开发的情况。
这套需求过程虽然不是唯一的解决方案,但学习这个过程可以获得很多帮助。
有很多客户采用了这个需求过程。
这些客户和他们都达成一个共识:发现需求需要一个有序的过程。

项目启动、网罗知识、制作原型、编写需求、需求审核、需求复查、产品设计构建、产品使用与演进

需求发现是所有构建活动先驱,应该非常重视。
作者假设我们在开发一个新产品,用这个新产品来介绍这个过程。以此避免旧项目的限制。

作者介绍了一个破冰项目,它的目标是在道路结冰之前,调度车辆进行撒盐,这样会使得道路更安全。另外如果撒盐合适的话,可以减少预算和对环境的影响。

项目完成需要大量的准备工作。
作者先从启动会介绍需求分析工作。

作者认为启动会需要凑齐一下利益相关人:
要买的人、要用的人、设计系统的人、实现系统的人、可以咨询的人
并让他们对关键问题达成一致看法。

作者认为会议要确定:
系统要做什么,以及系统不做什么。

作者提出用白板画业务模型图。
业务模型图包含两个部分,一个部分展示系统所包含的功能,另一部分展示与系统相联系的其他系统。

画好这个图后,需要确定利益相关人。
需求分析师跟这些利益相关人合作,找到所有的需求。

作者认为项目启动会议需要达成共识:
1.能不能赚钱?
2.能赚多少钱?
3.能否做成?

为了达成这些共识,会议需要对项目成本进行评估,并提出可能存在的风险。

另外作者认为早死早超生,宁可几个人决定什么都不做,也不要组织更多的人,把大家的时间和感情浪费在没有希望的项目上。

如果还有很多事情不确定,就带着问题去调研,等调研后再评估。

需求分析师在会后要确定业务内容,为了方便,作者建议将业务模型图拆分成一些业务用例。

作者提出:业务用例是响应一个“业务事件”所必需的功能。

作者认为业务事件可以独立分配给不同的需求分析师。分析师可以通过做学徒、场景分析、用例研讨会等方法来发现工作的本质。分析师可以与其他利益相关者交流,获得最终产品的其他需求。

作者认为需求工作中最难的是发现系统的实质。别人提的解决方案或者当前工作的需要都不是问题的实质。可以通过想象没有技术下的工作来发现系统的实质。

了解到工作的实质后,再与利益相关者合作,决定最佳的产品。
1.他们需要确定对工作中的哪些部分进行自动化或者改变?
2.这些决定会对工作产生什么影响?

作者认为理想的需求过程:
工作范围图->业务用例->用户故事->PUC场景->需求

最好的产品并不是对原有情况的模仿,而是要与利益相关者间隙合作,找到更好的完成工作的方式。

作者提议使用贴纸进行当前业务的建模,用纸笔进行对将来产品的建模。

作则认为需求场景非常有用,可以在短时间内,让每个人理解工作要做什么,并达成一致意见。在他们达成一致之后,场景就成为需求的基础。

为了避免需求被误解,需求必须用一种无二义、可测试的方式写下来,同时通过利益相关者的审核,然后再传递给开发者。写下需求可能是繁重的负担,但是这对于需求沟通以及产品交付都很重要。

作者认为需求需要包含三个部分:
1.需求内容
2.需求理由
3.需求的验收标准

作者提到两种机制来编写需求:
1.需求规格说明模板,需求规格的一个提纲(问题模板)
2.需求项框架,需求有一些属性组成(单个问题的属性)

迭代式的工作并不排斥需求,而是寻求另一种方式来发现和沟通。

待续->2.8质量关

推荐阅读更多精彩内容

  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 161,636评论 24 692
  • 赵楠打电话过来的时候许南正抱着萧琰的衣服看他化妆。 “忙完了?” “哦,好吧,我在忙,回头说。” 帮萧琰理了理领带...
    许南方阅读 173评论 2 1
  • 关灯之后,经历了几回合的翻来覆去瓜终于快要睡着了,忽然梦游般坐起, 瓜:妈妈,教室里不能跑来跑去的。 我:是啊,我...
    小点儿清阅读 71评论 0 0
  • 我认为 爱国首先要发自内心, 其次是表现在语言中, 最后落实在行动上。 我们不能空谈爱国, 也不能激进地爱国, 从...
    乐陵君阅读 215评论 0 2
  • 大概身体疲惫不堪就没有时间去思考人生了 进入社会才能感悟社会
    崔简舒阅读 48评论 0 0