如何将客户端从UI原型转移到一组实际需求?


17

假设您得到了一个由25个屏幕组成的应用程序视觉状态的模型。期望这足以使我们确信我们可以将其开发并作为最终应用程序移交给原始利益相关者或客户,他们将对此感到满意。自然,您最终将要再次向利益相关者询问很多用于UI的问题,这很浪费。

但是,我有很多次发现这还远远不够,在开发应用程序的过程中,由于我们正在复制一个接口,最终使客户不像他们最初看起来的那样满意,这一要求变得模糊不清当我们要求他们提供创建UI的所有信息时。

我只是不确定要提出什么要求,我试图做到具体,要求要求和对总体目标的理解,但是我不知道我应该提出什么要求。如果我现在才开始,那么重新散布导致进入UI的所有信息将浪费大量时间,在此阶段,客户最初失去的许多重要原因将丢失。

我如何让人们理解我们无法通过要求用户为我创建可操作的东西来锁定基于UI模型的需求?

为了正确执行为最终用户开发应用程序的任务,理想情况下从什么开始?


您如何要求?您是否只是去拜访客户/用户并说“我有要求吗?” 还是您正在使用各种技术中的任何一种来引发,捕获,验证和验证需求?
托马斯·欧文斯

2
为此,与非开发人员打交道并不容易。屏幕根本无法描述应用程序。我现在的雇主不明白这一点。我的工作倾向于针对每个屏幕,并询问有关每个项目的行为和“假设”的很多问题。这样,您就可以隔离功能并能够设计出真正的功能。
钻机

2
我猜它比25个选项卡式的excel文件规范要好得多。
Morgan Herlocker 2011年

1
从您的问题尚不清楚,这是否仅仅是您的客户给您的,还是这是您团队中其他人由于尝试捕获需求而产生的结果。如果是后者,则您的组织中可能存在根深蒂固的问题。如果是前者,那么您将需要实践一些需求收集技术,如其他人所建议的那样。
Angelo

1
@Ryan,在那种情况下,我希望需求专家能够回答您将为他带来的所有问题!也许他只是希望您会与他互动地非正式地讨论所有要求?那是乐观的情况。
Angelo

Answers:


19

您可能需要做的其他一些事情是:

  • 用例或工作流描述:仅仅因为您知道屏幕的外观,您知道如何处理不良输入吗?您知道在所有情况下如何在屏幕之间切换吗?您也可以在此处包括错误处理。

  • 高级系统描述:某些内容说明这25个屏幕的整个系统的用途以及它们的作用。

  • 数据模型:是否可以从这些屏幕推断数据模型?是否存在必须使用的数据模型,或者您可以自由设计自己的数据模型以完成工作?

  • 技术要求:是否由于许可或出于集成原因而必须使用特定的技术?

  • 性能要求:如果有搜索屏幕,是否期望可以搜索什么以及响应应该有多快?对其他类型的动作的响应又如何呢?它们中的一些可以异步还是异步异步(用户提交作业并稍后返回)?

  • 安全要求:应用程序是否存储潜在的敏感/个人数据,如果是,则存储什么类型的数据以及必须采取哪些措施来确保其安全?您是否需要达到某种程度的合规性(例如进行信用卡支付的PCI合规性)?

此外,您是否需要任何特殊的业务领域知识来协助您?一些行业,例如保险,银行业,医疗记录等,具有各种复杂的业务逻辑。没有知道该领域的业务分析师的帮助,不应尝试此类项目。但是,如果这只是通用小部件的购物车/信息网站,那么您可能不需要这样的团队成员。


1
我不知道您是否故意这样做,但此列表的重要性甚至很高,用例和高级系统描述(它们至少标记了样机屏幕吗?)到目前为止是最重要的事情。我不知道安全要求是否合理。在我看来,您作为开发人员应该对支持他们的用例所需的安全性有更好的了解,因此您应该从用例中确定安全性要求,然后通知客户。
2011年

10

如何使人们理解UI模拟还不足以创建可运行的程序:

我会用一个比喻来解决这个问题。由于我有点不知所措,所以我要走那条路。

“假装我对汽车一无所知。您递给我几张法拉利的照片。一对夫妇是从外面来的,一对是从汽车内部来的(是从驾驶员座位上拿来的,所以我可以看到汽车的控制装置。)现在您问我为您制造一辆法拉利。我回来的是一个看起来像图片并具有所有控件的东西。不幸的是,这些控件没有连接任何东西,因为(因为我对汽车一无所知)我不知道这些是什么控件应该可以。我什至无法猜测,因为我什至不知道应该做什么汽车,于是我们进行了如下对话:

