手指软件要求

关于开发需求基础的文章-没有复杂的图表,术语和表格,但带有gif。

图片

简而言之,制定需求的主要步骤是:

  1. 为什么我们必须做点什么?(需要更多的黄金)
  2. 我们做什么?(一切都像人一样,但是更便宜)
  3. 我们如何做到这一点?(当然有区块链和数据专家)
  4. 我们什么时候做?(昨天,并重构“以后”)

现在更详细。

如果您要求做某事,则意味着您已经创建了需求。它们可以是口头祝愿,信件,技术任务,任务或其他任何形式。
因此需求无处不在。

图片

如果在完成请求后出现问题-要么使表演者感到混乱,
要么您设置了错误的任务。

如您所知,错误的任务可能会非常昂贵。例如,如果半年由5个程序员组成的团队开发了一个不需要任何人的系统。

在这个动荡的时代,敏捷设计要求经常被忽略。但是灵活的方法论并不能总使您免于遭受重大损失。因此,即使您没有该项目的分析师,即使您根本不是IT人士,也不要忘记常识并从最佳实践中获取当前所需的信息。

那么需求是什么,为什么能够发展它们很重要?

因此,让我们看一下来源:

图片

也就是说,您可以将需求与未来的属性进行讨论。怎样的产品才能达到开发目标。

从哪里开始开发需求?定义中隐藏了一个提示:您需要从目标开始-为什么我们需要做任何事情。

1.为什么?


图片

就像“尽快!!!” 无需做任何事情-重要的是找到时间和精力,找出为什么这样做是必要的。

因为通常在明确目标之后,任务会更改或完全消除。
例如,

客户将立即向他显示系统中的所有订单。假设我们在sprint的中间拉紧并推了一个任务,以显示管理员的所有订单。之后,客户要求在单独的窗口中显示他看到其订单的所有公司的列表。他们也做到了。然后,客户要求另外撤回所有合作伙伴公司。好的...一段时间后,我们与客户会面,看看他如何将两个列表都上传到Excel,识别差异并开始给没有订单的公司打电话,以提醒他们通过我们的系统下订单。

如果我们从一开始就问客户,他希望通过查看所有订单来实现什么目标,我们将立即向尚未下订单的公司报告,从而节省了大量的时间和精力。
您可以使用“五种为什么”方法或任何其他方法。但是通常人们不会抗拒:如果您对他们的工作表现出兴趣,就会找到解决方案。

确定目标后,有必要明确定义目标并建立标准,以便您可以准确地说出目标已实现。

例如,

如果超过90%的合作伙伴公司通过系统下订单,则物料订购过程被认为是自动化的。

这有助于理解任务,同时解放了选择实现目标的手段的精力。

是的,不要忘记与客户协调这种美丽。通常,不要忘记与所有有关方面协调需求。

2.什么?


该目标以不同的方式实现。制定需求的第二个重要步骤就是选择路径-我们将如何确切地实现目标。

图片



, :

. . . // .

. — , .

. . .

要考虑所有选项,您需要弄清楚-现在正在发生什么?在没有您的系统的情况下,流程如何工作?用户和客户如何工作?即使没有任何处理,有关当前状态的详细信息也非常重要。因此,我们将了解哪种解决方案可以解决该问题,而无需创建另一个解决方案。

图片

每个实施选项都有其优点和缺点,必要的资源和结果的水平。在对所有选项进行建模,制定出解决方案之后,或者至少与相关方进行了交流,您将能够做出平衡而明智的选择。

3.如何?


因此,我们了解了我们的目标以及为实现该目标将要做的事情。仍然需要弄清楚我们是如何实现的:我们将向用户显示哪些页面,以何种形式为客户显示报告,如何从另一个系统接收数据,如何存储它们等等。

这个阶段是技术问题。而且,如果您已经成功完成了前两个,则将更加容易。
尽管该技术取决于具体情况,但沿Wigers和其他聪明人的“清单”前进很有用。如果对您来说某种类型的要求现在不相关-好的,我们不会对其进行描述。但是重要的是不要忘记和测试自己。

图片

例如

  • 调查表应包含带有照片的文件,因为在处理文档时必须使用照片-这是一项业务要求也许是业务规则。
  • - , — . , .
  • , — , . , .
  • base64 . — .
  • , . : 10.

通常,对于每个业务需求,有多个用户需求。用户需求被分解为许多功能需求。对于每个功能需求,必须考虑非功能需求和限制。

同样,非功能性需求和限制可以直接从用户需求以及业务需求和规则中产生。
这样,就可以从需求中获取树,每个需求的顶部都是业务需求。

图片

4.什么时候?


在您需求的“森林”中,可能存在任何互斥和重复的需求。因此,以表格和图表的形式记录并呈现所有这些美感非常有用。

这里有很多工具:例如,用于描述业务流程的BPMN和用于创建服务与组件之间的交互方案的UML。

如果您设法使用餐巾纸和3点咖啡向所有人解释该系统的功能以及操作方式,那么您就是分析专家John Wick,这真是太好了。

图片

但是,通常,“现场”详细程度不允许您看到陷阱并仔细考虑所有可能的情况。毕竟,一切似乎都是可以理解的,但是我画了一点图-在这里,您将面临无尽的挑战,被遗忘的工艺分支以及通往黄金的最短路径。
因此,了解哪些工具可用来解决混乱很有用。

在示意图和结构化形式中,需要确定需求的优先级-取决于实用程序(客户和用户会告诉您)和复杂性(开发团队会告诉您)。

图片

然后您就可以分散在开发和实施的冲刺/阶段了。好吧,在每次迭代中重复这些练习。而且,您会很高兴-没有改变,没有满意的客户,有快乐的团队,一种行之有效的产品,小精灵在彩虹的背景下弹奏竖琴。

图片

当然,总会有问题。会有改动,烧毁的截止日期和错误。不可能总是经过所有阶段并进行常规分析,同意甚至与客户交谈,记录和跟踪需求。但是在任何情况下,了解“应该如何”都可以使产品更好。即使目前您正在做“结果如何”-您也意识到自己已经错过了机会,并且知道了风险。而且,如果您知道风险,则可以进行管理。

我建议阅读Wigers and Beatty一书中有关需求的更多信息:“软件需求的开发”。虽然这本书并不总是那么简单,但是却很有用。关于该主题的大多数其他材料都是以不同程度的自由重述这些真理。

感谢您的关注和良好的设计。

All Articles