2011年下半年试题四：论软件需求获取技术及应用
论文库链接：系统架构设计师论文
论文题目
软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。软件需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是否科学、准备充分，对获取的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不可能看到系统的全貌。因此，掌握各种不同的需求获取技术，并且熟练地在实践中运用它，并与用户有效合作，是十分重要的。
请围绕“需求获取技术及应用”论题，依次从以下三个方面进行论述。
1.简要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
2.详细说明目前有哪些常用的需求获取技术？说明每种需求获取技术的基本方法。
3.详细论述在你参与分析和开发的软件项目中所采取的需求获取技术以及选取这些技术的原因，并说明需求获取的具体实施步骤。
写作要点
常用的需求获取技术:抽样(采样)、用户访谈、用户调查、现场观摩、联合需求计划(联合讨论会)等。
(1)采祥是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，,可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档(文件)就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法--研究时，就需要使用采样技术选出有代表性的数据。
(2)用户访谈。用户访谈是最基本的一种需求获取手段,其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行,非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行。用户访谈具有良好的灵活性，用较宽广的应用范围，但是也存在着许多困难，诸如客户经常较忙，难以安排到时间:面谈时信息量大，记录较为困难,沟通需要很多技巧，同时需要分析人员有足够的领域知识.另外，在访谈时会遇到一些对于组织来说比较机密和敏感的话题。因此，这看似简单的技术，也需要分析人员拥有足够多的经验和较强的沟通能力。
(3)用户调查。用户访谈时最大的难处在于很多关键的人员时间有限,不容易安排过多的时间:而且客户面经常较广，不可能一一访谈。因此，我们就需要借助用户调查，通过精心设计要问的问题，然后下发到相关的人员手里让他们填写答案。这样就可以有效的克服前面提到的两个问题。但是与用户访谈相比，用户调查最大的不足就是缺乏灵活性:而且双方未见面,分析人员无法从他们的表情等其它动作来获取一些更隐性的信息:还有就是客户有可能在心理上会不重视一张小小的表格，不认真对待从而使得反馈的信息不全面。因此较好的做法是将这两种技术结合使用。具体来说，就是先设计问题,制作成为用户调查表，下发填写完后，进行仔细的分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作为补充。
(4)现场观摩。对于许多较为复杂的流程和操作而言，是比较难以用言语表达清楚的,而且这样做也会显得很低效。因此，针对这一现象，分析团队可以就一些较复杂、较难理解的流程、操作采用现场观摩的方法来获取需求。具体来说，就是走到客户的工作现场,一边观察,一边听客户的讲解，甚至可以安排人员跟随客户工作一小段时间。这样就可以使得分析人员更加直观地理解需求。
(5)联合讨论会。这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表、分析人员、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6~18人，召开时间为1-5小时。在会议之前，应该将与讨论主题相关的材料提前分发给所有将要参加会议的人。在会议开始之后首先应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。会议的最初，就是针对所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，第三步则是大家在此基础上对新的解决方案进行一番设想，在过程中将这些想法、问题、不足记录下来，形成一个要点清单。第四步就是针对这个要点清单进行整理，明确优先级，并进行评审。这种联合讨论会将会起到群策群力的效果，对于一些问题最有歧义的时候、对需求最不清晰的领域都是十分有用的一种技术。而且最大的难度就是会议的组织，要做到言之有物，气氛开放，否则将难以达到预想的效果。
论文参考
论软件需求获取技术及应用
摘要
2024年1月，我以系统架构师的身份参与企业OA系统的开发，该系统旨在解决打卡签到难、物品申购繁、公文流转缓等问题，帮助工作人员实现更无纸化办公，提高工作效率。本文将围绕该系统详细论述如何通过需求获取技术详细准确地了解用户的需求。首先，在问卷调查阶段通过将问卷发放给企业所有办公人员了解基本需求；其次，通过现场观察的方式对需求进行捕捉；最后，经过用例建模形成基本模型初步了解系统需求，方便开发人员进行编程。该系统于2024年12月成功上线并运行至今，得到了领导和同事们的普遍认可，同时让我的需求分析能力得到了提高，感谢领导对我们能力的认可，希望今后可以继续为我们企业的信息化建设添砖加瓦。
正文
2024年1月，我以系统架构设计师的身份参与企业OA系统的开发，该系统旨在解决打卡签到难、物品申购繁、公文流转缓等问题，帮助工作人员实现更无纸化办公，提高工作效率。本文将围绕该系统详细论述如何通过需求获取技术详细准确地了解用户的需求。首先，在问卷调查阶段通过将问卷发放给企业所有办公人员了解基本需求,之后邀请用户代表、需求分析工作人员、编程人员等在需求分析会上对需求文档进行确认，避免之后返工现象的发生；其次，通过现场观察的方式对需求进行捕捉，比如打卡签到问题，同事以往通过在企业人事处签到的方式进行打卡，那么作为开发人员就要前往第一线跟人事处了解清楚痛点与难点，想办法解决问题；最后，采用用例建模方法根据前期了解的需求形成初步模型，方便开发人员进行编程。该系统于2024年12月成功上线并运行至今，得到了领导和同事们的普遍认可，同时让我的需求分析能力得到了提高，感谢领导对我们能力的认可，希望今后可以继续为我们企业的信息化建设添砖加瓦。
在需求分析阶段我们也从网上查找了诸多的需求获取技术手段，目前有问卷调查、现场观察、用例建模、原型法等。问卷调查是指通过将纸质或电子问卷发放给系统用户的方式，对大家的基本需求进行调研，了解一线用户在日常办公过程中遇到的痛点难点，更有针对性地予以解决；现场观察指在问卷调查的基础上对功能涉及到的处室或部门进一步地深入了解，对某功能的具体操作方式进行真实地模拟，假设该功能实现后会对用户造成什么样的影响，减少因需求沟通不畅导致用户使用不便等问题；用例建模是指根据前期了解到的用户需求进行初步建模，确定系统的参与者与场景，在描述用例时，只注重外部能力，而不涉及具体细节；原型法指开发出一个软件原型，它是所提出产品的部分实现，帮助开发人员、用户以及客户更好地理解系统的需求，它比开发人员常用的技术术语更易于理解。建立原型可以解决在产品开发的早期阶段需求不确定的问题，用户、经理和其他非技术项目风险承担者发现在确定和开发产品时，原型可以使他们的想象更具体化，如建立基于Web的应用系统原理，使用HTML进行界面设计。
在OA系统的需求分析阶段，我们采用了问卷调查、现场观察、用例建模的方法。下文将围绕该系统详细论述如何通过问卷调查、现场观察、用例建模需求获取技术详细准确地了解用户的需求。
一、基于问卷调查方式获取需求
我们采用最原始的办法问卷调查方式对同事们无纸化办公的需求进行收集。根据单位同事向我们技术小组反映的找领导签批文件要在门口等待很长时间，有时甚至发生无功而返的现象；打卡签到经常由于人数较多造成人事处办公室门口拥堵现象；部分同志经常在外地出差可能需要用到单位车辆，但由于没有线上审批操作系统，只能找人帮忙代签，无形中浪费了很多的时间精力，由于操作不便致使工作效率低下等问题。经请示领导同意后，我们组织用户代表、技术人员、相关业务处室工作人员等召开需求分析讨论会，对在问卷调查过程中发现的无纸化办公需求进行核实，并形成初步需求文档，确定开发打卡签到、公文流转、公车派送等功能，并征求进一步现场观察的意见建议，方便对功能进行深入了解。
二、基于现场观察方式获取需求
掌握用户如何实际使用一个系统以及到底用户需要哪些信息，最好的办法就是亲自观察用户是如何完成实际工作的。我们在问卷调查OA系统需求的基础上，对打卡签到、公文流转、公车派送、工资查询、加班统计等功能展开了实际的现场观察。经观察发现，打卡签到存在上班与下班高峰期短时间内在人事处办公室签到人数激增的现象；公文流转过程中很多同事在单位领导门口等待时间较长，经常出现已经快到下班时间了，但同事仍未签到字的现象；公车派送过程中也经常发生需要用车时因无法及时报批报备用车而只能在后期补签的现象；财务室在给大家提供工资查询时还是使用最原始的工资条方式，将工资打印出来撕成条状后交给同事，浪费了很多的人力物力；以及在进行加班统计时，还要对同事的每一张加班表日期时间进行核对，工作日不能加班、上班时间不能加班等均采用人工方式进行审核等。针对现场观察发现用户在办公过程中由于没有OA系统支撑造成的浪费人力物力现象，我们协调各处室负责人召开了需求专题讨论会，在短暂而紧凑的时间段内集中在一起，在应用需求上达成共识、对操作过程取得统一意见。
三、基于用例建模方式获取需求
在充分了解用户需求的基础上，我们进一步开展了用例建模。确定OA系统的参与者以及场景，并绘制用例图描述参与者与特定用例之间的关系，帮助编程人员理解用户的、业务和应用领域，并运用面向对象分析和设计方法将用例转化为对象模型。如，公文流转模块：首先由文稿撰写者向上级发起审批申请→处室负责人对文稿进行初审并签字→再由分管领导对初审文稿进行批阅→最后由主管领导对文稿进行最终确认；工资查询模块：汇总财政部门发给财务室的工资信息→按照身份证号对同事做唯一识别→将工资信息与身份证号进行关联→把工资信息展示在用户的OA系统界面；打卡签到模块：将用户所在处室信息录入系统→将系统与位置识别功能进行关联→当用户进入系统识别位置区域后自动进行打卡等。清楚用户使用功能流程，让大家对OA系统有了更清晰直观地认识，方便后期的开发工作。
最后经过编程小组的努力与奋斗，终于在2024年底成功上线并顺利运行至今，得到了领导和同事的普遍认可。当然在实际需求获取过程中与也遇到了一些阻力，由于前期部分同事对我们OA系统工作不熟悉，以为无法解决他们的问题，所以在了解沟通后仍未及时向我们反映，造成个别需求要单独处理的问题，最后我们采用原型化的方法将需求更加形象化，让同事放心大胆地提出疑惑，不必拘束。在需求分析的过程中，我也认识到了掌握各种不同的需求获取技术，并且熟练地在实践中运用它，并与用户有效合作，是十分重要的。感谢领导对我们能力的认可，同时让我的需求分析能力得到了提高，希望今后可以继续为我们企业的信息化建设添砖加瓦。