Many of us are familiar with the process of business analysis – start by gathering requirements from stakeholders then turn them into a specification which developers can understand. These days however, we need to do more than just document the requirements.
We need to work with stakeholders and business users to understand their systems and analyse their problems – why do you do it this way, why not that way? This is the real value add that the analyst brings to the table. It means challenging the status quo, pushing the boundaries, looking for alternative or creative solutions.
To develop a solution - unless we’re very lucky - we first need to understand the problem that drives the need. In this paper we'll look at how to understand and define business problems – part 2 will look at how to generate solution ideas and part 3 will cover how to choose the best ones.
Author: Jan Kusiak
In the past I have discussed the need to manage data (and all information resources) as a valuable resource; something to be shared and reused in order to eliminate redundancy and promote system integration. Now, our attention turns to how data should be defined. Well defined data elements are needed in order to properly design the logical data base as well as developing a suitable physical implementation.
Author: Tim Bryce
The subject of current systems analysis is usually greeted with dismay or disdain by systems departments. There are many reasons for this. In many installations, the support of current systems takes more than 85% of the systems department's time, and the departments are more than ready to get on with new systems development and bury the old, non-working systems as quickly as possible. In cases where systems do not require a lot of maintenance, the systems department may find that the current systems are not giving management the kind of information it needs for effective decision making; these current systems become likely candidates for replacement.
However, there are some very legitimate reasons for documenting existing systems.
One of the biggest challenges in any system design effort is to produce a viable design that is well thought-out with all of the pieces and parts working harmoniously together. If something is forgotten, regardless of its seeming insignificance, it will undoubtedly cause costly problems later on. The task, therefore, is to produce a design that is demonstratively correct.
In a nutshell, the concept of "stepwise refinement" is to take an object and move it from a general perspective to a precise level of detail. Architects have used such an approach for years, as have engineers building products. But to do so, they realized they cannot simply go from the general to the specific in one felled swoop, but instead, in increments (steps). The number of steps needed to decompose an object into sufficient detail is ultimately based on the inherent nature of the object. To illustrate, for architects designing a building, the typical steps include:
Over the last four decades I have met a lot of Systems Analysts in a lot of different industries. Some impressed me greatly by their knowledge of their business and the systems they designed, but I have also met a lot of duds along the way. When I think about the better ones, I consider the attributes they share which I can narrow down to three areas
In its simplest form, a Feasibility Study represents a definition of a problem or opportunity to be studied, an analysis of the current mode of operation, a definition of requirements, an evaluation of alternatives, and an agreed upon course of action. As such, the activities for preparing a Feasibility Study are generic in nature and can be applied to any type of project, be it for systems and software development making an acquisition, or any other project.
Good question! What do you think?
This is an important question which is ultimately at the heart of a lot of the problems in systems and software development. There is one camp that believes development to be an art form requiring free-spirited creative types of people, and another camp believing it to be a science requiring people that are more disciplined and organized.
The difference between an art and a science is subtle but significant. An art form is based on the intuitiveness of the person performing the work, something that is difficult, if not impossible, to pass on to another human being. For example, apprentices serving under an artist may try for years to emulate the master, but may never attain his level of skill and creativity. In contrast, a science is based on a governing body of concepts and principles and, as such, can be easily taught to others.
I have been very fortunate to see a lot of this history first hand. I have observed changes not just in terms of systems and computers, but also how the trade press has evolved and the profession in general. It has been an interesting ride.
Throughout all of this, there have been some very intelligent people who have impacted the industry, there have also been quite a few charlatans, but there has only been a handful of true geniuses, one of which was Robert W. Beamer who passed away just a couple of years ago. Bob was the father of ASCII code, without which we wouldn't have the computers of today, the Internet, the billions of dollars owned by Bill Gates, or this document.
I always find it amusing when I tell a young person in this industry that I worked with punch cards and plastic templates years ago. Its kind of the same dumbfounded look I get from my kids when I tell them we used to watch black and white television with three channels, no remote control, and station signoffs at midnight. It has been my observation that our younger workers do not have a sense of history; this is particularly apparent in the systems world. If they do not have an appreciation of whence we came, I doubt they will have an appreciation of where we should be going. Consequently, I have assembled the following chronology of events in the hopes this will provide some insight as to how the systems industry has evolved to its current state. I'm sure I could turn this into a lengthy dissertation but, instead, I will try to be brief and to the point. Further, the following will have little concern for academic developments but rather how systems have been implemented in practice in the corporate world.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: