需求作业...
最近blog也没有什么好写的,写点老师布置的作业吧.
上个星期老师布置了一次需求作业,摘录如下:
- 查阅一些有关介绍需求工程或软件项目管理的网站，读一篇写得不错的文章，用1－2页概括文章的内容（要求注明文章来源）。
- 人们已经认识到软件项目失败的直接原因主要是
- 缺乏用户的参与；
- 不完整的需求描述；
- 不完整的 SRS ；
- 将三个层次的需求混淆在一起。请你结合客户的10项权利和10项义务，谈一谈做好软件需求应该注意的问题。
自己的第3题的回答就将第2道题当成为客户的需求分析了一遍…
原文如下:
如果把做作业也可以看成一个项目的话，作业要求就是客户的需求，对作业要求的分析就是需求分析，客户是老师，用户是批改作业的助教，我就是需求分析员。客户的需求并不很明确。
1－2页纸
写1－2页纸，每一个人都不同的理解方法。五号字写1－2，或者是一号字写1－2？是word的A4纸写1－2页，还是800字格子纸写1－2页？
客户认为这是很日常的问题，如同怎么洗澡。开发方可能与客户的理解完全不同。模糊的需求造成了需求的歧异性。而且我做作业并没有向老师询问什么，没有做好需求调研，只是按照自己的想法去理解写1－2页纸。开发方与客户缺乏良好的沟通，就立即动手开始做项目，这是一种非常危险的行为。
因为开发时，自己觉得very cool的功能，很有可能不被用户和客户们认可。如果按照自己的理解用一号字写了1－2页纸，恐怕下次上课自己的名字就会被老师打到ppt里去了。
假设我去做进一步的调研（询问老师）：“请问老师1－2页什么意思？”
如果老师很忙，没有什么时间，可能这样回答：“就是1－2页作业纸。”如果这样就完成了一次调研，其实我什么东西也没有得到。
我当时如果认为客户方清晰的描述需求是项义务，但是客户方有可能也认为“作业纸”的回答已经是清晰的描述。我当然需要进一步的要求客户方加以描述，这时老师可能不耐烦的拿出过去别人做过的作业让我看。我必须从那堆作业中对作业纸的概念做一个概括。
如果老师拿出来的作业纸只是过去上交作业纸的某种特殊的类型（例如无格纸），这就有可能使我对“作业纸”这个概念的概括产生偏差。最后交的作业就会用无格纸写。
在项目审批阶段，助教认为本次作业的作业纸不符合作业的规定，作业应当重新完成。这种严重的后果是谁造成？
其实当初我可以这样提问：“作业纸是指的这种纸吗？”（我可以事先准备几种可能的作业纸）老师会对此进行选择。如果老师对这些纸都不满意，可以让老师讲出这种纸到底是什么样式，什么大小，有什么具体要求。也可以让老师找到相似的纸样。
我要纸的具体信息，老师有可能不知道，或者不耐烦，或者知道也说不清楚。老师那里可能再也得不到什么有用的信息。
下面去调查助教们。助教可能很多，可能权利还不一样。得到的信息可能五花八门。有要求用 800 字方格纸；有希望用湖大作业本；有的认为交上来就行，不管什么纸。
我认为要求最苛刻的是需求的最好的约束条件。到底用什么作业纸的矛盾冲突应该由助教，老师和我协商解决。
假设我们开了一次会议，我在会上提出我的解决方案：用 A4 纸写（这种方案对我有利）。老师和助教也都认为这个方案不错。于是我们定下用 A4 纸写。这样为以后留下的一点隐患。我如果当时有很好的洞察力就应该发现以后还要引入另外的附加问题：用什么字体，用什么字号写，用不用斜体、粗体、下划线写，有没有什么格式等等遗漏的需求问题。
可以这样认为：一旦提出了更好的解决方案，就一定会带来新的问题。需求是无穷无尽的，完美的需求是不存在的。只要做到客户满意即可。
假设以上问题都已经搞定，那么看看现在我已经收集到什么信息：
“查阅一些有关介绍需求工程或软件项目管理的网站”得到题目范围是“需求工程”和“软件项目管理”的领域。如果我还不知道这两个概念，可以上网查阅。反正一句话：每个词我都要明白，并且能用清晰的术语向老师和助教表达我的观点。
“读一篇写得不错的文章”，这句话有很大的迷惑性。首先写得不错是什么概念？
这是一个模糊词。
我感觉我这篇文章也写的不错，贴到网上应该也也符和以上要求。假如我们不能对这个“写的不错”有什么准确的理解，可以用“写的很差”的反面定义。
总之，需求的过程就是将模糊的东西明确下来的过程。我对写的不错的定义是：阅读此篇文章的人超过千人，并且有60％以上的评论者认为有指导意义。
下面我进一步分析：读一篇其实是一种暗示，老师的意思应该是至少读一篇，虽然只是写一篇文章的概括。我认为已经将这个潜在的需求挖掘出来。
“用1－2页概括文章的内容”这一个限制条件，经过我先前做的调研，可以这样清晰的描述。用 A4纸，白纸黑字，字体：宋体，字体大小：五号，常规字体无加粗等特殊表现形式，无特殊文体格式。字数限制： 1 － 2页，无其他特殊要求。文字内容：对需求工程或软件项目管理的写的不错的文章（前有定义）的内容概括。
“（要求注明文章来源）”这也是约束条件。而且是必须做到的。
此外还有特殊的规定：“2004-9-13号上交”这是时间约定。
现在我来区分业务、用户、功能和非功能需求。
业务需求：老师的作业要求；用户需求：各个助教对本次作业的要求。可以看到各个助教对老师的作业要求并没有异议。更多的用户需求：字迹工整，页面整洁等等。但是我是用A4纸打印出来，这些需求都可以满足。
我的功能需求：有对以上老师布置作业的详尽解答。非功能需求：解答简单易懂，符合软件需求这门课的专业术语。（省略SRS的制作和签约）
假设我现在有台高智能的计算机，我只要将以上的规约转变为它能懂的字符即可，现在一切搞定。就差这台计算机了 ……
从纯理论来说，在需求这个阶段，客户和需求分析员两个角色就像是在下棋，最终的目标是要走成和棋。
下棋的过程，便是更改需求的过程。客户不会谦让你，每次更改需求都有可能对项目造成不可估量的后果。那你就必须是下棋的高手。
每走一步都要小心谨慎，走错一步都有可能成为死棋。不管将死谁，对于项目组来说，都是种损失。如果需求分析员能够预测到客户下一步棋，那么走和棋的概率将增加。
现在所有的方法论的东西都只能增加你走和棋的概率，不能保障你一定能走成和棋。下棋用的棋谱是这样，关于软件需求的各种期刊杂志也是这样。
“一是理论，二是实践经验。这两者在任何时候都缺一不可。”这真要感谢我的马哲老师和我的良好记忆力。
需求分析员这一角色不是单靠某某理论就能胜任的。没有和客户打交道的经验，没有宏观和微观把握事情的能力，很难担当这一角色。
能够从细节中推出正确的需求，也能从客户和用户的利益冲突的地方找到潜在的需求。如此看来，这一种角色很难担当，甚至不可能有人担当这一角色。
但实际的情况并非如此。这就想我们编程一样：操作系统里有bug，编译环境中也有bug，谁能保证自己的程序中没有bug呢？需求的缺陷就向bug一样难以排除。
既然我们可以控制bug的数量，就也可以控制需求的缺陷。从另一个角度看，其实需求缺陷就是bug。
首先我们必须明确一个结论：“没有完美的需求”。现在我们用一大堆的约束条件来约束需求，我们只是在满足客户的条件下达到一种可行解，而不是最优解。
虽然客户希望随时随地改变这些约束条件，然而开发方却希望将这些约束条件尽可能固定下来。需求的变动将对项目的完工产生致命的影响。
除非客户非要对需求修改，并承担项目延期发布造成的后果。而且项目的后期，确保需求不被改动。否则这个项目可能永远都完成不了。如果非要改动，就放到下一个版本去吧。
不管怎么说，需求是最耗费脑力活动的事情。也是软件工程的起始，如果起点就错了，最后的项目不可能让客户满意。但是即使起点对了，最后的项目也不一定会让客户满意。因为需求这个环节毕竟是软件工程流程中的一环而已。
当初为了把字数限制在3页字以内,就省略了很多需求的过程。现在感觉这份需求分析的作业题目还是有许多要改进的地方。