能够在业务上“砍掉需求”的技术学生，应该具备什么样的六种能力呢？
我的另外两个整理：的需求回顾和设计需求回顾和分析
如何进行需求分析？ - dpdkl的答复- https://www.zhi Hu.com/question/20407032/answer/119861996
其他文档基于3360UML的需求分析和系统设计
为什么要需求评审？
许多创业公司都有一句话，没有需求评论。 很多细节只有在开发后期、验收后期才能被发现。 或者是开发和产品共同交流的结果。 此时，没有需求审查的是，开发是产品，一句话有自己的理解，同时具有修改协作成本低的优点。 再有，创业开城阶段，主要方向一致就可以了，与细节无关。 但是，不要为此给自己台阶。 前期不想弄清楚。
但是队伍长大了，关系到团队合作，而且关系到守城，不想出现问题。 前期需要充分沟通。 不仅是大方向，细节也需要双方沟通。
在需求审查之前，先大致了解一下开发，整理一下问题，但需求审查还是需要产品，然后一个人一个人说下去。 这样，开发就可以一个人一个人地思考。 而且，别人的疑问也能引出自己的想法。 确保细节在团队中得到充分挖掘，并在团队中保持同步。 特别是后期的最佳案例评论，可以帮助开发。
需求分析和需求评审是不同的。 需求分析应该由产品进行，将用户场景和需求转化为产品的需求/功能(why，how的过程如何进行需求分析？ - dpdkl的答复- https://www.zhi Hu.com/question/20407032/answer/119861996 )
什么是需求评审？
1 .感知、认知：查看产品设计，了解需求宏流程，了解用例(操作)，了解产品的ui展示(数据)。
2 .反馈：补充产品设计
为什么需要需求评审？
从技术设计的角度提出质疑，补充产品设计，避免技术task过少导致工期delay。
对于抓住主线的流程，还是陷入了正文的一些评述细节，看客自己判断
需求分析是产品的能力，但产品可能会更加关注用户场景问题，关注如何解决，很多细节闭环可能缺乏考虑。开发是细节， 涉及到项目时间计划.因此，需求评审是开发的能力，需要挖掘产品不关注细节。
开发和产品的一个很大的区别是开发关注重点，相对变细、变深。 产品考虑了不同的流程，(可惜很多产品都没有这种能力， 不能状态下的， 多用户同时，操作等case , 可能最好也不要如此， 会导致产品陷入细节. )，所以产品考虑相关变更的功能点，最好不要被太细小的枝节干扰。
在开发思维时，可以学习产品使用MECE——以相互独立、全面的思维方式进行扫描，与脑图相似，可以分层持续深入。
第一层次、人、第二层次的过程，第三层次同一过程的不同情况。
测试与产品的思维逻辑相同，但测试必须针对语言和程序运行。
前功能和后功能之间(写入、操作)的过程和过程的交错，即前行为引起后行为。 例)点餐时，乘客选择不用券，付款时不能自动绑定他。
产品描述了订单和支付两个逻辑。 输出和结果。
开发者，需要详细设计时，代金券id=-1代表乘客选择不使用代金券。 概要设计时是否需要说明
ui在各状态之间的显示方式以及发生了什么操作
写功能和查询功能之间-单人写、多人写、数据流。 页面上的数据来自哪里，哪一页上有哪些数据？ 示例：会议室日程锁定状态。 类似于电影票锁定状态。 增加这个状态后，另外一个人读怎么展示，我自己读怎么展示。
但是，过度设计：设计时不要回顾统计需求。 产品虽然关注订单时间，但有时会保存订单时间、支付时间等。
投入与需求之间权衡的注意是权衡，而不是怀疑产品的逻辑。 (也可以这样处理好与产品的关系) )一般来说，实现变得复杂，用户的操作和逻辑也变得复杂。 (这些需求往往是站在平台端引入的，也许是产品从high引入的方案) ) )。
例如，违约金和等候费。 最初，在支付了申请费后，还有一笔违约金(通过大数据安全分析计算判断用户是否需要支付违约金)必须支付。 再次打开订单状态或进入其他字段。 这样一个订单被多次支付，整个实体关系发生本质上的变化。 http://www.Sina.Cina.Cina
状态中一定不能有环回。 否则，就不能区分第一次和第二次处于那个状态。
案例2: 现金支付可以用券. 如何给司机展示入账流水和相关信息.
首先: 1.帐户变动金额要显示. 其次,显示怎么算出来的. 每个人分了多少钱. 这里面要包含司机.
代码设计上的多想一步,功能复杂性:
两个系统的状态边界要理清. 前置性条件要明确.状态要清洗.
末尾状态结束时必须要先通知下游系统生成衍生类(最好是同步调用). 有时候两个状态是独立的,大单服务结束和支付是独立的.
一切通过"版本号"的设计都是 反模式. 可以通过新版本新增support字段来实现.
状态如何设计
例如一个审批,内部有很多流程,是否需要显示给用户. 一般情况下不需要,但是饿了么/美团外卖的送货员的进度要展示给用户,避免用户等待漫长,而且快递员会和用户打交道,能感知到这个实体. 另外后台查询时,条件可能会很多. 前台的状态设计和后台的状态设计不同. 存储可能都需要备份.
怎么设计. 一般后台的需要重新拷贝一份,更甚至变成大宽表或者搜索引擎,用于查询. 还有一种呢反过来,推给C端展示,例如广告业务系统推给检索端,最终呈现给用户.
状态机最好要引入.
另外对状态的修改必须要封装成方法(分层),外部不能直接调用. Dao层的代码外部都不能调用的. java本身编译支持有限.只能通过规范和ide插件,maven插件实现.
谁调用谁由架构师决定.
思考多种设计.
1. 硬件视频会议
人扫码切换硬件入会. 一个需求两种实现方案.
1.1 硬件和人是两个uid. 但是从用户角度(需求)角度,用户其实期望"某某人通过某某社会入会",标题显示的是某某人的硬件名. 技术上可以包装对,对用户是同一个人. 如果只是从技术角度想的话,这就是两个人.
2.2 另外一个实现方式就是 硬件的uid就是人的uid. 只是在不同设备上登录而已. 动态登录,绑定的时候登录. 可能会有很多安全问题.
需求评审前做什么? 特别是跨团队. 1.先和对方沟通,对方产品接下需求,pgddlq给技术. 2. 技术初步沟通,价值上可行,方案上大概需要哪些依赖方,是否已经提供,整体排期多不多, 对出对接的技术方案,前端跨域,身份校验和系统上下行交互上可行 3.产品出马,交互ui,细节逻辑拉在一起做需求评审. 另外两篇文章:
需求拆分到设计流程总览 https://blog.csdn.net/fei33423/article/details/53351622
业务系统中最核心的状态设计,异常 case. (系统设计)
外部协作项目流程
初审
交互图,双方产品,定稿
双方技术owner初审,给出意见. (一起或者各自,有时间点,有纪要)
状态流程
各状态下的增,改,删,查交互设计.
多角色交互的逻辑.
交互和需求评审( 产品约会 有哪些角色,有哪些action,角色数(1-N 还是有限),action数(1-n 还是有限),多个角色是否存在角色互换,同角色之间,不同角色之间问题. 每个action下信息呈现是什么样的. 还有就是价值确认,这个action和信息呈现是否有意义,至于为什么要做这些信息呈现,是价值,解决的问题.在立项阶段做掉. 2.1 主流程 2.2 状态设计 ,交互也需要根据状态来画交互稿-人人都是交互师,通过不同的角色的展现需求,交互需求. 2.3 异常case 不同角色的并发冲突(例如会议预订:采用预抢占产品思路,产品交互和设计上都更复杂,还是采用后报错产品思路.),测试人员素养-人人都是测试专家)
交互图,各状态,需求评审一审(最好双方技术相关人员到场,一起评审,面基), 反馈评审意见
状态流程
各状态下的增,改,删,查交互设计.
多角色交互的逻辑.
各角色的查看逻辑
每个流程走查后的状态.
交互图 二审(如有必要)
一期角色交互不清晰
1. 业务状态不清楚,各状态的交互不清晰.
2. 交互需要定稿
技术评审( 技术owner约会 , 系统设计金字塔, 安全,稳定性等. 人人都是技术人)
出模块交互时序图,参数,字段,技术方案评审. (双方服务端,端,一起评审沟通)pc和手机技术评审分开.这个时间后,出task和时间点. 明确时间点,aone上标识总联调时间点, 服务端上线时间点,端封版时间点.变更
一旦交互主动变更,对应的时间点就需要变更,早会,钉钉popgddlq.
项目角度要求, 按迭代走:
有wiki (开发维护,需求稿 需求审批后由提供)
需求交互锁定, . 测试依赖该交互进行设计.
交互图(边界时序图),字段
接口文档,细节字段.
有时间轴.
联调时间点
发布时间点.
灰度时间点
晚会:
同步时间轴(服务端必须在场)
一起对焦现有问题
临时依赖进来的必须,添加进依赖
发布安排:
依赖方,发布顺序, 服务端灰度时间点, 全量发布时间点.