题往往就是搞不清需求之根源，把握不清背景和需要，往往就会被繁琐的需求规格所困住，被客户牵着鼻子走。理论是完美的，现实是残酷的，我们现实的需求分析工作，往往会出现这些问题：
背景啊背景，我该如何写你呢？
我们公司的需求规格说明书中，第一章节就是“背景”，但往往大部分项目写出来的背景写了等于没写。有些写了诸如此类的内容：某年某月某日与某某公司签订了某某合同，成立了改项目组，项目人员有谁谁谁，客户联络人是谁谁谁。有些项目更懒，直接复制前期需求文档的背景，以致项目已经做到第三期了，第三期的背景仍然是抄第一期的。不知道如何分析背景，背景不知道写啥，这是项目的普遍现象。
目标在哪里？
对于“项目的目标”，项目组普遍的问题有：
1.根本不知道“目标”这回事。
2.目标写出来了，但被扣上“大而虚”的帽子。
3.没有用目标来指导下一步工作，后面遇到具体问题时，没有用目标来思考。
4.目标写出来就不变了，没有持续去思考是否需要调整。
需求规格优先
很多需求分析人员喜欢将系统要做的事情，以用例或者功能点的方式记录下来，但往往没有记录为什么需要这样一个用例或者是功能点，没有去思考这个用例或者功能点背后隐藏的客户需要是什么。更甚者进入具体的界面设计，在需求文档中写清楚界面上放什么按钮什么菜单等，一开始就将需求“僵化”，这样会让后面的工作陷入“万劫不复”之地。
本小结开始的时候，要求你先写下本系统的需求，再继续往下看。不知道你写的需求中是否有背景、需要这些内容呢？你写的需求是不是几乎全部是“需求规格”呢？
下面，我们将来挑战“订餐系统”的背景、需求和需求规格。
1.3 背景-需要-需求规格
请按顺序回答以下问题：
1.本项目的背景是怎样的？
2.本项目能解决什么问题？
3.本项目的关键涉众有哪些？（说明：涉众是指系统会影响到的人、角色、单位等，或者说什么人、角色、单位会影响到本系统。）
4.本系统要达到怎样的目标？
5.本系统的范围是怎样的？
6.本系统应该具备怎样的功能？
7.本项目成功标准是怎样的？
在往下阅读之前，请先独立思考，写出以上问题的答案。
1.本项目的背景是怎样的？
参考答案：员工中午饭要吃好是很重要的事情，但手工订餐存在一些问题，领导试图通过订餐系统来改善。
答案点评：
1)本系统的用户是“员工”，而客户是“领导”。（说明：用户是指使用系统的人员，而客户是可以拍板付钱给公司的那个人，是项目组的米饭班主。）
2)领导的目的不是为了做这个系统，而是希望通过这个系统解决问题。
3)领导应该不太可能投入大的投资来解决这个问题，例如：不太可能将员工的午饭标准提高到每人每餐50元，也不太可能为这个项目投入100万的经费。
背景应该怎样描述？
背景应描述出系统的用户和客户是谁、项目的来源，并且可以由此推断客户可能的投资预算，本项目对于客户的重要程度等。
2.本项目能解决什么问题？
参考答案：
1)手工订餐本身工作效率低，有时会影响员工的正常工作。
2)手工订餐容易出错，导致员工吃不到饭或者是吃不到自己想吃的饭。
答案点评：
1)问题描述得很具体，并且问题产生的根源似乎都是因为“手工订餐”导致的。
2)手工订餐并不会让大家吃不到饭，只是有时会出一些小问题。
3)手工订餐的最大优势就是灵活，不好的地方就是容易出错，这个订餐系统如何才能保持手工订餐的“灵活”优势呢？
问题应该怎样描述？
需要清楚明确地描述清楚项目解决的问题，同时要分析好当前的工作方法的优点。系统除了要解决当前的问题，还应该保持原来工