I'm at odds with what a couple of other people have said.
First up the bit I agree with - stories are a great way of stating functional requirements. For my money they're one of the best ways of actually communicating requirements in a way end users will really take in. I've seen too many specs that get signed off without ever having been read.
The one thing I would say you might want to append to them is non-functional requirements - covering performance, security, data volumes, audit, archive and so on. While they can be covered in stories, sometimes they're better covered in a way that crosses all stories.
In terms of whether it's suitable for large companies this is where I disagree. In my experience (and I've done projects for Shell, American Express, a couple of multi-national banks and others) they're often no more formal than smaller companies so they'll be fine with stories. The reality is that a user in a large company is no better equiped (or interested) in reading class and sequence diagrams than they are elsewhere.
The size and complexity of the project may require more detailed requirements but it's the size of the project, not the size of the company that matters when you're determining how you document requirements.
For me the best requirements documentation is documentation that's suited to it's audience, and for me user stories hit the nail on the head most of the time - they're short enough and clear enough that when they sign them off they mean something because they've read and understood them (as opposed to the sign off of a 100 page spec which invariably means they haven't really read it), but good enough for the developers to work from too.
Yes, you can use user stories for your functional requires. I do it all the time, and have been for years. In my opinion, it works really well, and better than other systems I have used.
Would this approach work for larger clients? To make a gross generalization, no. They are going to have some system that use to define requirements, and likely its not user stories. If you come in with user stories, there is going to be a disconnect with the current practices, which you will have to work through.
I have been successful using user stories with larger organizations, but it take a concerted effort, which both parties need to be committed to.
What you're describing are the use-case scenarios that define the features, this is what is required from a usability perspective and is exactly what the client will understand and agree to. Screen mockups and flow diagrams will definately help both the client and developers.
An implementation specification may then be required to instruct developers on what needs to be included in the actual construction, the depth of this will be determined by your developers capabilities that include their knowledge of the house architecture/framework and methodologies/conventions and may include specifics on what impacts various parts of the application.
We also work in small teams (sometimes one or two developers) and believe the above is all that's required in this instance.
Larger companies with much larger teams may use Modeling Software, UML diagrams and other more detailed specifications. In the case where you the primary developer, you should still spend the time designing your application, but if nobody is going to review the designs and insist on all the formalities, your time is better spend implementing the software.
发布评论
评论（3）
我与其他几个人所说的不一致。
首先，我同意——故事是陈述功能需求的好方法。在我看来，它们是以最终用户真正接受的方式实际传达需求的最佳方式之一。我见过太多在没有阅读过的情况下就签署的规范。
我想说，您可能想要附加到它们的一件事是非功能性需求 - 涵盖性能、安全性、数据量、审计、存档等。虽然它们可以用故事来涵盖，但有时最好以跨越所有故事的方式来涵盖它们。
至于是否适合大公司，这是我不同意的地方。根据我的经验（我为壳牌、美国运通、几家跨国银行和其他公司做过项目），他们通常并不比小公司更正式，所以他们对故事很满意。现实情况是，大公司的用户并不比其他地方的用户更有能力（或更有兴趣）阅读类和序列图。
项目的规模和复杂性可能需要更详细的需求，但在您确定如何记录需求时，重要的是项目的规模，而不是公司的规模。
对我来说，最好的需求文档是适合其受众的文档，对我来说，用户故事大多数时候都击中要害——它们足够短、足够清晰，当他们签字时，它们意味着一些东西，因为它们’我已经阅读并理解了它们（而不是签署 100 页的规范，这总是意味着他们还没有真正阅读过它们），但对于开发人员来说也足够好了。
I'm at odds with what a couple of other people have said.
First up the bit I agree with - stories are a great way of stating functional requirements. For my money they're one of the best ways of actually communicating requirements in a way end users will really take in. I've seen too many specs that get signed off without ever having been read.
The one thing I would say you might want to append to them is non-functional requirements - covering performance, security, data volumes, audit, archive and so on. While they can be covered in stories, sometimes they're better covered in a way that crosses all stories.
In terms of whether it's suitable for large companies this is where I disagree. In my experience (and I've done projects for Shell, American Express, a couple of multi-national banks and others) they're often no more formal than smaller companies so they'll be fine with stories. The reality is that a user in a large company is no better equiped (or interested) in reading class and sequence diagrams than they are elsewhere.
The size and complexity of the project may require more detailed requirements but it's the size of the project, not the size of the company that matters when you're determining how you document requirements.
For me the best requirements documentation is documentation that's suited to it's audience, and for me user stories hit the nail on the head most of the time - they're short enough and clear enough that when they sign them off they mean something because they've read and understood them (as opposed to the sign off of a 100 page spec which invariably means they haven't really read it), but good enough for the developers to work from too.
是的，您可以使用用户故事来满足您的功能需求。我一直这样做，而且已经很多年了。在我看来，它运行得非常好，并且比我使用过的其他系统更好。
这种方法对大客户有效吗？做一个粗略的概括，没有。他们将拥有一些用于定义需求的系统，并且很可能不是用户故事。如果你带着用户故事进来，就会与当前的实践脱节，你必须解决这个问题。
我已经成功地在较大的组织中使用了用户故事，但这需要双方共同努力。
Yes, you can use user stories for your functional requires. I do it all the time, and have been for years. In my opinion, it works really well, and better than other systems I have used.
Would this approach work for larger clients? To make a gross generalization, no. They are going to have some system that use to define requirements, and likely its not user stories. If you come in with user stories, there is going to be a disconnect with the current practices, which you will have to work through.
I have been successful using user stories with larger organizations, but it take a concerted effort, which both parties need to be committed to.
您所描述的是定义功能的用例场景，这是从可用性角度来看所需要的，并且正是客户会理解和同意的。屏幕模型和流程图肯定会对客户和开发人员都有帮助。
然后，可能需要实施规范来指导开发人员在实际施工中需要包含哪些内容，其深度将取决于开发人员的能力，包括他们对房屋架构/框架和方法/惯例的了解，并可能包括具体细节关于影响应用程序各个部分的因素。
我们还在小团队中工作（有时是一两个开发人员），并且相信上述内容就是这种情况下所需要的全部。
拥有更大团队的大公司可能会使用建模软件、UML 图和其他更详细的规范。如果您是主要开发人员，您仍然应该花时间设计应用程序，但如果没有人会审查设计并坚持所有手续，那么您最好将时间花在实施软件上。
What you're describing are the use-case scenarios that define the features, this is what is required from a usability perspective and is exactly what the client will understand and agree to. Screen mockups and flow diagrams will definately help both the client and developers.
An implementation specification may then be required to instruct developers on what needs to be included in the actual construction, the depth of this will be determined by your developers capabilities that include their knowledge of the house architecture/framework and methodologies/conventions and may include specifics on what impacts various parts of the application.
We also work in small teams (sometimes one or two developers) and believe the above is all that's required in this instance.
Larger companies with much larger teams may use Modeling Software, UML diagrams and other more detailed specifications. In the case where you the primary developer, you should still spend the time designing your application, but if nobody is going to review the designs and insist on all the formalities, your time is better spend implementing the software.