写好市场需求文档的10种技巧

合集下载

软件开发过程中的需求管理技巧

软件开发过程中的需求管理技巧

软件开发过程中的需求管理技巧在软件开发过程中,需求管理是非常重要的一环。

因为一个软件的成功与否,很大程度上取决于对用户需求的把握和正确理解。

本文将介绍一些常用的需求管理技巧,以帮助软件开发者更好地控制整个开发流程。

第一、确定需求的优先级当我们面临大量需求时,应该先做什么,后做什么,如何把握时间,是每个软件开发者都需要思考的问题。

因此,我们需要确定需求的优先级。

通过对需求的分析,我们可以将需求按照紧急程度、实现难度、市场需求等因素进行排序,以便更好地安排开发时间和资源。

第二、搜集用户需求软件开发者需要通过与用户接触、文献资料和市场调研等多种途径,搜集相关用户的需求信息。

通过对这些信息的分析,我们可以了解用户的需求痛点,进而制定合理的软件需求列表,以便在软件设计时更好地关注用户的需求和期望。

第三、建立需求评估机制在软件的开发过程中,经常会出现很多变更和调整的情况,如果没有建立一个有效的需求评估机制,这些变更和调整会给开发团队带来很多额外的工作,甚至会推迟软件的开发进度。

因此,我们应该在开发项目开始时就建立一个需求评估机制,包括对需求的详细评估和风险分析等,以便更好地把握开发进度。

第四、清晰明确的需求文档在软件开发过程中,清晰明确的文件,如需求文档是非常必要的。

需求文档是整个软件开发过程中的核心文件。

软件开发者需要根据客户需求,将其转化为清晰明确的软件需求文档,以便开发人员更好理解和实现。

在整个开发过程中,需求文档将起到桥梁和纽带的作用,能够加速需求的沟通和理解。

第五、沟通和交流在软件需求管理的过程中,原则上具有较高的沟通和交流能力是非常必要的。

为了更好地了解对方的需求和想法,软件开发者应与客户 stakeholders 常常沟通和交流。

软件开发者应该尽可能了解客户的需求和项目,然后归纳和核对,以确保他们的理解是正确的。

此外,软件开发团队之间的内部交流和反馈也非常重要,以保证整个开发流程的顺利进行。

总之,在软件开发过程中,需求管理是非常重要的环节。

如何编写商业需求文档

如何编写商业需求文档

一、商业需求文档的概念商业需求文档(BRD)是描述产品商业目标和价值的重要文档,它基于商业目标或价值来描述产品需求。

BRD是产品生命周期中最早产出的文档之一,通常用于向决策层展示产品的商业价值和市场需求,以获得他们的支持和批准。

一般来说,一份商业需求文档通常有如下这些主要用途。

帮助企业决策层评估产品研发的商业价值:BRD中包含了产品的商业目标、市场前景、竞争优势、收益预期等信息,这些信息可以帮助企业决策层评估产品研发的商业价值,从而决定是否继续推进该项目。

为产品开发团队提供明确的方向和指导:BRD中定义了产品的需求、功能、性能、用户界面等方面的要求,这些信息为产品开发团队提供了明确的方向和指导,使得开发团队能够更好地理解产品的目标和要求,从而更好地实现产品开发。

帮助产品经理与业务人员沟通:产品经理通常需要与业务人员讨论产品的商业目标和需求,以确保产品的研发能够满足业务需求。

BRD可以帮助产品经理与业务人员沟通,确保双方对产品的商业目标和需求有共同的理解和认识。

帮助产品开发团队与市场人员沟通:市场人员通常需要与产品开发团队讨论产品的市场定位和用户需求,以确保产品的研发能够满足市场需求。

BRD可以帮助产品开发团队与市场人员沟通,确保双方对产品的市场定位和用户需求有共同的理解和认识。

二、商业需求文档包含内容一份完整的商业需求文档主要包含有文档说明,产品介绍,产品价值,产品模式,产品规划,收益与成本,风险与应对,总结这些内容:文档说明:文档说明中需要写清楚文档目的,参考资料,以及专业术语,名词解释等。

产品介绍:大致介绍一下想要做什么产品,以及产品的形态是什么。

产品价值:需要从市场分析的角度,说清楚产品的价值,以及产品的创新点。

产品模式:包含有业务模式,商业模式,盈利模式,运营模式,每种模式都需要阐述清楚,便于决策者更好的理解产品模式。

产品规划:需要详细规划产品的架构图,说清楚该架构图包含哪些平台?哪些终端?同时,还要罗列产品的线路图,当然如果是历史产品,还需要对历史版本产品做一个总结。

最实用的10种营销技巧

最实用的10种营销技巧

最实用的10种营销技巧1.调研市场:在推广产品和服务之前,对市场需求进行充分调研是必不可少的。

了解目标客户的需求,竞争对手的活动以及行业趋势,可以帮助企业制定更有效的营销策略。

2.明确定位目标客户群体:确定目标客户群体是成功营销的基础。

通过人口统计数据和社会经济状况分析,确定潜在客户的特征和喜好,以便更好地针对他们。

3.个性化定制产品和服务:根据目标客户的需求和喜好,定制化产品或服务,使其更具吸引力。

只有满足客户的个性化需求,才能在市场上脱颖而出。

4.市场定位:根据竞争对手和自身的优势,确定自己在市场上的定位。

市场定位决定了企业的目标客户、产品特点以及营销手段等。

5.创造独特的品牌形象:通过品牌形象的独特性来吸引客户的注意力。

借助精美的LOGO和标志性的广告语,以及高品质的产品和服务,建立起与其他品牌的差异化竞争优势。

6.使用多渠道推广:营销不再仅限于传统的广告渠道,如报纸、电视和广播等。

企业可以利用社交媒体、引擎优化和电子邮件市场营销等新渠道,以更广泛的方式触达目标客户。

7.提供口碑营销:借助现有客户口碑来推广产品和服务。

启动满意度调查、提供优质的售前售后服务和回馈机制,激发现有客户的忠诚度,以获得积极的口碑效应。

8.使用数据分析工具:利用数据分析工具来跟踪和分析营销活动的效果。

通过监测关键指标,如销售量、客户转化率和广告投资回报率,及时调整和改进营销策略。

9.参与公益活动:积极参与公益活动,可以帮助企业树立良好的社会形象,增强客户对品牌的认同感。

