It never rains, it pours.
不鸣则已，一鸣惊人。
—————————————————————————————————
句子的字面意思是，本来从不下雨的，却下起了倾盆大雨。虽然我们这里用的翻译是带有明显积极意义的成语“不鸣则已，一鸣惊人”，但实际上，英文中的这句话含有积极和消极两方面的涵义。
对此，英文的解释是，“One stroke of good (or ill) fortune is often followed by many other instances of luck (or misfortune) when you least expect them. ”，即，好的或坏的运气，在你完全没有料到的时候突然出现。因此，当我们用来形容“病来如山倒”或“祸不单行”之类的坏事时，也可以使用这句短语。
追溯IEEE（Institute of Electrical and Electronics Engineers的英文缩写，全称是国际电气与电子工程师学会）的历史，可以到19世纪80年代。IEEE的前身是成立于1884年的AIEE（美国电气工程师协会）。1963年1月1日AIEE和IRE(美国无线电工程师学会)正式合并为IEEE，是当时美国规模最大的专业学会。经过40多年的发展，IEEE早已突破美国国内学会的界限，成为全球最大的非营利性专业学会。IEEE是一个持续成长的专业学会组织。从1963年至2004年，IEEE会员以平均每年将近6000人的数量在增长，他们在各自的领域做出的贡献、发表的文章，大大提高了IEEE在全世界的影响力。目前，IEEE拥有全球近175个国家和地区的38万多名会员。
自成立以来，IEEE一直致力于推动电气、电子、计算机、网络、通信与电工技术在理论方面的发展和应用方面的进步，通过在广泛领域的活动规划和服务支持其成员的需要。IEEE主办或合办300多个国际学生会议，每年出版发行占全世界30％强的电力、电子及计算机科学技术类的书报、杂志和其他各种刊物，已制定了将近900个行业标准，在太空、计算机、电信、生物医学、电力及消费性电子产品等领域中都是主要的权威。
IEEE有着严密的组织机构，学会由主席（首席执行官）和执行委员会共同领导，每年选举一次。学会的重大事项由理事会和代表大会进行决策，日常事务由执行委员会负责完成。学会设有超导、智能运输系统、神经网络和传感器四个委员会（Council）和38个专业学会（Society），如动力工程、航天和电子系统、计算机、通信、广播、电路与系统、控制系统、电子装置、电磁兼容、工业电子学、信息理论、工程管理、微波理论和技术、核和等离子科学、海洋工程、电力电子学、可靠性、用户电子学等。此外，IEEE还根据会员的来源将IEEE的全球会员分为美国东北部、美国东部、美国中部、美国西南部、美国西部、加拿大、欧洲中东与非洲、拉丁美洲和亚洲与太平洋地区等10个大区(Region)和300多个地区分会（Section）组成。对应IEEE全球总部的设置，IEEE每个大区和地区分会都设有执行委员会；对应IEEE的专业学会每个地区分会下还设专业委员会（Chapter）。
IEEE会员可以相互沟通信息共享；IEEE执委会还设有奖励委员会，对会员的技术和专业成就给予认可并颁奖。由于IEEE拥有7万多名学生会员，除了IEEE在总部设有负责学生会员的学生活动委员会外，每个地区分会还在拥有一定数量学生会员的大学和科研机构下设立若干个在学生支会（Student Branch）。目前,IEEE共拥有将近1300多个专业分委员会和2000多个学生分会。
IEEE与中国
1985年，经当时的电子工业部的批准和中国科协的同意，IEEE在中国设立了IEEE北京分会。分会设有办公室，负责办理日常工作，挂靠在中国电子学会总部。
北京分会从建立之初就得到了中国电子学会、中国电机工程学会、中国通信学会、中国电工技术学会等四个全国性学会的支持。IEEE在我国的会员增加很快，截止到2005年，北京分会现在已有各种会员2600多名,建立了电力、通信、计算机、元件、微波、信号处理、工业电子、电力电子等二十个专业委员会。此外，IEEE北京分会还先后在清华大学、北京邮电大学、北京交通大学、北京大学、西安交通大学等高校设立了7个学生支部。
随着我国经济建设的发展、学术地位的提升和国际交往的增多，IEEE在中国的活动日渐频繁。特别是近五年来，IEEE的全球官员也频繁访问中国。2005年，IEEE亚太区执委会在北京主持了IEEE北京分会成立20周年庆典；2006年4月IEEE总部访问团先后对上海、北京、西安等6个城市进行了巡回访问；7月IEEE亚太区学生代表大会首次在中国召开。此外，IEEE每年都会在中国主办或者协办几十次国际会议。
IEEE-SA与标准的制定
一般而言，标准在电气和电子工程中具有重要作用。电器与电子工程师在设计产品和系统时都必须遵循标准。作为全球最大的专业学术组织，IEEE也非常重视标准的制定工作。IEEE专门设有IEEE标准化委员会IEEE-SA（IEEE Standard Association）。IEEE的标准制定内容包括电气与电子设备、试验方法、原器件、符号、定义以及测试方法等多个领域。IEEE-SA设有标准局，标准局下又设置两个分委员会，即新标准制定委员会（New Standards Committees）和标准审查委员会（Standards Review Committees）。
IEEE现有42个主持标准化工作的专业学会或者委员会。为了获得主持标准化工作的资格，每个专业学会必须向IEEE-SA提交一份文件，描述该学会选择候选建议提交给IEEE-SA的过程和用来监督工作组的方法。当前有18个学会正在积极地制定标准，每个学会又会根据自身领域设立若干个委员会进行实际标准的制定。例如，我们熟悉的IEEE802系列标准，就是IEEE计算机专业学会下设的p802委员会负责主持的。IEEE802又称为LMSC（LAN /MAN Standards Committee，局域网/城域网标准委员会），致力于研究局域网和城域网的物理层和MAC层规范，对应OSI参考模型的下两层。LMSC执行委员会（Executive Committee）又下设工作组（Working Group）、研究组（Study Group）、技术顾问组（Technical Advisory Group）等等。
新标准制定委员会的职能是负责推荐属于IEEE专业学会所属域内的各种新的标准，并将经过推荐的新标准课题提交给其所属修正技术委员会（Correct Technical Committees）和新标准课题编制工作组，然后将其编制成项目授权申请书（PAR，Project Authorization Requests）推荐到IEEE-SA大会审核。 在IEEE-SA中将进一步评审、修改推荐的新标准课题，以确保IEEE成员评审的一致通过。最后，将修改完成的新标准课题返回标准局颁布。
通常，一个IEEE标准通过流程如下：首先从发起人提出标准课题，接着形成由发起人组成的研究组，由此研究组向新标准制定委员会提交项目授权申请书并申请批准；依据该委员会批准的项目授权申请书，组织对此课题有兴趣的专家工作组进行审议，推荐的项目授权申请书原则上应在四年内完成。一旦标准草案起草完成，则先后经工作组、研究组两次无记名投票表决。若两次投票表决同意者均超过75%，则标准草案获得通过，经IEEE-SA最后批准后，便可形成正式标准发布。
来源：IEEE网站和IEEE-SA主页。
所有的失败都是管理性格的失败,因为，投资、产品问题，都可以靠别人帮助解决，而管理心理，真的跨越不过去。
你的公司员工，是否背地里抱怨这七件事？
1、工作压力太大，整天带着面具上班；
2、得不到授权，有被疏远的感觉；
3、你的承诺不兑现，公司充满政治色彩；
4、因背景、学历、资历原因受过歧视；
5、开会只是走走形式，每个重要决定都由你一个人做出；
6、大量的信息被隐藏起来，听不到内部真实的声音；
7、下属反映你按喜好决定员工的升迁，对人过于严厉。
我相信你的公司一定有几点与上面的相似。我现在讲七个小故事，请你分析导致这些不正确工作方式的原因。
故事一：工作压力太大，怎么办？
我的一位员工最近陪同来自不同国家的学员参加一个高级研修班，她负责录像、记录和事务性工作，一周下来，疲劳不说，常常要承受客户的冷言冷语。再加上，客户都是海外的大老板，她自己对比起来差距很大。这些使她的压力很大。研修班结业的最后一天，我给她打了一个电话。我只说了三句话，第一是问候，第二让她先回家休息，第三向她询问另一项工作的完成情况。另一项工作由她负责，而且到了最后期限。我没有意料到，她大发牢骚，抱怨满天，说的都是过头的话。我当时保持沉默，只听不说。
事后，我想这究竟为什么，平时这位员工不是这样，今天为何反常？因为压力太大。第一，她承受客户的冷言冷语，压力已经够大了；第二，而我询问新的工作又等于向她施加了压力。人的忍耐总是有限，在一定场合会爆发。
由此看来，一个企业不重视员工的情感或对处于超强度工作状态的员工不表示支持的话，那么，这个企业就一定要改变，否则，由此而来的副作用会积聚起来并寻找机会爆发。
看看一些服务行业，当员工在处理与客户的关系时会感到巨大的压力。你到餐厅就餐，希望赶走那些没有笑容的服务员，将食品狠狠地摔到他们面前，但你想过没有，对于这些服务生来说，时时保持好心情可能吗？我们得有宽容心。在电话销售行业，销售人员被要求使客户从你的声音感受到微笑服务，他们天天带着面具上班，我们应该将心比心。酒店的礼仪小姐被要求面对非礼的客户也要保持迷人的微笑，这是人性化的管理吗？
记住：宽容不是软弱，反过来，你的宽容塑造了出色的领导力和优秀的团队。
故事二：不欣赏的员工，如何处理？
我曾在一家国有企业工作，中国的国有企业是带有政治色彩的企业，这里的人们喜欢在一些小事情上耍小手腕，而领导也热衷于玩这种政治小*戏，但最终是“玩火必自焚”。
我当时负责一个部门，有一位主管因能力不足，被免职。她对我们这个团队极不满意，伺机报复。一天，她捏造说，我和另外两名同事在一起，诋毁我们的上司。上司也不做调查，相信了她的“告秘”。我们部的所有员工被叫到一起，上司让我们“说清楚”。我当时大吃一惊，这是根本没有的事！我们四人经过对质，谎言被揭穿，真相大白，全是那位主管一人捏造，从此以后，她在我们这个部门被疏远了。
被疏远是最难受的。第一，你在团体中可有可无，没人理你；第二，孤立无援；第三，感到工作失去意义。
我是如何帮她树立起自信心的呢？我让她负责一个项目，而这个项目需要跨团队的合作，她必须成为团体中的一员，我首先支持她，然后做别人工作。告诉大家，她很不幸，有过离婚的经历，多从她的角度去理解。我还帮助她介绍男朋友。这一切，使她重新找回了“家”的感觉。
记住：你永远不能疏远任何一个员工，不管你多么不欣赏他。你的任务是找到他的独特基因，然后，启动基因程序！
故事三：失信了，会怎么样？
这是我一位朋友的真实故事：一家事业单位领导找我的朋友谈话，暗示我的朋友去他那里会有更好的个人发展前景。在调动之前，这位领导许愿说，“先过来，半年后提拔你。”
我的朋友信以为真，轻信了他的话，调了过去。结果，半年过去了，一年过去了，再也不提我朋友的发展问题。你说，我的朋友还会相信这位领导的话吗？
人类有三个特征：第一，害怕丧失社会地位；第二，对拥有影响力的渴望；第三，对不讲信用的厌恶。企业领导者常常低估下属对其是否信用的重视程度，破坏自己做出的承诺。
记住：别人对你的信任就像一棵树，生长需要很长时间，但瞬间可以被你锯断。
故事四：敌视圈外人，对吗？
我在南开大学上课时，为了案例讨论，教授将我们分为几组，并按组给成绩。课堂结束后，我询问同学哪一组好，几乎每一组的同学都能找到一处自己强于对方，总的说来认为自己一方比另一方好；而当问起对另一组的评价时，每一个同学都对对方提出批评，哪怕是自己最要好的朋友也不例外。
如果把他们放到竞争性更强的*戏中呢？我记得，在模拟决策实战演习中，对本组的积极态度和对对手的“仇恨”态度不断上升，教室里充满了敌视的情绪。
我所在的小组，一位大型国企的CEO因为开董事会离开课堂，等开完会时，马上给我打电话，第一句话是，“我们排在第几？”
对事物和人进行分类，划分你我，是人的本能。我们天生喜欢分类思考，这种思考方式可以帮助我们辨别哪些是危险的，哪些人是不可信的。
在你的企业中，如果想让一个群体达成某个协议，只需设法将甲（你赞成的）归于好的、有益的一类即可，而将乙归到困难的、危险的一类即可。在公开选拔高级干部时，我们看到组织部门将中意的挑出来，只需给其他所有的人选标上负面标签即可，然后再给选拔的人编个理由即可。想一想，是不是这回事？
记住：人类容易宽容圈内人，容易敌视圈外人。请不要轻视不同类的人。
故事五：团队为何失败？
我是一个天生爱提出问题、研究问题的人，喜欢开会简短、直本主题。我在一家国有单位工作时，发现这里开会总在反复、低效地进行讨论。事实上，这个单位的每个重要的决策早就由CEO做出了，所有的人都按他的眼色行事。开会讨论时，你的意见与他相左，他马上武断地打断别人，副手成了他的“应声虫”。相反，当他不在会场时，大家倒是表现地积极和富有成效。在他任CEO期间，这个单位年年亏损。
我参加过不少国有企业、事业单位的会议，深深感到这里的气氛过于官僚化，没有真正意义的讨论，开会好像是为了显示级别存在，而不是为了有效解决问题。
在很多国有企业中，你找不到实际意义的团队，经常为了应付上级成立若干领导小组，成员都是各个部门的负责人，小组的成果无人过问，唯一关心的是“我是不是在这个小组名单里”。这样的团队是失败的。另外存在的一个典型问题是，这里的人们仅仅为代表自己利益的小团体工作，彼此之间暗中勾心斗角。
我们说，企业需要团队，但太多无用的例子说明，人们不愿意加入团队，因为上下级泾渭分明，这不是真正的团队。
记住：真正的团队是，为一个具体的目标工作，超越职能部门和上下级关系。这样的团队能建立一种团队精神。
故事六：信息隐藏起来，会如何？
有一家工业公司的管理体系是如此糟糕：采购部的负责人从廉价供应商那儿进货，后来因为供应商的破产，导致公司不得不重新寻找供应商并以高于成本很多的价钱进货；生产部从国外进口设备，但新机器总出问题，后来还是使用旧机器；市场部找了一家关系户作为广告代理商，结果根本不懂广告规律，自己的促销广告为同行做了免费宣传。而所有这些，就是因为这里的人们喜欢把实际情况隐藏起来做事，导致公司领导不断做出错误判断。
我们应该鼓励员工公开自己的想法，鼓励员工向那些“理所当然”的程序提出异议，鼓励公司把所有的事情都摆在桌面上。整个公司创造一种公开的气氛。
记住：君子没有什么事情不可以对人说。公开化后，即使你错了，别人可以原谅你。
故事七：读你自己
我记起一家纺织厂，它的CEO是作风强硬派，依靠个人奋斗有了自己的工厂。员工害怕让老板发现他们的错误，因为他们看到因为“勇于”暴露自己的问题而被开除的例子。所以，他们总是试图掩盖问题，即使尽早承认就可以解决问题，但没人说。在这里，犯错误是丢人的事，于是，为了不丢人，就故意不犯错误。在一次，CEO当着众人的面，就一些小失误，对一位重要的管理人员进行了严厉、尖刻的批评。最令我吃惊的是在场的所有人，除了我，竟无一人感到尴尬。他们会后告诉我，这种事是“家常便饭”。几年后，这个公司因处于破产边缘被人接管。
我研究过无数的失败案例，发现失败的真正原因，既不是投资问题，也不是产品问题，而是CEO的管理性格的失败。因为，投资、产品问题，都可以靠别人帮助解决，而管理心理，真的跨越不过去。
记住：所有的失败都是管理性格的失败，不论它千姿百态，翻来覆去总是隐性心理出了问题。
来源: 网友原创
1。技术人员/程序员不了解项目经理的作用。认为项目经理就会催他们干活和逼他们。
是公司老板派来监督他们的工头。
– 解决办法：要向所有的人员贯彻项目管理的基本概念和项目经理自己在项目中的作用，
让大家了解作为经理他自己要承担的责任是什么，主要的工作是什么。项目经理不是监工，
也不是项目失败的替罪羊，他是和大家在同一个战壕的战友，从而得到大家的认可。
另外，也要明确每个成员的责任，都要把这些写清楚在权限/责任列表中。
2。技术人员/程序员最讨厌写文档（起码是过多的文档），可是项目管理者偏偏最看重这个，
他们整天催你交他认为必须的文档，拿到手后又这也不对，那也不对，吹毛求疵。
程序员讨厌这样，但是却不能表现出什么不满，抵触情绪自然会影响到工作。
– 其实在一个有着正规开发流程的公司是完全可以避免这种情况的存在的。30%的时间用于
研究设计和编写设计文档；20%的时间来进行代码编写是完全可以接受的。但是在大部分的
公司里面，程序员和系统分析员都是同一个角色，95%程序员一般因为考虑到了项目进度的
原因都会着急在没有完全的设计文档的前提下写代码。
解决办法：在制定项目进度之前，项目经理要反复阐述文档的重要性，明确开发人员在每个
阶段到底都要提交些什么文档。在制定项目进度的时候，要让技术人员充分参与计划的制定，
把写文档的时间留出来。文档的格式和要求要在任务开始之前发给人员并做好解释。文档完
成后，项目经理一定要进行文档的审查和把关。一定要留出写文档的时间，否则不会有人在
项目都完成后补充文档，即使有，那样的文档也会是粗制滥造的，应付了事的。
3。技术人员自己喜欢掌控时间，当他们对某个技术问题没有搞清楚的时候或者自己的任务进
度落后了的时候一般都会主动加班，但是当自己目前的任务完成之后呢也会休息一下，上上网
等等。所以最恨项目管理人员时不时过来问你进度怎么样了？好像不允许你有一刻的轻松。
解决办法：在项目开始的时候做好沟通计划，明确在什么时候会开团队会议，在什么时候会提交
进度报告。平时项目经理就不要把技术人员当成过去工厂里面的工人，把自己当成监工。要充分
相信大家的责任心。在开项目会议的时候，也要主动把自己所作的工作向大家如实汇报而不是
一个单向的汇报。
4。一般的技术人员都不太善于沟通。有了问题，大部分人都只是沉默寡言或者背后说说闲话。
这种气氛非常不利于项目的进行。要让大家从项目一开始就知道，任何项目的进行都不可能是
一帆风顺的。风险和困难随时存在。项目经理不是全才，项目需要大家群策群力；要团队成员
勇敢和坦率的说出自己的担心和发现的问题，大家共同解决。如果发现项目经理在某些问题上的
做法有乱弹琴瞎指挥的错误，也要及时提出。在进行一个项目的同时使大家都共同提高！
5。在项目开始的时候就要告诉大家有问题要提前提出来，不要等到最后一刻才提出来。告诉大家
即使是要跳槽，也最好提前跟项目经理沟通一下。这样可以保证有充足的时间做好交接工作。
6。项目计划是项目经理自己的事情。
–项目计划不是项目经理一个人的事情，项目经理一个人的经验和能力也不可能制定出一个好的计划。项目经理要做的就是带领大家一同完成项目，要大家群策群力。这样项目计划才会是合理的切实可行的。
作为项目经理，我希望我们项目的开发人员做到以下几点：
1、主动性
在项目中积极思考，主动提出自己的意见和看法。
遇到问题主动寻求相关人员协助，主动沟通。
2、Bug修复及时
项目经理在项目计划中通常会安排了bug的修复时间,以及在此基础上的后续工作（比如集成测试、回归测试等），特别是到了项目后期，Bug修复是否及时将直接影响后续工作的进行。所以项目经理希望开发人员能按时完成bug修复任务。开发人员往往没有认识这一点的重要性，在bug修复的问题上不是很积极。
3、按时完成任务
通常，我们会要求开发人员根据任务的复杂程度和自己的能力评估所承担任务的开发时间，项目经理也会评估这些时间的合理性，然后结合项目的整体情况给出项目计划。一旦某个开发人员没能按时完成自己分配的任务将直接影响整个项目的进度。
当然由于需求变更以及某些不可预计的原因造成任务推迟，要及时和项目经理沟通，以便项目经理根据实际情况作出action，确保项目的顺利进行。
4、创新
创新不是口号，创新其实就是我们对平时工作的思考，如果你是个有心之人，那么创新的idea会源源不断从头脑中显现，而我们的项目就是创新思想实施的最好机会。流程、规范、技术方案等等地方都是你创新的舞台。
5、责任心
对自己的代码负责，尽量做到完美。
一个优秀开发人员的标志就是写出来的代码总是让人赏心悦目。好的代码体现 在良好的可维护性，易读性，性能优良。功能的实现只是代码的最基本要求，只有严格要求自己，我们的编程水平才能提高。
我也是从以上几点考核我们的开发人员。
来源：http://blog.csdn.net/yzhz 杨争
一天我与一个同事吃午餐的时候，他给我讲了一个令人惊讶的发现。他参加了一场关于面向服务构架 (SOA)讲座，认识到以前从没有的术语定义，比如，“授权（Enable）”是什么意思，“Enterprise Network Bus”又是什么意思等等。
在软件开发中我们经常使用术语，而这些术语对于不同的人具有不同的含义。本文将探究软件开发团队通用词典的必要性，同时指出创建通用词典应注意的事项。
混乱之塔
“上帝说：‘如果人们都说相同的语言那么他们想做的就没有达不成的。让我们下去混淆他们的语言吧，那样的话他们之间就不能相互理解了。’”《圣经》，新国际版，11章起源，5-7页。
人们都说同一种语言时，彼此之间都能相互了解，则能够完成几乎所有事情。如果人们更多的讲述、倾听和了解彼此彼此之间的语言，则不会在愚蠢的错误和误解上浪费很多时间。
大多数人都有这样的经历：我们为别人指出了去某个地方的方向，但是那人最后又折回来了，因为我们所给出的方向不容易被接受。或者我们接受别人的指导后，我们所做的与指导人所期盼的情况完全是两码事。
这让人非常恼火，而且对于软件开发这是要付出代价的。一般预计项目40%的预算被返工所消耗。想象一下这么多返工并不是因为技术而仅仅因为交流障碍，那么可以看出通过更好的交流减少返工从而提高团队的效率的潜力是多么巨大。
开发一种通用语言是减少返工的基础，它可以使交流更清晰更明了。虽然不很完美，但是这样可以大大提高在交流中完全理解别人意思的可能性。
现有词汇再学习
与开发者构建共同经验和在确信已经知道的事情上形成共同理解的基础上，发展自己的词典是满足词汇学习要求的一个大挑战。你可能知道别人的意思但是实际上你对事情的理解与别人稍稍有些不同。
举个例子，当我说“猫”的时候，你可能认为我是在谈论那只名叫“Fluffy”的你将它当作孩子的白色波斯猫。或者你可能认为是你今天买的那只带斑纹的猫。而实际上我讲的是最近看到的那只孟加拉虎。我应该指出我所讲的是一只“大猫”吗？也许应该。但是这还不够详细而准确。有可能我讲的是美洲豹、狮子或者老虎。
需要指出的一点是我们有共同的词汇但是我们对这些词汇的定义每个人都稍微有些不同。诀窍是让团队中所有人对词汇的定义尽可能趋于一致，使用这样的词汇则很容易让团队中的人员了解其精确意义。
一个有效的方法是找例文。例文定义和扩展了这些术语。例如：面向服务构架（SOA）对很多人来说都是个难以定义的词汇。但是，可以通过要求或鼓励人们阅读关于SOA的内容理解它。虽然不是每个人都同意文中SOA详细内容，但它也为团队定义词汇提供了参考。
支柱定义允许定义其他相关的术语。并且可以加强团队对此术语理解。但是即使有很好的理解，支柱术语还远远不够。
创建新词汇
现有词汇是很好的开始。从那些经验丰富的人员那里可以学到很多有特定意义的单词和短语。但是这需要时间。当你尝试着自己描述自己的技术、过程或方法的时候，你会发现现有的词汇不能表达它。
一位叫“David Feinberg”的前同事，他有个梦想：在他的词汇里添加新单词。这是个了不起的想法，我希望他能成功。当然，不管有没有完成目标，他都擅长于向词汇中添加新单词。这些单词的美妙之处在于对于团队成员来说它们具有详细准确的含义。并且对团队外的人员来说，他们提不出不同的定义。
虽然不让其他人知道词语的意思不是件好事，但是对于词语的意思不被曲解是有好处的。因为没有其他的线索联系到这个单词上来，它只具有团队故意限定的唯一定义。
最困难的工作是诊断和确定那些意思不清晰和可重复的新单词。交流中也同样存在这样的问题。如果看不到这个问题或它不成为一个问题，都将很难让大家都关注这个问题。一个新术语有利于理解或不理解某件事，但是被错误理解的可能性是非常低的。
精确的文化
从看我文章的不同专业编辑那里获得的最大利益之一是他们鼓励我的文章应更详细而精确。我不能只说事情发生了，还应该详细记述发生了什么、在什么时间、持续了多长时间等。我们讲话的时候都说一些一般的术语。这是很不正式的，这样的讲话将导致很多地方含糊不清并且不严密。大多数表达不严密的情况发生在通过Email询问问题的时候。我们指出问题但是很少指定问题回应的最后期限，在多长时间回应质询的地方留下了含糊之处。
读和写中精确文化的影响是微妙的。因为可以抛开它为开发人员编写自己的词典；但是它就像催化剂，能加速过程。通过标记团队交流的精确度，队员都会努力找出那些精确的单词表达他们的意思。他们将使用“我们需要一个编辑屏幕为用户添加、阅读、编辑和关闭客户，但是不能删除客户，因为这是不需要的”这样的表达来代替“我们需要开发一组需要的标准操作”。
这样有可能会增加交流的词汇量，有可能由于精确的表达浪费了一些时间，但是这肯定比向屏幕中编写根本用不着的“删除”代码所花费的时间少，因为根本不允许客户被删除。
精细的文化
精确的文化不仅仅只关乎读和写，它和听也有关系。换句话说，用精确的语言交流也需要听者校验说者所表达的意思。精细的文化是鼓励听者通过反馈挑战对说者所表达意思的理解。这会自动提炼说者所表达的意思，并且使其更精确。
人道主义方法到心理学基于告诉人们所听到的事情这一观念。这一方法可以确定病人也可以对顾问进行启蒙。病人喜欢有人倾听他们的讲话并且可以扩展他们感觉或描述一些情形的细节。而顾问可以以此验证对病人的了解，反过来也可以更好的了解病人。
这一基本形式是：说者讲，“我认为我们需要基于SOA方法解决这个问题。”，听者（或团队中的一个听者）会这么说：“我知道你认为与项目相配的网络服务是正确的”，这个回应没有使用说者所使用的词语，说者所回答的话可能是：“对，但我认为还需要地址队列和正在处理的事务表，同时我们必须关注维护松弛耦合。”。这些话阐明了说者认为队列、事务处理和松弛耦合是解决方案的重要组件。如果没有信息反馈，说者是不会讲出这些信息的。
这是精细的文化，在这里听者需要对他们所听到的进行提炼然后反馈给说者进行交流，这有利于减少返工的潜在可能性。
世界之大
当你为团队交流创造词典的时候，存在的一个挑战是必须应付身边的世界。你会收到很多与团队定义不同的术语信息。这就是找到自己词汇的重要性的原因所在。不必与外部世界纠缠不清。在术语前使用前缀“OurCo”，例如“OurCo-SOA”将有助于我们分清楚这些词语与外面意思的差别。
最后对你的词典有个警告――不要与外部世界词语的意思发生冲突。例如：不要将Web服务定义成Web站点。这一定义与其他地方的定义相矛盾。对于新手来说很可能产生误会。甚至跟同事或与新来的顾问进行交流都会产生误会。
最好的显示词典的方法是使用方言。这有点像外部世界进行交流，但是对于团队有特别且唯一的含义，并且便于高效的交流。
建议
不需要创建完整的新语言或学习那些难懂的语言，例如Klingon，但是应该考虑如何与团队之间进行交流和如何为交流创建词典。
学习关键术语并且应用自定义的单词形成新单词和强结合体。让说者和听者在交流过程中都能理解其言外之意。
一、鱼缸会议
这是一种组织会议的方式。不同的群体本着合作的精神，一起分享各自的观点和资讯。因此，让销售部门与客户服务部、或高层管理人员与管理顾问碰头，这种做法一定管用。
何时用：鱼缸会议使某些群体与顾客、供应商和经理等其他与之利益攸关的群体加强沟通。
何时不用：如果用这种方法不能明确地分清各群体的职责，就不宜使用。
培训：会议召集人需要接受培训。
能达到何目的：迅速增进了解、扫除误解。
注意事项：这类会议影响巨大。可能会暴露实情，使内情人和旁观者感到受威胁，因此需要精心组织。
使用程式：把与会者安排成内外两圈。内圈人员会上比较活跃，外圈人员则从旁观察、倾听，必要时提供资讯。会议结束时推荐改进方案，取得外圈人员的赞同。
二、横向思维
这是一种老问题寻找新解决方案的工具。
何时用：由於老方法、旧思路不再管用或已经不够好，需要寻找新方法、新思路时使用。
何时不用：种种制约使这种全新的思维方式无法发挥作用时不要用。
培训：建议读Edward de Bono（爱德华）写的Lateral Thinking for Management（管理中的横向思维）一书。
能达到何目标：开创新思路，激发创意，找出可行的解决方案。
注意事项： 需要传统的逻辑思维加以支援。爱德华建议，只有10%的解决问题过程采用横向思维。
使用程式：确定问题。运用幽默、随机排列和对流行观念的挑战来制定横向思维解决方案。对找到的各种想法加以适当的提炼和取舍。
举例来说，某工业缝纫线轴制造商的传统市场已经消失，公司不得不另寻出路。对此，公司经理们的本能反应是，从常规思路出发，b品找新的出路、新的市场或新的销售手段。不过，事态的发展很快表明，他们需要一种彻底的解决方案。
公司召开了一次集思广益会，对叁加者不加任何框框。思路应能用得上现有的技能和经验，但只能把它作起点。结果，横向思维把他们引向高尔夫球，成一家成功的高尔夫球制造商。
三、帕雷托分析法（Pareto Analysis）
该方法强调80%的问题找出关键的几个致因（通常20%）。
何时用：凡是一个问题的b生有多个变数因素并需要找出其中最关键的因素时，都可使用这一方法。在一个改进专案的开始阶段尤有用。
何时不用：如果设置有更完善的系统就没有必要使用此法。
培训：需具备基本的统计知识以备分析之用。
能达到何目标：非常直观地展示出如何确定问题的优先顺序，将资源集中在何处才能取得最佳效益。这种展示让企业各级一看就懂。
注意事项：仔细分析结果总是很重要；不仅靠资料还要利用常识来找出问题的原因和优先顺序。
使用程式：找出问题和可能的原因。收集有关原因的资讯。绘制帕雷托分析图，横坐标表示原因，纵坐标表示问题，以出现次数、频率或造成的成本来表示。找出最关键的几个原因。依据重要性排序，利用改进技术消除b生问题的原因。
例如，某洗衣机制造商出现质量危机。在一次广泛的可信度测试中，一家大型杂志将其b品排在末位元并建议消费者不要购买。
该公司具有完善的失误记录，列出的失误种类达22种。但运用帕雷托分析法表明，仅其中的4种失误就占了所有记录的83%。
四、质量功能分布图（QFD）
这是一种b品和流程设计工具，可以用於把顾客的呼声转化成b品或流程的特点。采用该方法能防止企业仅因某些观念似乎有效就予以实施。
何时使用：用以设计或重新设计b品或流程，保证提供顾客切实需要的b品特性；专制造业设计的，但也可用於服务业。
何时不用：如果问题的优先顺序已经分明、流程设计卓有成效或设计团队经验老到，不要采用该方法。
培训：该方法运用特定的惯例，建立相关的榘阵图和计分标准。在这方面有必要进行培训。
能达到何目标：有能力分辨基本的b品与流程特色和所期望的b品与流程特色，这样便可以看清高成本的技术或工程投资在哪方面将有回报。同时，还提供了一个评估b品或流程变化影响的框架准则。
注意事项：花时间通过市场调研来找出顾客的真正需求所在。
使用程式：研究顾客的需求。找出符合顾客需求的流程设计特色。建立一个榘阵图，将顾客的需求与设计特色进行比较（即性能／方案榘阵图）并加以计分。选取5个左右分数最高的设计特色，然後再按3个层次建立榘阵图：设计特色和关键部件特点、关键部件特点和制造工序、制造工序和生b要求。
例如，某割草机制造商耗时费资重新设计其畅销割草机的控制性能，却发现顾客对此毫无反应。因此，公司经理人在计划改进另一较老型号时，想要确保所做的改善的确是顾客想要的。
研究结果表明，顾客感兴趣的是性能。因此改善马达、驱动链和刀的效率比改善控制性能可以b生大得多的影响。
五、关联树图
这种图示工具对关联项进行层次分类。这是一种不错的思维工具，因它提供了一种快捷的方法把各种想法总括出来，并在相关的枝叉出现时可随即增加细节。
何时使用：使用该图示可以同一目标寻求多种不同的实现途径。
何时不用：不可用於详细比较各种方案。它只用於从总体上探索新的方向。
培训：无需正式培训，但设置一个协调人员会很有帮助。
能达到何目标：该图示能很有逻辑地揭示出该采用什麽方法来实现目标，它们要求哪些行动和资源。
注意事项：如果你选用的方法经不起分析，要随时准备回到关联树图上来。
比如，一个发展中的小公司运用这种方法来考虑员工的托儿问题。许多员工大学一毕业就加入了公司，现在都供养着子女。
公司开会讨论各种选择方案。结果，大家都赞成建一个日托中心。但树形图显示，潜在的成本太高，需要满足的地方法规要求太多，很难实行。於是公司选择了托儿津贴计划，让有子女的员工有选择的馀地。
六、方案效果分析法（solution effect analysis）
这种图表用於分析手头解决方案可能b生的效果。
何时用：在提议变革时可运用这种方法。它能让你看清各解决方案的效果。
何时不用：你所提议的不是根本性变革的话，不要使用。
培训：无需正式培训，但如加以辅助很有用。
能达到何目标：一种向前看的思维方式并能预见所建议的方案会造成什麽影响，避免未能预见的效果。
注意事项：人们对你正在致力的变革前景看淡时，不要阻止他们。他们并非有意发难，也许他们是对的。接受辅导会减少自己受威胁的感觉。
使用程式：记下正在考虑实施的解决方案，放在图的左侧，箭头则指向右方。在主箭头两侧用分箭头标出各种重大效果。通过集思广益，找出所有可能的效果并添到图上。计划实施行动以确保该方案行之有效。
来源：项目管理者联盟
在整个软件生存期中，各种文档作为半成品或是最终成品， 会不断地生成、修改或补充。为了最终得到高质量的产品，达到上 节提出的质量要求，必须加强对文档的管理。以下几个方面是应注意做到的：
①软件开发小组应设一位文档保管人员，负责集中保管本 项目已有文档的两套主文本。两套文本内容完全一致。其中的一套可按一定手续，办理借阅。
②软件开发小组的成员可根据工作需要在自己手中保存一些个人文档。这些一般都应是主文本的复制件，并注意和主文本保持一致，在作必要的修改时，也应先修改主文本。
③开发人员个人只保存着主文本中与他工作相关的部分文档。
④在新文档取代了旧文档时，管理人员应及时注销旧文档。 在文档内容有更动时，管理人员应随时修订主文本，使其及时反映更新了的内容。
⑤项目开发结束时，文档管理人员应收回开发人员的个人文档。发现个人文档与主文本有差别时，应立即着手解决。这常常是未及时修订主文本造成的。
⑥在软件开发过程中，可能发现需要修改已完成的文档，特别是规模较大的项目，主文本的修改必须特别谨慎。修改以前要充分估计修改可能带来的影响，并且要按照：提议、评议、审核、批准和实施等步骤加以严格的控制。
软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。
构造并编写软件需求规格说明，并使用户和其它读者能理解它牢记以下可读性的建议：
? 对节、小节和单个需求的号码编排必须一致。
? 在右边部分留下文本注释区。
? 允许不加限制地使用空格。
? 正确使用各种可视化强调标志（例如，黑体、下划线、斜体和其它不同字体）。
? 创建目录表和索引表有助于读者寻找所需的信息。
? 对所有图和表指定号码和标识号，并且可按号码进行查阅。
? 使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。
1.5 优秀需求具有的特性
怎样才能把好的需求规格说明和有问题的需求规格说明区别开来？下面讨论单个需求陈述说明的几个特点（ Davis 1993；IEEE 1998）。让风险承担者从不同角度对S R S需求说明进行认真评审，能很好地确定哪些需求确实是需要的。只要你在编写、评审需求时把这些特点记在心中，就会写出更好的（尽管并不十分完美）需求文档，同时也会开发出更好的产品。
1.5.1 需求说明的特征
1. 完整性
每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
2. 正确性
每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。
3. 可行性
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。
4. 必要性
每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。
5. 划分优先级
给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制
6. 无二义性
对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。
7. 可验证性
检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。
1.5.2 需求规格说明的特点
1. 完整性
不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用T B D (“待确定” )作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的T B D项。
2. 一致性
一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。
3. 可修改性
在必要时或为维护每一需求变更历史记录时，应该修订S R S。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在S R S中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。
4. 可跟踪性
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（ f i n e - [...]
你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。
现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种不同的方式解释需求15；需求9 的说明正好与需求21相反，你因该相信哪一个？需求24非常含糊，你根本不明白它的意思；你不得不花上一个小时与2位开发人员讨论需求30，只因为你们对其各有各的理解；并且，唯一能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义，并且你能预料到，如果你错了，你要做大量的重复工作。
许多软件需求说明书（SRS）写得非常糟糕。任何产品的质量需要其原始材料的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且，没有非常多的好需求可以借鉴学习，部分原因是很少有工程可以找到一个好的借鉴，其他原因是公司不愿意将其产品说明书放在公共区域。
这篇文章描述了高质量需求叙述和说明的几个特性（特点）。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订，也许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。
不要期望能够编写出一份能体现需求应具备的所有特性的SRS。无论你怎么细化、分析、评论和优化需求，都不可能达到完美。但是，如果你牢记这些特性，你就会编写出更好的需求，生产出更好的产品。
高质量需求叙述的特性
我们如何从一些有问题的需求中分辨出好的软件需求？这一节将分别介绍需求叙述应体现的6个特性，下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品行为（特性），能够显现缺陷、冗余和含糊之处。
正确：每个需求必须精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（当然，系统需求说明书本身可能不正确）。
只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。
可行性：在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做，哪些需要需要额外的付出或者和其他的权衡。
必要性：每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。每个需求源于你认可、具有权说明需求的原始资料，这是考虑必需的另外情形（译注，此句翻译不顺，请参照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户的意见。如果你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。
优先权：为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时， 项目经理将不能起到作用。优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。
我是用3种级别的优先权：高优先权表明需求必须体现在下一个产品版本中，中优先权表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中，低优先权表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。
明确：需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS作者很清楚但对于读者不清楚的主观词汇，如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。
可证实：看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。如果需求是不可验证的，决定需求是不是正确的实现就成了判断的事。需求之间不一致，不可行，不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的。
高质量需求说明的特征
一个完整的SRS不仅是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。
完整：不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难，因为根本不存在。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。
在需求抽象时，相对于系统功能，你过多的注意用户的业务，将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。
如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。
一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的部分，没有审定于修改相关的部分，就可能导致不一致性。
可修改性：当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。
可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。
需求质量的评审
这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢？为了体现得更切合实际，我们做个小练习。下面有几个从实际的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户，我们只能猜测每个需求的意图。
例1．“产品应在不少于每60秒的正常周期内提供状态信息”
这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。
弥补缺陷，重写需求的一种方法：
1、状态信息
1．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息
1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比
1．3任务完成时，应显示相关的信息
1．4后台任务出错应该显示错误信息
为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。
例2．“产品应瞬间在显示和隐藏不可打印字符间切换”
计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。
象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。
例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没 有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？
试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。
例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。
在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的，
编写质量需求的方针
编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。
句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们
要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。
需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。
密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。
通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。
避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。
如果你遵从了这些方针，你能够尽早地经常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。
