系统构架设计时应考虑的一些必要性因素[2]

　　模块构架设计可以从程序的运行时结构和源代码的组织结构方面考虑。

　　1、程序的运行时结构方面的考虑：
　　1） 需求的符合性：正确性、完整性；功能性需求、非功能性需求；
　　2） 总体性能（内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响）；
　　3） 运行可管理性：便于控制系统运行、监视系统状态、错误处理；模块间通信的简单性；与可维护性不同；
　　4） 与其他系统接口兼容性；
　　5） 与网络、硬件接口兼容性及性能；
　　6） 系统安全性；
　　7） 系统可靠性；
　　8） 业务流程的可调整性；
　　9） 业务信息的可调整性
　　10） 使用方便性
　　11） 构架样式的一致性
　　注：运行时负载均衡可以从系统性能、系统可靠性方面考虑。

　　2、源代码的组织结构方面的考虑：
　　1） 开发可管理性：便于人员分工（模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响）、利于配置管理、大小的合理性与适度复杂性；
　　2） 可维护性：与运行可管理性不同；
　　3） 可扩充性：系统方案的升级、扩容、扩充性能；
　　4） 可移植性：不同客户端、应用服务器、数据库管理系统；
　　5） 需求的符合性（源代码的组织结构方面的考虑）。 

　　三、程序的运行时结构方面的考虑：

　　1、 需求的符合性：正确性、完整性；功能性需求、非功能性需求软件项目最主要的目标是满足客户需求。在进行构架设计的时候，大家考虑更多的是使用哪个运行平台、编成语言、开发环境、数据库管理系统等问题，对于和客户需求相关的问题考虑不足、不够系统。如果无论怎么好的构架都无法满足客户明确的某个功能性需求或非功能性需求，就应该与客户协调在项目范围和需求规格说明书中删除这一需求。否则，架构设计应以满足客户所有明确需求为最基本目标，尽量满足其隐含的需求。（客户的非功能性需求可能包括接口、系统安全性、可靠性、移植性、扩展性等等，在其他小节中细述）

　　一般来说，功能需求决定业务构架、非功能需求决定技术构架，变化案例决定构架的范围。需求方面的知识告诉我们，功能需求定义了软件能够做些什么。我们需要根据业务上的需求来设计业务构架，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的技术构架要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个构架的范围。（此段From林星）

　　这里讲一个前几年因客户某些需求错误造成构架设计问题而引起系统性能和可靠性问题的小小的例子：此系统的需求本身是比较简单的，就是将某城市的某业务的全部历史档案卡片扫描存储起来，以便可以按照姓名进行查询。需求阶段客户说卡片大约有20万张，需求调研者出于对客户的信任没有对数据的总量进行查证。由于是中小型数据量，并且今后数据不会增加，经过计算20万张卡片总体容量之后，决定使用一种可以单机使用也可以联网的中小型数据库管理系统。等到系统完成开始录入数据时，才发现数据至少有60万，这样使用那种中小型数据库管理系统不但会造成系统性能的问题，而且其可靠性是非常脆弱的，不得不对系统进行重新设计。从这个小小的教训可以看出，需求阶段不仅对客户的功能需求要调查清楚，对于一些隐含非功能需求的一些数据也应当调查清楚，并作为构架设计的依据。

　　对于功能需求的正确性，在构架设计文档中可能不好验证（需要人工、费力）。对于功能需求完整性，就应当使用需求功能与对应模块对照表来跟踪追溯。对于非功能需求正确性和完整性，可以使用需求非功能与对应设计策略对照表来跟踪追溯评估。

　　“软件设计工作只有基于用户需求，立足于可行的技术才有可能成功。”