2008年1月31日,星期四07:21

撰写有效的项目要求

由吉姆·斯旺森(Jim Swanson)撰写

需求是(或应该)成为每个项目的基础。简而言之,一个需求就是需要。这个问题, 这种需要 导致需求,而项目中的其他所有内容都建立在这些业务需求之上。

需求的重要性
许多专家认为需求是主要的非管理,非业务原因项目,无法实现按时,按预算和高质量的“神奇三角”。很少有项目能够有效地识别并正确执行项目和所有需求。

各种研究表明,需求是项目中最大的问题。项目由于需求问题而失败,大多数缺陷发生在需求阶段。如果项目团队希望按时,按预算开发高质量的软件,则他们需要在需求上做得更好。

此外,随着项目的进行,需求错误也会加剧。发现需求问题的时间越早,它们解决的成本就越低。因此,当您与利益相关者(应该是项目需求的来源)一起收集,理解和记录它们时,最佳的修复时间是正确的。

最难解决的需求问题是被忽略的问题。这确实成为需求分析师的难题。分析人员通常不知道要问什么问题,而利益相关者也不知道分析人员需要什么信息。由于分析人员不提出要求,因此利益相关者不会提出要求。

由于以下原因,许多专家还认为需求阶段是任何项目中最困难的部分:
  • 需求阶段是业务满足(IT)信息技术的地方。
  • 业务人员和IT人员倾向于说不同的“语言”。
  • 商业:“已经确定,如果我们对事态进行卷积或追溯追溯,那么如果我们非常幸运的话,我们的盈利能力可能会超出平流层原子注资的范围。”

换句话说,英语是一种模棱两可的语言,我们倾向于以一种更加歧义,令人费解且不清楚的方式来说和写。

建立有效要求
需求分析员确实对项目需求的失败或成功负责。因此,预先建立有效的需求至关重要。达到此目标的四个步骤是:启发,分析,规范和验证。

启发
术语“激发”是行业认可的术语,用于从利益相关者那里获得需求。但是,启发意味着的不仅仅是获取或收集用户的需求。

事实是,失败要求的最可靠方法之一是对您的用户说:“给我您的要求”,然后退后并“抓住”它们。

为什么不起作用?利益相关者是各自领域的专家。尽管分析师可能在IT​​领域拥有更多的专业知识,但两者会说不同的语言。利益相关者确实不完全了解IT能够为他们开发有效系统的需求。

因此,一个项目要从所有利益相关者那里获得全面,正确和完整的需求的唯一方法就是真正地激发他们。合法意味着探究和理解需求,而不仅仅是捕获或收集需求。

现实情况是,需求的质量取决于分析师征集需求的质量。

分析
分析涉及将利益相关者需求细化(或分析)到系统中,然后是软件需求。分析是至关重要的一步,在项目中经常会忽略或忽略。

分析是从利益相关者或业务术语到系统或IT术语的关键过渡。例如,利益相关者谈论“每月营销报告”,而系统谈论文件“ MoMktRpt.doc”。

分析涉及脑力劳动,但这不是一个神奇的过程(就此而言,软件工程的任何其他部分也不是)。通常结合各种建模技术进行分析。使用标准符号对创建的图表进行建模-允许分析师以严格的方式更全面地理解过程和数据。这种理解使他们能够将通常非刚性的利益相关者需求转换为更简洁,严格的系统和软件需求。

常见的建模技术包括以下内容:

  • 传统系统
  • 数据流程图以了解流程和活动
  • 实体关系图以理解数据
  • 面向对象的系统:
  • UML(统一建模语言)图,尤其是用于分析的类图,但也可能是协作图

规范
规范子阶段涉及将需求记录在格式合理,组织良好的文档中。有大量资源可用于编写和格式化良好的需求和好的文档。对于一般写作帮助,应使用有关技术(非一般)写作的书籍。主要资源是IEEE软件工程标准集。

验证方式
需求规范以草稿形式完成后,在大多数情况下,必须由作者的同行和项目利益相关者进行审查。如果利益相关者写了详细的利益相关者要求并签字,则他们可能不需要参与对更多技术系统和软件要求的审查。假定存在良好的可追溯性矩阵。

规范由一组人员审阅,以确保技术上的正确性,完整性和各种其他内容。通常使用清单来确保所有可能类别中的所有要求均已正确列出并形成文件。

验证实际上是质量保证主题。在整个项目中产生的所有文件都应接受验证审查。


该信息来自Global Knowledge的 需求开发与管理 课程由课程主任兼作者PMP Jim Swanson开发。 Prior to teaching Jim在Global Knowledge任职惠普(Hewlett-Packard)25年,担任业务系统开发人员,技术产品支持和高级项目经理。 在加入HP之前,Jim曾在美国地质调查局担任地质学家。

 

版权所有©Global Knowledge Training LLC。版权所有。

©BA Times.com 2020

麦格雷戈徽标白色网站