SERU-需求定义
2021-04-26 14:56:40 20 举报AI智能生成
需求定义实际上就是确定项目的目标及系统范围
作者其他创作
大纲/内容
一、需求定义
需求定义常见问题
项目立项阶段开发团队（包含需求分析师）还没有开始工作，甚至团队还未成立
事后补课，必须认真审视需求定义阶段的产物
项目立项输出的目标与泛微很空洞，难以落实，如：全面提高企业信息化应用水平
通过内部寻根或外部溯源来破解混沌不清的项目目标
内部寻根：尝试寻找真正的项目发起人，和这些项目发起人进行深入沟通
外部溯源：外部因素所激发的项目，需求定义时要找到目标参照物，通过对目标参照物的分析与了解，做好需求定义工作
需求定义是什么
需求定义四进阶GPOA
定义目标：通过内部寻根或外部溯源的方法，先将整个项目要解决的问题或机会罗列出来，例如“废品率太高”
寻找问题根源：针对目标层面的问题进行分析，找到导致该问题产生的根源问题，然后将其全部列出来，例如“订单不准确”、“运输损耗”等
提出可选方案：针对每个问题罗列出可能解决的方案，例如针对“订单不准确”问题，可选方案可以包括“用户直接通过电子化手段下订单”、“对订单内容进行电子化校核”等
建议方案：从各种可选的方案中挑出认为比较合理，对解决问题贡献度更高的方案
需求定义策略
问题分析五步法
在问题定义上达成共识
手段：
采用统一的格式（模板）写出来就是很有效的手段
采用统一的格式（模板）写出来就是很有效的手段
RUP建议模板4大要素
问题/机会定义：描述真实世界中存在的问题或潜在的机会
影响人群：该问题影响的主要人群有哪些
影响结果：该问题对这类人群产生了什么影响
系统预期：预期什么样的解决方案，希望系统应该具备哪些优点
问题定义技巧
转换：
要善于将未知解问题转换成已知解问题，注意如何将客户的需求转换成自己的已有产品或者熟悉的场景
要善于将未知解问题转换成已知解问题，注意如何将客户的需求转换成自己的已有产品或者熟悉的场景
本源：
问题经常会被表象所掩盖，要寻找问题本质，直接修改错误，不要用其他方案来弥补错误。
但在确定某问题的解决方案时，一定要思考是否会引发新问题
问题经常会被表象所掩盖，要寻找问题本质，直接修改错误，不要用其他方案来弥补错误。
但在确定某问题的解决方案时，一定要思考是否会引发新问题
影响人群分析：
根据影响用户的年纪段、性别、区域等自然因素进行分析
根据影响用户的年纪段、性别、区域等自然因素进行分析
理解根本原因（寻找问题的本源）
策略
鱼骨图（因果鱼骨图）
好处
使分析人员将问题原因而不是症状放在首位
提供给一种运用集体智慧解决问题的方式
直观、简明、易于操作
步骤
选择问题：选择一个具体的问题或结果
头脑风暴：对所有的问题进行头脑风暴，找到所有可能导致问题的潜在原因
确定原因类型：对头脑风暴的结果进行整理分类（一般不宜超过6种），确定出主要的原因类型
分配原因：将头脑风暴得出的潜在原因进行按类（原因类型）分配，保证每一项原因都归类于适合的类别中
分析根本原因：针对所有的潜在原因进行分析，考虑造成 某一结果的根本原因最有可能是什么，或者说哪些原因是最核心的
帕累托图
作用
为80%的问题找出关键的20%的原因
一目了然的显示出每个原因的相对重要程度
有助于预防在解决了一些问题后，引入新的问题或者让其他问题变得更糟糕
步骤
确定问题和相关原因：在鱼骨图分析中已完成
收集数据：对每一个根本原因有针对性的收集数据，统计该原因造成问题的数量
绘制直方图：将原因放在横轴，数量信息置于纵轴，从数量从高到低绘制条形图，再用同一条线表示累计错误比率
确定相关人员和用户
Stakeholder解析
项目是一个博弈的游戏，有很多人都拥有相应的筹码，项目经理的目标就是尽可能多地获得筹码，只要获得的筹码足够多，项目就将获得成功：
操作层手里的筹码相对来说是很少的，人数最多；
中层管理人员手中有一定的筹码，人数较少；
高层管理人员手握着最有分量的筹码，而且人数极少。
操作层手里的筹码相对来说是很少的，人数最多；
中层管理人员手中有一定的筹码，人数较少；
高层管理人员手握着最有分量的筹码，而且人数极少。
用户分析
用户是指是直接使用系统的人群，也是Stakeholder的一类
了解用户的特点、能力，按照不同的角度对用户进行划分，然后对每类用户的特点进行分析，以便为后续的需求分析提供相应的信息
定义解决方案的界限
术语
范围：是指系统涵盖的内容，是涉及的事、物
边界：是指用户与系统的职责边界，是各自需要完成的事
边界管理策略
边界划分：梳理出业务场景流程，按照流程节点进行边界划分并按照先后顺序编号（从小到大编号）
边界确定：客户的预算是有限的，需要对每个边界右侧的系统实现进行工作量评估，以确定预算内边界的最小值
边界谈判：人永远希望用同样的钱干更多的事，在客户提出预算外的功能实现时，尽量从用户自身的困难和障碍触发说服客户，不要一开始就处处说开发的困难，更不要说“你要的功能太多了，这点投资是不够的！”，这种回复的说服力太有限了
创新边界：在客户预算充足甚至是预算可增加的情况下，为了争取更多的项目收益，可以考虑把顾客、顾客行为习惯纳入了系统的范围，在现有的业务流程基础上做前伸，创造原来没有的边界，继而扩大项目范围，索取更多项目经费
确定加在解决方案上的约束
技术开发约束
项目实施约束
需求定义的产物和重点
项目立项产物
项目综述（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 条评论
下一页