“那么法拉利做什么?” “它使我能够迅速地从一个点转移到另一个点。” “好。那么这圈事情是做什么的?” “哦,那是方向盘。通过转动它,您可以更改汽车外部的车轮指向的方向。这将改变汽车的行驶方向。” “好,那踏板的东西呢?” “这就是油门踏板。它使发动机行驶得更快,使汽车行驶得更快。” ……几分钟后……“好吧,那需要什么样的引擎?我做了一些研究,发现了高尔夫球车和跑车的引擎。我应该使用哪种引擎?” ...等等...“

然后,您可以解释类推。向开发人员提供屏幕模拟信息只会告诉他们外观,而不是外观。开发人员需要知道程序可以解决什么问题或将如何使用它(例如知道汽车的功能可以使汽车的设计变得更加容易,并对应该做什么应该进行有根据的猜测)。他们需要知道他们期望使用哪种类型的东西(例如,高尔夫球车引擎与跑车引擎),以及其他哪些非UI需求(汽车应该快速行驶)。

我想要的东西:

一般/高级问题描述

用例/用户案例

性能要求

所需技术/平台(Windows,Linux,Web)

FrustratedWithForms包含的所有内容


1
+1是一个很好的类比,尽管我不确定这是否真的是与客户沟通的最佳方式。我会告诉我的非技术朋友帮助解释我的工作,但对于可能有点光顾的客户。
2011年

@jhocking我完全同意使用类比不是与客户进行通信的方式。我假设这些模拟来自您公司中已经与客户进行过交谈的其他人。如果您必须将此信息传达给客户,则只需解释一下,该模拟就可以向您展示其外观,但很少告诉您它的功能(从模拟中获得的任何信息充其量都是一种猜测)。他们需要告诉您更多有关您正在做的事情。您只需要找到一种很好的方式进行询问和沟通即可。
Becuzz 2011年

5

80%的开发工作将达到20%的附带用例。屏幕截图不会告诉您有关用例的信息,因此80%的活跃开发中您将一无所获。

最好是尝试找出更多的东西,并尝试传达出让客户更多地参与项目需求的重要性,但是,如果他们不这样做,那么他们将建立失败的项目,并且那不是你的错

大多数软件项目失败,因为客户端没有充分参与软件开发过程。这不是一个新问题,当然也不是为什么软件项目失败的谜,但是由于这种情况,它在行业中不断发生。

您不仅可以在墙上扔一滴信息,而且希望以软件包的形式取回所有希望和梦想。软件开发只是无法以这种方式工作。无论您是敏捷商店还是瀑布商店,成功的项目指导都必须有明确的客户指导。


2
“您不能只是在墙上丢下一滴信息,而期望以软件包的形式取回所有希望和梦想。”我喜欢这句话,我很偷窃它。
HLGEM 2011年

@HLGEM,接受,这是你的!
maple_shaft

4

人们似乎忘了问的一件事,就是输入后的数据将用于什么?您需要报告吗?您是否需要生成装箱单并发送到仓库进行运输等。如果使用数据来做出管理决策并需要报告,那么那会改变数据库的设计。根据报告的复杂性,它还会增加大量的开发时间。

您还需要确保每个可能的决定都有一条路径。因此,如果某些事情需要管理部门的批准,那么如果被拒绝,您会怎么做?如果被批准,您会怎么做?如果在X时间内没有批准或拒绝批准,那么会发生什么?如果他们选择一种产品,但缺货,那么订单将如何处理?这些问题。

您还需要知道在每个字段中应放入哪些数据是否有特定限制。是否有要求的值。您打算从哪里得到这些东西?他们将如何更新?您需要知道如何处理错误。您需要知道数据库是否需要进行审核,或者是否需要能够从历史角度重新创建数据(返回到令人讨厌的报告)。

我看到发生的另一件事是,应用程序的设计可能只针对发行版,而不考虑其后如何维护数据。您是否需要一个管理员页面来确保他们可以更新其必需值列表?您是否需要将数据来回发送到其他系统。您如何将初始数据输入数据库?


3

就个人而言,我会要求与客户进行为期半天到一天的会议,以逐步了解他们的UI设计和目标,并确保一切保持一致。


2

从简单开始。让他们了解,利用您所获得的信息,这些屏幕都无法做任何事情。没有有关用例,不良输入行为等的详细信息。只是行不通。直率的解释比解释细节要容易,因为要点不会丢失。试图给他们一个更复杂的理由,说明为什么屏幕模型还不够用,这给了他们机会来质疑您的定义,而不是承认问题。让他们想象后端开发人员不会说英语(或屏幕显示的任何语言)。然后问这种情况与完全不了解的开发人员有何不同他们的业务流程。然后,建立一个自己的更现实的例子,他们自己有一些知识,但是有理由相信自己不适合为他们决定业务逻辑。


2

