《构建之法》学习(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.计划和估计

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

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

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

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

时间: 2024-09-28 02:05:11

《构建之法》学习(8)——需求分析的相关文章

构建之法学习总结(1)

构建之法学习总结(1) 从刚开始的自主学习过程再到暑期的开发实践,粗略一算也有一个学期多了,这段时间内收益匪浅.<现代软件工程>这门软件开发的基础课程,说实话这类概念型教材是很枯燥的,但邹老师编写的这本<构建之法>一书给读者带来了更多趣味性,简单易懂,是一本很好的软件工程书. 这本教材对于初学者来说是非常适合的,易懂且涉及全面,软件开发所涉及的方面和方法都有包括在内. 第一章 概论,讲述了软件工程的相关基础概念,为大家解答了软件以及软件工程到底是什么:软件工程和计算机科学的关系:源

构建之法学习(第一章 概论)

初读邹欣老师的<构建之法>,却发现并没有像其它大多数软件工程教材一样偏重理论知识,而是大量引用实例,将实践与理论相结合,一改原本的空洞.乏味,反而更多的是趣味性. 通过对于第一章的自我学习,总结了一些知识点: 1.软件=程序+软件工程 程序=数据结构+算法    程序,就是指的源程序,是可执行代码.软件构建,构建成机器能懂的可执行代码,要有合理的软件架构,软件设计与实现,还要有各种文件和数据来描述各个程序文件之间的依赖关系,编译参数,链接参数等等. 软件工程是把系统的.有序的.可量化的方法应用

构建之法学习回顾(二)

学习完构建之法五到八章之后,发现这本书更加贴近于当代,一般的软工教材为了追求更广更久的接受度,在内容上会趋于保守,而这本书不同,许多生硬的知识都得到了新的活力. 在第五章的学习中,主要讲了典型的软件团队模式和开发流程.以及我们也将讨论团队模式和开发效率之间的一些关系. 团队有一致的集体目标,团队要一起完成这个目标.一个团队的成员不一定要同时工作.团队成员有各自的分工,互相依赖合作,共同完成任务.只有我们当做一个团队一样进行工作和学习才能取得更大的成就. 第六章的学习中讲了敏捷流程及其原则,Bac

构建之法学习(5)

本周学习的是构建之法第五章 团队和流程 团队有共同的特点:1. 团队有一致的集体目标,团队要一起完成这目标.一个团队的成员不一定要同时工作,例如接力赛跑.(王屋村搬砖的"非团队"成员则不然,每个人想搬多少就搬多少,不想干了就结算工钱走人.)2. 团队成员有各自的分工,互相依赖合作,共同完成任务.(王屋村搬砖的"非团队"成员则是各自行动,独立把任务完成,有人不辞而别,对其他的搬砖人无实质影响.)

构建之法学习总结

在学习完构建之法这本书后我收获颇丰,构建之法与其他市面上编程教材最大的不同之处在于这本书没有大段枯燥无味的代码,作者别出心裁地用一个个小故事来启发读者,语言也不失风趣幽默.读完这本书后,我有许多感想,心得与疑问.今后的软件开发维护等大多都是团队合作,有良好的编程风格十分重要,良好的编程风格不仅能为团队中其他成员阅读代码时带来便利,也能极大程度地提升效率,减少错误的发生.今后的软件开发不再是自己写代码来满足自己的兴趣爱好而是要最大程度地满足客户的需求.创新对于一名程序员来说是十分重要的.对于他人的

构建之法 学习笔记01

起初我只是在专业要求的硬性规定下去接触了这本<构建之法>,然后仔细的看下来之后确实让我受益匪浅,让我更切实的了解了这个行业.这本书对我来书最实用的地方在于,在高大上的理论之后会有具体的实例来帮助理解.在介绍方法论的同时,会介绍方法论不适用的场景,介绍方法论在现实中是怎样跑偏--什么叫宏观视角?什么叫最佳实践?什么叫算无遗策?就像画一棵决策树,向哪个分支走,结果会怎么样,清清楚楚,明明白白,让人信服.能让学生了解到工作中接触的种种角色及其想法.诉求,避免"以程序为中心"思考问

构建之法学习(2)

本周学习的内容是第二章 个人技术和流程 2.1单元测试 你的RP是由你的程序质量决定的.软件是由多人合作完成的,不同人员的工作相互有依赖关系.例如,一个人写的模块被其他人写的模块调用.软件的很多错误都来源于程序员对模块功能的误解.疏忽或不了解模块的变化.如何能让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的.量化的保证?单元测试就是一个很有效的解决方案. namespace DemoUser{    public class User    {    

《构建之法》MSF&amp;需求分析

第七章 MSF MSF基本原则 推动信息共享与沟通 为共同的远景而工作 充分授权和信任 各司其职,对项目共同负责 交付增量的价值 保持敏捷,预期和适应变化 投资质量 学习所有的经验 与顾客合作 MSF团队模型 MSF团队模型定义了小组同级成员的一些角色和职责,在MSF团队模型中,任何技术项目都必须达到特定的关键质量目标,才能够被认为是成功的项目.任何一个角色无法实现其目标,都将危及整个项目.因此,每个角色都被认为是同等重要的,重要的决定都要共同做出.一个项目要达到的目标很多,MSF团队模型让不同

构建之法学习回顾(一)

在学习完构建之法一到四章之后,作为软件工程专业的一名在校生,有了一些全新的认识,作者把软件工程开发的方法和案例讲的清晰有趣而又实用,我们的思维水平也升级了不少. 在第一章的学习中,难免一切事物都要从简单的介绍开始,其中一个让人耳目一新的论点是程序=数据结构+算法. 程序就是一行一行的源代码,他们是建立在数据结构的一些算法.在这些数据之中,我们要构建让他们变成可执行的代码.构建需要一个合理的软件架构,软件的设计和实现,还需要各种文件和数据来描述各个程序文件之间的依赖关系,编译参数,链接参数,这些是

构建之法学习(第七章 MSF)

第七章 MSF MSF(Microsoft Solution Framework)微软解决方案框架: MSF是一套大型系统开发指南,是微软推荐的软件开发方法,它描述了如何用组队模型.过程模型和应用模型来开发Client/Server结构的应用程序,是在微软的工具和技术的基础上建立并开发分布式企业系统应用的参考. 一.MSF 9条基本原则 1.推动信息共享与沟通 --把所有信息都保留并公开,讨论要包括所有涉及的角色,决定要公开并告知所有人. 当然,对牵涉到技术机密.安全性等信息要采取必要的保护措施