1. 泳道职能+阶段流程图，可以让他人清晰知道流程如何运转。
2. 描述报表需求时，可能包括如下内容：业务背景、过滤口径、名词解释（通过解释生僻名词，下游更容易理解需求）、涉及到的表的主体关系、统计口径、保留位数、排序条件等。
3. 通过规范“需求控制标准化”，可以降低需求风险。内部定义的需求控制标准化主要包括：承接需求范围及文档要求、升级专家评估流程、决策处理流程，通过明确规范降低需求沟通和交互内耗，提高协作效率。
4. 使用统一语言描述，能够提高工作效率，如采用的统一语言能够模板化或工具化能极大提高工作效率。
5. 列表分为：常规列表、可编辑列表、主从列表、树状列表。
6. 偏技术性需求可由开发前置，由售前配合开发收集相关业务信息。其他偏业务性需求，由售前（一线）收集需求。
7. 描述需求需包括内容：业务背景（通过业务背景描述能够清晰获悉该功能解决客户什么问题或达到什么目的）、业务流程图（客户实际业务是如何流程的）、业务场景（在每个环节什么角色通过输入什么内容做什么操作输出什么）、ui+功能描述（结构化语言来描述该需求如何从系统层面实现来满足功能）、数据结构（表物理结构，以及表之间关系）等。
8. ui控件测试：比如文本框控件，首先分析控件基础属性，然后分析控件业务属性，然后分析该控件关联影响点。
基础属性：比如控件长度、录入数据类型、不允许录入长度；业务熟悉包括：默认值、是否必填、是否允许录入重复值；关联影响点：比如同系统中同一字段应保持一致、数据库字段长度和页面控制长度一致等等。
9. 页面通常分为：列表页面、编辑界面、选择界面（比如邮件选择发件人所打开页面）、其他界面。
10. 列表页面测试思路：
整体：页面整体布局；
局部：将页面拆分成小区域，针对每个小区域进行分析。
静态：页面初始展示（页面展示项、默认值、选项值、按钮、列名、列标题等）；
动态：选择不同选项，页面的刷新；各种操作（查询、按钮操作、列表操作）等；
从左到右，从上到下：属于常规的操作习惯，按照一定的顺序至少测试时不会一会东
一会西。
具体操作：列表操作、按钮操作。
有场景要细分：数据场景、操作场景等，如列表中有数据/无数据的
展示、操作，有关联数据/无关联数据的删除等。
有组合要考虑：将拆分的区域合并考虑，如果存在组合的情况，那么需要考虑典型的
组合，如组织架构、视图、查询条件的组合。
11. 制定开发工作规范目的：提高开发协作、提高可读性、可维护性，主要内容包括：js编码规范（命名规范、代码编写规范、注释规范、变量使用规范、函数使用规范、功能设计规范（图标使用规范、提示信息使用规范、文件和文件夹命名规范、逻辑流程规范、界面整体规范、数据样式规范等）。
12. 梳理和维护开发常见错误，可规避开发编码错误（比如代码块中有debug、alter(0等调试语句）导致的低级问题。
13. 在解决问题时，首先分析冲突点：问题责任人不明确导致相互推脱、解决方案或方法不明确（目前资源水平解决不了），然后再来确认问题、解决问题，在解决问题过程中可能会运用到制定的相关标准、要求。
14.系统分析主要包括2个部分：系统分析和设计阶段，系统分析主要是进行流程分析、实体分析、关联影响分析，工作量估算等工序，系统设计主要是进行ui设计、功能点设计、数据库设计等工序。
a. 流程分析又分为业务流程和系统流程分析，业务流程分析主要是分析who“when“why“what“where，谁在什么情况下，需要什么前置条件，然后做什么事情，输出了什么结果。系统流程分析主要是满足业务流程，分析部分或全部信息化管理，提高业务流程执行效率，降低管理成本。
b. 实体分析：通过理解需求，理解业务术语，弄清业务实体将关系，指导后续关联性分析和数据库设计。
c. 关联影响分析：通过分析理解需求对现有业务或代码的影响点，保证需求完备性。
d. ui设计：保证符合产品设计风格“保证符合平台控件要求“保证符合客户要求。
e. 功能点设计：保证开发对功能点取数、ui控制、操作控制、数据流、复杂算法等方面比较清晰，提高开发效率。
f. 数据库设计：设计库设计规范、典型案例设计，保证最终提交高性能系统给客户。