此外,借助公益活动来宣传并推广产品和服务,也是一个有效的营销手段。

10.与合作伙伴合作:与相关行业的合作伙伴展开合作,可以互相受益。

通过共同营销活动,扩大目标客户群体,提高品牌知名度。

同时,合作伙伴也可以提供一些资源和渠道上的支持。

以上是最实用的十种营销技巧,通过运用这些技巧,企业可以更好地推广产品和服务,提高市场竞争力。

然而,值得注意的是,不同行业和市场状况下,适用的营销技巧可能会有所不同,企业还需要根据实际情况进行灵活运用。

如何写好一篇PRD

如何写好一篇PRD

PRD(Product Requirement Document,产品需求文档),顾名思义是阐述产品需求的一种文档,其核心是将需求描述清楚。

通过PRD可以看出一个产品经理对产品理解的逻辑思维,产品经理在相关领域的认知和专业的深度以及对产品全局的认识。

如何才能写出好的PRD,让产品研发团队成员,开发、测试、运营同学了解产品需求,让其他人能从该文档中看到产品的价值和意义,估计很多人都思考过,如何让PRD不被其他人挑战,如何获得他们的认可估计是产品经理经常考虑的问题。

也有人可能认为PRD只要中心思想不变,阐明需求就已经足够,交给下游的同学他们理解了就完事了,但是这个文档是否被叫好,是否有用,是否有价值可能从没考虑过。

在此将从PRD的用户侧分析好的PRD应该具备的要素或必要条件。

首先,先了解清楚PRD的阅读对象,使用者。

PRD的模版中一般有如下信息:PRD预期的读者包括:产品、开发、测试人员及相应的负责人和用户方代表。

产品、开发、测试人员会从中了解到本次需求的背景和详细要求,以及每个需求点未来的优化方向或对用户的价值。

而用户方代表则可以通过该文档了解PRD中所描述内容是否是自己期望中的需求,是否符合以及是否都覆盖到了自己的预期。

因此PRD也是产品经理同相关角色确认开发任务的重要依据。

当所有角色认可了PRD中的内容后,这份PRD将作为后续开发、测试、需求验证的依据。

其次,一个完整的PRD还应该具备的要素有1、文档的命名和编号文档的编号和命名很关键,每个产品都是经过若干个迭代才完成的,而每个迭代所完成的产品功能或者升级的需求都可能是不一样的,因此需要定义清楚该文件属于产品的哪个迭代,修改了几个版本。

文件命名的方法一般是通过版本号定义,比如简单的方法是,XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号,后面的V2 PRD的版本号。

稍微详细点可以定义成,XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名,这样更便于阅读和记忆。

产品需求文档(PRD)的写作方法

产品需求文档(PRD)的写作方法

产品需求文档(PRD)的写作方法无论我们做什么事都讲究方式方法,写产品需求文档(以下称PRD文档)也是如此,之前我通过五篇文章分享了自己写PRD文档的一些方法,而这一篇文章主要是对之前五篇文章进行整体的摘要介绍,帮助大家快速了解写作流程。

产品需求文档(PRD)的写作五篇章:1、写前准备(信息结构图)2、梳理需求(产品结构图和用户流程图)3、原型设计(手绘原型,灰模原型,交互原型)4、撰写文档(PRD文档)5、用例文档(UML用例图、流程图)1、写前准备(信息结构图):在写PRD文档之前,我们需要先罗列出产品功能的信息内容,这一步是将想法逐渐清晰的第一步,也是帮助我们接下来规划功能的辅助信息,同时也可以辅助服务端技术人员创建数据库。

因为这是第一步,所以我们不需要罗列的很详细,在之后的步骤里,我们会逐步改进和完善信息内容。

例如一篇文章的信息内容主要有:文章标题、文章正文、文章作者、发布时间、所属分类。

初始的功能需求只有这些信息内容,但是在之后的功能规划中逐渐更加细致的考虑时,可能会增加或者删减,因此第一步我们不用刻意的追求信息的全面。

罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主要的是能够清晰易懂,我最常用的方法就是思维导图,因此我称这一步为信息结构图。

2、梳理需求(产品结构图和用户流程图):当我们对产品的信息结构了解后,我们就需要规整脑海中的产品需求,让想法更加结构化,因此这一步是梳理产品的需求。

我们首先要罗列出产品的频道及页面(产品结构图),其次再基于产品结构图梳理出频道及页面中的功能,并延伸构建出用户的操作流程(用户流程图)。

以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解,类似鸟瞰式的一目了然,也方便调整完善。

3、原型设计(手绘原型,灰模原型,交互原型):当我们逐渐清晰了产品的需求后,并梳理了产品的各个频道及页面,那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。

市场需求文档(MRD)文档的写作方法

市场需求文档(MRD)文档的写作方法

市场需求文档(MRD)文档的写作方法MRD定义与分类MRD指Market Requirements Document,简称市场需求文档。

市场需求文档的主要功能是描述什么样的功能和特点的产品(包含产品版本)可以在市场上取得成功。

产品进入实施,需要先出MRD,具体来说要有更细致的市场与竞争对手分析,通过哪些功能来实现商业目的,功能/非功能需求分哪几块,功能的优先级等等。

产品市场经理(PMM,Product Marketing Manager)负责分析市场变化,通过对市场的分析,MRD指出什么样的新产品、方案和服务可以更好的开拓市场。

通常情况下,产品经理或者技术产品经理会将在MRD的基础上完成PRD (Product Requiremnets Document),技术团队应用PRD开发产品。

在百度的ECOM PM部门,MRD要分为给RD/QA看和给业务部门看的两种。

给工程、测试、设计看的MRD是他们的输入信息和测试对象。

给业务部门看的MRD,最主要是因为MRD里面的功能实现后,会对客户产生影响,所以必须确认业务部门知晓。

MRD基本写法一般来说,MRD包含“项目背景”“名词解释”“可行性分析”“综合描述”“功能详述”等部分。

这里结合不同版本的MRD谈谈MRD的基本写法。

目前看到的几个MRD比较重视功能需求这块。

功能需求主要包括功能点类型和优先级/流程图/页面布局/功能点描述等要素。

其中优先级和功能描述比较重要,流程图常可省略。

要素1:项目背景要让RD理解。

