Requirements and Synthesis
Getting requirements right is the first step in the journey of creating a successful software system. The job of defining requirements is an exercise in design and in problem solving. Analysis is often used in the context of requirements and the people who describe a software requirement often carry the designation of an analyst. Like all aspects of design, synthesis is as important to getting requirements right as analysis is. Surprisingly however, one seldom hears the term synthesis used in the context of requirements design and the lack of synthesis leads to many a requirement going awry.
While analysis is the process of breaking something down into its parts and seeing how the parts work, synthesis is what gives one the bigger picture and the role the system being designed is to play in the context of this bigger picture. Analysis and synthesis work together in design but to me synthesis comes first.
Russell Ackoff describes synthesis and analysis as ways of thinking. Both involve three steps:
- In analysis, something that we want to understand is first taken apart. For instance we could take an ERP system that we are defining into modules for material management, production control, finance management and so on. On the other hand, in synthesis, that which we want to understand is first identified as a part of a larger system. The ERP system is a part of a larger system – say the manufacturing organization that needs to use it to manage its operations and resources
- The second step of analysis is to make an effort to understand the behavior of each part taken separately. In synthesis, an effort is made to understand the function of the larger system of which the system we are working with is a part. So we would as part of analysis look at each module independently but as part of synthesis understand the functions of the manufacturing organization
- The third step of analysis is to aggregate the understanding of the parts of the system in an effort to explain the behavior of the whole. In synthesis, the understanding of the larger containing system is disaggregated to identify the role or function of the system to be understood.
This gives us an extremely important insight – analysis of a system reveals its structure and how it works. It does not give us an understanding of what it is expected to do – its behavior and function – as part of the larger system that it belongs to. This understanding can come only from synthesis.
Most often, when we start defining the requirements of a software system, we lose the “system” perspective and think about only the software application being built. In my experience, this is a sure fire method of missing out on vital aspects of the applications quality. The synthesis exercise puts the application we are building right there as a part of a bigger system thus ensuring the systems viewpoint is not lost. This viewpoint is so extremely critical because the supportability needs of the application we are building is provided via this viewpoint. Synthesis provides a more complete perspective about the following:
- Users, usage patterns and expectations – A typical analysis exercise brings the users who interact with the application as part of its operations into focus. So if we were building a system for inventory control, our focus would be on the inventory managers and the operators within a warehouse. The synthesis exercise however tells us that this piece of software is part of several other eco-systems – for instance a datacenter in which it is hosted, a part of a larger supply chain management system, a critical element of business planning functions and so on. It also brings out several other nuances such as the system needs to be maintained and upgraded over time; it needs to be audited as part of the larger financial accounting process; while the inventory managers and warehouses work on a 9 to 6 basis, the ecommerce system queries it and blocks inventory on a 24×7 basis and so on. While the more “business” needs do get addressed in most requirements, the subtler ones specific to management, auditing etc often get missed out and are bolted on later.
- The overall operational context – the other systems that this is a part of brings out specific needs of integration as well as expectations of performance, reliability and stability. In fact as more and more business processes are “composed” on top of a set of applications, the silos between applications are rapidly breaking down. Viewed at from the process perspective there is an underlying fabric of application services that can be composed to create a business process. Building applications that are part of this fabric without taking into account the needs of the fabric as a whole is I presume an evidently bad idea
- The timeline and lifecycle of the application – moment the application is considered as a part of a larger system, decisions on the lifecycle of the application – when can it be put into production, turned off for maintenance or replaced with the next version of the application get pushed up because of a larger set of dependencies. The criticality of an application can only be gauged in the context of the larger system it belongs to. Understanding this perspective and how the larger environment is impacted by the lifecycle of the application is a key input to design. Synthesis also brings out the view that a good part of the application’s life has got software developers as the primary users of the application, either in development or maintenance mode. When was the last time we thought of building tools, code snippets or even documentation for our fellow developers from this perspective?
- The standards the application is expected to adhere to. Information systems are increasingly forced to adhere to a larger set of standards and regulations ranging from IT policies, security standards, operational procedures, compliance and control procedures and so on. I have gone through the rather embarrassing experience of having to pull a software system back into development from the verge of going into production because “no one ever told me” that the IT standards demanded automated installation with a complete audit trail of every change made to the application – “you mean you never read the IT standards manual?”
- Synthesis also allows you to define crisper definitions of SLA commitments your application must keep. Rather than arriving at arbitrary numbers for say the response time of a query or the size of records to return understanding the context in which the query is used and the performance demands from that context serve as more concrete guideline. It is a fact that SLA definitions are moving from being bottoms-up to being top-down. SLAs are now being defined at the level of business services and are flowing downwards to the other parts of the system that render this service. The storage requirements for an encrypted auditing system you are building for a bank could well be defined by a BASEL-II definition implemented by the bank that states that all customer information must be stored in an unmodifiable format for say 6 years. If the bank states that its processes and services are BASEL-II compliant, then sure enough your storage SLA has just got defined.
It may seem to many of us that these perspectives got from synthesis would be uncovered as a part of requirements analysis in any case or even that this is information that we would get from users or business analysts. However this view is not true. Users or business analysts focus on specific aspects of the application and its functionality and have very seldom any idea about its operational context. Further, once you get into the analysis mode – you have started drilling down into the parts of your application, you are lost in entities, attributes, relationships and events. As part of this process, you are not going to encounter the rest of the system that this is a part of. Synthesis hence must be a conscious part of requirements definition and not something you stumble on by accident. At the same time, there is often a legitimate fear of getting lost into a study of a higher system and then a still higher system and so on. What I do is to use the perspectives above to act as a guideline for me to understand the larger system. Once I have got enough answers, I move on to analyzing the requirement. I periodically take a step out from the analysis and kind of adopt a birds-eye view looking for discontinuities or a lack of harmony with my view of the larger world and then proceed with analysis if I don’t find any.
