“Higher level data models need to represent the business rules, with the scope of the model for each increment dictated by the needs to be addressed by that project. To do that well, the data modeler should genuinely be interested in understanding the enterprise mission, values, priorities and strategies” [1].

Many information systems professionals understand that information systems need to achieve some kind of business need. However, many information systems professionals may not fully appreciate the importance of incorporating sound business understanding into their systems analysis. This paper will argue that one of the most critical skills for a systems analyst is the ability to “merge the stakeholder’s knowledge of the business with the [analyst’s] understanding of business intelligence and approaches for leveraging the value of information” [2]. To do this effectively, an analyst needs to possess a sufficient level of business understanding. Additionally, an analyst needs to know when a system is “good enough”, and avoid designing information systems primarily for the sake of features and performance. Keeping an organization’s business needs in mind as the primary goal should help the analyst avoid the trap of “feature creep”.

The Analysis phase of the SDLC is where analysts begin to understand the need for system changes. A significant amount of effort and resources are required for effective analysis. This process is usually divided into two main categories: (1) Requirements Determination and (2) Requirements Structuring. Requirements Determination involves fact-finding and the gathering of information in order to discover what information and information processing services are necessary to support an organization's goals. Methods employed in Requirements Determination include: one-on-one interviews; Nominal Group Techniques; JAD sessions; and iterative prototyping. Once this information has been gathered it must be organized in way that will allow analysts to identify missing elements, illogical components, and overall deficiencies within an organization's current operations. This is where the second core component of analysis, (2) Requirements Structuring comes into the picture.

Requirements Structuring can provide three views of an organization's operations: (a) Process - which covers data movement and handling; (b) Logic & Timing - which covers data transformation and manipulation; and (c) Data - which covers the inherent structure of data. The Process View is usually represented by data flow diagrams (DFD), while the Logic & Timing View is represented by decision tables (which relate to what happens inside the process boxes within DFDs). A model's Data View is usually represented by Entity-Relationship diagrams, which depicts an organization's data structure and data integrity. This paper will focus on the Data View, its importance to an organization's viability, and the benefits that a sound business understanding brings to the overall Requirements Structuring phase of Systems Analysis, and specifically to the creation of an organization's Data View.

The next section will introduce the concept of the business model, and how a strong understanding of an organization’s business model can assist the analyst during Requirements Structuring and Conceptual Modeling.

For the purposes of this paper, the terms "organization", "company", and "business" will be used interchangeably.

NEXT SECTION: Business Models >>

Go back to the top!