“具体开发的背景是什么,解决什么问题得写清楚,否则开发人员在不清楚背景的情况下去做,很容易出问题,而且也缺乏参与感。

”事实证明,谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的对工程师很有价值,许多工程师想知道为什么一个产品或特性要开发,谁将使用他们,什么是他们可以另外选择办法。

这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。

需求格式及范文-概述说明以及解释

需求格式及范文-概述说明以及解释

需求格式及范文-范文模板及概述示例1:需求格式及范文需求是在项目管理和软件开发中非常重要的一步,它定义了项目或软件的目标、功能和特性。

一个完善的需求可以帮助团队成员明确任务,减少误解并提高开发效率。

在撰写需求的过程中,有一些常用的格式和范文可以参考,下面是一些常见的需求格式及范文:1. 标题需求的标题应简洁明了,能够表达需求的核心内容。

范例:用户注册功能2. 描述在需求的描述部分,应该详细说明需求的背景、目标、功能和预期结果。

范例:该功能旨在提供一个用户注册系统,使新用户能够创建一个账户并进入系统。

注册后,用户可以使用他们的账户登录系统,访问特定的功能和服务。

3. 功能点列出需求中必须实现的功能点,并对每个功能点进行详细描述。

范例:- 用户应该能够输入所需的个人信息,例如用户名、密码、电子邮件等。

- 用户应该能够验证他们的账户信息,以确保输入的信息准确可用。

- 系统应该能够保存用户的注册信息,并在需要时将其用于登录和其他相关功能。

- 系统应该能够提供错误提示和反馈,以帮助用户在注册过程中遇到问题时进行解决。

4. 非功能性需求除了功能点外,还需指定一些非功能性需求,例如性能、安全性、可用性等。

范例:- 注册过程应该在30秒内完成,以确保用户能够快速注册账户。

- 用户的密码应该经过加密存储,以保护用户的个人信息。

- 注册页面应该易于使用,用户能够轻松地找到和填写所需的信息。

5. 附加要求在需求中,还可以列出一些额外的要求,例如技术要求、测试需求等。

范例:- 该功能应该与现有的用户数据库进行集成,以实现用户信息的统一管理。

- 测试团队应该编写适当的测试用例,并在上线前对注册功能进行全面测试。

以上是一些常见的需求格式及范文,希望对你撰写文章有所帮助。

在实际工作中,需求的撰写还应根据具体项目的需求和团队的工作流程进行调整和优化。

示例2:需求格式及范文格式:标题:需求格式及范文引言:介绍需求格式的重要性,以及撰写需求的目的。

如何写好产品需求文档PRD

如何写好产品需求文档PRD

如何写好产品需求文档PRD十步做好产品需求文档做好产品需求文档的这十步,是经过长期的实践经验和反复验证而得到的。

可能这里描述的不是很全面,但他已经足够让你做一个成功的产品需求文档。

做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。

第一步:做好准备工作你要做的是一个让人无可争议的产品,为了做好他,你必须做好前期的准备工作。

你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。

你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。

这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。

建立良好的交流也非常重要,它会影响着产品团队。

如果你的准备工作做的够好,你也会变得越来越有信心和说服力。

第二步:确定产品的目的任何一个好的产品都开始于一个需求。

你必须清楚的了解这个需求,你的产品如何达到这个需求。

产品经理需要提出一个清晰、简明的价值主张,让它很容易被接受,要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。

虽然这听起来很简单,但是也只有少数产品才有这样的价值主张。

考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。

假设你在做电梯的时候遇到公司CEO,他问你产品的意图是什么,你能在电梯到达之前回答这个问题吗?如果不能,你就还有工作需要做。

也许是你的说明没有针对性,他可能表现出来和其他产品做的没有什么明显区别;也许你提出的观点不能和你的用户产生共鸣;也许你解决的是一个非常规的问题,可能你想应用一种技术。

这个价值主张可能需要满足公司的产品战略。

注意你不需要阐述太多的细节,从某些方面来说,一个有价值的观点应当是越简越好。

产品需求需要确切的指出这个产品发布的目标,同样的这个目标也有优先之分。

例如,你的目标可能是:1)易用,2)零售价不足$100,3)和前期产品很好的结合。

提高需求编写质量的十个方法

提高需求编写质量的十个方法

白皮书提高需求编写质量的十个方法Dominic Tavassoli版本12006年8月2日本文档所含信息归Telelogic AB所有。

未经Telelogic AB明确的书面许可,不得以任何方式使用本文档所含信息,或对本文档的全部或部分内容进行复制或影印。

Telelogic®和Telelogic DOORS®是Telelogic的注册商标。

Telelogic DASHBOARD™和Telelogic FOCAL POINT™是Telelogic AB的商标。

目录简介 (3)定义良好需求 (4)编写良好需求 (5)最佳方法1:结构化需求 (5)最佳方法2:管理客户需要、需求和合同文本,并将三者相互关联 (5)最佳方法3:管理约束条件 (5)最佳方法4:将需求直观化 (6)最佳方法5:可测试需求 (6)最佳方法6:缩小业务与开发之间的差异 (6)最佳方法7:需求变更控制 (7)最佳方法8:捕捉和跟踪计量和趋势 (7)最佳方法9:知识库示例 (7)最佳方法10:灵活重用需求 (8)结论 (9)关于Telelogic DOORS (10)关于作者 (11)关于 Telelogic (12)简介需求定义和管理向来被视为交付成功系统和软件项目所不可或缺的必要环节;各种标准、规则和质量改进措施(如CMMI®)也都要求实施这些过程。

对于IT、系统和产品开发项目—甚至需要进行合同关系管理的所有活动而言,创建和管理需求都是一个挑战。

组织需要有效定义和管理需求,以确保他们在遵守规则、保证进度和控制预算的同时,能够满足客户需求。

需求表述不善可带来毁灭性影响;其所引发的多米诺效应可导致耗时返工、延期交付及预算超支。

更糟的是,不良需求还可能造成业务违规,甚至导致人员伤亡。

更好地编写需求是一种投资收益高、见效快的活动。

本白皮书阐述了“良好”需求的特征,并介绍了有助于更好地编写需求的十佳做法。

定义良好需求由于需求是所有开发项目的基础,因此团队需要了解“良好”需求的特征。

产品需求文档8要素

产品需求文档8要素

