印度软件水平为什么世界第一

这是我 过去几年 与 Healthforge 团队一起在医疗保健领域开发软件的经验系列文章中的第一 篇 。 在大多数时间里，我们一直与欧洲，北美和澳大利亚的主要中心以及全球生命科学公司的医生和患者一起从事眼保健工作，致力于改善医疗服务和患者成果的项目。

在途中，我学到了一些我想分享的东西。 通过所有这些线程将是必需的。

TL; DR

为什么要求很重要？ 由于管理不善的需求会导致混乱，浪费和失败（不是好的类型），并且几乎是在无数软件项目启动之初就在这里出错。

在这篇文章中，我概述了需求的不同观点-客观，理想，现实世界，建设性和您的看法。 真实世界的视图描述了我团队和我多年来在执行需求方面遇到的挑战，而建设性的视图则是我们为处理这些挑战而开发的粗略模型，您可以将其用于自己的需求。

没有您的意见，这些观点将是不完整的。 您是否曾因需求不佳而失败的项目？ 您对如何避免这种情况有想法吗？ 如果可以，请保持联系，我很想听听他们的声音！

客观观点

软件需求强调软件的“为什么”和“什么”（例如，软件的功能，具有的特征），开发团队使用这些软件来提出强调“方法”的设计。 它们通常（但并非总是）记录在案，可以在不同的抽象级别（例如，业务目标，用户要求，系统要求）进行描述，并且可以使用具有定义属性的不同模板（例如，用户案例，用例，系统功能）。 收集它们的过程可能有很大的不同。

理想化的观点

理想化的视图告诉我们需求是由利益相关者的混杂组成的，可以简化为一组唯一且一致的规范，并且是合理的，主要是完整的并且描述得足够详细，以供开发人员着手进行实施以及其他人都可以理解。这是怎么回事。

理想化视图利用了理想化模型（图1）。 您可能会认识到它们所适用的语句：

1. 敏捷的用户故事：“作为[用户类型]，我想要[某些目标]，以便[某些原因]”（ INVEST模型）
2. 系统功能：“系统应提供...的功能”（ 关于良好要求的 INCOSE 准则 ）

有些团队甚至使用诸如TLA +之类的正式规范语言来在编写任何代码之前对自己的规范进行建模和测试。

图1. INVEST＆INCOSE需求属性模型。

和改变？ 当然，改变是不可避免的！ 需求会随着时间的推移而变化，就像开发周期中的所有其他事物一样，只要您的开发过程能够轻松地适应这一需求，那么变化就不可避免。

现实世界观

知道现实世界的观点与理想化的观点是矛盾的，这不足为奇。 下面总结了我们多年来遇到的挑战，这些挑战通常是在大型企业内部或与大型企业合作，尽管始终是一个小型，独立的团队，如今却是一个独立的初创企业。

不同的人在不同的抽象层次上需要不同的信息。 最好通过来自不同利益相关者群体（用户，客户，内部/外部利益相关者）的各种功能（例如，开发，质量保证，运营，UX和设计，产品，PMO，IT，采购，法律，Infosec，合规性，监管机构）和其他外部利益相关者（例如监管机构，供应商，行业机构）。 每个小组对构成相关要求的信息有不同的需求和期望。

获得这样的输入意味着在不同的抽象级别上定义，呈现和关联不同的信息。 这可能是正式的或非正式的，具体取决于您的工作方式，但往往会涉及较高级别的“内容”和较低级别的“方式”。 不同的抽象级别会带来许多其他利益相关者的偏好。 其中之一是使用不同的文档存储格式-纯文本，降价，XML，Excel，Word，Powerpoint等。

尽管这种多样性可以带来更好的要求，但是您从中得到的利益相关者越多，太多厨师稀释决策的风险就越大。 在涉及很多人的情况下，很难使决策集中化，但这对于维持可行的流程至关重要。

