Guiding principles of our business model

  • Our belief that Analysis, Design and Development of systems is all about common sense , rigor and discipline.
  • The more complex the system the more is the rigor and discipline needed to manage the complexity.
  • Every system in this world irrespective of the domain fundamentally is all about structure and behavior.
  • Basic engineering discipline and common sense is something which most of the software professionals fail to use.
  • Systems Analysis and Design is a task which doesn't need brilliant and genius professionals.
  • According to us the task of requirements gathering and analysis can be performed by trained and disciplined young graduates with the right attitude.
  • There is no excuse for not gathering the requirements, analyzing and designing the same irrespective of the scale and complexity of the system.
  • We believe lack of engineering discipline is something which is missing in the existing software industry.
  • Requirements Gathering and analysis is more of a detective job which needs a lot of rigor and discipline. I feel the job is more like a cops job. Every day he deals with a new case , he doesn't say that this case doesn't belong to my domain. His job is to first gather whatever data, facts and evidence available either by interrogating the people or by visualizing the fact . Once the information is gathered , he is supposed to analyze all the data and facts which will lead to a lot many queries. In this case the data collected and analyzed will give a lot of clues for the next set of information to be found. I am just trying to show the similarities.
  • More than Domain Knowledge , Requirements gathering and analysis needs a lot of discipline and engineering tools.
  • We have developed a lot of best practices and tools using which we can analyze and design systems in a domain independent manner.
  • The first thing that we teach in our trainings is for anyone to be a good analyst or a architect or a designer , domain in which the system lies should not matter as every system in this world is just structure and behavior.
  • I am not saying that Domain Knowledge/ Domain Experts are not needed , it is always good to have with them but Domain Experts who are undisciplined and dont approach the same in a structured/ engineering way can also be of little use.
  • Even if a person is a Domain Expert ... there are certain human limitations if not taken care of will not improve the situation irrespective of the domain expertise.
  • There should be a difference between Domain Expert and analyst.
  • Domain Expert is as good as the customers representative on our side and he typically faces the same problem as the customer. Domain Expert without analysis expertise is as good as a customer and he faces the same limitations as the customer.
  • Domain Expert might not be an analyst.
  • Analyst might not be a domain expert.
  • The job of the domain expert is to assist the analyst and the requirements gatherer.
  • It is better to have all the three roles to be separate.
  • Most of the time all the roles are played by a single person. It is quite possible that most of the people doesn't understand and appreciate the difference between the three roles.
  • An analyst is a person who is an expert in analyzing complex systems using the standardized modeling language and its best practices defined by that stream of systems engineering. He is also a person who is supposed to use engineering tools , techniques and best practices to deal with the complexity associated with complex systems.
  • There is no stream of systems engineering which was managed complex systems without analysis, analysis models, modeling tools, standardized modeling language, engineering techniques and best practices.
  • Then how is possible for software industry to deal with complexity of information systems without analysis and engineering best practices.
  • According to me if I want to blame anyone in this industry for the current mess , for me it is the Analyst. If analyst was using a bit of his engineering skills a lot of things can be plugged at the analysis stage itself.
  • We have developed some technique wherein just by looking in the domain model we can suggest the behaviors /functionalities that are possible in a system irrespective of the fact whether the customer is giving his requirements or not.
  • In our requirements engineering system we have exploited certain basic properties of a system using which we can validate the requirements of a system in a domain independent manner. To many this itself is unbelievable as to how can the requirements be validated in a domain independent manner.
  • I always teach that first thing that any analyst or a designer needs to understand is that systems are highly complex and we as human beings have certain limitations and hence the first discipline is dont make your brain do one thing at a time.
  • Analysis is mostly missing , I can very safely say , atleast in India 95% of the software engineers doesn't understand the difference between analysis and design.
  • 70% of the software professionals dont know what is UML
  • 25% of them who know UML doesn't know why is it needed and what do they get by it ?
  • Atleast this is the situation in India
  • Knowing the syntax of UML is just 5% of the Job.
  • The actual 95% is knowing the best practices of using these UML diagrams to analyze the complexity of a complex system which has not been documented in any of the books.
Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer