2018年3月1日,星期四08:21

使用原型编写需求

撰写者

当我刚开始做业务分析师时,我从事许多涉及内部应用程序开发的小项目。

因为需求很精确,并且用户导航步骤很简单,所以需求获取很容易。我不需要从设计和间距角度考虑太多,因为所有利益相关者和最终用户都来自组织内部,并且只要服务于应用程序的目的,应用程序的设计就会退居二线。 。

但是,随着我的进步和承担更大的项目(这些项目正在为组织创造收入并在全球范围内使用),我意识到在编写功能要求时必须非常小心。我必须知道该屏幕上的每个功能,才能使要求更加有效。用户管理必须进行详细说明,我必须牢记应用程序的设计,并且还要考虑导航流程。

最初,我曾经使用可视化方法来编写功能需求–想象一下头脑中的流程并继续编写。但是,当我查看这些要求时,发现我确实在某些方面或其他方面错过了。最终,我不得不添加更多细节以完成需求。

然后,我开始使用原型编写功能需求。还记得我们回到学校的时候被告知要用纸做粗糙的工作来进行数学计算。同样,使用原型来巩固导航流程可能是一个好方法。

通常,原型或模型被定义为代表网站骨骼框架的屏幕蓝图或可视指南。实体模型的更好版本是线框。线框考虑了软件的完整设计方面。模拟是在开始时创建的粗略草稿,用于放置网站元素。

以这个为例-您需要带头开展一个项目,在该项目中必须开发一个应用程序,最终用户可以使用该应用程序购买时尚配饰。您可能会问涉众的一些初始问题是:

  • 客户群
  • 用户历程
  • 付款将如何处理?支付网关集成
  • 如果用户可以作为访客用户进行购买
  • 用户将在哪里应用促销代码?
  • 用户可以使用哪些过滤器?
  • 我们是否保留任何订单历史记录?

这些问题的答案将有助于起草高级要求。但是以下问题呢?

  • 用户可以在自己的帐户中做什么? –更改个人资料
  • 页面之间的导航将如何?这看似简单,但利益相关者可能有不同的看法。例如,您可能认为当用户在评论订单页面上并且当用户单击继续购物时,他/他应该登陆产品列表页面。但是利益相关者有不同的要求–他们希望用户登陆网站的主页。 BAM现在有差距!

广告

案例–没有原型的需求

假设您要在用户帐户中捕获订单历史记录页面的要求。您可以想象页面在您的脑海中。您首先要写一些基础知识-该页面将包含以下详细信息:

  • 订单号
  • 产品详情
  • 总金额
  • 促销代码折扣
  • 支付的金额
  • 状态

案例–原型需求

现在,从细节上讲细节。您可以使用上面的信息制作模型,然后进一步分析“订单历史记录”页面。

 梅塔03012018

  • 用户可以单击产品详细信息并以列表形式查看不同的产品吗?如果是,那么用户可以选择每个产品以查看其详细页面吗?
  • 用户可以查看金额细分和付款方式吗?
  • 状态是图形表示还是文本?
  • 产品图像将放置在哪里?
  • 根据上面的布局,如何利用右边的空间?如果利益相关者要求添加一些横幅,将如何做?
  • 在此页面上是否会退货和交换产品?

这只是一个小模块。当涉及到整个应用程序时,复杂性可能会增加,并且要求可能必须写得很详细。

模型是需求的约束力。它们有助于理解用户的旅程,最终可以帮助有效地起草用例。这些很容易制作,并且可以有效地识别差距。尽管市场上有各种工具可用,但也可以在基本的笔纸模式下完成模型制作。不需要精通设计方面的人。但是,广管局应该考虑屏幕的各个方面,并确保是否存在与之相关的要求。模拟的主要目的是对用户的旅程进行全面了解。此外,还可以评估这些功能的可行性。

可以通过以下方式制作参考样机:

  • 功能需求可以以模块化的方式编写。当样机处理软件的所有屏幕时,可以在这些页面之间映射导航并编写有关用户旅程的详细信息。
  • 它有助于填补需求分析的空白。例如,在需求获取期间,涉众可以跳过功能。但是,如果在这些会话中设置了粗略的结构,则丢失细节的机会将很小。
  • 不会错过任何一个用户故事。例如,已有订单历史记录,但是作为用户,我可以对记录进行排序/过滤吗?如果我单击订单,是否可以查看所购买产品的详细页面?
  • 需求与实体模型结合使用时,可以使开发人员更清晰地了解开发人员,从而可以放心地进行编码。
 Poorti Mehta

Poorti Mehta 是拥有超过4.5年工作经验的业务分析师。她从事过跨领域的项目,例如教育,出版,金融产品和制造业。她来自印度新德里,可以通过电子邮件或Linked In与她联系。

此类别中的更多内容: «虚拟协作 业务规则-案例研究»

©BA Times.com 2020

麦格雷戈徽标白色网站