接口需求调研方法探讨

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
沟通前必须有明确的任务导向,不能被客户牵着鼻子走。沟通的
结果要及时确认
树上开花
借局布势,力小势大:既要善于造势和借势,通过日常交流细节, 潜移默化地建立自己的“专家”形象,如果你不是专家 ,也可以借 助内部的专家表达你自己的意见。
换位思考
对接口系统开发商,要换位思考,谋求双赢,一味压迫对方很可能双输
需求分析只考虑业务,不考虑设计,设计只考虑功能,不考虑性能
导致需求分析得到的功能无法实现,概要设计完成后,最后实现难以按照设计完成 处理: 1、需求分析不能只做用户需求分析,而必须做到软件需求分析。需求分析组要由业务专家和 技术专家共同组成,需求分析文档要组内讨论认可 2、设计人员在做设计的时候必须要做到对于最终实现的界面及接口交互过程和数据了如指掌 将概要设计工作做细。达到概要设计完成后基本可以开发的程度
我定规则我就赢 给出合理的接口规范,取得用户的认同。 只要标准在手,就可以“ 任尔东西南北风,我自巍然不动”
HOW ?
中策
知己知彼,百战不殆
详细了解接口系统的现有功能及发展趋势,如果有可能,亲自
登陆接口系统去操作一下
沟通,沟通,还是沟通
Comunication For The Result,所有的沟通都是围绕结果去进行,
我们孜孜以求的“综合XX系统”着眼于“综合” ,接口应该成为核心竞争力
HOW ?
上策
分清客户和用户 分清客户和用户的目的:知道谁的需求更有助于系统使用和 验收;通常情况下,在确定接口范围的时候,客户尤其是客 户领导的需求最为重要;在确定接口内容的时候,用户尤其 是基层用户的需求最重要
比用户更了解他自己 用户所说的不一定是他想的,用户所想的不一定他要的 关注用户的言外之意
WHY ?
为什么接口越来越重要?接口wenku.baidu.com价值
不可能存在能够涵盖所有用户的所有需求的系统, 系统不能独立存在;系统要扩展,必须要“拿来” ,而且也要允许别人“来拿”
建设系统的非常重要的目标是实现信息共享,而共 享则是接口的精髓
用户工作流程的交集决定了系统建设也存在功能的 交集,同样的工作在不同的系统中多次重复,降低 了效率,也增加了差错率
目录
▪ WHAT ? ▪ WHY ? ▪ HOW ? ▪ 常见问题及案例分析 ▪ 讨论
常见问题及案例分析
接口功能大而全
用户恨不得把所有的接口功能都在一个系统中实现,甚至是琐碎的功能 处理: 1)帮客户分析,该功能实现的工作量有多大,是否确实能够帮他们减少工作量,如果
减少工作量很小,而实现工作量很大,应该可以说服客户不做 案例:附件发送平台
目录
▪ WHAT ? ▪ WHY ? ▪ HOW ? ▪ 常见问题及案例分析 ▪ 讨论
讨论专题
如果要做统一的数据提供和 展现平台,网管系统最为关心 的接口有哪些? 要实现的这些接口,哪些是 已有接口规范的,哪些我们可以 参与制定规范? 如何主动成为一个接口的提供 商,能够从接口开发中获得经济利益 避免被动成为接口的配合方,吃力 而不讨好?
常见问题及案例分析
接口双方都竭力要把工作往对方推
尤其是接口数据提供商没有通过该接口获取任何利益的情况下
处理:
1)如果有接口规范,大家共同遵守
2)如果没有接口规范,尽量事先把接口部分的工作做细,而且能够给用户表达清楚,得到用户 的认同后,再找开发商来谈。且忌不能先找接口开发商,谈不拢再找客户
3)一切都为了项目进度着想,要衡量开发工作量和协调工作量之间的关系,不能因为双方顶牛 而造成接口工作停滞。必要时可以做出一些让步。
......
HOW ?
下策
借刀杀人
根据情况,对于比较“弱势”的接口开发商,借助用户要求接口开发商 按照自己的功能要求和时间要求完成开发,并尽量把工作量放在对方 身上
金蝉脱壳
如果需求功能确实实现难度过大,或者用户对于进度要求过于紧张, 通过详细的技术分析,告知用户本期不实现这些困难的接口,或者只 实现一些简单的功能
优秀精品课件文档资料
软件项目接口需求调研 方法论探讨
目录
▪ WHAT ? ▪ WHY ? ▪ HOW ? ▪ 常见问题及案例分析 ▪ 讨论
WHAT?
什么是系统接口?
接口可以理解为某一个系统为了实现系统内部不 同功能模块或者不同系统间的交流而具备的一系列 方法 接口可以分为私有接口和公用接口 接口的要素:接口对象、接口触发形式(实时、周 期)、接口调用方式(同步、异步)、接口调用过 程、接口实现技术、接口数据描述等
接口范围一变再变
多见于用户自己对系统最终实现目标不清晰的项目 处理: 1)事先确定接口范围,至少要确定接口的个数,且要通过纸面确认。即使最后不得 不改变范围,也为时间进度以及后续商务谈判获取了筹码 2)灌输接口阶段实现的思路,制定接口实现优先级,作为接口实现时间安排及工作 细致程度的依据
常见问题及案例分析
用户需求不一致
接口所涉及的多部门意见不统一 处理: 1)确定一个对自己有利的意见,联合提出该意见的部门,统一其他部门思想,必要时
先向客户领导灌输于己有利的意见,先入为主
接口数据多数据源
多数据源,且都可以修改,导致用户数据不一致 处理: 跟用户事先确定好原则:提供数据的系统为唯一数据源,且通过接口得到的数据在接 收系统中不可更改
相关文档
最新文档