业务分析师应该编写API用户故事吗？

Question

我在S/W开发公司担任业务分析师。在以前的一家公司，我是资产管理专业的学士，基本业务更面向业务(即较少的技术倾向)。

我们目前正在构建一个web应用程序，我正在使用JIRA为功能需求编写用户故事、验收标准等。

我正在编写用户故事来描述功能需求：

例如：

作为一个客户用户，我想要一个确认电子邮件，一旦我注册了一个帐户，所以我有确认我的注册已经完成。

接受标准：

• 一旦向导注册了客户端用户，注册向导将向已注册的电子邮件ID发送电子邮件。
• 确认消息将显示在屏幕上，以便客户端用户知道注册已经完成。
• 客户端用户将自动重定向到门户时，点击‘完成’等。

有些开发人员认为我也需要编写相关的API票据，还有一些开发人员认为这不是BA的角色。

问题是，虽然我研究过IT，但实际上我从未详细研究过API，也从未作为专业开发人员进行过工作。我直接进入了业务分析部门。

在软件开发项目中编写API票据是BA的职责吗？还是开发人员的角色是将相关的API票据编写为我编写的故事的子任务？

我访问过的所有BA站点在编写用户故事时只讨论功能性/非功能性需求(如我提供的示例)，而不是编写API票据。

谢谢!

Answer 1

IMHO注释中已经提到的关键点是API是否是外部需求(因为您的系统为第三方提供了以编程方式访问它的可能性)，或者它是内部实现细节。

对于前一种情况，将API视为业务需求的一部分是明智的，这是BA将负责的事情。对于后者，让API由团队中的开发人员负责通常更有意义。

注意，这只是一个“按本书建立的模型”：如果您希望组织中的“典型开发角色”和“典型BA角色”之间的分离严格由您和您的团队决定。一个真正敏捷的团队应该以他们之间最有效的方式来分配责任，而不是某些理论模型定义他们的方式。

Answer 2

首先，first....if --您是一个倾向于业务的BA，然后是业务流程分析师。如果您是一个技术上倾向于的BA (大多数情况下您来自开发背景)，那么您就是业务系统分析师。现在是行业明确区分这两类业务分析师的时候了。

基于以上描述，如果您从未是开发人员，也不了解系统如何通过API进行通信，那么您就是业务流程分析员。您所担任的角色需要一个曾经是开发人员的人，我这样说是因为我目前是业务系统分析师，我的背景是C#.net web开发。

如果您希望在软件开发项目(Business )上担任业务分析师，那么您显然有责任为您正在开发的产品定义API规范，而您所期望的一些细节将是标题、要解析的查询参数、逻辑数据类型、字段长度等。

API规范不一定是系统的“如何”(因此我不同意Daniel在他的评论中所说的话)，它实际上是系统“什么”的一部分，因为它描述了要发送到电子邮件程序的“什么”信息和逻辑数据类型(而不是物理数据类型)。

您需要告诉开发人员哪些信息要发送到电子邮件程序。如果我是你项目的开发者，我会问你同样的问题。一个简单的类比是，如果你让我给你造一辆车。你必须告诉我你会用这辆车做什么，运载多少乘客，它会被用于重型或非etc....based在你回答这些问题时，我将能够决定是否给你制造一辆汽车，一辆摩托车，一辆卡车，一辆拖拉机，还是一辆四轮驱动。因此，对于电子邮件，我也有兴趣知道有多少收件人，是否有CC或BCC，是否应该对电子邮件进行移动优化?应该是纯文本还是HTML，在发送电子邮件时是否需要加密或匿名，例如“如何”这个故事是使用哪种协议发送电子邮件，也就是SMTP，这取决于开发人员……我希望这能有所帮助。

Ps:在所描述的场景中，由于API规范定义了在两个系统之间交换什么信息，我将把它作为用户故事成功标准的一部分，而不是作为一个单独的故事，但是me.The最重要的事情是将信息记录下来。

我也不明白为什么每个人都在问你的API是要在内部还是外部消费……我想你的用户故事说all....you正在构建一个注册表格，作为一个网络应用程序的一部分，并且你要求网络应用程序与一个电子邮件程序(可能是你的组织的电子邮件程序)进行接口。伙计们，答案在用户故事中！

Answer 3

我相信任何人都可以编写API需求，只要他们熟悉领域、API、API测试，并且有一些常识。但是，我看到一些业务分析师和产品经理在编写API故事时没有基本和基本的细节，从而使这些故事对开发人员和测试人员来说毫无用处。因此，开发人员和测试人员必须自己确定需求。

例如，我看到API故事没有提到头、查询参数、样例响应等。有些API有日期、百分比等字段，但是这些字段的预期格式缺失了。(美国或英国的日期格式?，百分比与小数点1或2位？问这样简单的问题，学士或PM真的需要一个高级学位吗?)在所有的故事中，对于不同的愉快路径或正常用例场景的响应从来没有提到过。

正如布朗博士正确提到的，编写需求可能是整个团队的责任，而不仅仅是BA或PM但是，如果您的BA或PM不够熟练和聪明，那么开发人员和QA应该承担起这一责任。