需求分析挑战之旅（疯狂的订餐系统）(3)——背景-需要-需求规格

摘要：
说教性质的需求分析理论，各位看了也白看，所以咱们就来一个真实个案——“订餐系统”体验一下。“订餐系统”貌似简单，但陷阱重重，各种需求分析的经典场景将会一一重现，各位做好准备接受这个挑战没有？我将分8篇为大家分享，全部内容超过1万1千字，而且有n多图片和思考题，请准备好盒饭边吃边看吧……

  

大纲：
1.某IT公司员工的吃饭问题
2.需求分析的大道理
3.背景-需要-需求规格
4.没完没了的“新需求”
5.领导“突发奇想”
6.榨干人脑汁的需求分析
7.变被动为主动
8.最后的疯狂

3.背景-需要-需求规格

请按顺序回答以下问题：

1.本项目的背景是怎样的？
2.本项目能解决什么问题？
3.本项目的关键涉众有哪些？（说明：涉众是指系统会影响到的人、角色、单位等，或者说什么人、角色、单位会影响到本系统。）
4.本系统要达到怎样的目标？
5.本系统的范围是怎样的？
6.本系统应该具备怎样的功能？
7.本项目成功标准是怎样的？

在往下阅读之前，请先独立思考，写出以上问题的答案。

1.本项目的背景是怎样的？

参考答案：员工中午饭要吃好是很重要的事情，但手工订餐存在一些问题，领导试图通过订餐系统来改善。
答案点评：
1)本系统的用户是“员工”，而客户是“领导”。（说明：用户是指使用系统的人员，而客户是可以拍板付钱给公司的那个人，是项目组的米饭班主。）
2)领导的目的不是为了做这个系统，而是希望通过这个系统解决问题。
3)领导应该不太可能投入大的投资来解决这个问题，例如：不太可能将员工的午饭标准提高到每人每餐50元，也不太可能为这个项目投入100万的经费。
背景应该怎样描述？
背景应描述出系统的用户和客户是谁、项目的来源，并且可以由此推断客户可能的投资预算，本项目对于客户的重要程度等。

2.本项目能解决什么问题？

参考答案：
1)手工订餐本身工作效率低，有时会影响员工的正常工作。
2)手工订餐容易出错，导致员工吃不到饭或者是吃不到自己想吃的饭。
答案点评：：
1)问题描述得很具体，并且问题产生的根源似乎都是因为“手工订餐”导致的。
2)手工订餐并不会让大家吃不到饭，只是有时会出一些小问题。
3)手工订餐的最大优势就是灵活，不好的地方就是容易出错，这个订餐系统如何才能保持手工订餐的“灵活”优势呢？
问题应该怎样描述？
需要清楚明确地描述清楚项目解决的问题，同时要分析好当前的工作方法的优点。系统除了要解决当前的问题，还应该保持原来工作方法的优点。很多系统解决了问题，但丢失了原来工作方法的优势，往往是得不偿失。

3.本项目的关键涉众有哪些？

参考答案：员工、前台、领导、财务、餐厅。
答案点评：
1)全面考虑了各种涉众。
2)员工是使用本系统的主体，他们最关键的 需求应该是能方便准确地订餐。
3)前台通过本系统来统计订餐、和餐厅沟通、下订单等，前台可能是本系统使用功能最多、操作最复杂的角色。
4)领导有时也会通过本系统来订餐，但对本系统的主要要求就是大家要用得舒服。
5)财务可能需要根据本系统的订餐记录和餐厅结帐。
6)餐厅需要提供菜单给前台，餐厅可能以传真或电话的方式获知我们的订餐，不同的方式将会影响本系统的某些功能。
如果找出关键涉众？
1)应广度优先地尽量多地列出可能的涉众。
2)列出每种涉众在本系统的关键需求。
3)每一种涉众都应该清楚说明本系统是如何影响她的，以及她是如何影响本系统的。

