非功能性需求的用户故事描述（缺陷）
下面这个，则是缺陷。
缺陷的语法，也想过一些，现在还不太稳定：
话说火星人上面，可以同时对多个产品进行计划（就是一个项目组可以同时开发多个产品）
这就有一个“如何平衡每个产品这次开发多少的问题”
我们做了几个产品按钮，上面文字包含了里边有多少人天的工作量，点击就能打开查看产品的意向表细节。
但却遇到一个缺陷，就是按钮上面显示的，和里边的内容不符。
还是刚才的原则，要写出对用户商业价值的“伤害”来，而不能只说有缺陷。
陈勇-创业-北京(**9107533) 13:31:44
在加入故事时产品按钮丌刷新
–在加入或移除故事时，顶端的产品按钮上数据不刷新，因此其中的“人天数”不实际人天数丌同步，导致总工作量累计错误。
语法是：在……（场景）时，……（现象），因此……导致……（用户的潜在损失）
阚野-pm-北京(**6916487) 13:33:25
这个导致很重要
陈勇-创业-北京(**9107533) 13:33:25
这里，一定要写出用户的损失、缺陷、不便之处，而不要写技术上的。这样用户和产品经理才能为其排定优先级，否则他们会说：所有缺陷统统都得修正，才能发布！
lastwinner(**810932) 13:33:45
我们碰到一个……缺陷，由于它的存在，会导致……（操作上的非常不便或导致错误的理解等不利甚至有负价值的商业价值），可能会造成……损失（可以具体化说明）
陈勇-创业-北京(**9107533) 13:34:05
对，这里的“导致”，很像刚才说的“以便……”，都是关于对客户的影响的。
陈勇-创业-北京(**9107533) 13:34:35
lastwinner: 应该加上一个“在……时，”，好一些。利于复现。
陈勇-创业-北京(139107533) 13:35:12
缺陷语法是：在……（场景）时，会……（现象），导致……（操作上的非常不便或导致错误的理解等不利甚至有负价值的商业价值），这样吧。
lastwinner(**810932) 13:35:52
对，缺陷和bug一样，也要可重现才便于用户重现，以认识到缺陷的危害。谢谢陈老师指点
陈勇-创业-北京(**9107533) 13:35:52
我们未来有一个模板功能，现在还没有提供，可以内置好模板，新建字段的时候会自动赋值，防止写错了。
模板写好了，还能进行角色分析。比如问：你这个产品为产品经理提供了哪些功能？就可以到所有的“作为……”里边找。
找出来，画成UML。
好了，第一个部分讲完了，就是非功能性需求（不是用户业务数据，不是用户功能）的用户故事的描述语法问题。
语法的核心，是突出所有用户故事对用户的价值。