产品需求文档8要素标题:产品需求文档8要素:确保产品开发成功的关键摘要:产品需求文档是新产品开发中至关重要的一环。

本文将详细介绍产品需求文档的八个关键要素,包括目标市场分析、功能需求、非功能需求、用户故事、界面设计、技术限制、项目计划和风险管理。

通过深入探讨这些要素,你将更加全面地理解如何编写高质量的产品需求文档。

引言:在当今竞争激烈的市场环境中,产品的成功与否往往取决于产品需求文档的质量。

一个好的产品需求文档不仅能够明确产品的目标和功能,还能为产品团队提供清晰的指导和沟通渠道。

为了确保产品开发的成功,本文将介绍产品需求文档的八个关键要素。

一、目标市场分析:在编写产品需求文档之前,了解目标市场是至关重要的。

这包括分析目标市场的需求、竞争对手和潜在用户群体等方面。

通过深入了解目标市场,产品团队可以更好地定位产品的定位和目标,并确保产品能够满足市场需求。

二、功能需求:功能需求是产品需求文档最核心的部分。

它描述了产品需要具备的功能,包括基本功能、附加功能和特殊功能等。

在编写功能需求时,需要具体、清晰地描述各个功能,并根据优先级进行排序。

同时,还应该注意与目标市场的需求保持一致。

三、非功能需求:除了功能需求,产品还需要满足一些非功能需求,如性能、安全性、可用性等。

这些非功能需求对于产品的整体体验至关重要。

在产品需求文档中,要详细描述这些非功能需求,并根据优先级进行排序。

四、用户故事:用户故事是一种以用户的角度描述产品需求的方法。

通过用户故事,产品团队能够深入了解用户的需求和期望,并据此调整产品的功能和设计。

在产品需求文档中,要用简练的语言描述用户故事,并与功能需求相结合,确保产品能够满足用户的真实需求。

五、界面设计:产品的界面设计对于用户体验起着至关重要的作用。

在产品需求文档中,要详细描述产品的界面设计要求,包括布局、颜色、字体等方面。

同时,还要考虑到不同设备和平台的兼容性,确保产品在不同环境下都能够提供良好的用户体验。

需求报告范文

需求报告范文

需求报告范文需求报告是一种将用户需求、设计要求、市场趋势等信息进行分析整合后形成的重要文档。

需求报告的编写非常关键,能够帮助设计团队更好地了解需求,并且在产品设计上做出更精准的决策。

下面是关于需求报告范文及其案例。

需求报告范文的内容通常有以下几个部分:1. 引言:简要介绍需求报告的目的,对产品的概述和市场分析。

2. 用户分析:对目标用户的需求、特点、使用习惯等方面进行分析,尽可能了解用户的心理和行为习惯。

3. 功能需求:列出认为应当在产品中实现的功能和特性,并细化相应的设计要求,例如性能、可靠性、易用性等。

4. 界面设计:以用户为中心,考虑界面的总体布局、样式等,保证用户操作的系统性和易用性,尽可能简化操作流程。

5. 技术实施:根据产品类型和设计要求,对技术实现进行分析和讨论,保障产品的技术可行性和实用性。

6. 项目管理:对于设计团队的具体实施方案、进度、工作分配等进行统筹规划,并提出可能的风险预警和应对策略。

下面分别列出三个不同领域的需求报告案例:1. 网络音频产品需求报告引言:本报告旨在评估网络音频市场需求及目标用户,为优化设计提供决策参考。

用户分析:目标用户为年龄在18-35岁之间的音乐爱好者,主要存在于在线平台和社交网络的活跃用户中。

用户需求集中于音频品质与设备互通性、标签分类和分享交流、多元化快捷的服务体系等。

功能需求:音频的输出品质应达到高保真标准,能够与其他蓝牙设备兼容。

用户需要具有标签分类功能,能够快速搜索、展示、分享自己喜欢的歌曲、歌手、音乐频道等。

同时用户应该享有个性化定制播放列表、本地音乐缓存和高品质的在线直播功能。

界面设计:以简洁、鲜明、具有视觉冲击力和可操作性的风格界面呈现,附加用户社交元素如动态、评论、互动等。

应该采用简洁流畅的操作流程,使用户能够快速地完成想要的操作。

技术实施:在音质实现方面,可以沿用已成熟的媒体处理技术。

在设备兼容性方面,应使用基于蓝牙5.0的新一代通讯技术。

何为MRD,什么是MRD,写好MRD的10种技巧

何为MRD,什么是MRD,写好MRD的10种技巧

何为MRD,什么是MRD,写好MRD的10种技巧何为MRD,什么是MRD,写好MRD的10种技巧MRD-“市场需求文档”,是产品经理或者产品市场经理编写的一个产品的说明需求的文档。

这些文档用于计划一个新产品或修正一个已有的产品,是被工程师团队开发产品时使用。

在硅谷的一些软件公司,MRD仅仅覆盖high-level的功能。

在这种情况下,产品经理通过创建了另一个文档-通常指的是PRD(产品需求文档)来定义更加详细的产品需求。

在本文中,我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的,为工程师团队传达产品需求为目的的文档。

1、从用户角度的编写从用户角度编写需求内容。

使用“用例(Use Case)”和“用户角色(User Personas)”来达到这个。

考虑用以下两种方法来详细说明你们公司正在开发的SFA(sales force automation)软件的“Login”的功能性。

方法A:用户通过一个要求用户提供证书的登陆界面,然后软件允许用户带着特定的权限进入系统。

软件鉴别这些证书,在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。

方法B:Mike是一个销售经理,Cathy是一个销售代表。

当他们打开软件,他们看到登陆界面。

他们通过用户名和密码进入系统。

如果用户名和密码是正确的,他们能登进系统。

一旦登陆进系统,Mike能访问软件所有的功能部件。

Cathy只能访问那些对销售代表有有效的功能部件。

哪个方法更加容易阅读和理解?就我的看法,毫无疑问,"方法B"。

还有,它同时减少了令人烦恼的阅读!2、使用Screen Shots使用Screen Shots或者mockup来你的想法。

市场需求文档撰写

市场需求文档撰写

市场需求文档撰写市场需求文档(MRD,Market Requirements Document)是一份描述市场上对产品或服务的需求和期望的文件。

这份文档将产品经理、市场营销人员、工程师和其他利益相关者引向一个共同的目标:满足客户需求,提供他们需要的产品或服务。

