《构建之法》第八章自习感想与知识点

第八章主要讲述的是需求分析一些相关内容及注意要点。看似简单其实注意的细节还是有很多的,首先是引导和获取需求,然后再是分析和定义需求,之后还要验证需求和在软件生命周期中管理需求。这一系列的事项仔细研究起来都是一门学问。以下为本周的一些知识要点:
一.软件需求

1.准确而全面的找到需求的方法:获取和引导需求,分析和定义需求,验证需求,在软件产品的生命周期中管理需求。

2.软件需求从不同角度的划分:对产品功能性需求,对产品开发过程的需求,非功能性需求,综合需求。

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

利益相关者包括:用户,顾客(客户),市场分析师,监管机构,软件工程师。

三.获取用户需求--用户调查
常见的调研方法:焦点小组,深入面谈,卡片分类,用户问卷调查,用户日志研究,人类学调查,眼动跟踪研究,快速原型调研,A/B测试。

四.竞争性需求分析框架

NABCD模型:
N(Need,需求)
A(Approach,做法)
B(Benefit,好处)
C(Competitors,竞争)
D(Delivery,推广)

五.功能的定位和优先级

功能分析的四个象限:杀手功能,外围功能,必要需求,辅助需求

六.计划和估计
分清目标,估计和决心

时间: 2024-10-05 08:46:01

《构建之法》第八章自习感想与知识点的相关文章

构建之法第八章学习心得

今天,我学习了构建之法第八章软件需求,人们为了解决现实社会和生活中的各种问题,要求助于软件.人们的需求五花八门,那么软件团队如何才能准确而全面地找到这些需求呢? 需求分析1.获取和引导需求 软件团队需要找到 软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求. 不同的项目需要不同的手段,这一步骤也被叫做"需求捕捉",形容真正的需求稍纵即逝,需要靠火眼金睛和敏捷的身手来发现并抓住它们.另外,很多时候用户并不知道自己确切的需求,或者不愿意表达完整的需求,软件团队需要设

《构建之法》第六章自习感想与知识点

本章的学习主要讲的是敏捷流程.敏捷流程从字面上来看敏捷就是快速的,同时透露出一种年轻化的感觉的流程.但在深入的学习了之后才发现要快速的完成有价值的软件并交付给客户是有很大的学问在里面的.同时,也不是所有的情况都适合这样的流程的,需要综合各项因素来决定.以下是本章的一些知识点: 敏捷流程的定义:是一系列价值观和方法论的集合 敏捷开发的原则:1. 尽早并持续地交付有价值的软件以满足顾客需求2. 敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势3. 经常发布可用的软件,发布间隔可以从几周到几

《构建之法》第四章自习感想与知识点

本章讲的是两人合作.其实在我过往的经历当中也有过合作,比如大一时候的短学期大作业.每个人的代码风格都是不一样的,有的人的代码写的非常有个性,以至于其他人读起来都非常的废力.在一个中大型的项目里,自己改起来也是非常的麻烦.这种时候,代码的规范性就非常的重要了.规范的代码看过去就是清清楚楚的,是什么就是什么,不会产生疑惑,也不会有原作者不在其他人就无法对其参考修改的情况.以后的大工程都是要至少两个人合作才能完成的,不能再随心所欲了.在以前编写代码的过程中我也是往往不注意注释以及清晰的变量名的重要性,

《构建之法》第七章自习感想与知识点

本周的学习当中,我第一次接触到了MSF这个概念,它是微软所推荐的做软件的一种方法.它有9条基本原则,每条原则环环相扣,规划合理,并且并非一成不变,会随着学习而完善,所以可以适用于很多场景.沟通也是这个方法的一个重点,与团队沟通,与客户沟通.这样一个方法很显然也是要依赖于一个强劲的团队的.以下是本周的一些知识点: 一.MSF基本原则 1)推动信息共享与沟通 所有信息都保留并公开,讨论要包括所有涉及的角色,决定要公开并告知所有人.当然,对牵涉到技术机密.安全性等信息要采取必要的把握措施. 2)为共同

《构建之法》1-2章感想

提示:(下面的总结我会按照每章发现的问题,自己的回答,感想来陈述) 1章. 在1.1节中我从阿超给儿子写了个程序到越来越复杂的功能扩展到应用软件的过程中,觉得这本书挺有趣的,但是有一个疑问!我们知道软件=程序+软件工程,那么就阿超这个逐渐完善的程序来说,是什么时候开始,程序就变成应用软件的? 回答:我通过在课堂上问杜老师,我的理解是,当程序功能做大的时候,我们要用到软件工程的方法的解决,要按照(软件需求分析,设计,实现,测试等)来做,那么我们就可以把所做的程序叫做软件. 1章. 1.1.2在说飞

构建之法第六周感想 需求分析

这周我学习的是需求分析.软件团队通过以下几个步骤找到软件需求:获取和引导需求:分析和定义需求:验证需求:在软件产品的生命周期中管理需求.而软件的需求也分为几类:对产品功能性的需求,对产品开发过程的需求,非功能性需求,综合需求.软件产品的利益相关者有用户.顾客.市场分析者.监管机构.系统.软件团队.获取用户需求即用户调研,用户调研可以通过焦点小组方法,找到一群目标用户的代表加上项目的利益相关者来讨论用户想要什么.:深入面谈,通过详细的面谈,广泛而深入地了解用户背景.心理.需求等,效果取决于主持面谈

构建之法第八周感想 典型用户和场景

在产品的开发过程中,经常需要描述一组典型的用户.典型用户不再是一个抽象的概念,而应该是一个活生生的人物.一个典型用户往往描述了一组用户的典型技巧.能力.需要.想法.工作习惯和工作环境.典型用户的模板可以包括名字.年龄和收入.典型场景.工作情况.定义完典型用户后,不能开始写程序,因为典型用户只是设想,我们还要和典型用户的代表交流,理解用户,理解他们的工作方式和需要,然后再修改,细化典型用户.当完善了典型用户的定义后,就要进入创立场景阶段,创立场景就是我们深入理解用户需求的过程.对于每一个目标,列出

构建之法 第八章 需求分析

其实这是"啃硬骨头"的第一步,就是如何从"茫茫"中锁定需求相关方.挖出来需求的方法论 1.挖取需求 获取和引导需求.需求不仅是来自外界,甚至也可以来自技术成员团队内部: 分析和定义需求.主要是对需求进行量化: 验证需求. 在软件产品的生命周期中管理需求 需求不一定只在初期才有:在中后期的时候可能因为外界环境变化甚至是成员自身水平变化而出现新的需求 2.软件产品的利益相关者 最终用户(使用软件的人) 顾客(购买软件的人) 监管部门 3.获取用户需求的方法 焦点小组(f

构建之法 第八章 需求分析 读书笔记

软件需求: 1.获取和引导需求 2.分析和定义需求 3.验证需求 4.在软件产品的生命周期中管理需求 也可以从以下不同角度划分 1.对产品功能性的需求 2.对产品开发过程的需求 3.非功能性需求 4.综合需求 获取用户需求——用户调查 1.焦点小组 2.深入面谈 3.卡片分类 4.用户调查问卷 5.用户日志研究 6.人类学调查 7.眼动跟踪研究 8.快速原型调研 9.A/B测试