三、架构设计的过程
3.1 确定涉众代表
一般来讲，涉众包括客户（资方）代表、承接方（劳方）代表、用户代表。
3.2 确定系统边界
对于要明确实现某种标准的软件系统，通常确定边界非常容易，直接按标准圈定的scope分析即可，比如像SIPServlet容器，是要求遵从JSR168规范的，那么软件系统的Scope就是JSR168规定的Scope，但是也有例外，比如客户或者劳方明确指定要复用一个现有的实现了部分功能的系统或组件，那么Scope就不同了。对于没有标准的软件系统，就需要分别访谈客户代表、承接方代表确定系统边界。为什么要访谈承接方代表呢？因为承接方代表往往是劳方领导，领导肩负企业战略达成的使命，很有可能对系统提出比客户更多的要求。举个例子，某客户需要一个SIP通信协议栈，以实现三方通话的业务，但是劳方领导认为，后续ICT融合是趋势，我们构建的系统要支持ICT融合应用部署和运行，支持业务标准JSR168规范。
3.3 软件需求收集
软件需求可分为二类：
功能需求（即业务用例）：描述Actor（用户或系统）可基于软件系统做什么事，要符合什么业务规则；
非功能性需求又可分为两类：
质量属性：质量属性指软件系统的品质，可分为运行期质量属性与开发期质量属性。
运行期质量属性包括
（1）性能：性能是指软件系统及时提供相应服务的能力。具体而言，性能包括速度、吞吐量和持续高速性这三方面的要求。
（2）安全性：指软件系统同时兼顾向合法用户提供服务，又阻止非授权使用功能的能力。
（3）易用性：指软件系统易于使用的程度。
（4）可用性：可用性与易用性不相同。可用性指系统长时间无故障运行的能力。
（5）可伸缩性：指当用户增加时，软件系统维持高服务质量的能力。
（6）互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
（7）可靠性：软件系统在一定时间内无故障运行的能力。
（8）健壮性：也称容错性。是指软件系统在异常情况仍能够正常运行的能力。
开发期质量属性包括：
（1）易理解性：是指系统设计能被开发人员理解的难易程度。
（2）可扩展性：为适应新需求或者需求变化，为软件增加功能的能力。有些时候，称之为灵活性。
（3）可重用性：重用软件系统或其中一部分的能力的难易程度。
（4）可测试性：对软件测试以证明其满足需求规约的难易程度。在实际的项目中，主要指进行单元测试等难易程度。
（5）可维护性：修改Bug，增加功能，提高质量属性。
（6）可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
约束：规定开发软件系统时必须遵循的限制条件，如要基于什么操作系统，要基于什么开发语言等等。
对于功能需求，可找系统的直接使用用户代表，对其进行访谈，收集其要基于系统做的事情，可按照标准的用例模板，在访谈的过程中引导用户代表。之后，绘制业务用例视图，并针对每个业务用例，使用标准的用例模板将功能需求编档，通常叫用例规约。
对于非功能性需求，可找软件系统的涉众，依据下面的模板，引导涉众，收集其对相应质量属性的要求：
总结：本阶段需要输出业务用例视图，业务用例规约，非功能性需求。
待续。。。