Framework for System Analysis and Design

Determining the needs for a system is really the hardest part of the system analysis and design process. It involves far more than just picking the right piece of hardware and software. Needs determination requires “soft skills” long before you can design and build the system.

Any system, be it a technological or a human based business process, starts with interviews. All stakeholders must be interviewed for several reasons:

1. Each stakeholder may have different informational and operation needs.
2. Including stakeholders early in the design process overcomes objections and resistance. Furthermore, it develops a necessary trust and a sense of ownership that creates stakeholder buy-in.
3. Someone will inevitably point out a dimension of the system that you as a designer have missed. For a system designer, it’s sometimes hard to see the forest through the trees.
4. Interviewing all stakeholders provides a global view, which in turn, allows the designer to build the system correctly from the beginning. This means that missed functionality does not have to be patched on as an afterthought. Patching functionality makes the system more complex and far more likely to break.
5. The information gathering stage is the least expensive part of the design process. Once hardware and software are purchased, the roll out costs mount quickly. The more information and stakeholder buy-in culled from the beginning, the more efficiently the system can be rolled out.

The interview process should yield the following:

1. A list of inputs for the system.
2. A list of outputs for the system.
3. A list of business rules that determine how the inputs are processed.
4. A list of feedback loops to ensure data integrity. Each feedback loop entails a method to cross check data entering the system to make sure it is correct. Call it a system of checks and balances.

Data integrity is extremely important and often overlooked. Data integrity is an expansion of the garbage in – garbage out theory. If the data business decisions based on have an element of uncertainty, then the decisions inherit that uncertainty. The uncertainty may even be magnified. This often leads to costly mistakes.

An example would be predicting demand to decide on cyclic and safety inventory levels. You will never accurately predict the future so you know there is already uncertainty in your decision. Plus or minus 10% is usually considered a good error percentage for predicting inventory. If your data is accurate and you create your prediction, you then decide what level of safety inventory you need to cover the 10% of uncertainty.

Now imagine that your base data is incorrect. You expect your prediction to be off by 10%, but it is actually off by 50%. You commit the resources to either buying too much or too little inventory. If you buy too much, the probability it will become obsolete increases. If you buy too little, the probability of lost sales increases. Both potentially costly scenarios can be avoided by proper system analysis and design. Additionally, you now have to redesign your system to ensure your data is accurate. If a system is not designed right the first time, you will eventually build the system again. It is far better to roll out new systems that provide new business advantages than fixing systems that were not designed correctly in the first place.

Once the interview process is complete, you can translate the system needs into goals. Communicate the goals to all stakeholders and adjust them if necessary. The goals are then translated to project milestones and assigned dates. Each project milestone is then broken into sub steps and resources are assigned.

One milestone will always be actually designing the system. If it is a technical system, this will also involve choosing software and hardware. I cannot stress enough the importance of designing a system to be as simple as possible. Simple systems have higher uptime, are easier to troubleshoot, and are less prone to errors.

Which machine will have a problem first, the one with fifty moving parts or the one with a thousand moving parts? Simplicity is good. Simplicity works. Design the system as simply as possible to meet your needs.

For example, there is a lot of material written on data silos, separate islands of information in companies. The idea of a data silo is great as long as you only have one silo. A single silo means that all of your data is in one place so no interfaces need to be designed to cross connect data sources and ensure data integrity. A single silo is simple. It is easier to create, manage, and troubleshoot. The two obvious choices are a single data silo mirrored to multiple sites for redundancy or a meta-framework that seamlessly links multiple data silos into a single virtual data silo. The virtual data silo adds an entire layer of complexity. The extra layer potentially represents a whole new arena for things to go wrong. This increases support costs and can disrupt data integrity, which can lead to uncertainty in business decisions.

By following a few simple system analysis and design rules, new systems can be designed and rolled out with far greater efficiency. Define your needs long before you design the system. All stake holders need to be involved in the interview process. Plan feedback loops to ensure data integrity. Derive your system goals and translate them into project milestones. Design your system to be as simple as possible. Remember the acronym KISS: Keep it Simple Silly.