下载文档原格式
软件需求管理知识及案例软件需求管理知识及案例通过这篇⽂章，总结⾃⼰在⼯作实践中需求管理的⽅法论——普拉姆⽅法。
总结这个⽅法论的特点是，⽤最轻量化的投⼊，与他⼈协作，并管理需求，推动需求上线。
这套⽅法论组合了项⽬管理、敏捷开发的知识，希望能对⼤家有所帮助。
1. 为什么要做需求管理？1.1 我们的⼯作是否像救⽕总是做迫在眉睫的事情，会令⼈丧失⽬标。
——《普拉姆原则》我在⼯作中体会到每天忙东忙西的处理需求，虽然每天都很充实，但确实极为耗费精⼒，时间长久就会缺乏动⼒。
上⾯讲的是个⼈的⾓度，如果⼀个组织或者团队⾯对⼤量的需求，在处理需求的时候，没有节奏和规划，会产⽣消极的影响。
从⼩的⽅⾯看会影响团队⼠⽓，往⼤的⽅⾯看，会影响组织实现既定的⽬标。
我的⼯作环境是，作为后台产品经理，处在业务运营团队和技术团队之间，要作为⼀个桥梁，保障业务运营团队从我这⾥输出⾼质量的需求，也要保障具有不同知识背景团队，能过通过需求，⾼效沟通，快速推进需求上线。
于是，我就通过⼯作实践，形成了⾃⼰的管理需求⽅法论——普拉姆⽅法。
存在即有标识。
——《普拉姆原则》为了便于总结和归纳，我给这个⽅法论起了个名字。
在需求管理中，需求的名称也是很重要的因素，之后会提到。
1.2 需求管理是什么？我的定义是，通过协作，管理需求内容和进程，实现成功发布。
便于理解这个概念，在这⾥讲⼀个海湾战争的故事。
在海湾战争中，美军在前期并没有派出⼤规模的地⾯部队进⾏战术打击。
⽽是，派出⼀批批的特种部队渗透到敌⼈境内，侦查清楚敌⼈重要的军事⽬标，并将精准坐标和信息，传递给后⽅。
顷刻之间，海洋上的战舰派出飞机和战斧导弹对其进⾏精准轰炸，并取得战术和战略上的胜利。
在这个例⼦中，特种部队是业务运营团队，飞机和战斧导弹是技术团队。
产品经理通过需求管理的⽅法论，⽤⾼效和轻量化的⽅式，去精准的做出需求，实现预期的效果。
1.3 宗旨是什么？普拉姆⽅法的宗旨是积极主动，知识共享，相互尊重。
软件需求分析案例某公司的管理人员希望开发一款能够帮助员工进行任务管理和团队协作的软件。
该软件需要满足以下需求：1. 任务管理功能：- 员工可以创建新任务，并设置任务的优先级、截止日期和负责人。
- 员工可以查看自己被分配的任务，并标记任务的完成状态。
- 员工可以根据任务优先级和截止日期进行任务排序和筛选。
2. 团队协作功能：- 员工可以与团队成员分享任务，并设置任务的可见性和编辑权限。
- 团队成员可以在任务中进行讨论和留言，以便更好地协作和交流。
- 员工可以查看团队的任务进度和提醒团队成员完成任务。
3. 日程管理功能：- 员工可以创建个人日程，并设置日程的时间、地点和备注。
- 员工可以查看自己和团队成员的日程，并进行日程的编辑和调整。
- 软件可以自动提醒员工即将到来的日程和任务的截止日期。
4. 报表统计功能：- 管理人员可以查看团队成员的工作量和任务完成情况的报表统计。
- 报表统计功能可以根据时间段、员工和任务进行筛选和统计。
- 报表统计功能可以以图表和表格的形式展示统计结果，便于管理人员进行决策和评估。
5. 安全与权限管理：- 软件需要有登录和身份验证功能，确保只有授权的员工能够访问和操作系统。
- 管理人员可以设置员工的角色和权限，以便控制员工的操作。
- 软件需要有数据备份和恢复功能，确保数据的安全性和可靠性。
综上所述，该软件需求分析包括任务管理功能、团队协作功能、日程管理功能、报表统计功能和安全与权限管理。
这些功能能够帮助公司提高员工的工作效率和团队的协作能力，提升整体的管理水平和业绩。
软件项目管理经典案例全文共四篇示例，供读者参考第一篇示例：软件项目管理是现代企业中非常重要的一部分，它可以帮助企业有效地规划、执行和监控软件开发项目，确保项目按时、按质、按标准完成。
在软件项目管理领域，有许多经典案例可以供我们学习和借鉴。
下面我们就来看一些经典的软件项目管理案例。
1. IBM的OS/360项目IBM的OS/360项目是计算机历史上最有影响力的一个项目，也是软件项目管理领域的经典案例之一。
该项目开始于上世纪60年代，旨在开发一款操作系统，以支持IBM的大型机产品。
由于该项目规模庞大，涉及的技术复杂，以及开发团队庞大，因此项目进度一度非常缓慢。
IBM在项目管理方面做出了一系列创新，包括采用模块化开发、引入正式的项目管理方法等。
最终，IBM成功地完成了OS/360项目，为公司带来了巨大的商业成功。
2. 微软的Windows项目微软的Windows项目是另一个软件项目管理领域的经典案例。
Windows是微软公司的旗舰产品之一，它的开发历程非常漫长，技术难度也极高。
微软在Windows项目中采取了许多先进的软件项目管理技术，如敏捷开发、持续集成、自动化测试等。
这些技术帮助微软团队高效地协作，不断迭代产品，最终成功地推出了多个版本的Windows操作系统，赢得了广泛的用户认可和市场份额。
3. 苹果的iPhone项目苹果的iPhone项目也是软件项目管理领域的一个经典案例。
iPhone是苹果公司推出的一款革命性的智能手机，它的开发历程非常复杂，需要涉及硬件、软件、设计等多个领域的协同合作。
苹果在iPhone项目中采用了独有的创新模式，如设计驱动的开发、高度集成的团队协作等。
这些方法使得苹果成功地推出了多个版本的iPhone产品，成为全球最受欢迎的智能手机之一。
4. 谷歌的Android项目谷歌的Android项目也是软件项目管理领域的一个典范案例。
Android是谷歌公司开发的一款移动操作系统，它的开发历程充满挑战和机遇。
软件需求案例一、引言。
在当今信息化社会，软件已经成为人们生活和工作中不可或缺的一部分。
随着科技的不断发展，软件需求也在不断增长，为了更好地满足用户的需求，开发一款符合用户期望的软件变得至关重要。
本文将以一个软件需求案例为例，探讨软件需求的重要性以及如何进行需求分析。
二、案例描述。
某公司决定开发一款智能家居控制软件，该软件可以实现对家中各种设备的远程控制和智能化管理。
用户可以通过手机或平板电脑等智能设备，实现对家中灯光、空调、窗帘等设备的远程控制，并且可以设置定时开关、场景模式等功能。
同时，该软件还可以实现对家庭安防设备的监控和管理。
三、用户需求分析。
1. 用户群体。
该软件的主要用户群体为家庭用户，他们希望通过该软件实现家中设备的智能化控制和管理，提升家居生活的便利性和舒适度。
2. 功能需求。
用户希望该软件具备远程控制、定时开关、场景模式设置、设备状态监控等功能。
同时，用户还希望软件能够智能识别家庭成员，实现个性化的智能控制。
3. 用户体验。
用户对软件的界面设计、操作流畅性、响应速度等方面有较高的要求，希望能够通过简单直观的操作，轻松实现对家庭设备的控制和管理。
四、系统需求分析。
1. 硬件需求。
该软件需要支持多种智能设备，包括灯光、空调、窗帘等家庭设备，同时需要支持多种智能家居控制协议，如Wi-Fi、蓝牙、ZigBee等。
2. 软件需求。
该软件需要支持多平台，包括iOS、Android等主流操作系统，同时需要具备良好的兼容性和稳定性。
3. 安全需求。
考虑到家庭设备的远程控制可能存在安全隐患，软件需要具备严格的安全防护机制，保障用户数据的安全性和隐私保护。
五、总结。
通过以上需求分析，我们可以清晰地了解用户对智能家居控制软件的需求，以及系统在硬件、软件和安全方面的需求。
在开发过程中，我们需要充分考虑用户的实际需求，结合系统的实际情况，设计出一款功能完善、安全稳定的智能家居控制软件，为用户提供更便利、舒适的家居生活体验。
软件需求管理知识及案例通过这篇文章，总结自己在工作实践中需求管理的方法论——普拉姆方法。
总结这个方法论的特点是，用最轻量化的投入，与他人协作，并管理需求，推动需求上线。
这套方法论组合了项目管理、敏捷开发的知识，希望能对大家有所帮助。
1. 为什么要做需求管理？1.1 我们的工作是否像救火总是做迫在眉睫的事情，会令人丧失目标。
——《普拉姆原则》我在工作中体会到每天忙东忙西的处理需求，虽然每天都很充实，但确实极为耗费精力，时间长久就会缺乏动力。
上面讲的是个人的角度，如果一个组织或者团队面对大量的需求，在处理需求的时候，没有节奏和规划，会产生消极的影响。
从小的方面看会影响团队士气，往大的方面看，会影响组织实现既定的目标。
我的工作环境是，作为后台产品经理，处在业务运营团队和技术团队之间，要作为一个桥梁，保障业务运营团队从我这里输出高质量的需求，也要保障具有不同知识背景团队，能过通过需求，高效沟通，快速推进需求上线。
于是，我就通过工作实践，形成了自己的管理需求方法论——普拉姆方法。
存在即有标识。
——《普拉姆原则》为了便于总结和归纳，我给这个方法论起了个名字。
在需求管理中，需求的名称也是很重要的因素，之后会提到。
1.2 需求管理是什么？我的定义是，通过协作，管理需求内容和进程，实现成功发布。
便于理解这个概念，在这里讲一个海湾战争的故事。
在海湾战争中，美军在前期并没有派出大规模的地面部队进行战术打击。
而是，派出一批批的特种部队渗透到敌人境内，侦查清楚敌人重要的军事目标，并将精准坐标和信息，传递给后方。
顷刻之间，海洋上的战舰派出飞机和战斧导弹对其进行精准轰炸，并取得战术和战略上的胜利。
在这个例子中，特种部队是业务运营团队，飞机和战斧导弹是技术团队。
产品经理通过需求管理的方法论，用高效和轻量化的方式，去精准的做出需求，实现预期的效果。
1.3 宗旨是什么？普拉姆方法的宗旨是积极主动，知识共享，相互尊重。
什么是宗旨？可以理解为这套方法论的价值观。
这套方法论的每一个细节，都应该遵循这个宗旨来实践，并遵循这个宗旨发展和进化。
“积极主动，知识共享，相互尊重”的宗旨，是我借鉴了美国西南航空的价值观。
美国西南航空是美国航空业受到911事件巨大打击的背景下，依然能够盈利的廉价航空。
在航空业极为复杂的管理模式下，使用廉价航空的经营方式实现盈利，还是令人十分震撼的。
所以，阅读了相关书籍之后，将美国西南航空的价值观的精华，吸纳为普拉姆方法的宗旨。
（1）积极主动积极主动是核心，具体指团体之间的成员积极主动的承担责任去做事情。
在《高效能人士的七个习惯》中，积极主动也被列为很重要的素质。
在管理每个需求的过程中，每个人都要有担当或者忽略角色的做事情。
这也是敏捷开发中推崇的。
一个产品经理在不同的需求中，可能既是梳理需求、输出原型的角色，又可能是测试的角色。
但是，团队中每个工作的角色在变，通过管理需求达成的目标不会变。
请明确讲清需求的目标！我会像战士，即使身陷重围，也会向胜利的方向战斗！——《普拉姆原则》（2）知识共享知识共享，是指分享不同团队的领域知识，减少沟通的未知区域，减少沟通中的误解。
有一个Johari窗格的沟通理论，专门提到沟通分为四个区域，即开放区、盲目区、隐秘区、未知区。
通过扩大开放区，来提升沟通的效率和效果。
同时，“公则生明”，即将信息公开透明，可以增加协作团队之间的信任。
比如，公开展示各需求的进度。
讲个题外的故事，俞永福对产品经理说过，产品经理要有树靶子的意识。
自己的需求就是靶子。
公司内部的任何人都可以打靶子。
每个产品经理有责任，维护好自己的靶子，不被打漏。
所以，产品经理自己要让自己的需求健壮，不被打漏。
从另外的角度看，尽早的把问题暴露，可以最大的降低解决问题的成本，防止问题积累成一个“惊喜”。
（3）相互尊重相互尊重，是指尊重每一个人的人格、劳动及输出成果。
在管理需求的过程中，要与不同岗位的人打交道。
每个人站在不同的立场，必然会有看待问题的不同角度。
所以，大家在合作的过程中，要相互尊重。
内在的思想是人格上的尊重，外在的表现是尊重别人的劳动成果。
不要站在自己的立场和知识背景，去简单评判别人的劳动。
对他人劳动的尊重，就是对他人的尊重。
1.4 结尾这是文章的的开篇，湿货很多。
可能都是大家知道的常识。
不过，常识并不常用。
把常识内化为行动之中，可以让事半功倍，至少不会犯错。
2. 需求管理中的干系人和角色识别出需求的干系人，是需求管理中非常重要的起点。
之后的需求管理活动要与干系人及角色，进行紧密的合作。
2.1 什么是干系人干系人，是来自于项目管理中的概念。
项目干系人是能影响项目决策、活动或结果的个人、群体或组织，以及会受或自认为会受项目决策、活动或结果影响的个人、群体或组织。
他们也可能对项目及其可交付成果施加影响。
干系人可能来自组织内部的不同层级，具有不同级别的职权；也可能来自项目执行组织的外部。
——《项目管理知识体系指南(PMBOK指南)(第5版)》总结的简单点，干系人是与需求相关的人或者组织。
而且干系人在需求管理中起到很重要的作用。
特别是在做跟业务流程密切结合的需求时，找到并找对干系人极为重要。
在需求中的每个人，都会从自己的立场出发提需求，可能会不经意间破坏别的业务线的流程，所以这个时候就需要产品经理从全局的角度去思考需求，或者找到那个能从全局思考的干系人去帮助找到需求中的障碍。
有人就会有角色，每个角色必然有不同的关注点，被忽略的关注点都变成了坑。
——《普拉姆原则》这里再扩展一点，就是需求可能存在二律背反的情况。
也就是说，提一个优化改善的需求，可能会损害其他流程或角色的利益。
有时，产品经理要找到需求的受害者，从而更全面的了解需求。
不害人的需求，不是完整的需求。
——《普拉姆原则》所以，找到和找对需求的干系人，对于需求管理非常重要。
2.2 需求管理中的角色在《西游记》中，六小龄童扮演的角色多达16个，最知名的就是孙悟空，还有道士、和尚之类的角色。
而唐僧的角色，就有三位演员扮演过。
同理，在需求管理中，干系人是一个个的演员，而演员可以担任多个角色。
以下是我在从事后端系统的工作中遇到的角色：（1）需求人顾名思义，真正提出需求并描述需求细节的角色。
这个角色可以是任何干系人，毕竟产品经理是一个负责从四面八方收集需求的人。
需求人一般要与其所在的部门联系在一起，有助于判断所提需求的立场。
（2）负责人负责人也来自于业务部门。
收集需求人的需求，从业务角度对需求进行梳理和判断，并转发给产品经理和研发同事。
当业务团队远大于技术和产品团队时，负责人的角色就非常重要。
如果业务团队的人数小于等于技术团队时，可以省去这个角色。
负责人，就像一个漏斗和筛子一样，初步筛选一遍需求。
毕竟，评估需求也是要花费时间，特别是占用研发同事的时间。
（3）产品经理需求管理的组织者、推动者。
以“积极主动”的态度，与需求管理的角色进行沟通。
（4）研发经理研发资源的管理者。
在这里的研发经理，一般是带四、五个人小团队的级别。
因为，他们能够了解每个研发工程师的工作和能力，协助评估业务需求。
（5）研发工程师实际参与研发需求的程序员。
（6）测试工程师参与需求测试的测试人员。
可以根据公司的组织架构，增加测试经理的角色。
测试经理的级别也是带四、五个人小团队。
在需求管理中，产品经理要当成一个桥梁，与不同的角色，进行沟通和协作。
在后面，需求管理的流程和需求看板的管理方法，都会与这些角色紧密相关。
2.3 如何识别干系人和角色了解所在公司的组织架构，以及团队组织架构，是识别干系人和对应角色的关键。
产品经理可以根据组织架构，明确了解到研发和测试的相关角色。
同时，产品经理可以跟业务团队进行沟通，了解业务团队的业务背景和知识，以及团队文化。
识别出潜在的需求人，才是真正的考验。
以上，就是需求管理中干系人的相关内容。
3. 需求管理的三个模式与公交模型普拉姆方法的运行流程包含三个模式：急诊模式、登机模式、看板模式。
本章将介绍这三个模式与公交模型的关系，提供一套应对”越快越好“类需求的方法。
3.1 破解“越快越好“的局面在接到来自各部门的需求时，每个需求都会打上”越快越好“的标签。
站在提需求者（需求人和负责人）的角度，研发资源是稀缺的，老板的要求是急迫的，如果不表达需求的急切性，需求就排不上。
这就像飞机迫降之后，每个人都会带着”越快越好“目的奔向出口，如果没有空乘人员的指挥，最后大家慌不择路的堵在出口，最终导致延误了逃生时间。
处理工作的模式：划散乱为规律，划应急委预测。
——《普拉姆原则》所以，可以借鉴急诊室的场景，来规划”越快越好“的需求，让需求管理有序的运行起来。
3.2 急诊室的场景产品经理面对的需求，就是来看急诊的病人。
病人都会觉得自己应该马上得到最快的医疗救治。
但是，医疗资源有限，只能让医生先救治最危重的病人，病情较轻的病人要先等待一下。
这个时候，需要有一个预检分诊的流程，预先对病人进行判定和分诊，从而让急诊室高效的运转起来。
因此，借鉴急诊室的做法，我们对需求增加一个”预检分诊“的预处理模式。
从而对”越快越好“的需求，进行区分，在研发资源稀缺的情况下，让真正紧急的需求获得资源。
3.3 让需求管理运转——公交模型设想一下，病人去急诊楼就医的时候，我们安排了”预检分诊“（预处理）的流程。
那么就需要安排一个房间，让病人们在那里等候，并安排医生进行诊断。
然后，病人根据预检医生的诊断，再从这里出来，去对应的诊室去看病。
所以，要让这个流程在需求管理中正常的运行，就需要采用公交模型。
公交模型，是我结合火车模型发布模式，起得一个通俗易懂的名字。
（火车模型发布模式是）以固定的周期持续发布产品，如果某项既定功能未完成，就挪到下个周期发布的开发方法——《启示录——打造用户喜爱的产品》公交模型，就像我要从到家到公司要换乘3趟公交车去上班，到公交站等车。
每趟公交车之间都有发车间隔和到站时刻，并且周而复始的经过公交站。
所以，我就按照规划好的路线，从公交站坐车，再到下一个换乘站乘车。
从公交模型中，可以提炼出几个概念：出行路线、发车间隔、到站时刻。
在公交模型中，出行路线称为”需求管理流程“，发车间隔称为”需求管理周期“。
到站时刻，称为”需求时间“。
（1）需求管理流程需求管理流程，是指在需求管理中，按照顺序依次进行需求管理活动。
需求管理活动按先后顺序分为三个阶段：需求收集需求设计需求研发再强调一遍，这三个阶段是依次进行的。
先进行需求收集、在进行需求设计、最后进行需求研发。
每一阶段的需求管理活动对应一个指导原则。
指导原则就是急诊模式、登机模式、看板模式。
急诊模式指导需求收集，登机模式指导需求设计，看板模式指导需求研发。
在文章的开头，我用急诊室的场景，介绍了急诊模式。
后续的章节中，我会介绍剩下的两种模式：登机模式和看板模式。
