Running head: ENTERPRISE-LEVEL BUSINESS SYSTEM

Enterprise-Level Business S= ystem

Effective information gathering during the analysis phase of enterprise-level business system development is critical. According to Tom Mochal, director of internal development at a software company in Atlanta, “ga= thering comprehensive requirements can mean the difference between a project’s success and failure” (Mocha= l, 2001). Mr. Mochal goes on to point out there are two types of developer= s, “some developers love to gather requirements, perform modeling, and m= ake nice flowcharts. Their idea of the perfect project is one where all you do = is gather information and model the business requirements. On the other side a= re the majority of developers, who view the formal gathering of business requirements as a process of questionable value that takes time away from t= he red meat of development—design, coding, and testing” (Mochal). In this paper, I will examine the methods and tools available for developers to gather business system requirements before beginning a project.

There are several methods of information gathering when anal= yzing the requirements of a new system. “In order to accomplish any given s= et of tasks effectively one must have a work plan or procedure. Without such a procedure or work plan, activities are performed in a haphazard manner and = with little if any coordination” (Modell, 2003). Effective planning requires the developer to determine beforehand which information gathering methods to use. The ultimate results of the analysis phase is to “determine a) if there is a problem to be addres= sed, b) if there is a feasible solution to the problem, and c) if developing a solution to the problem is cost beneficial to the user and to the firm as a whole” (Modell). The information gathering method must fit the information gathered, and several methods can be in use simultaneously.

The one-on-one inter= view method involves sitting down with the customers to determine needs and requirements. An effective interview “should be planned ahead of time based on the type of requirements you’re looking for. The interview c= an be tailored to discuss current processes, uncover future needs, or determine the problems the customer is trying to resolve” (Mochal, 2001). This method is v= ery time-consuming, however, as it requires interviewing a broad base of custom= ers for a clear analysis.

The group interview<= /i> method requires “more preparation and more formality to get the information you want from all the participants” (Mochal, 2001). This method allo= ws the developer to gather more information in a shorter period from a chosen grou= p of stakeholders. A potential downside of this method involves the group dynami= c. In any large group of people, some dominate, some dither, while others are apathetic. The developer must be well prepared and ready for the challenge = of keeping the group focused on the task.

The facilitated sess= ion method allows the developer to “get a much larger group together and potentially keep them together until all the requirements are gathered̶= 1; (Mochal, 2001). This method is preferable when it is important to “require the attendance of all pri= mary and secondary stakeholders to make sure no piece of the requirements puzzle= is overlooked” (Mochal). Although a great deal of information gathering can occur, it requires a gre= at deal of preparation.

The questionnaire method “is much more informal and can have limited value. However, questionnaires are good tools to use with stakeholders in remote locations = or with those who will have only minor input into the overall requirementsR= 21; (Mochal, 2001). When carefully constructed, a questionnaire becomes a good source for compiling statistics. However, careful wording is required to avoid incorrect data gathering.

Following people aro= und requires time and effort. Nonetheless, it may lead to some interesting observations. “You may find, for instance, that some people’s w= ork routines have become so habitual that they have a hard time explaining what they do or why they do it” = (Mochal, 2001). There are many cases in working environments where written proce= sses do not jive with the actual work habits. It is through observation that this discrepancy becomes apparent.

Author Martin Modell identifies three levels of business pro= cess mapping methodologies: the general<= /i> or business environmental analysis level, the detail business or client environmental analysis leve= l, and the application analysis level = (Modell, 2003). Of these three methodologies, it is the general or business environmental level analysis l= evel that “concentrates on the firm wide functions, processes, and data models” (Modell). This methodology analyses the enterprise as a whole entity, and examines process= es at a very high level.

Several tools are available for documenting business process mapping. Once such tool is the entity-relationship diagram. This diagram is helpful in visualizing how entities in an organization relate to one anothe= r, and is “typically used in computing in regard to the organization of = data within databases or information systems” (Webopedia, 2005, entity-relationship diagram).

Another tool is the = data-flow diagram, which identifies how data flows within the process. “Data flow modeling examines processes, data stores, external entities, and data flows” (Webopedia, 2005, da= ta flow modeling). This type of diagram uses basic symbols to represent th= ese four identities, as well as their functions within the system.

The data dictionary documents the location and type of data = within a database. Typically, the data dictionary is not available for users, but = is a necessary part of the system nonetheless. “Data dictionaries do not contain any actual data from the database, only book-keeping information for managing it. Without a data dictionary, however, a database management syst= em cannot access data from the database” (Webopedia, 2005, data dictionary). The types of information found in a data dictionary include data flows, data stores, data structures, data records, data elements, external entities, and processes (Shelley, Cashman, & Rosenblatt, 2004, chap. 4).

Process Description<= /i> tools help the developer to visualize “a specific set of processing s= teps and business logic” (Shelle= y et al., 2004, chap. 4). Using Stru= ctured English, Decision Tables, a= nd/or Decision Trees the developer descr= ibes the process. The use of software processes this information into a diagram representing the process.

The final task in the enterprise-level business-level system analysis phase is to determine the measurement of success, or validation. “The completed analytic documentation must be validated to ensure that: a) All parties agr= ee that the conditions as presented in the documentation accurately represents= the environment, and b) that the documents generated contain statements that are complete, accurate and unambiguous” (Modell, 2003).

An important aspect of determining the validity of the syste= m is to compare the analysis to the existing system. If the proposed system does= not improve the process on an enterprise level, as analyzed by using the methodologies and tools discussed in this paper, then the project becomes s= tructurally and financially infeasible.

A useful tool for determining if the new system meets the requirements of the organization is prototyping. The developer gathers preliminary requirements used “to build an init= ial version of the solution—a prototype” (Mochal, 2001). The organization= views the prototype to determine if it meets their requirements. If it does not, = the developer re-works the prototype. “This repetitive process continues = for an agreed number of iterations or until the product meets the critical mass= of business needs” (Mochal). According to Tom Mochal, this relatively new approach works well with Web development.

In this paper, I have examined information-gathering methods, business process mapping methods, business process mapping tools, and proto= typing for enterprise-level business system analysis. Proper analysis in this phase can make or break a project. For various reasons, this phase of system development becomes a nirvana or hell for developers. “Many developers have a tendency to gather requirements forever or to not gather them at all” (Mochal, 2001). The effective use and understanding of the methodologies and tools available to= the developer is vital to maneuvering through this process with appropriate results.

References

Mochal, T. (2001, Novemb= er 27). Gathering Business Requirements. R= etrieved July 1, 2005, from http://b= uilder.com.com/5100-6315-1045549.html

Modell, M. E. (2003). System Development Life Cycle -- Analy= sis. Retrieved July 1, 2005, from = http://w= ww.dai-sho.com/ddsd/ddsd02.html

Shelley, G. B., Cashman,= T. J., & Rosenblatt, H. J. (2004). Sys= tems Analysis and Design. <= span style=3D'mso-bookmark:R385349296412037'>Boston, MA: Course Technology.

Webopedia (2005). Webopedia. Retrieved July 1, 2005,= from http://www.webopedia.com/

Return to Index

Return to Home Page