由于我们是一家小公司，我既是项目经理又是开发人员。我为客户创建的规范包含许多用于描述和定义项目的元素，包括用户故事以及我认为需要包含的任何其他元素以向客户定义项目（例如线框、用户流、站点地图等）。
如果功能规范“完全从用户的角度描述产品将如何工作。它不关心事情是如何实现的。它谈论功能。“。那么有没有人认为使用用户故事来定义网站的功能规范有什么问题呢？真的有人用这种方式做功能规范吗？
真的，我正在尝试提高我的游戏水平，并且想知道这种方法是否适用于可能对功能规范应包含的内容有更严格想法的大客户，因此可能需要正式的方法。目前，我们的客户肯定对我们制作文档的方法反应良好。
我很想听听专业从事项目管理的人对此有何看法。
我与其他几个人所说的不一致。
首先是我同意的一点——故事是陈述功能需求的好方法。对我来说，它们是以最终用户真正接受的方式实际传达需求的最佳方式之一。我见过太多的规范在没有被阅读的情况下就被签署了。
我想说的你可能想要附加到它们的一件事是非功能性需求——包括性能、安全性、数据量、审计、归档等等。虽然它们可以被故事覆盖，但有时它们最好以跨越所有故事的方式进行覆盖。
至于它是否适合大公司，这是我不同意的地方。根据我的经验（我曾为壳牌、美国运通、几家跨国银行和其他银行做过项目），他们通常不比小公司更正式，所以他们会接受故事。现实情况是，大公司的用户在阅读类和序列图方面并不比在其他地方更好（或感兴趣）。
项目的规模和复杂性可能需要更详细的要求，但在确定如何记录要求时，重要的是项目的规模，而不是公司的规模。
对我来说，最好的需求文档是适合其受众的文档，对我来说，用户故事大部分时间都一针见血——它们足够短且足够清晰，以至于当他们签署它们时，它们意味着什么，因为它们已经阅读并理解了它们（与签署 100 页规范相反，这总是意味着他们还没有真正阅读过），但对于开发人员来说也足够好。
是的，您可以将用户故事用于您的功能需求。我一直这样做，而且已经很多年了。在我看来，它运行得非常好，而且比我用过的其他系统更好。
这种方法适用于大客户吗？做一个粗略的概括，不。他们将拥有一些用于定义需求的系统，并且可能不是用户故事。如果你带着用户故事进来，就会与当前的做法脱节，你必须努力解决这个问题。
我在大型组织中成功地使用了用户故事，但这需要双方共同努力。
您所描述的是定义功能的用例场景，这是从可用性的角度来看所需要的，并且正是客户将理解和同意的。屏幕模型和流程图肯定会帮助客户和开发人员。
然后可能需要一个实施规范来指导开发人员在实际建筑中需要包含哪些内容，其深度将取决于您的开发人员能力，包括他们对房屋架构/框架和方法/约定的了解，并且可能包括细节影响应用程序各个部分的因素。
我们也在小型团队（有时是一两个开发人员）中工作，并且相信以上就是这种情况下所需要的全部。
拥有更大团队的大型公司可能会使用建模软件、UML 图和其他更详细的规范。在您是主要开发人员的情况下，您仍然应该花时间设计您的应用程序，但如果没有人会审查设计并坚持所有形式，那么您最好将时间花在实现软件上。