语言，模板和属性很少保持一致。 不一致有不同的来源和类型。 一种是不同利益相关者团体用来描述其要求的语言。 通常在业务和技术领域之间的这种不匹配会导致误解和可交付成果，这些问题无法解决当前的问题。 开发所有利益相关者都同意的无处不在的语言可以有所帮助，但是利益相关者群体越多，开发，达成共识和传播它所需要的投资就越大。

另一个是异类组需要异类信息，通常在不同的抽象级别。 系统需求对用户没有用，就像没有系统需求的用户需求仅对开发人员部分有用一样。 这需要为异构组使用异构模板和属性。

另一个仍然是无法基于模板属性定义需求实例属性，因为基础模型并不总是有效。 例如，INVEST表示用户故事应该始终独立于内部和外部依赖关系-当您被迫根据客户的流程/人员/技术来设计依赖关系时，后者很难满足。 同样，INCOSE告诉我们要求应该是“完整的”-对于复杂的项目，这很难实现。

有时人们会犯诚实的错误。 图2显示了一个对我们最近进行的项目的需求不一致的示例，作者决定使用两种不同的模板，一种由团队同意（用户故事+接受标准+线框+设计），一种没有。

图2.对Vision Coach （我们为糖尿病眼病患者开发的应用程序）的需求不一致。

总是不完整，有时可以避免。 尽管在复杂的项目上很难达到完整的要求，但是尽管有时会遇到困难，但仍有很多差距可以弥补。

例如，需求可以针对负责他们的个人/团体的优先事项和技能，从而提供不完整的整体情况。 同样，客户和利益相关者可能对他们的需求是错误的，因此要由他们吸引，分析它们并将其转变为要实施的明智要求。 对于这两者，从一开始就与合适的利益相关者进行协作可以为您带来很多好处。

利益相关者也可能会很慢，尤其是在企业中，在达成决策点和问责制迫在眉睫之前，很难参与其中。 由于这可能会在周期的后期出现，因此需求也可能会出现。 答案的一部分包括：不断努力让这些人更早地参与需求开发流程，并尽一切可能减轻风险。

取消优先级或排除内部开发团队或重要的非功能性需求也很常见。 例如，您看到多少次实施的系统没有适当的日志记录或安全性？ 时间，金钱和决策者对用户和功能的关注通常可以解释这一点，但是结果对于开发团队来说非常重要，通常对于软件质量也是如此。

提出要求不是理性的也不是线性的。 您地址 “为什么”，“什么”和“如何”以相同的顺序排列，对吗？ ah！ 不在现实世界中。 有时，它们是不按顺序发生的，而另一些时候，它们受到的重视程度却不相同，或者完全被忽略了。

在理性的世界中，将以不同的粒度级别捕获这些问题的答案，随着您从愿景，范围到实施的过程变得越来越详细。 但是，在现实世界中，过度规范和更高级别的解决方案泛滥成灾，这使开发人员在实施时变得更加艰难，他们希望（通常是对的）以另一种方式做事。

最后，从“为什么”到“如何”的进展很少是线性的。 需求是迭代的，通常您会和开发团队讨论实现细节，只是意识到需求是模棱两可的，不完整的，或者可能是纯属错误，因此必须再次循环。

捕捉“适量”的细节是很难的。 应用Goldilocks原理，即捕获的对象不要太多，也不要太少，但是很难获得正确的细节。

过度指定的需求在瀑布中很常见，它经常发生在需求金字塔中的错误抽象级别上，从而给开发人员在实现过程中带来问题，如所述。 规格不足会在敏捷中很常见，在这种情况下，有时仅将用户故事视为足以使开发人员继续进行编码，通常会引起分歧，混乱和返工。 两者都可能是非常浪费的，并且会对上市时间和成本产生负面影响。