在撰写市场需求文档时,需要考虑客户的需求、行业趋势、市场规模、竞争对手的优势和劣势等多个方面,具体如下:1. 客户需求一份好的市场需求文档需要详细描述客户的需求和期望。

这些需求和期望可以从多个渠道得到,如客户反馈、市场调研、竞争对手的产品等。

其中包括客户关心的问题、问题的优先级、产品的关键功能和其它要求。

2. 行业趋势在编写市场需求文档时,必须认真分析当前行业发展趋势,包括新技术的崛起、创新产品的出现、消费者偏好的变化等。

将这些趋势融入到文档中,可以更好地创造出符合市场需求的产品。

3. 市场规模市场规模是指某一市场中活跃用户数量和销售额。

在编写市场需求文档时,需要了解市场规模,以确定产品是否有足够的空间在市场上生存和增长。

这不仅是重要的市场分析部分,还是有效评估市场机会的关键信息。

4. 竞争对手的优势和劣势了解竞争对手的优势和劣势是编写市场需求文档时的重要因素之一。

可以通过市场调研、竞品分析和陈述竞争对手的营销战略等手段来收集这些信息,并加以分析和对比,从而确定产品的差距和未来需要改进的方向。

5. 产品定位描述产品在市场中定位的目的是明确产品的售价、目标受众、关键功能和核心卖点,强化产品的差异性,便于与其他竞争的产品进行区分。

这需要根据产品的特点和目标市场进行详细的考虑和分析。

6. 产品特点在市场需求文档中描述产品的特点和功能,既可以帮助客户更好地了解你的产品,也可以让工程师更好地理解产品设计的需求。

同时,这也是与竞争对手的关键区别,对于产品主打点的呈现非常重要。

7. 发布计划发布计划需要描述产品的时间表,包括在不同时间节点所要完成的任务、测试 / 修改 / 验收的任务、预计产品发布的日期等。

MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA

MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA

通俗名解:MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA、(2009-11-24 14:59:19)转载标签:it 分类:网站运营经常听到有朋友在群里面问一些专有名词的缩写含义,恰巧在网上找资料看到这个帖子,故此转帖过来。

希望对朋友们有所帮助。

MRDMarket Requirements Document,市场需求文档。

获得老大的认同后,产品进入实施,需要先出MRD,具体来说要有更细致的市场与竞争对手分析,通过哪些功能来实现商业目的,功能/非功能需求分哪几块,功能的优先级等等。

实际工作中,这个阶段PD可能的产出物有Mind Manager的思维图,Excel的Feature List等。

市场需求文档(MRD)重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。

与BRD指出商业问题和解决这些问题的解决方案不同,MRD更深入提议解决方案的细节。

它包括一些或者所有这些细节:a. 解决商业问题所需要的特色b. 市场竞争分析c. 功能和非功能需求d. 特色/需求的优先级e. 用例MRD通常是由拥有产品经理,产品营销经理或者行业分析师头衔的人撰写的。

MRD通常是一份连续的5-25页Word文档,或者正如之后描述那样在一些机构中甚至更长。

BRDBusiness Requirements Document,商业需求文档。

这是产品声明周期中最早的问的文档,再早就应该是脑中的构思了,其内容涉及市场分析,销售策略,盈利预测等,通常是和老大们过的ppt,所以也就比较短小精炼,没有产品细节。

商业需求文档重点放在定义项目的商业需求。

BRD要能说出客户碰到的一个或多个商业问题,并且通过公司的产品能够解决这些问题。

接着建议一个方案——通常是新产品或者现有产品的改进来解决这些问题。

BRD也可能包括一个高级的商业案例,例如收益预测,市场竞争分析和销售/营销策略。

BRD通常是由拥有产品经理,产品营销经理或者行业分析师头衔的人撰写的。

不要找模板了,一篇文章告诉你商业需求文档(BRD)怎么写

不要找模板了,一篇文章告诉你商业需求文档(BRD)怎么写

不要找模板了,一篇文章告诉你商业需求文档(BRD)怎么写撰写BRD是产品经理或者说想表达自己想法的人,尤其是需要宣讲和汇报工作的人必备的硬技能,今天这篇文章就教大家怎么来系统地写商业需求文档。

不论在工作还是生活中,我们总会产生一些好想法,或者有机会去做一些新的事情,比如领导说,我们的竞争对手做了一个xx产品,让你想想看我们要不要做,或者你想到一个好的产品解决方案,能弥补现在产品的短板,你想把它实现了,如果你刚参加工作,以上情况都没有遇到过,那么你总有过想去开发一个APP,做一个网站,或者想去开一个自己的小店这样的想法吧!当遇到这样的场景,我们要做的第一件事情,不是马上行动,而是去分析这个事情,梳理思路,描绘出蓝图,然后把它表达出来,为接下来的行动争取充足的资源,这些资源包括资金,场地,软件,硬件,研发,运营等。

你要获得这些资源,就要说服掌握这些资源的人,告诉他们,你要做一件什么样的事,做这个事需要用到哪些资源,用在什么地方,怎么使用,能获得什么样的收益,用一个系统的思路和语言表达来说服他们,这个系统的思路和语言表达的输出物,就是我们经常说的商业需求文档(BRD), 如果你是创业者,对应的就是商业计划书(BP).撰写BRD是产品经理或者说想表达自己想法的人,尤其是需要宣讲和汇报工作的人必备的硬技能,今天这篇文章就教大家怎么来系统的写商业需求文档,内容主要包含以下5个方面:1.在什么情况下需要写BRD2.BRD的构成要素3.BRD撰写前的准备工作4.BRD的撰写5.BRD的使用场景6.注意事项一. 在什么情况下需要写BRD在项目的管理流程中,有一个关键的决策的动作叫“立项”,这个动作不限于在互联网项目的管理,在所有的规范的项目管理流程中也都有,立项是一个项目的风水岭,立项了,就是决定一个产品要正式开始做了,在立项前,往往要进行大量的考察和调研,最后基于调研结果输出一个方案,这个方案就是BRD。

在BRD中不只要说明为什么要做,还要说明打算怎么做,以及需要的资源和预期收益,决策者依靠它来决定一个项目要不要立项,撰写的人依靠它来获取资源。

软件需求工程的方法与技巧

软件需求工程的方法与技巧

