基于自己的实际工作流程，对功能（主要基于已有产品进行功能的扩展）的整个生命周期的梳理如下。欢迎大家分享自己的想法，一起学习交流。
一、需求的出现
-
需求输入
新的需求，由需求负责人加入需求的Backlog中，定期有同步会议将需求指派到某个系统设计师。
这些需求主要来源于真实客户，或负责整理需求的团队根据市场情况分析得出。
-
注意点
- 系统设计师需要了解需求的来源，尽可能多的了解需求的背景信息，这些信息会让自己对功能的优先级有初步的判断。因为一个系统设计师可能会同时工作在多个不同的任务上，新需求的加入，需要调整任务顺序。当然，后续也可能根据实际变动更新需求的优先级。定期会有针对整个需求Backlog的同步会议，主要为了需求负责人与系统设计师的信息互通，如新需求的加入，已有需求优先级的变动。
- 从需求负责人确认需求的细节，将其作为技术分析的输入信息。当然，这个时候的需求不一定是最终版本，后续通过系统设计师的技术分析，可能发现某些细节从技术上不能或难以实现，和需求负责人确认后，可能会被移除或更新。也可能由于市场变动，需求被相应负责人取消。难以实现的情形，如团队的技术储备不够，或者需要的成本太大不可能被相关负责人接受。
二、技术分析阶段
-
输入
指派的新需求，需要实现的功能（不仅限于功能开发，也可能是一些其他工作，如支持其他团队做一些验证支持）。
-
输出
- 计划什么时候呈现该需求的技术分析报告。
- 同步会议后，系统工程师通过分析得出大概时间后，通过邮件告知（邮件主要为了有一个正式记录，便于追溯）。
- 或者，经过分析得出大概时间后，可以在下一次同步会议上说明更新。
- 技术分析报告，即Technical Analysis(TA) Report。TA报告主要包括两方面：
- 该需求从技术层面能不能实现。
- 能实现的话，大概需要的Cos。这个时候的Cost是一个大概的量级，如500mhours，1000mhours。
-
注意点
- 基于需求的细节并结合自己的经验，整理出TA Report的大概时间计划，如发生在Week14，给相关的Stakeholder一个大概时间。自己需要对TA Report前的整个时间进行时间段划分，如Week09查看技术资料，Week10~Week13也技术人员讨论和调查，Week14准备TA Report。
- 从技术层面确认需求是否可实现，能实现的情况下需要多少Cost的（大概给一个初期估计的量级）。当然这个Cost后续可以根据实际情况更新，正常情况下这个更新的量级差距不能太大，如果太大，需要很Strong的理由，得到相关Stakeholder的认可。
三、可行性分析阶段
-
输入
TA Report。
-
输出
- 计划什么时候呈现该需求的可行性分析报告。
- 可行性分析报告，即Opportunity Analysis(OA) Report。字面意思的话，更多的是机会分析，但这个术语应该是对需求负责人更实用，他们需要考虑市场的机会。但对系统设计师来说，可行性分析可能适合。
-
注意点
- 这个是一个粒度较粗的分析过程，可以提供多个可实现功能的方案，并给出各个方案的优势和劣势。可以结合自己的经验和团队实际情况，给出建议的方案。
- 可行性分析报告，主要内容包括：功能实现的必要描述、收益描述、功能实现的原理、功能的技术复杂度、影响整个产品的哪部分、功能验证的影响、是否依赖其他功能的实现等信息。
- 这个过程可能需要软件架构师或者软件开发工程师的支持，因为整个产品可能有很多模块，很难做到了解每个模块的技术细节，自己分析的话可能难以在一定时间内给出结论。
-
其他
- 之前作为软件设计师的时候，考虑的点大概只有：功能实现的必要描述、功能实现的原理、功能的技术复杂度和功能验证的影响。其他点都不会去考虑，其它点的考虑算是一个面的扩展。
四、预研究过程
-
输入
OA Report。
-
输出
Pre-Study Report，详细的预研究报告。
-
注意点
- 基于OA推荐的方案，进行更细节的技术研究，给出较详细的技术文档描述。相对OA阶段，这个过程针对推荐的方案，进行的是更细节的技术分析，细化粒度是具体的软件模块。
- 梳理整个功能需求的实现，不是该阶段结束的必要条件。只要有一个完整的Solution Package(SP)或Preliminary User Story，就可以让其进入PD阶段，避免Team资源的空置。
- 这个阶段不能以软件设计师的侧重点只考虑实现阶段，还包括Cost，收益，可验证性等方面。
-
其他
这一过程，我的理解，对系统工程师来说是其中重要的一环。需要提供较详细的实现说明，指导实现团队进行具体的工作，如何开发，如何验证等。根据计划，Stakeholder什么时候需要验收功能。
准备用单独的文档详细描述这一阶段。
五、实现阶段
-
输入
PSR。
- 输出
功能实现，项目得到交付。
- 注意点
- 这个实现阶段，不只是软件层面的功能实现，还包括功能验证，项目验收等过程。
- 为开发工程师提供必要的支持，技术，协调资源。
- 实现阶段，一些重要点的审核工作。如，审核实现团队对系统文档的更新，确认验证报告的结果符合期望等。
- 相关的会议，如该功能的验证Case是否需要加入到Legacy体系中，作为日常验证的一部分。加入到Legacy体系这个动作，就是关注功能整个生命周期的一个动作（在软件工程师的角度，这部分工作一直被弱化），这个动作更体现在后期维护阶段。防止后续功能开发影响到该功能等情况，出现问题时可以及时发现。
- 支持和协调实现团队，向Stakeholder进行功能的验收。
六、项目的发布
- 实现的功能，按照整个产品的发布计划，按季度，半年等周期进行发布。 这个过程，系统工程师需要提供当前功能的必要信息，记录到整个产品的发布信息中。
- 实际工作中，这个过程和系统设计师没有直接联系。写在这里是为了体现需求的整个生命周期。
七、后期的维护
- 在后期维护过程中，出现与该功能相关的问题，需要从系统设计层面提供支持，解决问题。
