需求从哪儿来？
来自于项目甲方
还是直接或间接
用户、经理、高级经理、操作人员、支持人员、测试人员和你系统有联系其它系统开发人员或是维护人员？这是所有正式需求来源吗？事实上提供需求、解释需求、指定需求和排列需求优先级是项目甲方职责所在
此外项目甲方有权利要求开发队伍投入时间去辨别和理解这些需求要想以这种轻巧建模方式获得成功理解这个概念是非常重要项目甲方负责提供需求开发组负责理解和实施这是否就意味着你可以坐等你
项目甲方来告诉你他们需要什么呢？当然不是针对他们所告诉你内容你可以提出问题进行分析促使他们给出更具体内容甚而至于可以提出你自己见解使的改变初衷你可以建议增加
些新需求请注意你所提出仅是建议他们可以考虑作为正式需求加以接受(可能会作出修改)或拒绝为了找出潜在需求你应该经常和甲方保持联系并借助于些已有文档比如公司政策法规、以前系统或者公开可用资源比如web上信息、书籍、杂志或你竞争对手产品和服务再次声明你项目甲方是需求最终决定者而不是你我不能不强调这点那么项目甲方又从哪里知道他们
需求呢？“我真希望我能这样做”他们经常会这样抱怨现有系统
他们竞争对手能做到但他们却不能；或者想避免过去所出现问题；或者仅仅是想多增加个新功能些甲方尤其是操作人员和高级IT部门经理可能需要集成现有或即将上马系统；或者由于某项(象必须削减计算机数量)政策而带来需求值得注意是你项目甲方应该基于大量依据明确地阐明需求而这些依据是应该存在你可以通过和的交流确定这点我
经验告诉我在项目中邀请相关方面专家加入对找出潜在需求是很有价值例如构建个电子商务系统我会邀请有国际化软件Software设计经验人员、税法专家或者供应专家加入当你对系统中某些方面不熟悉时(有可能这是你首次构造面向世界各地用户电子商务系统)这个思路方法尤其有效我经常会邀请些外部专家和几个甲方在起交流两天来帮助我们检查是否由于我们经验欠缺而遗漏了什么这对于确保我们系统是否完整是个很重要方式特别是在最初定义项目所应包括范围这同样也能够帮助甲方进步研究但是你意识到其中存在危险吗？你所邀请外部专家提出些建议可能听上去是非常好但目前根本就用不上换句话说你依然得从这些专家意见中精挑细选些基本原理项目甲方
积极参和对构造需求是非常关键实际操作中要做到这点存在着两个问题:第甲方自身提供需求能力以及他们(或者你)是否愿意积极地参和进来从我经验来看些项目组并没有足够途径和甲方联系(或不知道甲方在哪)这完全是项目组自身问题你项目肯定有资金不是吗？这些资金定是来自于以某种形式存在项目甲方所以他们是确实存在同样用户也是肯定存在即使你系统是面向大众也至少存在着潜在用户你可以找到他们同他们交谈所以定存在着你可以向的询问人你可能会说“有时要找出这些人有定困难”“要让他们参和进来不是很好办”是确实存在这样难处想办法克服它在“解决需求分析建模中常见难题”节中我谈到了些解决办法包括没有足够途径和甲方联系问题我原则是如果你项目甲方不能或不愿意参和这就意味着你项目失去了内部支持这条成功条件因此你要么解决这个问题要么干脆取消这个项目以减少损失如果你听的任的至少你不能宣称使用是灵巧建模(Agile Modeling)开发思路方法(甲方积极参和是其中项核心内容在AM开发思路方法中必须实施)那如何才算项目甲方积极地参和进来了呢？图1使用UML活动图(UML activity diagram)大体上描述了需求阶段
流程标示出开发人员和甲方各自应承担任务图中虚线把这两部分任务分开来从图中可以看出有些任务是共同承担如想法或建议确定(ident
ying ideas or suggestions)、潜在需求讨论(discussing a potential requirement)、建模(modeling)可能还有文档开发(potentially documenting)项目甲方单独负责指定需求优先级系统是为他们开发这当然是他们责权所在同样开发人员负责估计实现这个需求所需资源他们是实际工作人员如果自己不作估计而采用来自于项目组外部估计这是不合理也是不可取虽然需求优先级确定和估算超出了AM讨论范围但是你可以在如XP和UP这样软件Software流程(Software Process)中找到它理解它们对于整个需求分析是很重要AM并不是个软件Software流程它只是应用于这些软件Software流程中种建模思路方法 ![\"\"/](\"/Softproject/UploadFiles_3488/200609/2006923134517350.jpg\")
图 1 需求分析阶段
流程(使用UMLactivity diagram)我
观点是:项目甲方应该加入需求建模和文档开发中来积极地参和而不仅仅是提供信息为达到这点肯定需要开发人员对甲方进行培训、导引和指导这是完全可能做到我曾经见过些刚起步小公司、大企业和政府机构中甲方能够以非常高效率建造需求模型以及将这些需求文档化在电信业在金融业在制造业在军队里我都看见这样人存在为什么这点这么重要？你项目甲方才是需求真正专家他们知道他们想要是什么(参见“解决需求分析建模中常见难题”如果他们不知道)而且只要你愿意他们是能够学会如何建造需求模型和将它们写下来(译注这样你们的间就可以同种语言进行沟通)从轻巧观点看这是很有意义有更多人将会分担需求建模工作为了让项目甲方更容易地参和进来
消除行业术语方面障碍你应该遵循使用最简单工具这做法表1列出了许多需求阶段artact他们都可以用简单或复杂工具得到对于每种artact表中都给出了对应简单工具图2和图3是使用简单工具两个例子图2表示用粘贴纸针模拟出个显示界面图3是使用索引卡片建立概念模型例子当你在需求分析阶段引入新技术时比如些可以制作很好使用案例图绘制工具或有强大功能CASE工具这就会使得你项目甲方很难加入进来他们不但要学习建模技术而且还要学习如何使用这些工具使用越简单工具进入门槛也就越低由此你才有更多机会去增进相互的间有效协作
![\"\"/](\"/Softproject/UploadFiles_3488/200609/2006923134518751.jpg\")
图 2
个基本用户界面原型图 3 两个CRC卡片
我坚信需求
建立是独立于技术面向对象需求、结构化需求、基于组件需求这些都属于实现技术范畴虽然你可以选择某种技术来分析需求建立需求但必须牢记你所真正关心是需求本身下面所讲所有技术你可以选择其中种或几种来进行需求建模工作但有时你又不得不抛开“建立和技术无关需求”
想法比如个很普遍限制就是大多数项目可以从已有基础技术上获益在这个层次上需求仍然是独立于技术但如果你仍执著要抛开已有些基础技术比如某个版本Sybase数据库或要和SAP R/3给出模块集成而非得从最底层开始那就过头了只要你知道你在做是什么就可以了但不要经常性地这样干记住从小事做起
越小需求(象特性(features)或者用户故事(user stories))相对于越大需求(象使用案例(use 
))就越易于估计和实现平均来说个使用案例涵盖功能要多于个使用情景这就是“大”含义对于需求跟踪表(requirements tracebility matrix)
使用也需要 3思而后行跟踪能力是指能够由项目进行中所生产某个artact某方面追踪到另个和其相关artact而需求跟踪表就是用来记录这些关联关系它从每个需求为起点可以追溯到所有和的相关分析模型、架构模型、设计模型、源代码或者测试用例使用跟踪表组织为了保证各个阶段artact(包括跟踪表本身)致性必须要经常进行更新工作而不是仅在受到影响时才改动使用它好处是你可以很容易地分析出系统中哪些部分将会受到该需求改变影响但是如果你有两个熟悉系统人(译注:当然你得留住他们)当系统需要改变时通过他们来进行评估影响会更容易而且费用也会更低在我看来给予跟踪表评价过高了维护它所带来开销远大于所得到好处即便你有特殊工具去做这件事情让你项目管理层认识到它真正价值和代价所在让他们来作决定是否使用它毕竟跟踪表是份有效文档他们可以据此做出决定需求
类型我认为需求可以分为两类:行为类型
(behavioral)和非行为类型(non-behavioral)行为类型需求描述是用户如何和系统交互(用户界面)、如何使用该系统(使用方法)、或者是系统如何实现个业务功能(业务规则)非行为类型需求描述是系统技术方面典型如可用性、安全性、性能、互用性、可信度和可靠性要注意是这两类需求有时并不定能够完全分开来对存取数据速度性能要求明显是技术方面需求但它也会反映为用户 界面响应时间从而影响到可用性和某些使用方法访问权限管理比如谁能够获取特定信息这明显是个行为类型需求但它也同样涉及到安全性这个非行为类型需求别紧张不要死揪住这类问题关键是能够确定和理解所给出需求如果你把个需求分错了类谁又会真去关心呢？可能
需求分析artact由于存在几种类型
需求有可能其中些或全部适合于你项目；又每种模型都有长处和缺点你应该综合利用这些模型取长补短以发挥最好效率表1列出了些常用需求分析建模artact更详细描述可见Artacts for Agile Modeling 文表中“简单工具”栏指出生成相应artact所常用简单工具(使用简单工具重要性在“些基本原理”节中讨论过)art
act 类型 简单工具 描述 业务规则定义Business rule definition 行为类型 索引卡片(Index card) 业务规则是软件Software必须满足条有效原则或政策 变化案例change
两者的 索引卡片(Index card) 变化案例常用来描述新潜在需求或对已有需求修改 CRC模型CRC model 两者的通常是行为类型 索引卡片(Index card) CRC模型是组标准索引卡片每张卡片被分为 3个部分分别是类名称类职责以及该类合作者类是类相似对象抽象职责是该类所知道或要去做合作者是另外个和该类有交互类在需求建模过程中CRC模型用在概念建模中用来揭示某领域内概念和它们的间高层关系 约束定义Constra
definition 两者的 索引卡片(Index card) 约束是对你提供解决方案自由度限制把约束作为全局需求对你项目来说是很有效 数据流图Data flow diagram(DFD) 行为类型 白板 数据流图展现系统中数据在处理过程间、实体间、以及数据存储站间流动情况它常用来描述系统环境指出和你系统相交互主要外部实体 基本用户界面原型Essential UI prototype 两者的 粘贴纸 基本用户界面原型是低精度它表现是界面背后大致想法而非细节 基本使用案例Essential use 行为类型 纸张 个使用案例(use )就是针对个参和者(actor)连串动作通过使用案例可对该参和者价值进行测量基本使用案例是个简化了、抽象、般化用案例它以和特定技术和实现无关方式攫取个使用者意图 特性Feature 两者的常用于行为类型 索引卡片(Index card) 从用户角度来看特性是个小、有用结果个特性是可以用于计划、报告和跟踪个计量单位它是可理解和可衡量可以在两个星期内完成(同其它几个特性起)(Coad, Lefebvre, &Deluca, 1999)(译注:个特性在大多数情况下等同于个功能) 技术方面要求Technical requirement 非行为类型 索引卡片(Index card) 技术上要求是属于系统中非功能性部分比如性能上问题、可靠性问题或者技术环境方面问题 使用情景Usage scenario 行为类型 索引卡片(Index card) 个使用情景通过个或多个使用案例或用户故事描绘条单逻辑路径个使用情景可以表示个使用案例中基本路线即愉快路径；或者该使用案例中其它路径；或者条跨越几个使用案例或用户故事路径 使用案例图Use diagram 行为类型 白板 使用案例图由些使用案例、参和者和它们的间关系组成或者还会有个系统边界盒建模时数据流图用来描述系统环境指出和系统相关主要外部实体 用户故事User story 两者的 索引卡片(Index card) 个用户故事就是你和项目甲方进行次谈话备忘录它是高层次需求包括行为需求、业务规则、约束和技术要求
表 1 可选
需求建模artact应该注意
是并不意味着你需要将所有上面所列出都用在任何个项目中熟悉你模型这条原则(见The Principles of Agile Modeling文)说就是你要知道每个artact适合在什么时候用你对模型了解得越多就越能够根据实际情况运用正确artactart
act选择往往被所采用底层软件Software开发流程所左右在主页上我简要地介绍说明了AM和其它有着完整生命周期软件Software开发流程起使用情况比如XP或UP通常区别底层软件Software开发流程对需求分析artact有着区别偏好象XP使用用户故事而UP用使用案例这也是你在为需求建模时应该考虑问题详细内容请参见AM and XP和AM and UP以使用为中心
思路方法如何在
个商业应用中以灵巧方式为需求建模呢？让我们来看下面例子在这个例子中我们要为个SWA Online系统建立需求模型在开始的前读者必须认识到几个问题第本文主要集中在需求建模讨论上如涉及到其它类型建模如分析建模、构架建模或设计建模我会就此打住并给出我所著相关文章连接灵巧方式软件Software开发是高度反复过程由此实际上需求建模和其它类型建模界线不是很明确第 2这里所讲只是许多可用方式种其它方式也可能是灵巧记住AM是套基于实战思路方法它没有定义特定规范标准种做法因此可采取方式是多样不用担心我会在过程中给出我可能会采用另外方式但这也不是所有 -- 保持你开放思维第 3由于SWA Online开发小组采用是Enterprise Unied Process(EUP)(Ambler,2001b)开发流程那么使用案例就会起主要作用反的如果采用是eXtreme Programming(XP)(Beck,2000)话用户故事就会占主导地位我在AM and XP文中从XP角度重新讨论了这个例子第 4这个例子虽然是基于我实际经历所虚构但我想这会使我们讨论更加形象而简单第 5最好将需求建模化分为两个区别阶段:需求
阶段(initial requirement up front(IRUF))和详细需求建模阶段
最新评论