然而，要在两个极端之间取得平衡是很困难的。 解决方案的一部分在于定义一种捕获需求的过程（例如，启发，分析，规范，验证），并约定在层次结构中何处捕获哪些信息。 其中的一部分还可能涉及就具有定义的属性的模板达成共识，以捕获此信息，您的团队会随着时间的推移而发展。

改变和冲突是当然的（当然）。 像开发周期中的所有其他内容一样，需求是迭代的。 变更的最重要来源来自将软件交付给用户和客户-这通常会产生新的需求，并且随着潜在需求的出现并引入新的迭代中，会对旧的需求进行更改。 这是一个良好而健康的变化。 由于反复出现的错误或明显的错误决策等原因，还存在不健康的更改。 这种变化是不受欢迎的（至少对我而言不受欢迎），并且迭代崇拜不应成为决策或执行不力的无花果叶。

正式或半正式地管理变更涉及花费时间使需求保持最新，这涉及内容变更，版本控制，审查和批准，管理依赖关系和测试用例等。选择正确的位置，工具和方法来管理此变更可以使幸福与永恒的悲伤有所不同。

需求也彼此冲突-用户想要一件事，内部利益相关者想要另一件事，两者是互斥的。 当然，这只是产品管理的正常部分，有时您可以通过建立优先规则来解决冲突，该优先规则可以识别一个组比另一个组更重要（例如，在医疗保健领域，拥有最大规则的人通常胜出）。

在您无法执行此操作的地方（例如，您有两个相互冲突的必备条件），需要一种机制来标识冲突发生的位置和最佳解决的位置。

建设性观点

为了给您一些建设性的知识，我将概述一些我认为是好的要求的高级属性。 蒸馏上述内容，并保持理想状态的玫瑰色眼镜遥不可及，良好的要求是：

1. 为听众量身定制。 异类受众需要在不同抽象级别上使用不同的数据，并且需要能够以适合其偏好的格式工作。
2. 共同努力。 从一开始，良好的需求就需要包括用户，客户以及内部/外部利益相关者在内的各种人员的投入。 与他们合作来引出，分析和定义需求，同时保持明智的决策制定，有助于改善需求，设计和软件。
3. 一致（大部分）。 无论您选择哪种语言，模板和属性，在使用方式上几乎一致都将提供必要的清晰度和可比性优势。 从INVEST和INCOSE借用，例如，您的用户故事的一组不错的属性可能是：独立，可协商，有价值，可估计，较小，可测试，可追溯和清晰。
4. 详细描述。 随着您从视野，范围到实现的过程中，抽象程度降低。 如果您定义一个层次结构，例如视觉，用户需求，功能，体系结构，系统需求，请决定在每个层次中收集哪些信息，并使用具有已定义属性的模板来帮助对齐。
5. 如有更改（右）。 由于需求是迭代的，因此您需要一个适应变更的过程（可能有些敏捷的味道），管理其生命周期的工具以及避免不必要或浪费的变更的方法。
6. 在发生冲突的地方（大多数）可以解决。 当需求发生冲突时，提出用于建立优先级的粗略准则，以快速有效地解决冲突。 在无法解决冲突的地方，请确定发生冲突的级别以及在何处可以最好地解决冲突。

您的看法

您的观点如何比较？ 您花多少时间在需求上？ 你如何做？ 您遇到了什么挑战？ 您如何处理他们？ 你成功了吗？ 我很想听听您的想法-看到您的经历与我们的经历相比会很有趣。 请通过发推文@getfluxapp或通过flux@healthforge.io发送电子邮件来告诉我们您的观点！

下一步是什么

在我的下一篇文章中，我将研究一个案例，该案例研究了对软件项目Vision Coach的需求进行管理的过程，其中描述了许多挑战。 我将详细研究过程和工具，并提供一些好的实践实例，这些实践可以用来改善您的需求方式。

翻译自: https://hackernoon.com/why-software-requirements-in-the-real-world-are-hard-953iv3z3d

印度软件水平为什么世界第一