SERU-需求定义
2021-04-26 14:56:40 20 举报AI智能生成
登录查看完整内容
为你推荐
查看更多
需求定义实际上就是确定项目的目标及系统范围
作者其他创作
大纲/内容
SERU过程框架
一、需求定义
需求定义常见问题
项目立项阶段开发团队（包含需求分析师）还没有开始工作，甚至团队还未成立
事后补课，必须认真审视需求定义阶段的产物
项目立项输出的目标与泛微很空洞，难以落实，如：全面提高企业信息化应用水平
通过内部寻根或外部溯源来破解混沌不清的项目目标
内部寻根：尝试寻找真正的项目发起人，和这些项目发起人进行深入沟通
外部溯源：外部因素所激发的项目，需求定义时要找到目标参照物，通过对目标参照物的分析与了解，做好需求定义工作
需求定义是什么
需求定义四进阶GPOA
定义目标：通过内部寻根或外部溯源的方法，先将整个项目要解决的问题或机会罗列出来，例如“废品率太高”
寻找问题根源：针对目标层面的问题进行分析，找到导致该问题产生的根源问题，然后将其全部列出来，例如“订单不准确”、“运输损耗”等
提出可选方案：针对每个问题罗列出可能解决的方案，例如针对“订单不准确”问题，可选方案可以包括“用户直接通过电子化手段下订单”、“对订单内容进行电子化校核”等
建议方案：从各种可选的方案中挑出认为比较合理，对解决问题贡献度更高的方案
GPOA理念图
需求定义策略
问题分析五步法
在问题定义上达成共识
手段：采用统一的格式（模板）写出来就是很有效的手段
RUP建议模板4大要素
问题/机会定义：描述真实世界中存在的问题或潜在的机会
影响人群：该问题影响的主要人群有哪些
影响结果：该问题对这类人群产生了什么影响
系统预期：预期什么样的解决方案，希望系统应该具备哪些优点
问题定义技巧
转换：要善于将未知解问题转换成已知解问题，注意如何将客户的需求转换成自己的已有产品或者熟悉的场景
本源：问题经常会被表象所掩盖，要寻找问题本质，直接修改错误，不要用其他方案来弥补错误。但在确定某问题的解决方案时，一定要思考是否会引发新问题
影响人群分析：根据影响用户的年纪段、性别、区域等自然因素进行分析
理解根本原因（寻找问题的本源）
鱼骨图和帕累托图都是站在问题域的角度进行的分析，因此当这些分析完成之后，需求人员应该判断哪些原因是可以通过信息系统解决的（系统不是万能的），从而使得系统目标的确立更加科学，需求的范围也更易于确定鱼骨图找到了靶子，帕累托图为靶子标上了环数
策略
鱼骨图（因果鱼骨图）
好处
使分析人员将问题原因而不是症状放在首位
提供给一种运用集体智慧解决问题的方式
直观、简明、易于操作
步骤
选择问题：选择一个具体的问题或结果
头脑风暴：对所有的问题进行头脑风暴，找到所有可能导致问题的潜在原因
确定原因类型：对头脑风暴的结果进行整理分类（一般不宜超过6种），确定出主要的原因类型
分配原因：将头脑风暴得出的潜在原因进行按类（原因类型）分配，保证每一项原因都归类于适合的类别中
分析根本原因：针对所有的潜在原因进行分析，考虑造成 某一结果的根本原因最有可能是什么，或者说哪些原因是最核心的
帕累托图
作用
为80%的问题找出关键的20%的原因
一目了然的显示出每个原因的相对重要程度
有助于预防在解决了一些问题后，引入新的问题或者让其他问题变得更糟糕
确定问题和相关原因：在鱼骨图分析中已完成
收集数据：对每一个根本原因有针对性的收集数据，统计该原因造成问题的数量
绘制直方图：将原因放在横轴，数量信息置于纵轴，从数量从高到低绘制条形图，再用同一条线表示累计错误比率
确定相关人员和用户
Stakeholder解析
项目是一个博弈的游戏，有很多人都拥有相应的筹码，项目经理的目标就是尽可能多地获得筹码，只要获得的筹码足够多，项目就将获得成功：操作层手里的筹码相对来说是很少的，人数最多；中层管理人员手中有一定的筹码，人数较少；高层管理人员手握着最有分量的筹码，而且人数极少。
用户分析
用户是指是直接使用系统的人群，也是Stakeholder的一类
了解用户的特点、能力，按照不同的角度对用户进行划分，然后对每类用户的特点进行分析，以便为后续的需求分析提供相应的信息
定义解决方案的界限
术语
范围：是指系统涵盖的内容，是涉及的事、物
边界：是指用户与系统的职责边界，是各自需要完成的事
边界管理策略
边界划分：梳理出业务场景流程，按照流程节点进行边界划分并按照先后顺序编号（从小到大编号）
边界确定：客户的预算是有限的，需要对每个边界右侧的系统实现进行工作量评估，以确定预算内边界的最小值
边界谈判：人永远希望用同样的钱干更多的事，在客户提出预算外的功能实现时，尽量从用户自身的困难和障碍触发说服客户，不要一开始就处处说开发的困难，更不要说“你要的功能太多了，这点投资是不够的！”，这种回复的说服力太有限了
创新边界：在客户预算充足甚至是预算可增加的情况下，为了争取更多的项目收益，可以考虑把顾客、顾客行为习惯纳入了系统的范围，在现有的业务流程基础上做前伸，创造原来没有的边界，继而扩大项目范围，索取更多项目经费
确定加在解决方案上的约束
技术开发约束
项目实施约束
解决方案的约束类型
需求定义的产物和重点
输出物常见形式
POS
项目章程
项目可行性报告
项目立项产物
项目综述（POS）类：主要是项目型软件开发工作产出
愿景类（Vision）：主要是生命周期较长、应用面较广的项目或产品软件开发工作产出，更注重于对市场潜在机会的分析
需求定义重点
目标
好的目标描述应该满足SMART原则
S：Specific，必须能够指导具体的工作
M：Measurable，必须是可度量的，能够进行成本/效益分析
A：Attainable，必须是技术可实现的
R：Relevant，必须和其他目标有相关性
T：Time-Base，必须有明确的截止期限
目标的具体写作过程，主要关注的几个要素：目标、业务优势（带来的好处）、度量指标（数据指标）、合理性（经济可行性）、可行性（可以达到的结果）、可达成性（技术可行性）
范围
需求定义工作的核心工作就是确定范围，描述范围采用“两图一纲”（4.4节描述）
相关干系人
在进行需求定义时，需要对软件项目干系人进行研究
针对用户：了解用户的能力特点，才能提高系统的可用性如果系统在可用性方面的风险较小，可以在该阶段忽略对用户特点的了解
用户之外的人员：需要了解他们对系统的关注点，想通过系统获得或实现什么利益，对系统的实施过程是十分有价值的
相关事实与假定
相关事实：可能对系统产生影响的外部因素
假定：需求定义阶段所做的假定清单，可能是对用户能力、外部系统性能的一种假设，这些假设都说是对系统有影响的
如何有效描述需求范围？
采用业务导向的层次结构来整理需求，通过三个独立的步骤逐渐演化出需求的范围定义，并采用“两图一纲（构件图、上下文关系图、需求大纲）”来描述，为SRS提供最初的目录结构
执行步骤
划分主题域
什么是主题域？
在分解系统时，以“事（业务的脉络）”为线索划分成的不同的业务域
实用技巧
以组织结构为线索：组织结构式划分主题域的重要参考，通常主题域的边界恰好是部门的边界
从分管领导中找突破：观察企业分管领导的设置
借鉴典型的业务职责区块：例如，很多企业都会有自己的产、供、销、存环节
工具（描述方式）
构件图
组成
构件（组件）
对应主题域
服务接口
每个主题域都不是孤立存在的，之间总有这样那样的协作，需要将其标识出来，这就是主题域之间的服务接口
尽早地标识出各个主题域之间的接口，可以有效地避免后续系统对当前系统的影响。
标识服务接口要点
职责驱动设计：确保能做的事和知道的事相匹配是职责驱动设计的要点实际工作中，哪个系统最后是业务的落实者，谁应该就是接口的提供者，并且要注意不能将职能交给接口的使用者
关系
构件与构件：构件与构件之间一般不直接建模它们的关系
构件与接口：构件对接口而言有两种关系，一种是实现关系（表示这个接口是某个构件提供的），另一种是使用关系
接口与接口：接口与接口之间是没有关系的
目标决定范围
将主题域划分完成后、最终确定前，需要结合目标来考虑。如果主体域内某个子系统对系统既定目标（要解决的问题或机会）没有直接贡献，根据目标决定范围的原则，就应该移除
主题域任务划分
如果团队规模较大，就可以考虑根据主题域进行需求分析人员的分工，各小组工作的协同点就是服务接口
确定主题域范围
Customer和Worker
Customer
主题域的客户，处于该主题域的外部，其他主题域的内部工作人员也是当前主题域的客户
Worker
主题域的工作人员，处于该主题域的内部，包括子系统本身（比如系统自动发送系统消息告知用户，也是Worker自身发起的事件）
上下文关系图
上下文关系图应该是在与用户代表沟通时绘制的，是一种团队建模的产物，不建议需求分析人员独自在电脑上进行绘制
绘制步骤
以系统中的某个主题域作为子系统，针对该子系统用一个矩形表示子系统且命名，将整个系统看做一个黑盒子
找到该子系统所有的客户Customer，并考虑客户会发起什么事件，这些事件会引发内部工作人员Worker的什么工作，讲这些序列逐一表示出来
找到该子系统每个内部工作人员还有没有主动发起一些事件
标识业务事件与报表
为什么要标识业务事件与报表？
对于联机事务处理系统OTLP而言，业务事件（流程）是核心线索，对于管理信息系统MIS而言，Report（包括各种查询、分析、统计）是核心线索，通常的业务系统都包含了这两种成分
业务事件
解析
业务事件：是业务流程的触发点，标识出业务事件能够有效的识别出业务流程
业务流程：是为了响应业务事件而触发的一系列业务活动，它通常是由不同部门、不同岗位协作完成的。因此业务流程的信息是掌握在中层管理人员手里的，它属于脉络信息
业务活动：则从属于一个特定的业务流程，它是一个人的活动，因此一个业务流程应该是由一个或多个业务活动组成的；而业务步骤是完成某个业务活动所需要的具体步骤。因此业务活动和业务步骤的信息是掌握在操作层人员手里的，它属于细节信息
业务事件类型
外部事件
客户发起（C事件）
由主题域外的客户发起的，在绘制上下文关系图时我们建议的主线索
内部工作人员发起（W事件）
内部事件
时间事件（T事件）
由于到达某一时刻所发生的事件，例如，到信用卡结算日时就会向客户发送账单，这就是一种时间事件
状态事件（S事件）
由于到达某一状态时所发生的事件，例如，当体检结果出来并出具了报告之后，就将通知体检者领取报告
业务事件标识要点
业务事件是主动触发的，并且会产生一系列的后续行为
业务事件是直接作用与系统的，也就是将触发系统行为
报表
主要要素
报表类型
为什么需要这些报表
报表使用场景
主要人员
主要以中层管理人员为主的访谈来确定所需的报表类型
关键在于从管理意图的角度进行是梳理，以事、物为线索
生成需求大纲
1-3三步将需求的范围界定之后，就可以将它填充到POS或Vision文档中的“项目范围”小节中去，先从主题域划分，然后到每个主题域一个小节，分别阐述业务事件与报表需求，并利用这些信息将SRS的框架搭建出来
0 条评论
回复 删除
下一页
