写用户故事的挑战之一是如何表达非功能性需求。有些需求是与具体的需求无关的，它不像“作为一个文档处理者，我想要在一个文档中插入一个表格”这样的功能描述，而是关于系统的一个属性或者特征的描述。比如说可靠性，有效性，可移动性，可放大性，可用性，可维护性等。在这样的例子中，非功能性需求通常是指“某某性”或者“某某能力”。当然，并不是所有的非功能性需求都是在说“某某性”，还包括像安全机制，性能，自动化能力等等。
在过去，第一次看到“非功能性需求”的时候，我一下子陷入了一个死循环。“既然与功能无关，我为什么要考虑它？”,我确信需求描述者随后一定澄清了为什么我需要考虑它，但是这种叫法始终让我需得困惑。我倾向于把这些非功能性需求理解为一种系统中的“限制”。一个产品负责人说“这个系统必须能够承受10万个并发用户”时，他实际上给开发团队声明了一个“限制” 。产品负责人还不如说“随便你们怎么设计这个系统，只要它能够实现10万个并发用户就行了”更直接。每一个系统中加入的限制都会缩小我们的设计选择范围，把它们叫做“限制”比叫他们“非功能性需求”更容易让人记住这一点。
幸好，限制或者说非功能性需求也能够很容易的使用用户故事的方法表达。下面是一些例子：
• 作为一个客户，我希望能在Windows95之后的所有版本上运行你们的产品。
• 作为CTO，我希望系统能使用现有的定单数据库，而不是重新创建一个，这样我们就不会有两个数据库需要维护。
• 作为一个用户，我希望这个网站在99.999的时候我都可以在想访问的时候可以访问它，这样我不需要麻烦去找另一个站点。
• 作为一个使用拉丁语使用者，我希望某一天也能使用这个系统。
• 作为一个用户，我希望90%的情况下我的驾驶方向都是正确的，而99%的情况下我所花的时间 都是合理的。
如上面例子中所示，我其实很容易就能使用“作为。。。，我想要。。。，这样。。。”的模板，我倾向于在大部分用户故事中使用这样的模板。我这样做有很多原因，这里只强调一点。拿上面的CTO的故事为例子，他希望限制团队让他们使用现有的数据库。（这是一个真实的例子，团队正在考虑建立一个新数据库的方案，并打算让两个数据库在晚上做同步，CTO得知后，果断的说了“不”）。如果我们简单的把需求写成“必须使用现有的数据库”，非常有可能在数月后，我们怎么也想不起来，我们为什么要加这样的限制。我们可能去问我们的产品负责人她是否考虑让我们使用第二个数据库，然后她说“应该没有问题”。然后我们就开始犯错误了。在需求写上是谁会有这个要求，在这里会非常的有帮助。
当然，我们要担心一点，不要完全被这个格式所困。它只是一个帮助思考的工具而已。把系统限制用这样的格式表达有助于我们理解是谁以及他为什么要有这样的限制。如果这样做只会让你写出一条让人迷糊的文字的话，你可以把这个格式扔掉。如果你能找到一个更好的表达方式，那就用那种你认为最自然的方法。
作者:Mike Cohn