尚未开发软件的人不知道软件开发人员需要知道什么。不能期望他们自己产生需求规范和用例。您需要应用需求启发技术来获取您需要了解的信息。与客户(最好是来自各种角色的用户样本)一起工作,以确定他们需要或想要的东西。常见的技术是访谈和/或用​​户观察,识别用例和用户案例以及原型。

我强烈建议在这种情况下应用迭代和增量开发技术,因为您的需求含糊,不完整或理解不深。查看用于解决生命周期规划的各种敏捷方法以及螺旋模型。

首先获得驱动该软件开发的业务目标。采访客户和用户,如果可以的话,观看他们的工作情况。尝试确定他们要解决的问题。查看他们当前正在使用哪些工具以及如何使用它们,以便您可以改善他们当前的工作方式。利用此机会学习域及其语言-如果软件开发人员和客户/用户都说相同的语言(并且不希望客户/用户以软件的方式讲),交流将变得更加容易。

一旦了解了目标是什么,就可以开始使用已有的UI设计模型,并根据各种屏幕的组合情况对它们进行“反向工程”用例和用户案例。用户故事格式可能会很好地解决非技术受众。解决方案的格式As a <user type>, I want to <action> so that <reason>取决于使开发人员和客户/用户说相同的语言。一旦您可以了解用户故事,就可以采用原型开发方法。

我认为我会通过使用原型来解决这个问题。您可以从进化原型或一次性原型的角度来解决这个问题,但是我将首先考虑一种进化原型方法。从您最熟悉并经过验证的用户案例开始,然后开始实施它们。在实施它们时,请从客户那里获得反馈,并开发新的用户案例,用例并解决误解。

另外,不要将其视为“使用具有其下的功能的用户界面”。相反,可以将其视为垂直的薄片。不要一次实现所有用户界面,然后再担心功能。而是使用用户界面模型来标识功能和其他要求,然后实现从UI到业务逻辑和数据存储的垂直切片。对每个垂直切片重复此操作。您还应该根据需求和可用性原则随意提出建议以改进UI。

我建议阅读Karl Wiegers撰写的两本书:“ 软件需求”“关于软件需求的更多信息”。我认为这些将帮助您解决该领域的需求工程和最佳实践。


4
请记住,如果您制作了原型,则永远不要使用户界面看起来光洁和完成,如果屏幕看起来固定,他们会认为您已经完成了编码。
HLGEM 2011年

@HLGEM非常真实,非常真实。实际上,我很确定之前已经在该站点上给出过建议。
汤玛斯·欧文斯

1

好吧,这是一个令人尴尬的显而易见的入门参考,但是Wikipedia可能是您和用户入门的地方。关于这些东西的条目这一事实可能有助于使他们确信这是一个实际问题,而不是让您感到痛苦。

更具体地说,即使在浏览了模型之后,您是否对应用程序的功能还是感到困惑?如果是这样,请接受它,并尝试解释您不知道每种表单应该显示什么数据,或者它将来自其他屏幕或外部数据?

如果你有一些想法,试图拿出东西的例子,你不知道该怎么办(“将模板列表,选择是一个全局列表或由用户在其中任何一个,还是别的什么?如果它是不是按用户显示的,我应该让两个人一次编辑它吗?如果有人在编辑它,UI应该显示什么?是否有一个屏幕呢?该更改是否应该传播到他们使用模板所做的事情?”)。

明确说明,在目前的知识水平下,您将需要在其余的开发周期中每90秒回答一次问题,而且在很多时候您将无法继续工作,直到获得答案为止。目的应该是弄清楚为什么有某种过程会使一切变得简单。还请注意,质量检查将需要与您相同的信息,因此将其全部写下来将更加容易,因此每个人都可以使用它,而且没有人会忘记任何东西。

可能需要提及的是,您编写的某些代码一次会影响一个屏幕以上,因此,如果您尽可能多地获得答案,则可以更轻松地正确编写该代码,而不必稍后进行更改。

如果您仍然无法获得需求并且您真的不知道如何进行,请在每次您需要更多信息(例如需求)时发送电子邮件,并且如果您无法在没有这些信息的情况下继续工作,请清楚说明您不幸的是,由于您需要编写的代码将根据问题的答案而有所不同,因此无法继续工作。不要抱怨,只是非常专业地让他们知道,除非您知道该怎么做,否则您将无法编写该程序。


0

您需要知道应用程序中每个字段的限制和范围。例如,如果该字段是电话号码,他们希望您处理+1吗?需要哪些字段?如果用户在电话号码字段中输入“ abc”,他们希望应用程序做什么?是否所有用户都必须依次执行所有25个屏幕?

否则,只需将所有内容创建为文本字段即可完成!想打赌会像铅球一样过去吗?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.