The way things are and requirements gathering.
First off is an architect responsible for uncovering all requirements including requirements that were withheld for a reason?
The process to gather requirements Ii n and of itself can be flawed. That is the risk for the architect. The gathering process for requirements may be flawed. There are many architects who then fall back to use cases. Everything becomes a use case. That is also a flawed model. Requirements should always drive use cases. But use cases should always exceed requirements.
Conceptually let’s take a 1960’s mainframe and pull it into the 2010 time period. Would the original requirements for that system include remote computing? Remote computing at the time of the requirements gathering would have been tethered to a terminal. Modems and dial in connections don’t really start appearing until the 1970’s.
This is not a future requirements gathering blog. There is no intent to say architects should in fact be responsible for future proofing their solutions. Rather that when gathering requirements consider what they will look like in different environments.
A thought experiment for Software Architects where we take the known (requirements) and the known (current state of technology and of the deployed technology from where we gathered the requirements) and create an initial roadmap.
The first thing to do is assess the environment (technology deployed) where the requirements were gathered. You then have to evaluate the actual requirements process to determine are you considering the right things. Let’s call this phase “conceptual environment.” Why is it important to consider not only the reality of the requirements but the environment they come from? It is as a friend of mine always says “the art of the possible.” But in this case it points to what people think is possible as well. Not just what could be done in a green field but what has to be done in a brown field.
Once we’ve determined the reality of where the current concept state is we can now evaluate the overall requirements. If the organization is struggling to adopt and embrace new technologies a wholly new solution won’t help them. Over the years organizations trend towards models of technology deployment. Some companies are on what we call the leading, bleeding or cutting edge of technology. They move to new solutions very quickly. Requirements gathered in an organization can actually be shorter future looking because they embrace technology and move if the market shifts. Companies that are slower to embrace new technology actually need requirements, use cases and solutions that are 3-5 years ahead. It takes them time to get where they are going.
In terms of requirements you can see that the first organization what Gartner used to call Dynamic will have requirements that are pretty closely mapped to organizational capabilities and will allow you, the architect to look ahead easily. The second organization will struggle to see anything beyond what they have. This as Gartner called them Basic organization needs requirements gathered from the current state, and then a very long look forward. Not just the art of the possible at that point. Now it is the art of what is needed.
Can you imagine designing a green screen application for a cellular device?