软件需求工程的方法与技巧软件需求工程是软件开发过程中至关重要的一环,它旨在确定和分析软件系统的需求,为软件开发提供准确的指导和规范。

本文将介绍一些软件需求工程的方法与技巧,帮助开发团队更好地理解和满足用户需求。

一、需求收集需求收集是软件需求工程的起点,它决定了后续开发工作的方向和内容。

以下是一些常用的需求收集方法和技巧:1. 用户访谈:与用户面对面交流,了解他们的期望和需求。

2. 用户调研:通过问卷调查等方式了解用户群体的特点和偏好。

3. 竞品分析:研究市场上类似产品的特点和优势,为产品定位和功能设计提供参考。

4. 需求文档分析:分析现有的需求文档,理解已有需求和问题,并提出改进建议。

二、需求分析与建模需求分析是对需求进行深入的分析和理解,并将其转化为可执行的任务。

以下是一些常用的需求分析方法和技巧:1. 用例分析:通过对用户故事的分析,识别出各种可能的用例,并绘制用例图。

2. 数据流图:分析系统中的数据流和处理流程,帮助识别功能和流程中的问题和风险。

3. 类图:识别系统中的各个对象和它们之间的关系,为后续的设计和实现提供依据。

4. 业务流程图:通过可视化展示业务流程,帮助开发团队更好地理解业务逻辑和流程。

三、需求验证与确认需求验证与确认是确保需求的准确性和可实施性的重要过程。

以下是一些常用的需求验证方法和技巧:1. 原型验证:通过制作交互式原型,模拟用户界面和功能,验证需求的可行性和用户友好性。

2. 需求审核:组织需求评审会议,邀请相关人员对需求进行审核和确认。

3. 需求追踪:使用需求追踪工具,对需求进行跟踪和管理,确保每个需求都得到满足和验证。

四、需求文档编写需求文档是对软件需求的详细描述和规范,它对软件开发起到了桥梁和纽带的作用。

以下是一些常用的需求文档编写方法和技巧:1. 结构化文档:按照一定的结构和规范编写需求文档,包括需求概述、功能需求、非功能需求等部分。

2. 使用简洁明了的语言:避免使用过于复杂的术语和句子结构,使文档易于理解和使用。

MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA

MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA

通俗名解:MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA、(2009-11-24 14:59:19)转载标签:it 分类:网站运营经常听到有朋友在群里面问一些专有名词的缩写含义,恰巧在网上找资料看到这个帖子,故此转帖过来。

希望对朋友们有所帮助。

MRDMarket Requirements Document,市场需求文档。

获得老大的认同后,产品进入实施,需要先出MRD,具体来说要有更细致的市场与竞争对手分析,通过哪些功能来实现商业目的,功能/非功能需求分哪几块,功能的优先级等等。

实际工作中,这个阶段PD可能的产出物有Mind Manager的思维图,Excel的Feature List等。

市场需求文档(MRD)重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。

与BRD指出商业问题和解决这些问题的解决方案不同,MRD更深入提议解决方案的细节。

它包括一些或者所有这些细节:a. 解决商业问题所需要的特色b. 市场竞争分析c. 功能和非功能需求d. 特色/需求的优先级e. 用例MRD通常是由拥有产品经理,产品营销经理或者行业分析师头衔的人撰写的。

MRD通常是一份连续的5-25页Word文档,或者正如之后描述那样在一些机构中甚至更长。

BRDBusiness Requirements Document,商业需求文档。

这是产品声明周期中最早的问的文档,再早就应该是脑中的构思了,其内容涉及市场分析,销售策略,盈利预测等,通常是和老大们过的ppt,所以也就比较短小精炼,没有产品细节。

商业需求文档重点放在定义项目的商业需求。

BRD要能说出客户碰到的一个或多个商业问题,并且通过公司的产品能够解决这些问题。

接着建议一个方案——通常是新产品或者现有产品的改进来解决这些问题。

BRD也可能包括一个高级的商业案例,例如收益预测,市场竞争分析和销售/营销策略。

BRD通常是由拥有产品经理,产品营销经理或者行业分析师头衔的人撰写的。

产品需求文档(PRD)的写作方法

产品需求文档(PRD)的写作方法

产品需求文档(PRD)的写作方法无论我们做什么事都讲究方式方法,写产品需求文档(以下称PRD文档)也是如此,之前我通过五篇文章分享了自己写PRD文档的一些方法,而这一篇文章主要是对之前五篇文章进行整体的摘要介绍,帮助大家快速了解写作流程。

产品需求文档(PRD)的写作五篇章:1、写前准备(信息结构图)2、梳理需求(产品结构图和用户流程图)3、原型设计(手绘原型,灰模原型,交互原型)4、撰写文档(PRD文档)5、用例文档(UML用例图、流程图)1、写前准备(信息结构图):在写PRD文档之前,我们需要先罗列出产品功能的信息内容,这一步是将想法逐渐清晰的第一步,也是帮助我们接下来规划功能的辅助信息,同时也可以辅助服务端技术人员创建数据库。

因为这是第一步,所以我们不需要罗列的很详细,在之后的步骤里,我们会逐步改进和完善信息内容。

例如一篇文章的信息内容主要有:文章标题、文章正文、文章作者、发布时间、所属分类。

初始的功能需求只有这些信息内容,但是在之后的功能规划中逐渐更加细致的考虑时,可能会增加或者删减,因此第一步我们不用刻意的追求信息的全面。

罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主要的是能够清晰易懂,我最常用的方法就是思维导图,因此我称这一步为信息结构图。

2、梳理需求(产品结构图和用户流程图):当我们对产品的信息结构了解后,我们就需要规整脑海中的产品需求,让想法更加结构化,因此这一步是梳理产品的需求。

我们首先要罗列出产品的频道及页面(产品结构图),其次再基于产品结构图梳理出频道及页面中的功能,并延伸构建出用户的操作流程(用户流程图)。

以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解,类似鸟瞰式的一目了然,也方便调整完善。

3、原型设计(手绘原型,灰模原型,交互原型):当我们逐渐清晰了产品的需求后,并梳理了产品的各个频道及页面,那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。

市场需求文档

市场需求文档

市场需求概述市场需求是指在特定时间和特定地点,买方对特定产品或服务的需求量。

它是指导企业产品开发和营销活动的重要依据。

了解市场需求对企业制定合理的发展战略和产品定位至关重要。

