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

这周我学习的是需求分析。软件团队通过以下几个步骤找到软件需求:获取和引导需求;分析和定义需求;验证需求;在软件产品的生命周期中管理需求。而软件的需求也分为几类:对产品功能性的需求,对产品开发过程的需求,非功能性需求,综合需求。软件产品的利益相关者有用户、顾客、市场分析者、监管机构、系统、软件团队。获取用户需求即用户调研,用户调研可以通过焦点小组方法,找到一群目标用户的代表加上项目的利益相关者来讨论用户想要什么。;深入面谈,通过详细的面谈,广泛而深入地了解用户背景、心理、需求等,效果取决于主持面谈的团队成员的能力;卡片分类,把各种需求做成便于规整的小卡片,然后反复进行讨论、明晰定义、归类、排序;用户调查问卷,向用户提供实现设计好的问题,让用户回答。;用户日志研究,用户记录自己日常工作或生活中与所用软件相关的行为,供软件团队分析;人类学调查;快速原型调研。做软件项目需要有目标、估计、决心;目标是表明一个希望达到的状态,估计是以当前了解的情况和掌握的资源,要花费多少人力物力时间才能实现某事;决心是保证在某个时间之前完成预先规定的功能和质量。

时间: 2024-08-07 23:02:10

构建之法第六周感想 需求分析的相关文章

构建之法第五周感想 敏捷流程和MSF

这周我学习的是敏捷流程和MSF的知识.敏捷流程是一系列价值观和方法论的集合.敏捷开发的原则是:1.尽早并持续交付有价值的软件以满足顾客的需求2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势.敏捷流程的步骤是:第一步,找出完成产品需要做的事:第二步,决定当前的冲刺需要做的事情:第三部,冲刺:第四部,得到软件的一个增量版本:第四步,放松一下,总结上一次的经验教训,争取下一次做的更好.所以敏捷流程的经验教训是:敏捷宣言表明的是一些优先级,不必当作教条来争论:在复杂的项目里,要让一线团队成

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

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

构建之法第六章学习心得

这周我学习了构建之法第六章敏捷流程,本章主要介绍了敏捷流程及其原则,Backlog.Burn-down.Sprint.Scrum方法论.以及什么时候选择敏捷的开发方法,什么时候选择其他方法..敏捷开发的原则是尽早并持续地交付有价值的软件以满足顾客需求敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势经常发布可用的软件,发布间隔可以从几周到几个月,能短则短业务人员和开发人员在项目开发过程中应该每天共同工作以有进取心的人为项目核心,充分支持信任他们无论团队内外,面对面的交流始终是最有效的沟通

构建之法——第六篇

经过一段时间的学习,我已学习到<构建之法>的第八章需求分析.本周我将继续学习第九章项目经理.第十章典型用户和场景.第十一章软件设计与实现. 第九章项目经理主要给我们介绍的是在企业里占据重要位置的项目经理.项目经理的作用就表现于他在企业中充当了中间人的角色.对外,项目经理需要与客户交流,发现用户需求,了解和比较竞争对手的产品,改进团队流程等.对内,需要把市场/销售人员那一套MBA的套路语言翻译成程序员能懂的规格说明书,这样可以大大节省开发人员的麻烦.而一个合格的项目经理,必须要具备观察.理解和快

2018-2019-1 20189221 《构建之法》第一周学习总结

2018-2019-1 20189221 <构建之法>第1周学习总结 教材学习内容总结 第 1 章 概论 理论和知识点: 计算机科学的领域,软件工程与计算机科学的关系,软件的特性,软件工程的定义与组成部分 1.1 软件 = 程序 + 软件工程 程序 = 数据结构 + 算法 简单的应用程序--->满足各种功能的应用软件--->保证服务质量的软件服务 软件工程的要求质量保证.用户体验.国际化和本地化 软件工程的工作有源代码管理.配置管理.软件项目的管理.需求分析.软件测试.程序理解.软

构建之法 第六次心得

构建之法12.13章小结 第12章 这一章讲的是用户体验,对于软件的使用,用户的体验是非常重要的方面,如果一个软件给用户的体验不好,那么这个软件无疑是不会受到欢迎的.但是用户体验和用户界面的领域不是那么容易的,这两个需要丰富内容的学术领域.就像一个游戏,如果这个游戏界面单调,但是操作又非常复杂,那么用户可能很快就失去了兴趣. 在设计软件界面时,我们也要考虑到使用这个软件的人群的特征,使用习惯等等,可以根据这些来设计界面,还要让用户在每次使用的时候减少对自己没有价值的部分的访问,尽量使得用户不浪费

构建之法第六次随笔

我这个礼拜阅读了构建之法第12,13章. 其中,第十二章讲的是用户体验,我们要考虑用户体验的不同角度,用户的第一印象就很重要,用户第一次使用软件,就很大程度上决定了用户对软件的评价.软件服务始终都要记住用户的选择,从用户的角度考虑,要有一颗同理心.理解用户的处境,心理,动机的能力有着一颗为用户着想的同理心,是好的产品设计的出发点.也不要让用户犯简单的错误,所以要不停改进,高明的设计能让用户不需要花费额外的注意力,也不需要经验与专业知识即可凭借直觉完成正确的操作. 对于一个软件的用户界面,有一些原

构建之法-第三周

构建之法第三章-软件工程师的成长 本章主要的理论和知识点是评价软件工程师水平的主要方法.技能的反面以及TSP对个人的要求. 首先,不同的数据能够从不同方面一个展示软件工程师的技术和能力,例如,通过完成时间平均值的比较,两位工程师或许能决出完成效率的高下,但通过比较方差则又能体现出的两位工程师的工作稳定性. 作为一个初级软件工程师,我们可以关注的成长有一下几个方面: 1.积累软件开发相关的知识,提升技术技能: 2.积累问题领域的知识和经验: 3.对通用的软件设计思想和软件工程思想的理解: 4.提升

构建之法第六七八章

第六章 敏捷流程 敏捷流程开发原则 1.尽早并持续的交付有价值的软件以满足顾客需求 2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4.业务人员和开发人员在项目开发过程中应该每天共同工作 5.以有进取心的人为项目核心,充分支持信任他们 6.无论团队内外,面对面的交流始终是最有效的沟通方式 7.可用的软件是衡量项目进展的主要指标 8.敏捷流程应能保持可持续的发展.领导.团队和用户应该能按照目前的步骤持续合作下去 9.只有