盖房子 开发软件:业务分析师在需求分析中的作用

盖房子是一件棘手的事。 最基本和最重要的步骤是提出设计或房屋计划。 提出美观和用户友好的设计也是一项挑战。 即使房子从里到外看起来很漂亮,但如果它不实用或在可用性方面不合格,那末也没有意义。 有时,这些房屋的主人也有疯狂的设计想法。

采取这样的抽象概念并建造一个符合所有标准的房屋并取悦所有有关方面可能会感到非常压力和沮丧。

如果设计师,结构或土木工程师或建筑师试图过多地参与设计,并且如果最终建造的房屋与业主的期望不同,那么遗憾的话可能会困扰房主很长时间,因为房屋本身就是一个大笔投资。

可以说软件开发也是如此。 有时,业务分析师可能只是一句话。 XYZ功能应可帮助客户完成ABC任务。

但是,仅凭一句话就可以提供超出要求的内容,这正是我们作为业务分析师应该尝试的事情。

要提供超出期望的东西,应该做的第一件事就是确定期望的东西。

定义范围

如果是小型应用程序,则在几次尝试中定义范围可能会有点容易。 但是,如果它是一个较大的应用程序,则有很多组件相互作用,范围设置可能会有些困难。

让我举例说明。 这可能不是始终查看需求的“方法”。 但这就是我的想法。假设您想开发一个小型移动应用程序,它将帮助用户练习信息通信技术主题的多项选择题。 那么,这里最基本的要求如下。

·能够查看问题

·能够收集回复

·应当能够验证提供的响应

·应该能够显示摘要统计信息

这将是初步范围。

在初步范围内成长

可以将上述初步范围改进并发展到各个子级别。 但是,请确保深入您定义的初步范围内。 在JIRA环境中,这些子级别称为用户案例和子任务。 需求将分为有意义的和可访问的子任务。

如果我们查看用户能够查看问题的第一个要求,则用户可能会使用许多方法使用该应用程序查看过去的问题。 被认为的一些方法如下。

·要求1.1:每年必须能够查看问题

·要求1.2:必须能够按主题领域查看问题。

·要求1.3:应能够在类似于实际考试的环境中查看问题(考试模拟器环境中,您可以在计时的同时回答问题)

这里要记住的一件事是,拥有很多细节将帮助下一个人从您的眼中看到需求。 但是,再次必须始终在此处包含相关信息。

分而治之

让我们以为开发人员着眼于任务1。他(她)将尝试提出一种设计,该设计能够每年查看发布的问题。 他可以采取许多方法。 这里的歧义可以进一步细分。 我想将此级别视为用户故事中的子任务。 因此,我决定进一步阐述要求1.1。

1.1.1应该能够从包含随附出版物的菜单中选择一种论文

1.1.2应能够查看问题并根据问题的类型提供一个或多个答复

1.1.3提交答案后应能够查看问题的答案

1.1.4应能够为问题添加书签以供以后参考

1.1.5在考虑了用户输入后,应该能够从停止的位置恢复纸张。

很高兴有要求

必须在多项选择题练习应用程序中查看问题。 这将是强制性要求。 但是会有一些不是必须的要求。 这些很高兴有要求。

这些是我们可以生活的要求。

如果我再次参考前面的示例,那么如果用户应该能够在仪表板上看到他们过去的表现,那么它将增加价值。 或者应该可以设置重复的或一次性的定制提醒,以提醒用户遵循常规并完成可用的论文。

非功能性要求

适当的需求分析的后半部分将着眼于需求的非功能性方面。

通常,这些要求来自性能,容量,可访问性,安全性,清晰度,异常处理等领域。

如果我参考前面的示例,则在移动应用程序中,GUI非常重要。 您试图在适合手掌的屏幕上显示大量信息。 因此,过度拥挤的屏幕将使用户难以进行交互。 在这种情况下,要牢记正确的用户体验。 如果它是一个庞大的应用程序,并且具有大量信息,那么它们应该聪明地告诉用户显示什么以及如何在较小的屏幕上显示给用户。 但是,我将在此处停止,因为这是完全不同的主题。

我能想到的另一个非功能性需求是可访问性。 我们尝试通过移动设备执行某项操作的主要原因是能够随时随地进行该操作。 如果应用程序未加载或加载时间很长,则将不会使用它。 这些非功能性需求在大多数情况下都是至关重要的,因此应更加重视。

注意事项

在现实世界的开发中,有时需求分析可能不像我之前说的那么简单。

尤其是在敏捷环境中工作时,可能会在整个开发生命周期中定义需求。

此外,还将与开发人员甚至需求所有者和最终客户进行很多来回讨论。 在这种环境下,范围和要求可能有很大差异。

另外,仅业务分析人员可能无法一次了解所有内容,并且可能需要其他方的帮助才能全面满足要求。 总而言之,需求分析的各个方面可能很棘手,需要进行彻底的开发,因为开发的成功与否取决于它。 就像盖房子一样。