4.本系统要达到怎样的目标？

参考答案：达到“吃饭易”的效果，保证员工不会因为吃饭问题影响正常工作。
答案点评：
1)目标描述应简单容易记忆，以便项目组随时记住。
2)本项目的目标并不是让员工吃饭吃得开心，也不是用来保证员工正常工作（光靠这个系统，是不能保证员工正常工作的），而是希望通过本系统来消除手工订餐的问题。
应该如何描述目标？
应该用简单、明确、恰如其分的语言来描述。简单、明确是方便项目组记忆，以便在工作中随时可以用目标检验工作。恰如其分则要求目标描述不要夸大系统的作用，也不要缩小系统的作用。很多项目描述目标的时候，往往会夸大系统的作用，如提高工作效率、提高生产力等，这些目标往往不是单纯靠系统就可以做得到的，更多是靠企业的管理，系统只是起到配合和支持的作用。

5.本系统的范围是怎样的？
参考答案：
1)这是一个订餐系统，只考虑与订餐相关的功能。
2)这是一个单独的系统，不考虑与其它系统集成或交互。
3)使用本系统的是**的全体员工，不考虑分公司的员工。
答案点评：
从功能、与其它系统的关系、用户三方面描述了本系统的范围。
应该如何描述范围？
范围往往客户并不会直接给出的，我们需要从项目解决的问题、目标等入手，从功能、与其它系统的关系、用户等来思考系统的范围。
由前面的资料，我们可以知道，客户应该不会投入很多钱，客户目标只是希望解决手工订餐带来的麻烦，所以我们定范围时，应该尽量让系统简单，能满足目标便可。本系统其实可以做得很复杂的，订餐这事情其实与请假外出相关的，订餐也会与财务结帐有关系，如果将系统边界扩大，很可能将问题复杂化。

6.本系统应该具备怎样的功能？
参考答案：

图4 用例图

对于“订餐”这个用例，我们还可以进一步细化用户与系统的交互：
用户指示订餐
系统给出菜单
用户选择菜单并 确认选择
系统保存用户的选择，提示订餐成功。

答案点评：
1)用例图全面地描述了系统用户与用例，条理清晰、一目了然。
2)对于每一个用例，还可以进一步描述用户与系统是如何交互的，为下一步工作做好准备。
3)除了描述功能，还需要考虑系统的非功能需求，如性能要求、安全性要求等。
应该如何描述功能？
1)要根据前面的问题导出系统应具备的功能以及非功能需求。
2)用例图是描述功能性需求的好工具，但不要拘泥于只用用例图。
3)对于非功能性需求，客户往往没有具体想法，需要我们从客户的需要出发，定出具体的非功能性需求。

7.本项目成功标准是怎样的？
参考答案：用简单的方式达到目标的要求，达致双赢。
答案点评：
1)“简单”意味着成本低，符合双方利益。
2)达到目标要求是真正的客户所需。
如何考虑项目的成功标准？
我们做一个项目，成功标准并不是为了赚钱，更加不是不惜一切谋取最大利益，双赢才是最重要的原则！对于客户来说，首要目标就是要满足他的需要，然后就是合理的预算，对于 软件公司来说，首要目标就是为客户提供高性价比的解决方案，赚取合理利润。要达致双赢，客户的成熟度是很重要的，但更重要的是软件公司的成熟度，项目组需要以专家、顾问这样的高度来解决项目中的问题，引导双方达至双赢。

以上7个问题，问题1是背景相关的问题，问题2、3、4、5是需要相关的问题，问题6是需求规格相关的问题，而问题7是我们需要认真考虑的问题，考虑清楚项目的成功标准才能更好地指导项目后续工作，提高项目成功概率。

请看下一篇……

作者：张传波

创新工场创业课堂讲师

华为某团队高级顾问

《火球——UML大战需求分析》作者

www.umlonline.org 创办人