Process Model

Often the first step for Process Model is the ‘Level 0’ process diagram, this is a step that will take a business requirement and begin the process of turning it into a conceptual solution. This is an absolute essential for the whiteboard.

The ‘Level 0’ diagram takes the agreed scope of the projects and defines how it interacts with other processes will occur and what the dependencies are. At this level the data interactions are represented as lines between the process. The interactions will be more than data flows they will also be the transactions that trigger process events. From the project management view, this is the diagram that will determine the technical scope of the project and this should align closely with the original business requirement.

Impact Analysis

The impact pf changes to business process on external entities needs to be considered. Often, in corporate situations there are shadow systems which rely on the data coming from enterprise systems. Changes and enhancements may also provide the opportunity to improve the integration of shadow systems into the enterprise. Shadow systems may also act as data feeds for enterprise systems. If there are internal coding structures within data that are used of provided by shadow systems of external systems these should be identified. A shadow system normally exists alongside an enterprise system and provides enhanced functionality, the enterprise system may not be aware of shadow dependencies.

Process Map

A process map can provide some added detail for transactional processes, it is the assumed that the transactions represent the core process of any business problem and is an analysis of the actual business process. There are a number of methodologies that recommend various approaches, key to the map are the inputs and the outputs and the process that transforms the input to the output.

This process map is for a physical shopping process and lists inputs to the process, further detailed analysis may include the interactions of the inputs, for example books and shelves.

Conceptual Analysis should involve the further decomposition of the high-level process into manageable components. Decomposition is a task that provides insight into the components that will need to be designed and the entities that the business process will require. Decomposition will also provide the framework for a further iteration of the estimation process. A Decomposition diagram may prove useful and naturally complements a ‘Level 0’ diagram and the first level of decomposition is sometimes referred to as ‘Level 1’.

Different methodologies may use different shapes, this diagram is methodologically agnostic. The first level of decomposition will reveal small subsystems, the lines on the diagram represent data flows between the subsystems. These data flows can be analyzed and added to the information model. The decomposition also starts to imply the business process by identifying some key entities, in this case ‘Stock’,’Transaction’ and ‘Customers’. The original project initiation document should reference these key entities in much the some terms. The Process model should reference all the sub-systems and there processes such that a table of contents will show the full structure of the business processes.

This is an area where a modeling tools cam be useful, but it is not an essential unless your development methodology requires a specific format of model for requirements management. The process model is actually a requirements model when taken in context with the visualizations and the information model.

‘As Is’ and ‘To Be’ Diagrams

Diagrams that illustrate the before an after business processes are regarded as best-practice for any project that involves changes to the business process and is the best way to demonstrate to the customer that he is actually getting something for his money. If process improvement cannot be demonstrated then the project would have to yield improvements in other areas such as performance or operational expenditure. This type of diagram is typically a swim lane diagram, with the swim lane describing different roles or systems in the business process.

This type of diagram can be used in a variety of ways but is at its best demonstrating the work flow of a business process. This diagram models an ideal process and could be an ‘As Is’ or a ‘To Be’ diagram used to demonstrate what a process is about in simple terms. One of the key differences between an ‘As Is’ and a ‘To Be’ diagram is that the ‘As Is’ diagram is an analysis of the current system and will contain the problem whereas the ‘To Be’ diagram is belongs to the the design for the solution to the problem. This does not mean that a ‘To Be’ diagram does not belong in an analysis phase, but it is important to do the ‘As Is’ ,or equivalent, to complete the analysis of the existing problem in the analysis phase.

Examples of the business process

Business process can be illustrated by examples which will show various business rules in use. These business rules will form the basis of the functional requirements, the the requirement is not clear this can be clarified by working through and example of the case which is being clarified. Examples may also help with discovery of requirements by exploring the boundaries of processes and inferring conditions from the data. In our example we may illustrate various stock conditions such as ‘ In Stock’,’Out of Stock’,’Insufficient Stock’, and then verify that we know how to handle these as conditions.

Functional Requirements

Functional requirements should represent business policy and rules that apply to a business process, either directly or implied. It is possible for analysis to uncover conditions that are not covered by existing procedures. If a business rule does not exist for a condition the sponsor must be made aware of this so that the condition is not catered for in an arbitrary fashion; that is a business rule should be created in the appropriate policy. Ultimately the functional requirements should consist of a series of work flow descriptions referencing the business policies and rules that they implement. Not all business rules will be internal to the business, they may be external rules with which the business must comply.

User Acceptance Test Plan

As conceptual analysis is conducted information is gathered as to the specific requirements of the system and these requirements will be illustrated by examples. This information is valuable an should be incorporated into a User Acceptance Test Plan (UAT). By starting a test plan at this stage it will ensure that a common document is available throughout the software life cycle describing what the user expectations are comprised of. Because the UAT can reference other documents it does not need to be a long and exhaustive retelling of requirements, it can summarize the policies, regulations and constraints defined by the requirements.

Interactions with the Information Model

The Process Model will describe work flows and business rules and these will reference business information which is collected in the Information Model. If a process references information that is not in the information model, it should be added to the information model. The Process and Information Models are interdependent. While it may appear that the process model will become programs and the information model will become a database during the physical design phase, this is simplistic as the interdependencies themselves are also carried forward. Process creates and modifies Information, but the analysis of the information will raise questions relating to process

This ‘Mandala of Modeling’ illustrates the interaction of process and information and how programs and data relate to this. Ultimately the analysis of the problem and the synthesis of the solution must combine process and information to form the whole.