本文将介绍市场需求的概念、分析方法以及如何满足市场需求。

市场需求的概念市场需求是指市场上消费者对特定产品或服务的需求量。

它可以通过市场调研和数据分析等方法来确定。

市场需求是由消费者个体需求的总和所构成的,它受到多种因素的影响,包括人口结构、经济状况、消费习惯、文化背景等。

市场需求的分析方法1. 市场调研市场调研是了解市场需求的重要手段。

它可以通过问卷调查、访谈、观察、数据分析等方法来收集市场信息。

市场调研可以帮助企业了解消费者的需求、竞争对手的情况以及市场规模等重要信息,从而为制定产品策略提供依据。

2. 数据分析数据分析是通过统计和数学方法对市场数据进行分析,以识别和理解市场需求的变化趋势。

数据分析可以通过收集和分析历史销售数据、市场份额数据、市场增长率等数据来洞察市场需求的潜在趋势,为企业决策提供参考。

3. 市场预测市场预测是对未来市场需求的估计和预测。

它可以根据当前市场状况、行业发展趋势以及竞争对手的动态来进行。

市场预测可以帮助企业在产品研发、生产和营销方面提前做好准备,以满足未来的市场需求。

如何满足市场需求1. 了解目标客户了解目标客户是满足市场需求的关键。

企业需要了解目标客户的特点、需求、偏好和购买决策等方面的信息。

通过市场调研和数据分析,企业可以对目标客户进行细分,从而更好地满足他们的需求。

2. 提供有竞争力的产品或服务为了满足市场需求,企业需要提供有竞争力的产品或服务。

这意味着产品或服务要优于竞争对手,在品质、性能、价格和服务等方面具有优势。

企业可以通过研发创新、提高生产效率、优化供应链等方式来提升产品或服务的竞争力。

3. 建立良好的品牌形象良好的品牌形象可以帮助企业吸引更多的目标客户,并提高他们对产品或服务的认知和信任。

如何写好商业需求文档

如何写好商业需求文档

产品经理简称PM,是指在公司中针对某一项或是某一类的产品进行规划和管理的人员,主要负责产品的研发、制造、营销、渠道等工作。

产品经理是很难定义的一个角色,如果非要一句话定义,那么产品经理是为终端用户服务,负责产品整个生命周期的人。

产品经理需要考虑目标用户特征、竞争产品、产品是否符合公司的业务模式等等诸多因素。

近年来互联网产品经理火热,一起看下为大家精选的互联网产品经理学习文章。

前言:做产品的都听说过三大文档,BRD、MRD、PRD,本文教你写好BRD的正确姿势。

一、什么是商业需求文档BRD是英文”Business Requirement Document“的缩写,根据英文直译过来就是”商业需求文档“的意思,商业需求文档是产品生命周期中最早的文档,其内容涉及市场分析、销售策略、盈利预测等,是为企业高层提供决策的演示文档,一般用PPT形式,不涉及产品细节,需要简明扼要的向决策层展示项目的商业价值,需要投入的推广和研发成本,然后领导觉得这个项目可以做,大腿一拍,“干”,这个时候商业需求文档就起到它的作用了!二、商业需求文档给谁看相比与产品需求文档(PRD),大部分产品人员没写过商业需求文档,在大部分公司,产品人员其实只是一个执行角色,做啥事情都是老板定的,产品经理只需要执行好,导致大部分产品经理对商业需求文档很陌生,这也是能理解的。

写商业需求文档主要是给领导看的,主要的目的是让领导为你的项目提供必要的财力、人力资源支持,所以写商业需求文档更像是写一个商业计划书,不同的是商业计划书是给资方看的,而你的商业需求文档是给你的领导看的。

哪都有那些领导要看商业需求文档呢?资本型:就是管账的,这类人能够为我们提供充足的产品研发和推广经费,一般是首席财务官(CFO)、财务总监。

这类人比较关注投入产出比(ROI),说服他们不仅要展示需要那些成本,更要给出明确的收益预测,不要展示说:这个项目投入2万,能获得4万收益”而要展示说:“第一个月能获得1万收益,第二个月能获得2万收益,第三个月能获得3万收益..."这样的对比体现增长率,给人以无限的遐想。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

写好市场需求文档的10种技巧
MRD-“市场需求文档”,是产品经理或者产品市场经理编写的一个产品的说明需求的文档。

这些文档用于计划一个新产品或修正一个已有的产品,是被工程师团队开发产品时使用。

在硅谷的一些软件公司,MRD仅仅覆盖high-level的功能。

在这种情况下,产品经理通过创建了另一个文档-通常指的是PRD(产品需求文档)来定义更加详细的产品需求。

在本文中,我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的,为工程师团队传达产品需求为目的的文档。

1、从用户角度的编写
从用户角度编写需求内容。

使用“用例(Use Case)”和“用户角色(User Personas)”来达到这个。

考虑用以下两种方法来详细说明你们公司正在开发的SFA(sales force automation)软件的“Login”的功能性。

方法A:
用户通过一个要求用户提供证书的登陆界面,然后软件允许用户带着特定的权限进入系统。

软件鉴别这些证书,在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。

方法B:
Mike是一个销售经理,Cathy是一个销售代表。

当他们打开软件,他们看到登陆界面。

他们通过用户名和密码进入系统。

如果用户名和密码是正确的,他们能登进系统。

一旦登陆进系统,Mike能访问软件所有的功能部件。

Cathy只能访问那些对销售代表有有效的功能部件。

哪个方法更加容易阅读和理解?就我的看法,毫无疑问,"方法B"。

还有,它同时减少了令人烦恼的阅读!
2、使用Screen Shots
使用Screen Shots或者mockup来你的想法。

我们中很多人都听说过“一张图片好比一千个文字”。

当提到写MRD的时候,一个screen shot好比一千个文字!
举个例子,看看下面这个screen shot,你需要多少字来描述?我想可能不只一千个字。

3、用简单的语言编写
在我超过11年的行业中,我通常注意到的(更多是令我懊恼)一件事是用很做作的语言来写的MRD。

我想这个主要是因为MRD听起来是正式的和专业的原因吧。

相反,想象你写的MRD是写给你的在工程师团队工作的朋友。

你的目标是帮助他理解你需要什么,以便于他能开发产品实现这些需要。

