广州-胖胖的蠕 (531***13) 2012-01-06 16:12:09

广州-胖胖的蠕 (531***13) 2012-01-06 16:12:35

广州-胖胖的蠕 (531***13) 2012-01-06 16:13:03


广州-胖胖的蠕 (531***13) 2012-01-06 16:13:25
这个其实还有点粗
广州-胖胖的蠕 (531***13) 2012-01-06 16:13:28

广州-胖胖的蠕 (531***13) 2012-01-06 16:13:49
按照讲师的说法，用户只要看得到的，都要将清除
广州-胖胖的蠕 (531***13) 2012-01-06 16:13:54

小渔儿 (26311280) 2012-01-06 16:14:20
这个肯定都有的啦
广州-胖胖的蠕 (531***13) 2012-01-06 16:14:21
刚才给出的，只是一个查询功能
广州-胖胖的蠕(531***13) 16:13:08

广州-胖胖的蠕 (531***13) 2012-01-06 16:14:33
比如输入一个email的提示框，需要说清楚用户输入为null、超长、补正确的邮件格式、是否需要类似google suggest之类的全部写清楚
广州-胖胖的蠕 (531***13) 2012-01-06 16:14:59
也就是说需求文档没有任何歧义，其实我们现在也很难做到
广州-胖胖的蠕 (531***13) 2012-01-06 16:15:35
主要是高质量的需求人员太少，没办法每个模块都写这么细
潘加宇 (704837756) 2012-01-06 16:15:44
这个哪里是需求啊，有表，有控件，有具体操作细节。
广州-胖胖的蠕 (531***13) 2012-01-06 16:16:02
只能是核心模块写得细一些，简单增删改查模块一笔带过
广州-胖胖的蠕 (531***13) 2012-01-06 16:16:33
这个其实是需求、设计二合一了
小渔儿 (26311280) 2012-01-06 16:16:38
对，我们的需求都说，不能设计表
潘加宇 (704837756) 2012-01-06 16:16:56
代码最没有歧义了，但代码不是需求！
广州-胖胖的蠕 (531***13) 2012-01-06 16:17:38
这个就看公司有没有独立与需求的设计人员了
潘加宇 (704837756) 2012-01-06 16:18:25
人是可以合为一个，但事情不可以合，需求（问题）和设计（解决方案）要分开是有道理的，否则直接写代码不就行了吗