Software Architecture and Feasibility

The following situation is well known. (Too) many requirements are compiled by the stakeholders of a software project. Everybody wants everything in terms of features and functionalities performed by the software product that should be called “monkey wrench”. It’s not possible to say simply yes or no about feasibility just from reading the requirements. Beside the fact that we all adhere to the KISS-rule, a well documented architecture can help to understand the intended solution and to identify contradictions in the requirements. Just one example: some requirements might ask for client implementations based on key features like high availability and a rich feature set in terms of user interaction. On the other hand, requirements coming from another group of stakeholders may request communication technologies and strong perimeter protection that will never support the features requested for the clients. A well-documented software architecture that encompasses different views of the software product can help to detect such contradictions early enough. Experts from different domains - say network, application server, and security, can use the architecture to assess the outlined approach. And even for the folks requesting all the important functions, it might be helpful to see their product in a very early state (with the chance to reconsider some decisions).