这个将有助于你避开陷入那些令读者人厌烦(有时他们会把MRD撕碎然后再碎片为给碎纸机)的用做作的语言的陷阱。

还有:
a)保持简短的语句,把长的语句分解成多个小的语句。

b)避免大篇幅的连续文本,把他们分解成多个小的章节。

c)把大块文本内容分解成,screen shots,表格、重点列表等等。

4、小心的使用模板
我发现MRD模板非常有用。

他们的几个好处包括:
a) 模板提供了一个标准的格式,使那些不得不阅读大量MRD的读者更加容易阅读。

b) 模板让新的产品经理快速的写MRD变得容易,因为公司与公司之间的MRD内容是不同的。

c) 模板确保你不会忘记所有需要在MRD中覆盖描述的部分;
然而,一些公司过分的使用模板。

一个硅谷最大的公司之一有一个所有部分被强制使用的近60页的模板。

我觉得这个让人觉得非常难以忍受并且有几个负面的作用:
a) 产品经理害怕但又不得不写MRD - 几乎和不得不和Dick Cheney去南德克萨斯打猎一样(译者按:美国副总统Dick Cheney在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴)。

b) 工程师团队害怕但又不得不阅读MRD。

c) 写MRD和读MRD都需要花大量的时间。

我推荐你使用MRD模板,但确保他们不要过分的长。

还有如果需要,确信产品经理可以灵活的跳过模板某些部分和创建新的内容。

5、区分需求的优先级
在这些年里,我从来没有碰到一个工程师团队实现了MRD里包括的所有特性的没有删减的
项目-通常由于那些我们控制之外因素!
这就是说作为MRD作者的产品经理,当出现需要决定取舍的时候,应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。

区分需求的优先级是一个最好的能帮助完成这个事情的办法。

我发现把需求分等级就像P1,P2,P3...这样工作的刚刚好。

在这个分类中-P1是最高优先级,P2是第二高优先级等等。

最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。

在实际实践中,最好是和其他多种因素一起综合决定。

我推荐你只要包括P1,P2,P3的需求在你的MRD中,在多数的项目中更低的优先级可能未必会实现。

还有这样也让MRD变得更加容易读。

6、说明"是什么"和"为什么",但不要"如何"
产品经理为理解客户的需求负责,然后基于这些理解定义什么和为什么需要开发.
有一件比任何事情让开发者发疯就像在几英里外都能听到的汽笛在他们耳边尖叫一样的是一个令人痛苦的详细描述了怎样实现每一个需求细节的MRD。

考虑你们公司正在开发的以下两种描述CRM“Login”功能的方法。

推荐-描述“是什么”
Mike是一个销售经理,当他打开我们的CRM软件,他会看到一个登陆界面...登陆界面建议提供“记住我”复选框。

如果Mike在点击登陆按钮之前选择了该复选框,我们的软件将记住并且在他下次来到登陆界面时自动填写他的名字。

不推荐-描述“怎么样”
Mike是一个销售经理,当他打开我们的CRM软件,他会看到一个登陆界面...登陆界面建议
提供“记住我”复选框。

如果Mike在点击登陆按钮之前选择了该复选框-将通过Javascript 保存他的名字以cookie的方式写到他的硬盘。

当cookie写到硬盘后,用户名和密码将被发送到服务器。

下一次Mike来到登陆界面时,Javascript 将读取他的cookie,成功读取后,Javascript 将是适当的DOM命令填充登陆页面上的用户名。

好的产品经理擅长理解用户的需求和描述什么需要实现,好的工程师擅长决定怎么样实现它。

好的工程师希望能自由的决定怎么样最好的实现用户希望得到的东西。

我注意到有技术背景的产品经理尤其喜欢描述“如何实现”。

如果这些描述的就是你,应该从现在开始不要再做这样的事了。

工程师们将会感谢你。

附:这里有一些例外的情况-当在描述“是什么”中描述“怎么样”是必要的,当描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么样”的情况。

7、覆盖非功能性需求
尽管功能性需求描述产品的功能,非功能性需求描述系统特性,如:
a)性能
b)可伸缩性
c)可用性
d)国际化
e)等等...
我注意到因为许多产品经理和产品市场人员认为这些是“技术细节”,而在MRD中被忽略。

我发现这些是我的MRD中非常重要的一部分,工程师们会非常感激在MRD中定义这些需求。

要点:当写非功能性需求的时候,尽可能的是使他们可度量(可测试)。

否则,QA不能测
试它们,你将没有办法知道完成的产品是否已经实现了这些非功能性需求。

8、评审&修正
我有一个朋友-我们叫他Matt(他的真名叫Steve)。

Matt在硅谷一家成功的公司做产品经理工作。

最近我在午餐的时候碰到他是告诉我一个非常有趣的故事。

他们雇用了一个有三年经验的产品经理。

在他被雇用的几个月里,不知何故他让他的产品经理同事和工程师一样疏远他。

他是罪犯?他基本上认为他的MRD就像一个法令。

他写了它,但不想和任何人评审或在反馈的基础上修改它。

他仅仅想工程师团队没有问任何问题的拿着它并实现它们!
不要像Matt的同事那样。

确信做到和你的产品经理伙伴和工程师团队评审你的MRD。

保持一个敞开的思想然后在评审反馈的基础上更新MRD。

这将帮助你写出更好的MRD,工程师将喜欢你(或者至少少恨你一些),你的团队也将创造更好的产品。

9、定义市场目标和定位
大部分我看到过MRD在覆盖了市场目标(谁将买和使用户你的产品)和定位(与竞争对手的产品比你的产品定位怎么样的)的方面做的很好。

我还看到过一些没有描述市场目标和定位的MRD,他们通常会这样争辩:“为什么工程师们需要知道这些?拿到定义了什么是需要的还不够吗?”
这些问题(谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的)的确有一些正面价值,我发现许多工程师想知道为什么一个产品或特性要开发,谁将使用他们,什
么是他们可以另外选择办法。

这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。

我的建议的尽可能的(在MRD中)包含这些信息。

- 它们不一定要很详细,只要包含几个段落就足够了。

10、包含一个术语表
如果你的MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一个术语表。

当你像这样说“我们的软件将提供SME用户通过选择W AP或PSMS开MRC帐单”时,这个将确保你的所有读者(有些可能不是技术人员)理解你的意思是什么。

相关文档
最新文档