对系统需求分析的一点看法

需求
一般情况下，需求是用户提出来的，但是这种需求的提法都是通过交流沟通的方式表示出来的，因此说这种需求是原始的，未经过加工处理的。我们将这种需求称为原始需求。原始需求往往通过简单的描述来表达客户的要求，这种要求对用户来说是标准的要求，我们将用户提出的要求称为基本要求。我们可以想象基本要求的内容一般可以是下面的表述内容：“我们人事部门需要知道每天员工的出勤情况”。设计人员会对这个表述进行分解：
1、按日期对员工出勤情况进行统计，这里的统计周期可能有按日统计、按月统计、按年统计等；
2、出勤情况有描述，按我们通常的理解至少应该区分出勤、加班、迟到、旷工、病假、事假等；
3、出勤情况应该有细化的描述，如：迟到时间大多少是对迟到程度的具体描述；病事假内容和请假时间也是对病事假程度的具体描述；
有经验的设计人员会对客户的表述进行延伸思考：
1、根据出勤情况决定月工资中的部分项目、绩效工资和年终奖金的分配情况；
2、对各个阶段的出勤情况进行对比分析，可以使用具有表述和对比意义的图形对信息进行加工和展示；
3、建立数据分析对比表，根据出勤数据的特点，以表格的形式展示数据的可读性；
4、用数据辅助管理层进行决策，这是非常重要的延伸思考。一个最终系统能否经历考验，对数据的充分利用是非常重要的。当然辅助决策的建立和作用应该和客户进行深度的对话、沟通和交流才能获得。有时，客户也没有能够思考过这方面的内容。
我们说，客户提出的一个功能需求，往往可以套用我们通常所说的增删改查的模块，仅仅是数据信息内容发生了变化。例如：一个企业的人事部门经理提出对企业中的所有员工建立数字档案并管理起来。这里当然适用增删改查的模块化结构，但是这个只是普通的需求分析和做法。我们不能将这个需求定义为一个简单的增删改查就满足了。现代企业的信息处理已经不可能是简单的、单调的手工录入和数据检查了，我们有太多的手段进行数据录入，一个非常现实的事实就是，我们要对原始数据进行调查、然后进行分析和处理，我们会发现，数据的录入可以批量的进行了。
有时在进行需求调查的过程中，我们通常应该注意的是数据元的调查。有些数据元我们可能是清楚的，例如：性别，这只能是男或女吧，再比如，身份证号，这个数据元应该是18位并有验证规则的吧。但是有些数据元看起来是那么普通，但是在进入设计阶段我们可能才发祥，在需求调查过程中我们忽略了非常重要的步骤，就是对数据元的忽视。我这里举一个在工作中忽略的例子：
我们曾经建立了一个会员系统，其中有一个业务流程是会员的注册和激活，这里注册和激活是由时间和介绍人等信息组成的，一个会员先注册，记录会员的重要信息，其中包括介绍人的会员ID，当然介绍人会员ID必须是存在的，介绍人的会员ID可以是刚刚注册的会员，按理说，时间在数据元家族中是非常普通的一员了，但是我们正是忽略了时间，所以可能产生了注册的会员在激活时找不到介绍人的会员ID了，因为我们往往习惯性认为，按时间顺序注册了会员，并在录入信息中确保了信息的完整和准确，应该没有问题，但是用户在激活过程中并没有按我们想象的顺序进行会员的激活，他们可能先激活下一级会员在激活上一级会员，从而造成介绍人的会员激活时间反而在后面。在后面模块中如果按时间顺序进行数据处理的时候，就可能造成数据和信息紊乱。时间：我们不该忽略这个很普通的数据元。

原则
根据上面所述的情况，我们知道需求调查和分析过程是需要具有一定的经验的。那么我们在进行需求分析过程中需要准守那些东西呢？
第一个原则是倾听。永远不要认为你比客户懂得多，永远不要显得比客户更聪明；诚然，我们的客户经理都是有智慧的人，但是要善于把我们的智慧暂时隐藏起来，首先是要听用户的，认真的听，听他们都在讲述什么，在听的过程中要向学生一样进行吸收，并把自己的疑惑和不解记录下来。记住，真正的问题只有客户知道，我们要做的就是让客户愿意说出来。
第二个原则是记录。不要认为我们的记录会对客户造成负面的影响，记录是对客户的尊重，所以应该在倾听的过程中善于记录，用笔和纸、用录音。用笔和纸记录的内容可以方便和客户进行继续的交流和沟通，用录音记录可以帮助我们进行回听和复习。
第三个原则是询问。
第四个原则是接受。需求永远是第一位的，因此要准守接受的原则，我们可能认为客户所提出的要求是难以解决的或难于接受的，没有关系，我们首先要换一个角度去对待这个问题，这样就可以理解了。用户提出的问题一定是有原因的，他们在工作中或思考中碰到了让他们认为需要解决的问题才会提出来。因此接受客户的要求，是必须的。这无关成本、无关非技术因素。
第五个原则是引导。由于客户是通过讲述来描述自己的业务及过程的，因此在经过充分沟通后，如何引导客户提出深层次的需求是调研人员的任务之一。我们要善于探寻客户基本需求，通过纵深提问挖掘需求背后的原因，引导客户深层次的思考问题和解决问题，帮助客户抛出解决方案，从而将需求导向正确的轨道。
第六个原则是提炼。
方法
问卷调查法：
开发方就用户需求中的一些个性化的、需要进一步明确的需求，通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。这种方法适合于开发方和用户方都清楚项目需求的情况。因为开发方和建设方都清楚项目的需求，则需要双方进一步沟通的需求就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。
会议讨论法：
开发方和用户方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法，这种方法适合于开发方不清楚项目需求（一般开发方是刚开始做这种业务类型的工程项目）但用户方清楚项目需求的情况。因为用户清楚项目的需求，则用户能准确地表达出他们的需求，而开发方有专业的软件开发经验，对用户提供的需求一般都能准确地描述和把握
界面原型法：
开发方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。这种方法比较适合于开发方和用户方都不清楚项目需求的情况。因为开发方和用户方都不清楚项目需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。这种情况下，采用“可视化”的界面原型法比较可取