需求工程和产品工程演进: 互联网技术发展的今天，传统意义上的需求工程、需求分析师越来越被产品工程和产品经理的领域涵盖，但两者的出发点和侧重仍有不少差异！ 我们期望以更广义的产品经理的概念，补足现在某些产品人员的局限，解决和开发人员沟通和协调中的脱节gap！
Step by step: 以上是我们的实践，到目前为止，既能够帮助我们的产品/BA（Business Analysist）新人快速掌握需求和产品中的方法； 又在公司层面的沟通上，很好帮助高层管理者知道我们如何从产品角度推进公司战略，保持良好产品规划和顺畅的开发节奏！
软件架构:
不同涉众对于软件架构的视角是不同的，温昱大牛的书中提到了这个故事：
软件架构的争论
办公室里，关于什么是软件架构，争论正酣。
程序员说:软件架构就是要决定需要编写哪些类、使用哪些现成框架。程序经理笑了；
程序经理说：软件架构就是模块的划分和接口的定义。系统分析员笑了；
系统分析员说：软件架构就是为业务领域对象的关系建模。配置管理员笑了；
配置管理员说：软件架构就是开发出来的以及编译过后的软件到底是啥结构。数据库工程师笑了；
数据库工程师说：软件架构规定了持久化数据的结构，其他一切只不过是对数据的操作而已。部署工程师笑了；
部署工程师说：软件架构规定了软件部署到硬件的策略。用户笑了；
用户说：软件架构就是决定一个个功能子系统如何划分。程序员又笑了；
大家想了想说，这些架构视图好像我们都需要啊，软件架构师哭了。
......
RUP 的这个4+1视图说明了架构工作是在基于需求基础上的，针对不同情景（开发时/运行时）不同涉众（开发、配置、运维等）
的对软件系统的整体设计描述。
架构任务:
以上是温昱大牛在其《软件架构设计》一书中列举的架构设计的任务，根据实际项目需求，我们会达成如下主要目标：
- 开发人员清晰了解其框架使用，模块和类划分边界，接口设计；
- Web前端开发了解网站主体结构和页面关系；
- DBA根据对象设计，确定E-R关系；
- IT架构或运维部署，确定从源端（静态代码）到目标部署环境的设计和部署，并可以对系统扩展制定方案；
- 系统的非功能性需求和功能性需求均得到满足！
Step by step:
这个具体架构设计的步骤也是体现从总体到部分，自顶向下的设计方法。
过程中需遵守面向对象设计的那些原则，SRP、OCP、LSP、DIP和ISP，同时避免过度设计。
Note:我们的一个体验是，面向对象的设计需要从产品经理做起，否则会产生很多的Gap！