下载文档原格式
软件需求管理一大工具作者：周盛来源：《现代营销·理论》2020年第08期摘要：当前传统瀑布式项目管理方法中的需求管理模式针对软件类项目存在着一定的弊端导致项目失败的风险增大。
如何利用用户故事地图的方法来有效的避免传统需求管理中的疏漏，对用户故事地图进行了简介，总结了用户故事地图的优势以及关键点。
关键词：用户故事地图;需求管理引言通常在一个瀑布模型的项目管理过程中，会产生如（图1）所述的项目工作流。
在项目运行初期，用户会面临一个问题，他们只会参与到撰写需求以及最终测试的这两个阶段中。
但是在需求文档制作完成之后直到最后的测试阶段之前，用户一般不会了解整个项目的运作情况和实施进度。
无疑这将会在软件开发工程项目中增加了项目（如用户需求的演进变更史，项目经理的统筹协调，开发工作者对用户需求的实际理解程度不一等等）不成功的风险。
而在设计思维一整套方法论体系中，利用用户故事地图工具能较大程度优化项目进展阶段中碰到的问题，规避安全隐患，加强协作体系中可靠性，从而显著提升各工作环节的进度及完成质量。
什么是用户故事？用户故事地图是设计思维的其中一个实用工具。
在20世纪90年代末，Kent Beck先生在开发软件的过程中发现，最大的困扰就是如何使用文档来精确的记录客户想要的东西。
传统行业中有很多人采取在需求文档上各自签字的方式来证明互相已经达成了共识，然而同样一份文档，阅读的人不同，各自得到的信息可能并不一致。
心理学家Jerome Bruner发现，用讲故事的方式来陈述事实，给人留下的印象在深刻程度上高出单独陈述事实的22倍。
用户故事的核心思想即是用一种非正式的文档记录方式，最自然易懂的语言来描述实际想要实现的功能或要求。
以客户或者用户的观点撰写下有价值的功能和框架等来帮助项目中不同各方对需求更好的理解。
在这个基础上，可以更好的利用用户故事地图对项目进行评估筹算，制定发布计划，最终推动整个项目顺利交付。
用户故事的三个关键点：卡片（Card）用户在一堆card上写下对产品的期望功能和特性。
基于需求的测试管理解决方案概述嵌入式系统开发一般分为需求分析、概要设计、详细设计、产品实现、测试等阶段，每个阶段的工作都是围绕着不同类型的需求开展的，基于需求的测试管理是当前亟待解决的问题。
基于IBM Rational DOORS、IBM Rational Quality Manager和NI/dSPACE Adaptor的测试管理解决方案可以满足项目所有阶段的需求管理任务和测试管理任务，包括需求定义、需求跟踪矩阵、需求变更控制、测试计划、测试用例设计、测试用例执行、测试缺陷跟踪、测试报告统计等。
通过DOORS和RQM的跨生命周期协作，实现了基于需求的测试方案，帮助测试人员尽早准备测试，实现持续的质量保障，确保设计的产品满足用户需求。
解决方案1. 需求分析人员在DOORS定义和管理需求• 集中管控所有项目需求DOORS通过直观、文档风格的用户界面为大量并行开发用户提供了统一的、可定制化的视图。
在DOORS数据库中，客户可以同时存储、访问和管理多个项目的需求信息及其衍生的项目其他文档。
• 需求的条目化管理DOORS提供了类似Word风格的编辑界面和功能，对需求采取条目化的存储方式。
• 需求的链接、跟踪、管理DOORS中可以很容易创建两个需求文档内需求条目之间的关联关系，通过关联标识用户可以很方便地跳转到相关联的需求。
• 需求变更、影响分析DOORS 包括一套完整的变更建议流程和审核系统，使得用户可以针对需求，递交变更建议及其建议的原因。
DOORS提供了基线功能，可以使用户看到不同需求版本的区别。
2. 测试人员在RQM中进行测试管理• 测试计划创建在RQM中创建的测试计划清晰地描述了项目目标和项目条目以及退出条件，同时可以跟需求集进行链接。
• 手动测试用例管理RQM中的测试用例详细描述了测试的内容，包括测试初始条件、测试步骤、期望的测试结果、真实的测试结果等，并可以将测试用例与需求相关联。
• NI TestStand/dSPACE AutomationDesk测试用例管理结合NI/dSPACE Adaptor，可将RQM和TestStand/AutomationDesk无缝集成。
需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。
这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。
本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：市场营销用户需求管理层需求开发需求管理市场营销管理层项目环境项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理在CMMI 中，需求管理的目标定义为：a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：软件需求的复用需求管理的原则和方法a. 必须与需求工程的其他活动紧密整合b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的c. 只要需求变化了，需求变更的影响就必须被评估d. 需求必须分优先级e. 需求一定要分类管理需求管理的主要工作：特定目标和特定实践特定目标●管理需求管理需求并识别需求与项目计划和工作产品之间的差异。
●SP 1.1 取得需求理解●SP 1.2 取得需求承诺●SP 1.3 管理需求变更●SP 1.4 维护需求的双向追溯性●SP 1.5 识别项目工作与需求间的差异REQM特定目标的关系SP 1.1 取得需求理解SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者l 识别出需求的接受标准：a. Clearly and properly stated得到清晰和恰当的定义b. Complete完整的c. Consistent with each other相互一致的d. Uniquely identified得到唯一标识的e. Appropriate to implement适宜实现f. Verifiable (testable)可以验证（测试）g. Traceable可追溯l 分析需求，确保符合已建立的准则。
测试管理工具大全测试管理工具大全软件测试类工具现列举如下，并非百分百全面，仅供测试同行参考：测试管理工具厂商工具名称* HP Quality Center (TestDirector)备注：Mercury公司原主打产品TestDirector于2003年开场迁移到J2EE 平台，重构了整个软件的开发，因融入了Mercury BTO理念，继而重新命名为Quality Center，它是Mercury BAC平台的重要组成局部。
2006年后是HP Quality Center。
时至今日，仍然为业内最强大、使用最广泛的测试管理工具之一，可与QTP、Winrunner、Loadrunner等集成，也与MS Office、IBM Rational等产品集成。
* IBM Rational TestManager备注：原Rational产品中专业对软件测试资源进展管理的强大工具。
包括测试用例管理、测试执行管理、测试脚本和报告管理等。
另外可与Robot结合做性能测试，更可以和RFT、RFP、CC、CQ等集成使用。
* IBM Rational Quality Manager备注：IBM2021年推出的新产品，是完全可以与HP Quality Center媲美的软件测试管理工具。
包括测试方案、工作流、任务跟踪和统计分析等功能。
* Micro Focus QADirector备注：原Compuware公司产品，是业内强大的软件测试资源和过程管理工具，虽然市场不大，但是可以和IBM Rational TestManager比拟，与原Compuware 产品集成严密。
* Micro Focus SilkCentral Test Manager备注：原Segue产品，被Borland收购后又被Micro Focus收购。
是业内强大的软件测试资源和过程管理工具，可以和IBM Rational TestManager比拟，与原Segue产品集成严密。
基于B/S结构的需求管理工具需求工程是软件工程的初始阶段，是整个软件开发过程的基础，也是项目成败的关键阶段之一。
近些年来，随着软件规模的不断增大和在各个领域的广泛应用，使软件工程研究越来越重视对需求工程的研究。
需求工程包含两方面的内容：需求开发和需求管理。
需求开发的结果是需求管理的对象，需求管理又是顺利进行需求开发的保证，因而这两方面是密不可分的。
在国际上，软件开发的质量标准——ISO9000和CMM(Capability Maturity Model)得到了普遍应用，CMM对软件开发更具有针对性。
需求管理是CMM2中的一个关键过程域(Key Process Areas)，在这个关键过程域中对如何进行需求管理进行了详细描述。
从而我们可以看出需求管理在软件开发中的地位是不可忽视的。
在软件开发过程中经常会碰到用户需求变更或者需要追溯需求的情况。
面对需求开发阶段得到的大量用户需求、需求跟踪和必要的需求变更，单靠人工进行需求管理已经显得非常力不从心，因而借助需求管理工具来完成需求管理是一个较好的解决方法。
在国外，专家们提出了多种需求建模方法，并开发了很多需求管理工具，例如RequisitePro、DOORS等商业需求管理工具。
尽管如此，现有的需求建模方法和需求管理工具仍然还有很多欠缺，有待进一步提高。
在国内，目前在需求管理理论方面的研究还不够深入，在需求管理工具这样的实践研究方面更是欠缺。
针对于国内在需求管理方面的研究现状，本文深入阐述了需求管理的理论知识，并探讨了当前的需求管理工具的优缺点，提出了一种新的需求管理模式——基于B／S结构的需求管理。
此工具可以管理和跟踪业务需求、用例需求和功能需求。
并且当有需求变更时，此工具可以给项目负责人提供变更影响分析，便于负责人控制整个开发过程。
本文的第四章和第五章详细地描述了基于B／S 结构的需求管理工具(BSRMT1.0)的开发过程，最后说明了进一步要做的工作。
你需要了解目前的项目管理趋势，使能够获得正确的执行。
有很多类型的管理工具，源码管理、问题跟踪、基于web或桌面等等。
下面提供了几大类的项目管理工具，你可以从中找到与你的业务需求匹配的管理工具。
开源项目管理工具。
Trac Open Source ProjectTrac是一个增强版的Wiki以及软件开发过程中的问题跟踪系统，采用Python 开发。
More Information On Trac Open Source ProjectRedmineRedmine 是一个开源的、基于Web的项目管理和缺陷跟踪工具。
它用日历和甘特图辅助项目及进度可视化显示。
同时它又支持多项目管理。
Redmine是一个自由开放源码软件解决方案，它提供集成的项目管理功能，问题跟踪，并为多个版本控制选项的支持。
More Information On RedmineGantt ProjectGantt Project 是一个使用 GPL 授权的开源项目管理软件，采用 Java 开发的桌面管理工具，支持 Windows、Linux 和 Mac OS X 系统，适合小型项目团队，包含进度管理和项目经理顾问功能。
More Information On Gantt ProjectiTeamwork 是个免费、基于web的团队项目管理应用，UI非常简洁。
More Information On iTeamworkphpCollabphpCollab是个开源的项目协作管理软件。
对于类似咨询机构这样的主体，依赖于公司端和客户端分割的情况，非常适合使用phpCollab。
More Information On phpCollabConsultCommConsultComm 是个轻型的，Java编写的项目，允许任何用户来管理多个项目,客户端,或者任务，并可跟踪项目时间。
More Information On ConsultCommPBwikiPBworks 在线项目工作区提供了一个丰富的、统一的、工作为中心点来管理所有形态和尺寸的项目...More Information On PBwikiTeamSCOPETeamSCOPE 是个协作项目环境的团队软件，基于web的协作工具。
/ Enterprise Architect的介绍EnterpriseArchitect的需求管理编写： Sparx Systems 公司所有材料版权归 © Sparx Systems 2008 – version 1.2/ 注册商标Object Management Group（对象管理集团），OMG ，Unified Modeling Language（统一建模语言），UML，是Object Management Group，Inc公司的注册商标。
Microsoft，MS Word 和 Excel 是Microsoft Corporation的注册商标。
本文中所涉及其它产品或公司名仅做用作标识目的，可能已被各自所有者注册使用。
/ 目录ENTERPRISE ARCHITECT的需求管理介绍 (5)使用UML的进行需求管理 (5)术语汇编 (6)需求管理入门 (6)需求建模 (6)外部需求属性 (7)为外部需求设计的功能 (8)为需求增添附加属性 (9)为需求预设标签值类型 (10)元素编号 (11)使用元素列表看到的不同的需求视图 (13)跟踪和关联外部需求 (15)使用图（ Diagrams）创建关系 (15)创建常用图 (16)关系类型 (17)关系矩阵 (17)使用层次关系窗口的可跟踪能力 (18)更改控制 (20)审计（Auditing） (20)使用基线 (22)更改外部需求的请求和问题 (22)使用维护视图（ the Maintenance View） (22)用于问题和变化的维护元素 (22)内部需求 (23)创建客户要求质量的需求报告 (25)外部需求报告 (25)内部需求报告 (26)实施报告，附属报告，和元素列表视图 (27)实施报告 (27)依赖性报告（Dependency Report） (27)元素列表视图（Element List View） (27)附加需求管理功能 (28)创建你自己的需求类型 (28)彩色编码需求 (29)自动元素命名 (29)拖放实现（D RAG AND D ROP R EALIZATIONS） (30)使用CSV导入外部需求 (30)ENTERPRISE ARCHITECT中用例介绍 (37)用例图（U SE C ASE D IAGRAM） (37)设计情景（S CENARIOS） (38)连接需求 (38)/ENTERPRISE ARCHITECT的附加功能 (39)拼写检查 (39)附加和启动外部文档 (39)词汇表功能（T HE G LOSSARY F UNCTION） (40)使用PROFILE或模板定义需求属性 (41)定义标签值 (42)用模型模板定义需求 (44)使用Profile定义需求 (44)/Enterprise Architect的需求管理介绍Enterprise Architect (EA) 是为数不多的，可将需求管理与其它软件开发规范集成为一体的UML 工具，可以在模型内直接创建需求。
IPD-PLM之需求管理需求管理模块⼀.需求概述1.需求的定义软件产业存在的⼀个问题就是缺乏统⼀定义的名词术语来描述我们的⼯作。
客户所定义的“需求”对于开发者似乎是⼀个较⾼层次的产品概念。
⽽开发⼈员定义的“需求”对于⽤户来说⼜像是详细设计了。
实际上，软件需求包含着多个层次，不同层次的需求从不同⾓度和深度反映者细节问题。
IEEE对需求的定义（IEEE软件⼯程标准词汇表）（1）⽤户解决问题或达到⽬标所需的条件或能⼒。
（2）系统或系统部件要满⾜合同、标准、规范或其他正式规定⽂档所需具有的条件和能⼒。
（3）⼀种反映上⾯（1）或（2）所描述的条件或能⼒的⽂档说明。
IEEE公布的定义包括从⽤户⾓度（系统的外部⾏为）和开发者⾓度（⼀些内部特性）来阐述需求的概念。
关键的⼀点是⼀定要编写需求⽂档。
如果只有⼀堆邮件或者纸条，会谈过⼏次或⼀些零星的对话都不能算是明⽩了客户的需求。
下⾯是⼈们对需求定义的另外的⼀些看法：●需求是⽤户所需要的并能触发⼀个程序或者系统开发⼯作的说明，并且从系统外部能发现系统所具有的满⾜⽤户的特点、功能及属性等。
●需求是指明必须实现什么规格的说明。
它描述了系统的⾏为、特性或属性，是在开发过程中对系统的约束。
综上，并没有⼀个清晰的、毫⽆⼆义性的“需求”术语存在，真正的“需求”仅存在与⼈们的脑海中。
任何⽂档形式的需求仅是⼀个模型，⼀种叙述。
我们需要确保所有项⽬承担者在描述需求的名词的理解上务必⼀致。
2.需求的特性需求具有层次性需求包含三个不同的层次----业务需求、⽤户需求、功能需求。
业务需求（business requirement）反映了组织机构或客户对系统、产品⾼层次的⽬标要求，它们在项⽬视图与规范⽂档中予以说明。
⽤户需求（user requirement）⽂档描述了⽤户使⽤产品必须要完成的任务,这在使⽤⽤例（user case）⽂档或⽂档情景（scenario）说明中予以说明。
功能需求（function requirement）定义了开发⼈员必须实现的软件功能，使得⽤户能完成他们的任务，从⽽满⾜了业务需求。
