软件需求规格说明书通用模版_通用需求挑战和机遇

软件需求规格说明书通用模版

When developing applications there will be requirements that are needed on more than one application. Examples of such common requirements are non-functional, cookie consent and design patterns. How can we work with these types of requirements in a smart way across several applications and teams, without adding bureaucracy and increased lead time?

开发应用程序时，将需要多个应用程序的需求。 此类常见要求的示例包括非功能性，Cookie同意和设计模式。 在不增加官僚主义和增加交货时间的情况下，我们如何在多个应用程序和团队中以明智的方式满足这些类型的需求？

It is a common challenge, that we work in silos, developing “our own” application within one organization. Each application has their stakeholders, product owner, scrum master, user experience, business analyst, architect, developers… In the beginning it’s fine if you only have a few applications running, however what happens when you have 10 applications running? Consider each product team spending 8 hours analyzing a requirement, that means the organization is potentially wasting 72 hours on each requirement. And not only is it a waste during the initial development, consider the amount of waste during the full life-cycle from that one requirement.

一个普遍的挑战是，我们在孤岛上工作，在一个组织内开发“我们自己的”应用程序。 每个应用程序都有其利益相关者，产品所有者，Scrum管理员，用户体验，业务分析师，架构师，开发人员...刚开始时，如果只运行几个应用程序就可以了，但是当您运行10个应用程序时会发生什么呢？ 考虑每个产品团队花费8个小时来分析需求，这意味着组织可能在每个需求上浪费72个小时。 不仅在最初的开发过程中浪费了资源，还考虑了该需求在整个生命周期中的浪费量。

So why do we implement solutions in silos? The answer is that it’s often quicker. We want to deliver with speed to the market, and it’s often easier and faster to do the solution within the team rather than having to rely on other teams, their priorities and time available. Autonomy in all its glory, but sometimes it makes more sense