如何澄清“一句话需求”?
发布于 2024-10-01
1911
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
一句话需求描述的情形及问题概述
项目描述系统需求时,常通过一句话需求来概括。这些需求可能包含一个或多个功能,功能的业务逻辑,功能的细节要求,或功能与处理逻辑的组合。
一句话需求的类型与案例
- 单一功能描述(例如,通过邮件发送发票)
- 功能组描述(例如,手工录入、批量删除、导出、导入等)
- 功能的业务逻辑(例如,权限控制限定的台账初始化)
- 功能的细节要求(例如,录入单据时提供供应商信息帮助)
- 功能与处理逻辑组合(例如,自定义审批流程,审批完成后台账信息生效)
一句话需求中的常见问题
这些需求描述可能存在问题:数据对象不全、数据属性不全、缺少业务逻辑的详细描述,或层次关系混乱。
- 数据对象不全(例如,台账包含多种类型,各自有不同数据项和处理逻辑)
- 数据属性不全(例如,自定义查询条件中关键字段不明确)
- 缺少业务逻辑详细描述(例如,入库单导入功能时的合法性判断规则)
- 层次关系混乱(例如,功能的辅助特性与主要功能的并列问题)
澄清一句话需求的问题
为了澄清这些需求,可以针对名词、动词、副词与形容词、量词提出一系列问题。
- 名词:涉及具体含义、子类、属性、取值范围、缺省值、空值、数值精度、输入输出格式、同义问题、出现频度等。
- 动词:具体含义、分支场景、处理规则、人机交互序列、处理数据、同义问题、功能还是处理逻辑、从属关系、执行频度等。
- 副词与形容词:是否可以量化或删除。
- 量词:数值大小的合理性。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1254.3K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
小概率事件实际不可能原理在软件量化管理中的应用
1 小概率事件实际不可能原理的含义小概率事件实际不可能原理,即:(1)小概率事件在理论上有发生的可能,但是在某次实际的实验中实际是不可能发生的,一旦真发生了,一定有其特殊的原因。(2)如果我们重复无限次的实验,则小概率事件一定会发生。在概率论中,我们将发生概率很小(通常不超过5%)的事件称作小概率事件。人们对待小概率事件有两种截然相反的态度:2 识别小概率事件的方法 (1)箱线图法:处于内围之外的
漫谈需求与设计的区别:做什么与怎么做
2009年曾经写过一篇博文,讲述需求与设计的界线(参见博文:https://blog.csdn.net/dylanren/article/details/4965181),最近又有所思考,对上篇博文整理补充如下。 首先我们从两个日常生活的例子思考一下: 案例一:DIY一台PC。 概要描述...
再论:是否一定要做规模估计?
举个例子: 2009年1月1日,张三站在你面前,让你估计体重,你已知的确切信息是:张三是男士。根据你面前张三的形象,你估计其身高约在1米七五,看上去张三有点胖,比较结实,因此你估计张三的体重为75公斤。估计体重是你的目标,在估体重之前,实际上你先估计了张三的身高、胖瘦程度、结实程度。 2009年2月1日,你又见到了张三,让你再次估计体重,同样你已知的确切信息是:张三是男士。根据你面前张三的
为什么必须首先做规模估计?
这个问题客户问过我,我也解答过多次,但是我一直没有更直接的理由说服我自己,认为必须先做规模估计再做工作量估计。 比如:对维护类的项目,或者是维护类的活动,为什么要估计规模呢?项目组的人没有技术风险,对需求很熟悉。 我总结了如下的理由: (1) 以规模来估计工作量与成本 (2) 规模估计与实现的人与技术无关,比较客观 (3) 可以度量项目的开发效率:规模/工作量 (4)
白话SCRUM之五:四种会议
在SCRUM方法中定义了4种会议活动: Sprint planning Daily meeting Sprint review Sprint retrospective 除去开发活动外这4种会议构成了scrum方法的核心活动。 这四种会议的要点如下:
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线