Requirement Analysis Phase, The New Paradigm
Remember we talked about "the" contracts. A contract is actually the story telling part of a use case, the text definition about Ins and Outs of that use case and pre-post conditions determine mostly the way use case is getting "used" or "extended" to connect the dots to other use cases.
Here is the 1st serious job of getting started with Analysis Phase, the new paradigm - See the pre-post conditions as what defines the interfaces. These interfaces could be as simple as function to pass variables or a sophisticated AI App! Let me explain it before it gets more complicated ...
Remember how business rules and entities made the core of the contracts. In order to have a set of business rules work together in different contracts - we need to connect the dots scientifically - these dots have preliminary set of hardware and software conditions to be met in order to work.
Because we are dealing with
- The dots that connects the business rules of natural environment
The dots that connects the business rules of built environment
- The dots that connects the business rules of Iranian people water centric framework
- The dots that connects all the above together
Remember I said before that we already have large data, related to our program that are not organized and/or not set in a format useful as a proper requirements - we have them ready now! We have to be able now to define the pre-post conditions of contracts the way they can define the import / export data (entities) to be set with the dots that connects relevant business rules in the use cases. This includes the complete determination of boundaries, spaces and auras that will contain them!
Middleware capability management during Requirements Analysis phase
Here it where the Infrastructure Architect gets into the serious Middleware work during the Analysis Phase based on the prediction of data transfer on each use case / contract. Oh yes Middleware now! This is the time, not during the design or implementation, or testing phase! I don't have to remind you, we have done the "cost driver" value assignments already!
Now, it doesn't hurt to go through the middleware capability management phase to handle the requirement analysis based on what we already have. Middleware is the software layer that lies between the operating system and the applications on each side of a distributed computer network. Typically, it supports complex, distributed business software applications. Remember we are at age of Big Data and The Advanced Technology Transition Models Rule!
Technology transition model applies during the "Requirement Analysis" phase - very important
These models attempt to explain the mechanisms that cause a group to become self-sustaining technical coordinators of different technologies to work together. Remember I mentioned the Software Architect who makes a note about the usage of software patterns based on the entities and business rules, the scientific dots connection that determine type of pattern to be gently applied to the code later, He or she is going to make decision with the Infrastructure Architect to define the type of the portions of the Middleware layers.
They already have the boundary, space and aura by which use cases are located. They need to answer vital technology transition questions that relates to the boundaries, spaces and auras.
- Does this use case needs to be run in an in-memory platform!
- Does this use case needs to be wireless platform enabled!
- Does this use case needs to be supported with replication servers!
- Where does the heterogeneous environments overlap which boundaries!
- Does the space should be defined virtual over this or that boundary or it is a set of business objects in the framework to be grouped in a specific on-premise aura! etc.
After giving answers to the most high priority questions - we have the LAYOUT where the use cases are located based on the infrastructure they rely upon to be processed accurately with minimum change in future to start the designing diagrams - some prefer to get started directly with the CODE. Just a matter of the taste of that IT department or talents available in the Networked IT structure. Things are getting more straight forward now!
You may ask what was the deal with the traditional "bottom-up", we got there by the Technology Acceptance Model, or "the" user acceptance model, which is already tested at the end of the requirements gathering phase, the very beginning of the requirements analysis. I will explain this better.
To be continued in part 7