根据调查
属于需求分析和软件Software设计
和缺陷约占软件Software64%而属于
代码仅占36%
因软件Software积累和放大效应造成整个软件Software业项目拖延情况高达20%到60%这些数据表明搞好需求调研分析及软件Software设计是提高软件Software质量基础以下是
些通过全面了解所有项目干系人需求改进需求调研分析效果体会关键字:
项目干系人、需求、调研
在需求调研分析阶段
项目组对客户整体组织结构、有关人员及其关系、工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认需求由于项目经理(project manager)和需求分析员工作问题客户参和程度部不高客户方相关责任人不明确或对范围和需求责任心不强提出需求具有随意性项目前期对需求确认不够积极；或者是多个用户代表各说各话、昨是今非但同时又希望软件Software尽早交付；项目后期需求变化随意造成项目范围蔓延进度拖延成本扩大造成上述现象
原因是系统分析人员没有全面了解所有项目干系人需求并按照重要性优先级进行权衡取舍全面需求来自所有项目干系人项目干系人STAKEHOLDER也有翻译成利益关系人、利害关系人、利益干系人、利益共享者、涉众如此等等即所有可能受到项目结果重大影响人项目干系人即可能是项目受益者也是项目风险承担者甚至有可能是项目受害者项目干系人需求包含明确和隐含也可以分为NEED、WANT、WISH等区别层次区别
干系人其愿望和追求目标往往相差甚远因此对项目干系人愿望进行平衡可能是相当困难事情例如政府部门准备建设不少对群众办公信息系统上层管理机关往往希望能够采集尽可能多信息项以便对数据进行多种多样统计分析同时为了对信息进行有效控制而增加些审批流程；基层对外办公窗口则
办公速度压力希望减少信息项输入量；甚至有些不良基层客户由于害怕建立透明度高信息系统会影响他们工作考核成绩而消极地应付即所谓反需求；而客户客户(办事群众)则希望相关政府机构能够简化工作流程加快办事速度；些客户相关管理机构或组织也会制定些有关标准规范标准；作为项目干系人公司领导层也可能会提出些技术上、接口上、环境上需求；甚至项目组本身技术、资源、进度等原因需要对些功能进行优先级排序和取舍虽然不是所有人需求都是可以满足特别是消极反需求是不能接受但他们需求都是应当考虑全面并进行平衡软件Software开发项目
目就是实现项目干系人需求和愿望如果对项目所有干系人没有进行足够沟通和影响使其尽可能地参和项目则可能项目开始时项目范围和些具体需求不够完整清晰也可能某个项目干系人后期认识变化而提出新需求造成工期延长成本增加甚至项目完全失败因此应当从项目启动开始需求分析员及其项目成员就要分清项目干系人包含哪些人和组织通过沟通协调对他们施加影响驱动他们对项目支持调查并明确他们需求和愿望减小其对项目阻力以确保项目获得成功以下是些有效措施:1、尽快熟悉项目干系人全貌
有些项目在做需求调查时
由于受进度要求等客观原因影响需求分析员和建设单位技术部门交流较多向业务管理部门和实际使用者调查不够深入造成软件Software试用后不得不再对需求做较大调整"从头再来"部分比例很高大大超过进度要求时间因此熟悉项目干系人全貌是进行需求调查第步也是需求调查基础在定制开发项目项目干系人中最重要是建设单位中人事组织、业务关系最好是能够用组织结构图画出相关单位组织结构；用责任矩阵确定各部分调研对象；建立调研对象通讯录以保证调研及分析期间及时沟通和此同时要注意项目干系人主次关系以便在他们的间需求出现矛盾时能够进行合理取舍熟悉建设单位内部相关部门
业务划分及它们的间相互关系,为功能分析准备了必要资料, 同时可以熟悉用户方各类人员并及时进行广泛、有效沟通和交流特别要和客户方业务和技术规划者和实际使用者进行深入探讨收集必要原始资料保证需求调查完整性、正确性建设单位只是项目干系人中
部分(当然是主要部分)为了更好地了解项目干系人全貌还应当在建设单位组织结构图基础上全体项目干系人结构图以便更好更全面地进行需求调研分析2、详细描述各项业务
以利于让所有客户确认尽可能全面详细地调查并且描述原有系统和用户希望将来系统具有
各项业务流程并将这些业务流程文档化后和客户进行讨论对描述或不准确不精确进行修改最终让客户进行确认从近年来开发软件Software看对业务处理过程了解完整性和准确性非常重要虽然对数据来说都是SIDUT(查增删改传)但具体业务都是分为若干步骤每个步骤都有其业务名称同步骤可能对多个数据集进行区别操作需要调查了解清楚才能设计出适合各流程业务节点用户业务特点和习惯软件Software使开发出来软件Software更受欢迎当然在进行软件Software概要设计时要尽量排除业务流程制约即把流程中各项业务结点工作作为独立对象充分考虑他们和其他各种业务对象接口在流程的间通过业务对象相互
实现其业务流程这样在业务流程发生有限变化时就能够比较方便地修改系统而实现新需求对于各项业务
调查可以通过对以下资料收集整理分析这些资料来自各种各样项目干系人:遵循标准、组织发放工作手册、作业流程、有关业务上级通知、有关业务办事指南、办理业务时需要填写登记表、各种相关统计报表及通过其他途径收集类似系统介绍、技术资料等等3、可视化需求调研
引导各种客户挖掘他们需求有
客户自己缺乏计算机知识无法提出完整准确、隐含或潜在需求但若这些需求不能满足将导致用户不满因此需求调研分析人员应善于想用户所想不但要确定明确需求还要善于用启发方式和用户探讨隐含或潜在需求并结合各种调研分析技术挖掘超出客户期望令人兴奋需求这就要求需求调研分析员要尽快完整地熟悉相关业务从而能够站在用户立场看待软件Software需求想用户所想做好业务和计算机的间桥梁利用可视化需求调研思路方法可以很好地启发用户深入挖掘潜在需求可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求并且使需求更加全面完善对于高层领导
可以提供系统总体框架图；对于业务管理人员可以用业务流程图来描述新旧系统业务流程；对于客户中技术人员可以用数据流图、实体关系图或UML中各种图形对系统进行各种角度描述；而对于业务管理人员、客户中技术人员、以及各层次各流程中用户画出用户界面图来进行需求挖掘是个比较有效沟通方式这里特别介绍说明
下用户界面重要性用户界面设计按理来说是软件Software设计责任当然客户自己对界面有特别提出要求除外但是如果把它提前到需求调研时(紧接着原有系统调研分析和系统模型完成的后)和客户进行讨论则可以大大改善需求调研效果因此不少需求分析著作把用户界面说成是“设计层”需求的这时客户对于将来系统还没有个形象上概念或者有个模糊预想概念需要表述、验证、明晰化、完善化以笔者经验画出用户界面草图和客户进行讨论可以大大激发他们提供更为准确全面需求原来收集资料描述业务介绍说明系统模型到了山穷水尽时候这种思路方法可以达到柳暗花明又村效果在
微软项目:求生法则
第8章“需求开发”中从头到尾都是围绕着“使用者接口”(USER INTERFACE也可以翻译成“用户界面”)进行讨论如“建立简单使用者接口雏形”、“不断修订使用者接口雏型直到使用者对软件Software感到兴趣盎然为止”、“完全扩展使用者接口”同时还要“区分份非使用者接口需求文件”等等因此所谓需求就是“当你按下各种相关按钮(或输入各种相关命令)时系统做什么”所谓设计就是“当你按下各种相关按钮(或输入各种相关命令)时系统如何做”虽然在英语中“接口”和“界面”实际是同个单词但“接口”含义似乎比“界面”来得广泛如功能的间接口、和其他软件Software接口、和其他硬件接口等等需求最终目实际上是完整准确地描述系统需要各种接口或“界面”及它们相互关系或和外部环境关系如界面中某个按钮按下去时可能产生新界面、新按钮、或者其他软件Software硬件完成某些功能自顶向下把这些界面及涉及到数据描述清楚就是份不错需求4、和其他项目小组成员共同协作、持续完善系统需求
需求文档完成的后
并不是万事大吉把它扔给后面设计人员就了事了作为项目干系人的内项目组其他成员对需求有效性也起到某种程度验证作用虽然软件Software项目生命周期按照各种开发模型有区别阶段划分但每个阶段结束不是简单地把阶段工作成果塞给下阶段成员就可以了特别是高科技软件Software开发项目上阶段工作成果往往要通过多次沟通才能更为清晰地被下阶段成员接受其有效性、合理性也要被下阶段工作所检验通过检验有时也有必要对上阶段工作结果进行相应调整需求更是如此因此无论是同阶段区别人员的间或是区别阶段人员的间都应根据需要相互协作相互配合共同完成软件Software开发任务
最新评论