SERU-原理、模型与误区
2021-04-26 15:07:18 7 举报AI智能生成
登录查看完整内容
软件需求常见误区及解决方法
作者其他创作
大纲/内容
SERU过程框架-原理、模型与误区
需求实践现状分析
1.1需求相关败因分析
需求不完整
用户作为需求完整性评价的主要源，但常见的SRS中主要充斥着技术类字眼与机构，导致用户不能很好的理解甚至不能理解
要让用户读懂SRS更好的参与到需求完整性评价中来，就必须采用“业务导向”的组织结构，将用户带入到自己熟悉的业务场景中去且需求实践过程及SRS都要利用树形层次结构将“宏观信息与微观信息”进行有效的隔离
需求分析人员由于各种原因或嫌麻烦试图“以点带面”完整需求验证，让一个或几个用户代表看完SRS所有内容指出错误，过于天真（公司不会有人上通宏观策略，下解微观操作）
措施：树形层次结构应该面向不同的层面：决策者（高层）、事务管理层（中层）、操作层（基层），将需求分为不同的部分，让合适的人验证适当的部分，然后再汇总、分析、解决矛盾
需求“验证”经常以“签字确认”的形式主义体现，更多的是责任。而“需求验证”本是需求质量关，其目标是暴露出更多的错误，指出潜在的问题与错误
提前预约会议做好会议相关准备工作，以需求评审会的形式进行需求评审
缺乏用户参与
用户常以“你们先做，做出来我们试试后再改”之类的话搪塞，事不关己高高挂起，没有主动参与意识
充分研究不同用户代表的关注点、利益点，让用户有兴趣积极参加
需求分析人员常以一些专业的技术名词或行业内术语与用户沟通，导致用户听不懂直接劝退
了解、使用用户行业用语及通俗的语言进行表达，多举例将用户拉入到自己熟悉的业务场景甚至生活场景
需求分析人员捕获需求时没找对人，用户对沟通的领域不专业所以不愿多介入，甚至捕获到错误需求
找对的人聊对的事，一般从基层向上找比较好找，因为基层的微观操作和软件功能很好对应，再找其上级即可
需求变更频繁
用户朝今夕改，一时一个主意，没有深思熟虑过，频繁变更需求
1、用户对变更对软件产生的负面影响没有意识2、软件企业（需求分析人员）缺乏统一的变更处理渠道，使得变更相对而言比较散落，没有集中的体现出来
对变更进行分类、统计，有效的找出问题的根源，有针对性的改进需求过程，提高设计弹性
沟通失真
现在很多公司轻视、甚至忽视需求分析的工作，由研发与用户直接对接或项目经理简单沟通后转述研发继而直接动手干活，导致：1、在沟通传达过程中“词不达意”或受到个人经验或主观意识影响“加工减料”，使得最终沟通严重失真2、没有持久化材料支撑，一段时间后完全忘记当时用户是如何说的，然后按照大意“自主创造”需求3、没有文档、原型等，无法与用户进行需求评审，语言沟通毕竟不如原型、图形等可直观展示的东西易于理解且不易曲解
1、在信息传递过程中有效的利用文档、原型等设计文件，达成有共识的信息文档化2、Review(需求评审)：让用户再看一次或再确认一次，实践中最简单有效的就是需求分析师及时用自己的语言再复述一遍，以确保这就是用户的要求
用户需求放大
用户在描述需求时“添油加醋”，过分描述需求有部分乙方也会由于利益关系对客户“胡乱报价”，缺乏有效的估算实践，导致用户预算很高）
用户想“花更少的钱干更多的事”，尽量避免自己“亏损”，那么在需求协商时很可能通过增加需求的方式来降低所谓的“亏损”风险
更好的和用户沟通，确认用户认可他的钱花的物有所值，打消用户“亏损疑虑”
在需求捕获过程中，需求捕获的接口人不是熟悉相关业务的客户，用户自己都对业务不是很熟悉，所以不能直接告诉需求分析师“最佳解决方案”，导致在软件的使用过程中不断的发现其它可选的、更适合的替代的方案，从而导致了不必要的需求变更
不切实际的用户需求
用户总是很天真的提出大量需求，有些技术根本无法实现，有些则是脆弱的成本或时间预算无法实现的
软件的无形和成本的不透明
主动帮助用户更好的理解软件的成本，并说明为什么有些需求做不到
注重技术而忽略业务
很多公司都是一人多职，“项目经理、需求分析、系统分析”一肩挑之，导致更多时候在追求技术框架、新技术等，很少从“业务”角度进行分析
增加专业的需求分析人员或者增强技术人员业务分析能力，但是要看公司的重视程度，很难个人左右，比较无力
丢失业务场景单纯描述需求
很多时候忽视用户使用场景，简单的描述信息如何录入系统、分析、处理，完全没有考虑用户使用系统的环境、可行性、易用性、时限性等，比如用户可能在“无网络环境”下操作；一个操作需要很长时间（系统可能登录过期）；在户外操作，无法携带或不方便是用电脑等
在描述需求时，业务场景至关重要，是“需求之魂”，因此要重点突出说明
1.2透过表象看本质
软件项目失败不一定是项目管理技能不足导致的，很多时候也是需求问题
常见的需求表象
表象1：需求变更频繁
应该重视对需求变更分门别类进行分析与管理
诱因1：原有需求的背离：说明需求描述与沟通有问题，导致交流失真
应该加强需求过程的管理，加强沟通后手段的管理
诱因2：需求遗漏：说明需求捕获有问题，需求不完整
加强需求捕获方法的组合应用，加强对业务模型的梳理
诱因3：业务流程变化：说明需要采用流程引擎工具
诱因4：用户界面变化：说明需要界面动态生成器
......
表象2：上线阻力大
诱因1：利益冲突：业务数据管控力的提高会伤害到某些部门的既得利益，有时还会产生新的利益冲突
在需求捕获过程中细心的发现与总结潜在的行政因素，尽量了解利益的冲突点然后去解决或绕开
针对某些问题，在系统实施前将这些因素整理成文，直接提交至客户高层，这样可以很好的减轻团队压力问题：1.针对哪些问题的需求讨论时争论最大？具体是哪些部门或者人员？各自的提出意见是什么？2、是否剥夺了某些人的行政决策权？
诱因2：工作量增大：当增大的工作量影响基层使用人员的日常工作时，就会产生很大的上线阻力
提高易用性：在需求捕获时，将具有重复性、规模性大的需求重点标识出来，在设计时应该充分基于业务实际场景来提高易用性、速度
工作量价值化：在需求阶段尽可能标识出软件新增的工作量对于实际业务、管理带来的直接好处，告诉基层人员提高他们的积极性
将数据迁移、准备工作独立出来：系统在刚上线时经常会对历史数据进行处理或录入大量的基础数据，在需求阶段应该标识出来，减少或避免成为基层的负担
表象3：运行效果差
诱因1：软件项目在开发过程中缺乏有效的目标作为指引，与实际的业务过程脱节严重
管理层内动力分析：在需求分析阶段针对不同管理人员的利益进行分析，尽量将管理人员的利益与系统连接起来，比如：了解、分析管理层干系人的考评在制度或绩效评审方式，了解内部工作模式；
基层易用性提升：帮助基层扫清使用障碍（根据业务场景设计易用的系统），解决一些困难
“以点带面”突破：可以先找关系较好的一个或多个部门（说服该部门领导）使用，然后进行数据分析，用数据向领导汇报最具有说服力，这样子在领导认可的情况下更容易以点带面推动系统全面上线
实际中很多项目（政府比较严重）在上线之后都没有用起来、用的极少或运行极差
表象4：软件不可用（完全崩溃）
诱因1：忽略了某方面的非功能性需求，比如：系统容量不足、用户并发过高服务宕机
在第三章软件需求与需求过程中阐述
一般SRS都可以中找到“非功能性需求”描述，但是问题一般都出在非功能性需求的定性描述上，如：高可靠性、高可用性...等，实际上就是一种“无效信息传递”！而所谓的“平均无故航时间为1000个小时”的定量描述，写的人和读的人都没有明确感知。
1.3方法论与需求工作
计算模式：需求分析师更多要考虑方法论的适用性而非先进性（不要一味追求新的东西，一般技术人员会比较严重），要从用户的角度分析哪种模式更适合用户，要考虑到实际用户的年纪分布、文化程度、教育经历、使用习惯、使用环境等多个因素，比如上年纪的老人使用C/S架构或者最简单的交互界面才最适合，而不是最新的B/S架构以及炫酷的UI界面
软件工程方法：分为重方法论和敏捷方法论
重方法论：强调前期设计，为未来而设计，适合业务复杂度高且相互制约（耦合性较高）且业务场景不易变的项目，对于项目组人员较大（超过30~40人）的团队比较适合
敏捷方法论：强调只为现在设计，未来再重构，适合互联网类的业务场景变化较快的项目，适合小规模的团队
开发思想（技术选型）：在打算应用某项未知技术前，应该重视技术的成熟度及其局限性
成熟度：了解该技术的出现时间、应用企业数量（在国内这个更直接有效）
溯源：对某种技术要有深入的了解，就直接去了解它为什么诞生以及发展历史，然后思考自己的业务使用场景与之是否匹配
局限性：技术不是万能的，要了解其优势，当然也要了解技术的局限性，才能更好的使用技术或避免一些不必要的返工或额外的工作量
不同软件项目的需求视图
2.1 信息系统
分为6大类别
联机事务处理系统OLTP
数据生产者：负责对流程进行电子化，在该过程中，用户通过手动输入、系统采集等方式积累大量数据
管理信息系统MIS
数据消费者：为中层管理人员（事务性管理人员）提供服务，主要通过查询、分析、统计等手段完成监督、控制等活动，核心载体就是报表
主管信息系统EIS
决策支持系统DSS
专家系统
数据生产者/消费者：对个人知识的沉淀，同时消费数据
办公自动化系统OA
对沟通与协作的直接支持
数据高级消费者：为高层管理人员（决策型管理人员）提供服务，形式与管理信息系统类似，但会对数据进行更深层次的挖掘、分析
1 联机事务处理系统OLTP
流程分析（业务事件）是联机事务处理系统的关键线索和主要视图
流程电子化优劣性
更利于流程的固化：能够建立刚性的规则，确保制度执行的效果
对业务产生一定的约束：会限制业务的灵活性，如果流程不合理将会产生不好的后果
许多需求实践中没有真正把握【主要需求视图】，使得需求实现受到很大阻力
1、结构化分解过早考虑程序结构
割裂了业务流程（业务场景）：1、使客户无法很好的参与到需求验证过程2、同时也导致分析需求的线索丢失（失去了客户最熟悉的场景，客户无法继续业务线索）
常见的错误的需求分析产物
需求开发思想：提倡从用户的场景触发，从业务流程出发的横向视角，而不是“系统结构化分解”这种自上而下的纵向视角
2、流程分析相对零散
不知道流程图应该细化到什么程度、流程之间的关系应该如何处理，从而导致流程图不能成为有体系的线索
流程分析（电子化）的上游
BPR（Business Process Reengineering） 业务流程重组
一般是定义为对企业战略、增值运营流程以及支撑它们的系统、政策、制度、组织和结构等进行重组和优化，达到工作流程和生产力最优化
BPD（Business Process Design）业务流程设计
为了达到信息系统的目标选择相关的流程，确定系统的边界，进行设计、实现
流程分析（电子化）的下游
系统内建流程机制与现有业务流程的融合
2 管理信息系统 MIS
报表需求是MIS的关键线索与主要视图
主要面向中层管理人员，而管理的本质是计划、控制、组织、协调，需要报表（数据价值化的体现）进行支持。而在企业或组织运行的过程中会产生大量数据，只有将这些数据根据实际需要进行加工、整理才能产生对管理活动有价值的信息
通过对关注的业务事件、业务实体对象进行分析、统计，生成报表（不局限于表格、图形化展示）
报表（查询、统计类）需求
应该在分析业务功能性需求OTLP之前分析报表类需求MIS
MIS是消费者，OTLP是生产者，应该先了解消费者的需求，再满足生产者的需求（很容易理解，报表的基础数据来自业务功能，所以了解报表类需求很容易在分析业务性功能时对容易忽视的点进行“补充”，并且在设计时充分考虑，说的直白一点就是：我要的数据在生产（输入或采集）时就必须要有或可间接得到）
经常先进行业务性功能分析，再进行报表类需求分析（需求分析师只关注“眼前功能”，客户中层领导往往说“先实现系统功能再加吧”）
报表的本质不是形式，真正的本质在于目的需求分析要开始在OTLP之前，要关注客户的“目的”，“形式”反倒不是当前重点（刚开始客户也说不清楚报表具体展现形式这种细节的东西，过分关注询问会使得客户陷入细节且可能对此产生反感，因为常人的理解就是“先有基础数据再有报表的”）
系统在某个阶段开发完成后，客户如果提出新的报表类需求，没有找到“格式一样”的报表功能，先不要急着开发，多问“为什么”，在了解客户目的之后对系统内建报表进行分析，有时会发现通过其他途径就可以实现客户目的且有可能比客户要求更加实用，就可以避免二次开发（客户有时只是因为对系统不够熟悉或只关注自己的业务功能模块导致没有发现想要的报表信息而提出新的要求）
捕获要点（关键角度）
Why（目的是什么）
目的
从管理场景出发，了解中层管理者的诉求与目的，借助对管理的控制点（计划、控制、组织、协助）理解报表的目的
使用者（部门/职位）
了解报表使用者，以便针对性调研（挑选合适的用户代表）
相关场景
了解报表的数据量、查询频率、用户数量等非功能性场景描述（非功能性需求）
What（如何获得）
关联实体
利用E-R图或类图说明数据的来源及实体之间的关联关系（有时需要数据流图DFD辅助）
关联指标及计算规则
细化推导出关联的字段及派生属性的计算方法
How（如何展现）
展现形式
说明最终的呈现方式
输入输出需要
说明是否需要查询、打印，以什么样的格式提供等其他信息
报表分类
事务管理类
从业务事件的管理和业务实体情况的基本分析角度展开
业务事件
进度报表
关注业务事件相关的进度信息，通常按周期或日程生成通常，关键指标报表也是一种特殊的进度报表，是对前一周期关键活动的汇总
异常报表
异常是中层管理者采取相应措施的时机，因此是很关注的视角一般由系统自动生成来提醒用户，例如：告警自动发起事件运维流程
业务实体
常规报表
针对某一情况对中层管理者提供详细的数据，通常都是针对实体的信息，例：运行设备的告警历史
需求报表
按照中层管理人员的需求提供相应信息信息，通常涉及多个业务实体之间的信息，例：项目的收入与支出，会涉及项目、合同、订单等业务实体
决策管理类
侧重不同的维度分析，特别是自然维度（客户职业、年龄、爱好、地域等），是对数据的进一步抽象与整理一般基础的数据库操作就不能很好的满足了，经常需要对历史数据进行抽取、加工、转换等，也就会产生对数据仓、数据集市的相关需求了
3 主管信息系统 EIS
报表需求依旧是关键线索与主要视图
4 决策支持系统 DSS
决策场景是DSS系统的关键线索与主要视图
1、整理决策关注的决策场景2、针对决策场景将管理人员的日常工作分解为具体的分析步骤3、针对每个分析步骤分析其所需的数据以及所需的呈现方式
1、在需求定义阶段只需确定需求决策场景2、在需求捕获、分析阶段再针对每个决策场景进行梳理决策步骤3、再针对每个决策步骤来整理所需的数据以及人机界面支持
5 专家系统
工作场景是专家系统的关键线索与主要视图
1、对于具体场景而言不仅仅有相应的数据视图2、更重要的是有相应的经验模型、判断模型等
如何将知识工人的知识通过计算机固化下来，是新员工可以“站在巨人的肩膀上”，迅速成长为合格的知识工人
6 办公自动化系统OA
协作场景（并行工作流）是OA系统的关键线索与主要视图
常见的协助场景：信息共享、文件交换、文档多人在线协作等
还包括一些对个人事务的支持场景：日程表、行事历、备忘录等
随着企业发展，企业对流程的效率予以很大关注。而将串行的流程转化为并行的流程就是一种很重要的策略，但并行执行会涉及多个部门、岗位之间的沟通与协作问题目的就是为了提高工作效率（集体协作的和个人的工作效率）
1、整理出关注的协作场景/个人事务支持场景2、对具体的场景进行行为分析
信息系统的其他多维视图
四大线索
人
事（过程）
OTLP、OA中，事是主线索
业务流程图
活动图
物（数据）
MIS、DSS中，物是主线索专家系统中也偏重与物的线索
DFD
E-R
类图
接口
需求分析人员需要的工作视角（工作方向）
必须从全局看待系统，起到一个翻译和桥梁的作用
需求分析人员是用户与开发人员之间的桥梁
需求分析人员还是管理层和用户之间的桥梁
高层管理人员只在需求启动大会上待很短时间，象征性的说一些与项目无关或空虚大的话，并不能捕获到高层管理人员所关注的问题或机会
抓住高层管理者想解决什么问题或者带来什么样的机会来进行沟通（高层关注点就是中层管理人员与基层用户的执行目标，具有指导意义）
针对用户都是企业的高层管理人员
2.2 嵌入式系统
根据嵌入式与最终用户的关系划分为三种类型
面向直接用户的嵌入式系统
具体的使用场景是此类系统的关键线索与主要视图
1、首先找到具体的使用场景2、根据其逻辑性归纳成不同的功能域、功能子域3、再对重要功能域中的重要使用场景进行行为分析
针对此类系统，要重视可用性设计，可以针对每个使用场景进行行为分析，以便设计出更合理的用户界面
常见设备：手机、Pad、手持设备、ATM等
面向特定设备的嵌入式系统
外部接口和事件分析是要点
外部接口：，重点在于找到与该系统相关联的外部系统，然后明确外部系统与其的功能交互点
内部功能：对其内部功能进行分析与描述，在梳理这些内部功能时，可以采用事件作为线索
外部事件（通常是外部接口触发的）
状态事件
时间事件
内部事件（内部设备触发的）
常见设备：设备检测器、GPS模块、传感器等
综合应用的嵌入式系统
一般拆解为面向用户与面向特定设备来处理
2.3 软件产品
从需求角度，根据与问题域的相关度将软件产品分为三大类
信息系统类
问题域相关性强，业务域的了解是关键
常见系统：ERP、OA、进销存、DCIM等软件产品
工具软件类
问题域相关性弱，工作场景分析导出产品特性是关键
常见系统：腾讯文档、QQ
游戏类
问题域相关性弱，游戏策划、编剧代替需求分析人员（不讨论）
1 信息系统类产品
软件产品的成败在于对问题的理解，与信息系统项目对需求采用的方法是类似的
由于软件产品本身的特性，在完成需求工作时还有一些需要注意的方向因为产品类软件通常都会比项目型软件针对更大的目标市场
1 目标市场定位与分析
目标客户分析
确定软件针对什么行业、什么样规模的企业
竞争对手分析
确定了目标客户之后，再搜索针对相同目标客户的竞争对手，进行SWOT（优势、劣势、机会、挑战）分析，以便更好地提炼软件的卖点，制定合理的销售策略
商业模式分析
商业模式分析则是对需求分析、产品体系结构设计有着直接关系的任务目标就是抽取所有目标客户可能采取的商业模式，以便在产品体系设计时求同存异
2 产品体系设计
将不同商业模式之间的共同点做一些抽象，然后将不同点封装到可插接的模块中
信息系统类软件产品的需求重点在于针对不同目标客户群体的不同商业模式分离变化点；经常需要减出通用性，再通过插接解决扩展性
2 工具软件类产品
基于使用场景的困难点分析时工具类软件的需求要点
梳理需求步骤
先对不同用户进行分析，标识出具体的使用场景
针对不同的使用场景进行分析，确定所需的功能点
软件需求与需求过程
什么是软件需求？
软件需求的组成（定义）
业务知识
包括业务事件、业务实体、业务规则
问题列表
就是用户在工作中遇到的困难与痛点，实际上就是软件要解决的问题
其他因素
包括一些设计约束及非功能方面需求
需求的三个层次（需求工作的三个阶段）
阶段1：业务需求
业务需求反映的是企业或组织的对软件系统的高层次目标要求，也是软件系统的建设目标
业务需求的提出人通常都是企业或组织的高层管理人员，它是彻底从业务角度描述的，是指导软件开发的高层需求，明确的定义了业务需求
业务需求一般是在项目立项阶段整理的，也是需求定义的产物
阶段2：用户需求
描述用户使用软件需要完成什么任务，如何完成的需求
在需求定义的基础上进行用户访谈、调查，对用户的使用场景进行整理，从而建立用户角度的需求
用户需求具有的几个特点
零散：用户会从不同角度、层面、颗粒度提出需求，通常是以一句话的形式提出
矛盾：不同的用户处在不同的企业层面，看待事务难免片面，甚至产生不同的观点
阶段3：软件需求
软件需求是对用户需求进行分析、提炼、整理后的产物，这个过程就是需求分析与建模
三种类型
功能需求
在于如何对其组织、描述，让开发人员看懂，首选使用“用例”
避免使用传统的“层次（WBS树）结构”来组织，它更多的是按照程序结构来梳理了，会割裂用户使用场景
非功能需求
信息无效传递
列出类似高可靠、高可用、高扩展等定性描述，根本没有判断标准
忽略非功能需求的局部性
一刀切，不区分具体的使用场景，比如查询三年的数据与一周的报表数据都要求查询响应时间3秒以内很多时候就不合理
设计约束
主要受到几方面影响
非技术因素：比如企业要求使用国有自主类数据库、必须使用JAVA开发等限制因素
硬件环境：是云部署还是本地化部署，可能就会影响到软件设计架构、用户电脑分辨率有多种就需要适配
使用环境：比如要求支持IE9+、可能在无网环境下、户外使用等
需求三阶段示意图
对应需求定义、需求捕获、需求分析建模三个阶段
什么是优秀软件需求的标准？
分为4组
完整性：保证需求没有遗漏，换个角度就是说在需求变更时新增需求占比较少，且新需求都是由于外部环境变化产生的
不失真：需求正确、无歧义，确保需求在传递过程中不失真
有优先级：明确指出优先次序，才能对项目更好的管理
技术早期介入：让开发与测试在开发之前就介入需求，开发判定可行性及技术难度，测试判定可验证性及需求逻辑
如何保证需求是优秀的？
需求优秀，就要保证满足优秀需求的标准
保证完整性
将用户作为需求完整性验证最合适的人选：必须从业务角度来组织各种需求项，让用户验证SRS罗列的主题域、业务事件、业务活动、业务步骤、困难障碍与痛点是否完整，是否具有可操作性
保证需求不同层面的完整：需求完整性在验证时需要采用分层评审的方式，不同层次（高层、中层、基层）只负责评审与自己相关的那层需求
先理清宏观部分（主题域的划分），并让高层对其进行验证，看标识出来的主题域是否达到目标所需涉及的范围
再针对每个主题域进行分析，找到它的脉络（流程、实体），再让中层对其进行验证
最后走向操作层，对细节进行描述与验证
不失真
正确性：找到正确的人来进行评审：1.应该按照宏观、脉络、细节分而治之（与保证需求不同层面的完整一致）2.找到直接相关的人员来验证还需要注意避免需求的片面性，通过用户调查来补充
无歧义性：不同背景的人在传递时会加入不同的理解，光靠文档传递是不充分的，是无法代替沟通的，还需要加入一些验证活动来缓解、消除歧义
有优先级
优先级的不同角度：优先级可分为业务角度、技术角度和项目管理角度
业务角度：是需求分析师需要引导用户对需求优先级按照业务价值与频度进行划分
技术角度：架构师与开发人员在接收到业务优先级后，根据技术依赖性对其进行调整，对业务优先级只能提级不能降级
项目管理角度：项目经理与架构师接收到业务优先级后，根据项目风险对优先级进行调整，对业务优先级只能提级不能降级
需求必要性评价：需求优先级只考虑了需求的充分性，没有考虑需求的必要性，会导致需求蔓延和镀金需求的增多，如何保证需求是必要的呢？建议使用【满意/不满意模型】，是需求必要性评价的有效手段
满意度：当该需求被实现时，用户满意程度的量化值，体现了需求的充分性
不满意度：当该需求没有实现时，用户不满足程度的量化，体现了需求的必要性
总评价：上述两者的乘积得到更具参考的权重值，得出更适合的优先级评价
4 技术早期介入
SRS来自客户，但开发与测试也是主要读者，因此应该让技术早期介入，来评估SRS的可行性与可验证性。一般在开发工作开始之前进行需求评审会议，要求开发与测试都参加
可行性
开发对需求描述的重点需求项以及一些实现技术较复杂的解决方案进行评价
可验证性
测试对需求的可验证性以及需求逻辑性进行评价
需求工程
用户需求到技术解决方案的转换
需求工程的范畴
需求开发：是收集、分析、整理、编写、验证需求的全过程，重点在于开发出高质量的SRS
需求定义
需求获取（需求捕获）
需求分析
编写规约SRS
需求验证
需求管理：对需求的实现、变化进行追踪的全过程，重点在于确保开发的软件满足需求
基线管理
变更管理
需求跟踪
需求开发工作要点
需求开发的三次循环
初始循环：明确项目目标和范围，明确每个子系统的内容（业务事件与报表）和相互之间的接口
脉络循环：通过对每个业务事件进行流程分析、业务实体分析，并标识出所有用例（活动）
细节循环：对每个用例的细节进行分析，包括事件流、用户界面原型等
需求开发盲区
需求捕获常见问题
在捕获前准备阶段都应考虑到
捕获范围不足：认为客户要求就是软件需求，不注重对业务知识（业务事件、业务实体、业务规则）的捕获，从不主动问为什么
缺乏计划性：无准备（没有预先对问题、时间、访谈人员进行计划），捕获过程随意、走过场，造成需求捕获的时间利用率低
缺乏科学性：将宏观层次问题与微观问题混在一起，没有做到定向、聚焦
捕获对象不明确：很少主动找到合适的被访谈者，而是客户占据主动
捕获手段不足：认为只有用户访谈和调研会议才是有效手段，却忽略了在不同场景下可以通过组合不同的捕获手段达到更好的效果
需求分析是什么？
是业务分析：它的任务就是对问题域进行研究，从业务线索入手（而非系统结构）
是分解活动：将待开发系统按照职责划分成不同的主题域，再分解该主题域的所有流程，再分解到业务活动、业务步骤
是提炼和整合活动：将业务分解后，需要将用户原始需求合并到业务活动中去：1.要将业务流程合并到全局业务流程图2.要将各个业务事件的领域类图合并到全部领域类图3.要将各个业务事件的用例图合并到全局用例模型中或者说是对零散化的软件需求的粘合、重组，说清楚各个业务事件、业务实体之间的业务规则及其他关联
是规格化活动：找到冲突、矛盾，通过访谈等手段解决问题
需求分析的内容与形式
建模：核心思想是用“图表”代替“文本”，以更加可视化的方法来表述信息
需求分析是目的，需求建模只是手段，不要本末倒置，过分形式化而忽视需求分析要做什么，建模的过程比建模的结果更重要
需求分析生命周期
在首次需求捕获之后就开始进行需求分析，并将分析的结果补充到已规划好的SRS。需求分析会贯穿整个软件生命周期
编写规约
将需求分析结果文档化的过程
四字要诀：共享、更新
共享：让技术人员可获得SRS，并容易找到自己需要的信息部分
更新：保证SRS和开发最终结果保持一致，及时更新且确保同一类信息只在一处描述（避免更新不彻底的情况）
第八章 需求验证最佳实践
需求管理要点
统一、明确的需求项划分标准
要对需求进行有效管理，就必须有清晰、统一、明确的标准将需求划分为具体的需求项
颗粒度均匀：每个需求项的大小（工作量）是相当的，或者说衡量工作量的单位（人天、人周、人月）是一致的
大小合适：取决于管理粒度。如果采用迭代、增量的开发的开发过程，通常每个需求项的工作量以人周为单位；如果要对迭代内的开发作进一步的控制，就需要拆解为以人天为单位；
完整：最低一级的需求项应该涵盖所有的开发任务，应该包括
引入基线管理
基线管理将需求一分为二
基线内的需求：已经开始开发的需求 Baseline
就是一次开发迭代的工作内容，是有固定的、较短的时间盒（一次迭代一般控制在2~6周）
基线内的需求是明确的，所以每次迭代都是一个小型的瀑布型生命周期，在每次划分基线时，需要完成三方面工作
确立优先级：确保高优先级、高风险的需求项在尽早的迭代中完成
工作量评估：准确评估工作量，合理安排时间，确保每次迭代的时间安排是紧凑的
未完成项合并：每次迭代前将上次迭代某些未完成的工作考虑进去
没有安排开发的需求：待处理需求 Backlog
引入变更管理
变更管理重点在于完成业务影响分析、技术影响分析、项目影响分析三方面工作
业务影响分析：从业务角度对变更的合理性、优先级以及对原有需求的影响进行分析，以便决定是否纳入Backlog中。如果决定纳入Backlog，还有确定其优先级
技术影响分析：从技术角度对变更的影响范围进行分析，并决定是拒绝在后续迭代中响应还是在本次的迭代中对其响应
项目影响分析：基于前面的工作量分析，考虑是否对整个项目的时间、进度、成本产生较大影响
引入需求跟踪
需求分析师的技能组成
需求完成的活动
定义业务需求
确定项目涉众和用户类型
获取需求
分析需求
为需求建模
编写SRS
主持需求验证
引导用户对需求进行优先级划分
管理需求
需要的能力
业务能力
类比：以自己熟悉的业务场景对比、找出陌生的业务场景中的线索
宏观思考：有大局观意识，过于陷入细节会影响宏观理解
技术能力
溯源
分析技术的发展历史，更好的了解其作用
优缺点了解：了解技术优缺点，就能了解其局限性，正确的使用技术
沟通能力
思维模式：学会改变思维模式去锻炼沟通能力
0 条评论
回复 删除
下一页
