![](https://img-blog.csdnimg.cn/2ce21fb50a7e40d7b56dade0bdea2e9e.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
2022年学习笔记——软件需求
文章平均质量分 90
从项目出发,学习写高质量的需求,尽可能减少返工,尽可能提升生产效率。
将如何存在
一直在路上
展开
-
7 需求获取
需求获取技巧原创 2022-02-09 10:03:30 · 1274 阅读 · 1 评论 -
6 倾听用户的心声
客户参与交付卓越的软件必不可少,就必须保证业务分析师和项目经理从一开始就尽其所能把合适的客户代表拉入项目、软件需求,甚至软件开发的成功取决于开发人员能否听到用户的声音。为了听到用户的心声,可以采取以下三个步骤:识别产品的不同用户类别挑选用户和干系人小组代表,并与他们一起工作对谁是项目需求的决策者达成共识客户参与最能够避免期望落差(客户对产品的期望与开发人员提供的产品功能不匹配),只向个别用户或其经理问几次他们有何具体需求就开始编码,是远远不够的。如果开发人员严格遵照客户最初的需求开发软件,可能需原创 2022-02-07 14:41:52 · 1473 阅读 · 0 评论 -
5 建立业务需求
业务需求代表的是需求链的顶部。它们定义解决方案的愿景和实现该方案的项目范围。用户需求和功能需求和功能需求必须与业务需求建立的背景和目标保持一致。任何无助于项目达成业务目标的需求都不宜实现。如果项目没有清晰的定义和充分沟通方向,肯定会带来灾难性的结果。参与者如果不能保持目标和优先级的一致性,工作方向就会不自觉地南辕北辙。如果对项目的业务目标缺乏共同的理解,干系人永远无法就需求达成一致意见。团队如果不能提前意识到这一点,即使劳神费力交付合格的产品,项目也很可能超期,预期也可能超支。5.1定义业务需求总的来原创 2022-01-28 14:42:11 · 1371 阅读 · 0 评论 -
4 业务分析师
在每个软件项目中,都有人在显式或隐式地扮演业务分析师(BA)的角色。业务分析师是能够在组织中促进变化的人,他们通过定义需求和向干系人推荐有价值的解决方案来促进这些变化。分析师获取和分析他人的观点,将收集到的信息转换为需求规范说明,并于其他干系人沟通和交流这些信息。分析师帮助干系人发现他们所描述的需求与实际需要之间的差别。他承担着教导、提问、倾听、组织和学习的任务。4.1业务分析师的角色业务分析师的首要职责是获取、分析、记录和验证项目干系人的需要。作为首席“口译”,业务分析师要将客户群体的需求传递到软件开原创 2022-01-25 21:14:17 · 3803 阅读 · 0 评论 -
3 需求工程优秀实践
3.1需求开发过程框架需求工程包括获取、分析、规范说明和验证。但不能只是简单以一种一次性线性顺序来实施这些实践。实际上,这些活动是相互交织、渐进的和迭代式的,如下图所示。“逐步完善细节”是实施中的一个关键术语,指的是从一些原始的需求想法向更精确的理解和表述演进。如果你是一名业务分析师,你会向客户提问,听他们的回答,观察他们的行为(获取)。你会处理这些信息并加以理解,还会将它们归入不同的类别,并且将客户的实际需要与可能的软件需求联系起来(分析)。在分析过程中,你可能会意识到自己需要澄清一些需求,所以需原创 2022-01-24 14:29:10 · 597 阅读 · 0 评论 -
2 从客户角度审视需求(2)
2.7识别决策者让一个代表各个关键领域(如管理、客户、商业分析、开发和市场部门)的小组来决定通常更有效。决策小组需要指明决策领导并选择一个决策规则,该规则描述了他们如何做决定。有很多决策规则可以识别:决策领导做决定,不管是否已经和其他人讨论过小组投票,少数服从多数小组投票,但是结果必须获得一致通过小组讨论和协商达成共识。每个人都拥护这个决定并承诺支持它决策领导授权一个决策人小组达成一个决策,但是一些人有权否决小组决定没有普适的决策规则。单一的决策规则通常也不普遍适合于每个场景,所以小组原创 2022-01-23 15:31:04 · 382 阅读 · 0 评论 -
2 从客户角度审视需求(1)
从产品的使用者那里直接挖掘需求依然无可替代的,一些敏捷开发方法就建议有一个驻场的客户代表(产品负责人)与开发团队一起紧密合作。本章讲述的客户-开发人员关系是软件项目成功的关键要素。软件客户拥有权力清单,同时也有对应的义务清单。这些清单重点强调客户(特别是终端用户)参与需求开发的重要性。2.1期望落差如果没有足够的客户参与,当项目结束时一个无法避免的结果就是期望落差,用户的真实需求和开发人员根据项目之初听到的需求开发出的产品之间的巨大鸿沟。下图中的虚线标示了这个鸿沟。缩小期望落差的最好方法是与合适的客原创 2022-01-21 14:11:04 · 931 阅读 · 0 评论 -
1 软件需求的本质(2)
1.4需求开发和管理人们对需求术语的困惑甚至延伸到整个学科的称谓上。有些地方将整个范围都称为“需求工程”,有些统称为“需求管理”,还有些人认为这些活动属于广义上业务分析的一个分支。软件需求工程的细分:1.4.1需求开发需求开发细分为获取、分析、规范说明、验证,这些细分囊括的活动设计产品需求的开发、评估、记录和确认。获取需求发现的所有活动,例如访谈、研讨会、文档分析、原型等。识别产品的预期客户群和其他干系人。理解客户任务、目标以及这些任务相关的业务目标。了解新产品的应用环境。与每一类客户原创 2022-01-19 16:15:12 · 530 阅读 · 0 评论 -
1 软件需求的本质(1)
1.1前言软件中的很多问题大多数来源于人们了解、记录、协商和修改产品需求的方法不当。现实生产环境中的软件产品发现的缺陷有40%~50%是在需求阶段埋下的“祸根”(Davis 2005)。在具体说明客户需求和管理客户需求过程中用户输入不足和有误,是造成项目失败的罪魁祸首。在软件项目中,所有干系人的利益交接点主要集中在需求方面。(更多干系人方面的内容参考本栏目后面章节)这些干系人主要包括客户、用户、业务分析人员和开发人员等。若处理得当,这种交接既让客户满意,又能鼓舞开发团队。若处理不当。则会引发误解和摩擦,最原创 2022-01-18 13:51:59 · 2758 阅读 · 0 评论