Separating analysis from design
(decide what is needed before deciding how to implement it)
Successful projects solve business problems
Seeing what business goals you’re trying to meet before jumping into technology allows you to use technology wisely, manage scope and reduce costs, producing systems that work for your customers.
It’s easy to focus on the technical features of any project and lose sight of why you exist. Every project exists to solve a problem. Either what you have doesn’t work well enough and needs to be improved, or you need to invent something totally new. After all, “if it ain’t broke, don’t fix it.”
Too often, the pressures of deadlines and budgets cause us to bypass the important process of analyzing business needs and jump right into technology. But how often do we find that the system does not do exactly what is required. Users are forced to use workarounds, which reduces some of the benefits we were supposed to provide, which also affects our credibility. How often do we need to invest additional time and expense to provide Version 2 (and 3 and 4 and…), when careful work could have exposed the real needs sooner?
The classical life cycle of the waterfall
There are many variations on the System Development Life Cycle (SDLC) and the following may not be exactly the terminology your methodology uses. The content of the phases is certainly simplified in this table, but the projects follow the following phases:
(IMAGE NOT AVAILABLE HERE – you can download this complete document with illustrations of [http://www.irm.com.au/businessanalysispapers.htm]or see the image in [http://www.irm.com.au/images/waterfallcycle.jpg])
The output of each phase is the input of the next. Garbage in garbage out. Or to put it a little more elegantly, you can’t make a silk bag out of a sow’s ear. You can’t implement a good operating system without a good proven system, you can’t build a good system without good technical specifications, and you can’t design a good system without a good business specification.
Make sure that talented people are used at the beginning of your project, to ensure that you can achieve a good result at the end.
Don’t be fooled into thinking you’re doing someone a favor by skipping business analysis and going straight to design, or by combining the two. If the time frame is tight, negotiate a phased implementation. If the budget is tight, remove some functionality.
Many surveys, including Boehm’s work, have consistently shown that the increase in the cost of fixing bugs increases exponentially the later the fix takes place in the SDLC. A bug that costs $1 to fix during the startup phase will cost $10 if left until analysis, $100 in design, and $1,000 if nothing is done until implementation. However, how often do we say “We can fix that in code”?
Software tools can’t do the thinking for you
Would Shakespeare have been a better writer if he had had a word processor?
Any tool will believe what you tell it. There are some great tools out there that will take the pointless hacking out of his job so he can focus on doing what he does best. But don’t think that if he has the best possible tool, his systems will be the best possible. If you don’t believe me, grab your favorite word processor and write a sonnet that people will be happy to quote 400 years from now.
You still need to do your own thinking. That’s what business analysis is all about.
Separate business analysis from technical design
Business analysis is about thinking about what your solution should do, while design is about how to make it happen using available technology. With this in mind, it will be easier to avoid mixing these two phases. What Y How. This will help you build more robust systems.
What your business does doesn’t change as much as how it’s done. Technology changes faster than business needs. Companies restructure. But what they do hasn’t changed, just which individual does it. Business analytics provides a logical view of data and process needs and is not tied to physical implementation.
IT specialists and business users regularly complain about their misunderstandings. Of course they don’t understand each other. Technicians care about making the best use of their technology, users care about achieving their business goals. Business analysis should bridge the gap perfectly.
The Terms of Reference produced during the Initiation phase must include, without ambiguity, the Problem to be solved, the Objective to be achieved to solve that problem, the Constraints and the Scope.
The purpose of business analysis is:
Business analysis techniques.
To dig deeper into problems and find solutions, many techniques are used that are beyond the scope of this document. They include carefully structured interviews, document gathering, brainstorming, risk analysis, cost benefit analysis and many more.
business analysis tools
Only four tools are needed for Analysis: two for Processes and two for Data.
For processes, the data flow diagram (DFD) shows the business processes in a system and their connections to each other, while the business specifications show the business rules for each process. For data, the Entity Relationship Diagram (ER Diagram) shows the things that need to be stored from a business perspective, and the Data Dictionary details the specific elements (fields) required for each entity and their connections to the data flows in the DFD.
The purpose of this article is not to show how to build these models, but rather to demonstrate the importance of their use in a business model rather than a technical model.
Any idiot can draw an ER diagram.
This is true, but the quality of the resulting model often leaves much to be desired. Reflect business needs in the model and leave nothing to chance. Be careful with things like required and optional relationships and data elements, as your final system must satisfy 100% of the business requirements, not the most likely events. Never try to combine the documentation of business data requirements with the design of a database.
If the business model is accurate, the design will be easy to produce and can be easily modified in light of business requirements and new technology.
Why a data flow diagram is better than a hierarchy of functions
A role hierarchy shows the major functions of a system and drills down into their details, but does not show the data requirements for those processes. It is very easy to inadvertently bypass lower level processes. A hierarchy of functions is not immediately obvious to a user who needs to double check the accuracy of their model.
A data flow diagram similarly shows the main functions and drills down, but since the data flows act as the “glue” that holds the processes together, it is easy to construct such a diagram in collaboration with a sales representative. “What information do you need to carry out this process? Where does it come from? What information is produced? Where is he going? In this way, individual processes can be gradually added to the model and nothing will be lost. Complex processes can be broken down and related processes can be grouped together.
A large data flow diagram is difficult to read and maintain, thus losing its effectiveness as a communication tool with both business users and the technical team. Instead, have about seven processes per diagram and drill down to more detailed diagrams, with a numbering system for cross-referencing. For example, the details of process 3 will be numbered 3.1, 3.2, 3.3, etc. and will appear in diagram number 3. Then the high level diagrams can be used for discussion with management and the lower level diagrams can be used for detailed double checking. with users who are experts in that area. There is no need to draw it separately.
Many analysts prefer to use a process model that includes “swim lanes” to identify who performs each process. This is just a data flow diagram in a different format. It’s fine to start the analysis using such a diagram, but by the end of the analysis the swim lanes should be gone, as your model should be resilient enough to survive restructurings in the business. You are documenting what needs to be done, not who does it or how.
Data flows must be specified with their detailed content in the data dictionary, just like data stores. Gradually, the data flow diagram will help build the data model so that your data definitions support the processes.
Include all processes in the data flow diagram, even the ones that seem trivial. I recently heard of a project that fell into the “Reporting is easy, we’ll save it for last” trap. At the time of compilation, the data needed for the reports turned out to be inaccessible.
Multiple versions of the model.
First document the existing system, including all its failures, without adding improvements. The cause of the problems is somewhere and you should not jump to conclusions about the best way to solve it.
Remove the how from the current physical model, giving a current logical model. Then determine the best way to solve the problems and include new requirements. This gives the new logical model, ready for design.
In some cases, problems can be resolved simply by reorganizing work practices, saving unnecessary design expense. Does this put the tech team out of a job? No problem. They can be freed up to use their expertise where it will make the most difference on other projects.
write specification
Don’t write a single big spec. It will be wrong, since you will lose some detail and you will not be able to modify it easily. And no one will be able to memorize everything. Instead, write a single specification for each detailed process: a “mini-spec”. Each can be double verified with the appropriate business expert. The collection of all these mini-specs is your system-wide specification. Each one is individually easy to maintain without affecting the rest of the specifications.
The specifications should not include any technical information, just the business rules for that process. The design team can find the best way to make it happen.
What to automate?
Looking at the data flow diagrams with the sales representatives and the technical team will help you decide the best implementation. This is based on factors such as what is acceptable to the business, what is technically possible, what fits within budget and time constraints.
You can go for full automation, partial automation, phased implementation, or some other great idea. Then hand it over to the design team.
Combining analysis and design.
Never do it. You are not saving anything.