Consider the following dialogue between a system’s professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:
Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.
Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.
Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.
Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.
Required:
a. Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.
b. What method would you propose they take? Why?
(3000 words)
Based on the dialogue given between a system’s professional named John Juan and a manager of a department namely Peter Pedro, obviously, Peter Pedro aims for a new information system that would not be considered as a modified version type of their old system. Definitely, after working on different position, they will have diverse views on how a systems analysis phase should be conducted.
As what I have understood, an organization is a set of people or a formal collection of people and various resources established to accomplish a certain set of goals. The organization itself is already considered as a system. In the world of business today, the real challenge is how a firm can cope up with change. Change occurs in most areas. This includes political, economic, social and technological. Globalization, the increased of customers expectations, low-cost computing and telecommunication tools, and rapid organizational change are just some that can be considered as the anxiety for change. Because of this unstoppable change, a department of a firm has its own information system that was chosen to match their specific activities. Information system is typically used for operational and decision support. A competitive advantage is a significant and a long-term benefit for the firm thus the strategic plan for viable benefit is by using information systems for strategic purpose.
Since the two actors have different point of view in conducting a systems analysis phase, it would be perfect to have an introduction by discussing what systems analysis phase is and what the things that should be considered are before I comment on which side should I sympathized. As what I have read on my resources, systems analysis is the second of the five phases in the Systems Development Life Cycle (SDLC). The purpose of systems analysis phase is to build a logical model of the new system. The overall objective of system analysis phase is to comprehend the proposed project, guarantee that it will support business requirements, and build a solid foundation for system development. Naturally, in this phase, the systems analyst uses models, questionnaires or other documentation materials for them to visualize and identify the new system proposed. The systems analysis phase includes four essential activities. These are requirements modeling, data and process modeling, and object modeling. Let’s discuss each activity one-by-one to have a broader knowledge about it.
Requirements Modeling
The first step in systems analysis phase is the requirements modeling. In this step, the analyst generally investigate every business processes and to document what are the functionalities or what the new system must do. Base on what I have read, the preliminary investigation already starts in the system planning phase to know more about the system request and was continued in the requirements modeling in the systems analysis phase. Normally, system requirements fall into five general categories: Outputs, Inputs, Processes, Performance and Security. These general categories are used to identify the requirements for the new system. Outputs, from the word itself, refer to any electronic or even printed information generated by the system. Inputs are basically about the necessary data that enters the system. It doesn’t matter if it is manually done or in an automated manner. Processes, on the other hand, are concern with the logical rules that are followed and applied to transform all the gathered data into meaningful and reliable information. Performance refers to the characteristics of the new system. Such system characteristic includes speed, volume, capacity, availability, and also reliability. Lastly we have the security. Security focuses on the hardware, software and especially the procedural controls that will be used to safeguard and protect the system as well as the data installed unto it from any internal and external threats.
To be able to understand more about the system, a systems analyst perform a so called fact-finding technique. This technique involves interviews, surveys, document review, observation, and sampling. The results of the fact-finding technique are mostly used to build business models, data and process models, and object models. Using fact-finding, you must answer the five familiar questions. These are who, what, when, where and how. Basic questions that gives a concrete and dependable respond like asking “Who performs each of the procedures within the system?”, “What is being done?”, “Where are operations being performed?”, “When is a procedure performed?”, and “How is a procedure performed?”.
Fact Finding Techniques
1. Interviews
In the interviewing process consist of the following procedure: Determine the people to interview, Establish objectives for the interview, Develop interview questions, Prepare for the interview, Conduct the interview, Document the interview, and Evaluate the interview.
2. Document Review
In the document review, you will acquire the copies of the actual forms and the current operating documents in use. You will then review all the gathered copies of the forms as well as the samples of the actual completed forms.
3. Observation
Observation is also necessary in requirements modeling. Observation refers to your personal observation wherein you are allowed to verify statements made in the conducted interview and also determine whether the flow of the procedures really works as what they have identified.
4. Questionnaires and Surveys
A questionnaire is also referred to as survey. Questionnaires are just a simple template or document that contains a number of typical questions that are answerable by many individuals. These questionnaires are sent to numerous individuals and will serve as a tool for you to evaluate base on their answers.
5. Sampling
Records, reports, operational logs, data entry documents, complaint summaries, work requests, and various types of forms are included on samples. The sampling technique in fact-finding involves a systematic and random sampling.
Data and Process Modeling
In the data and processing modeling, there will be a contiguous modeling process through gaining more knowledge on how to represent a graphically system data and process using traditional structured analysis techniques. The structure analysis determines the data flowing into a process. Also includes the business rules that transform the data, and the resulting output data flow. During the requirements modeling process, we gather the requirements by following the fact-finding techniques and to examine and analyze the currents system and also we use the technique to determine what the possible user requirements are. After gathering all those necessary information, you will do the next step which is the data and process modeling in the systems analysis phase. Using that information, you will develop a logical model of the proposed system and also, you need to document all the system requirements. Logical models are practiced to show the different features and functionality of your system. Data flow diagrams, data dictionary and process descriptions are the three tools that comprises the data process and modeling.
Data Flow Diagram
Though system analysts use numerous graphical techniques in describing an information system, creating a set of data flow diagram is one of the popular methods of graphical technique. Usually, a data flow diagram utilizes various symbols to illustrate how a certain system converts the imputed data into useful and reliable information. It is one way of visualizing the information system. Processes, data flows, data stores and entities are the four basic symbols in data flow diagram. A process symbol represents where the input data is received to produce an output can either be in different content or form or maybe both. It contains the logic of a business, also called the business rules. The symbol for a process can be represented in a rectangular with rounded corners. Data store symbol is used to illustrate the data that the system had store in the data flow diagram. Hence, Data flow diagram does not show the detailed content of a data store since the specific structure and data elements are already defined in the data dictionary. The physical characteristics and the length of time that the data is stored are unimportant. The only thing that is important is that process needs access to the data. The latter symbol is illustrated by a flat rectangle that has an open right side and a closed left side. A data dictionary is also important because all the details within the data flow diagrams re documented on it.
Data Dictionary
Data dictionary is the second component of structured analysis. A data dictionary, or referred to as data repository, is the main storage area of all the information about the system’s data. It is used by the system analyst to collect, document, and organized specific facts about the system, as well as the content of data flows, data stores, entities and processes. This describes and identifies all the data elements. A data element is only a sheet of data that has a meaning within the information system. It is needed that all the data elements on a data dictionary are documented.
Process Description
A process description records all the details of a functional primitive, and also represents a specific set of processing procedures and business logic. There are also a set of tools used in process description to create a model that is accurate, complete and concise. These tools include structured English, decision tables, and decision trees. Since process description goes with a functional primitive, when you try to analyze it you will need to break the processing steps into smaller processes which is also called modular design. Modular design is also called control structures that is based on the combination of the three logical structures and serves as the foundation for the process.
Object Modeling
A systems analyst use to form a logical model using an object modeling technique. In addition, you will be using an object-oriented analysis in designing an information system. Object modeling techniques is another strategy to view and model the system requirements. It is utilizes to document, analyze and even model the information system. Object-oriented analysis describes an information system by identifying things called objects. And these objects can be a real person, place, event, or transactions. The end product of an object-oriented analysis is an object model that would effectively represent the information system.
Unified Modeling language (UML) is used in the object-oriented analysis since it is considered as an object-oriented approach. It is widely and commonly used method nowadays to visualize and document an information system. It is used to develop object models. A Unified Modeling Language includes the following diagrams: Use case diagram, activity diagram, sequence diagram, class diagram, state chart diagram and etc. I’ll discuss some of its diagrams based on the resources given in our software engineering subjects.
Use Case Diagram – models the functionality of a system using actors and use cases. Use cases are services or functions provided by the system to its users.
Class Diagrams – are the backbone of almost every object-oriented method including UML. It describes the static structure of a system.
Object Diagrams – are also closely linked to class diagrams and could be viewed as an instance of a class diagram. Object diagrams describe the static structure of a system at a particular time and they are used to test the accuracy of class diagrams.
Sequence Diagram – diagrams that describe the interaction among classes in terms of an exchange of messages over time.
Collaboration Diagram – describes interactions among objects in terms of sequenced messages. Collaboration diagrams represent a combination of information taken from class, sequence, and use case diagrams describing both the static structure and dynamic behavior of a system.
Statechart Diagram – it shows the behavior of classes in response to external stimuli. In this diagram model the dynamic flow of control from state to state within a system.
There are numerous diagrams under the Unified Modeling Language that can be used in modeling and explaining the flow of your system. It is easy to understand and it is commonly used now by the developers.
Now, going back to the dialogue of the two professional individuals and after having an overview about the different system analysis phases, if we try to analyze it well both of them have separate opinion but they are still under the requirements modeling in the systems analysis phase. Choosing between who has a greater idea is really a though one since both of them are right. But as we all know, a system’s professional or he can be a systems analyst since the person who is responsible for doing the analysis job is a systems analyst. A systems analyst investigates, analyzes designs, develops, installs, evaluates, and maintains company’s information system. But before he can perform those mentioned tasks, he/she must constantly interact with users and managers inside and outside the organization. It is his/her job to help translate business requirements into projects. With Mr. John Juan, I agree that before you develop a new system, it is also necessary to study the current system. Well, I just remember what our instructor in my software engineering subject told us when we have our consultation about our proposed system, she told us that it is essential to know and analyze first the current system before we develop a new one and according to her we must know the scope of our system and who are those persons that will be involved. It is also needed that we would approach those people so that we can gather more data for the development of our system. On the other, Mr. Peter Pedro wants to start with their list of requirements. I can’t blame Mr. Peter Pedro if he wants it that way. After reading his words, he really wants a system that maybe somewhat different from their current system. He doesn’t want another modified version of their current system. Since the job of Mr. Peter Pedro is not merely more on technical, he won’t be able to understand it well why the systems professional wants to study first the current system and observe the working performance of the employees. I would suggest that Mr. John Juan will explain it well to Mr. Peter Pedro through requirements modeling and object modeling.
Base on what I have tackled earlier, in gathering the requirements needed for the development of the new system, requirements are not only based on what the manager wants or needed. Maybe he don’t like the current system but as system analyst he/she must know what lacks the system and know how the workers interact with that system because even if the system is pretty good but the workers resist unto the change of system it would be worthless. As I remember what the Management Information System supervisor of the Sta. Ana Multipurpose Cooperative told us during our MIS 1 subject, he told us that whenever they are developing a system they made a questionnaire to survey if the end-user would like to change the system or what are the comments on the current system, they sometimes ask what the end-user wants into the system. They sometimes do a manual survey on it. Because according to him, that’s one way they could gather a useful and reliable data.
For Mr. Peter Pedro understand Mr. John Juan, it would be easier if Mr. John Juan will provide a documentation of the requirements modeling and produce an object modeling. Mr. John Juan must clarify everything especially on how he gathers the data and how thus those data is useful in the development of the new system. Looking back with our discussions in Software Engineering and Systems Analysis and Design subjects, we both tackled about Unified Modeling Language (UML). Through the use of the different diagrams of the Unified Modeling Language like use case diagram, activity diagram, class diagram, activity diagram and sequential diagram, Mr. John Juan can explain well the flow of the new and current information system based on the requirements that he have gathered. He will be able to illustrate it into an easier and understandable manner because diagrams such as use case diagram, activity diagram ad sequential diagram are easy to comprehend and evaluated. And also it would be lessening to Mr. John Juan because as a professional it would not be hard for him to create such diagrams. I had chosen object-oriented modeling than data and process modeling because for a person who is not that knowledgeable with the systems and not that expert in developing an information system, it would be hard for him to understand it well.
As I remember when we had an interview for the System Analysis and Design 1 for our reporting and again with the MIS supervisor of SAMULCO, he told us that in terms of diagrams when they had a project to be proposed to the top-level management, they usually used those Unified Modeling Language diagrams. They also used data flow diagram but it is just for him and his programmer because they are those who can understand it more. In developing a system every phases is important, every data and requirements are essential and every end-user is needed that is why before you create an information system or software it is necessary that you have gathered all the important things that should be considered.
Reference:
http://books.google.com.ph/books?id=i_7EnA2cS5sC&pg=PA697&lpg=PA697&dq=object+modeling+%2B+system+analysis+phase&source=bl&ots=W-BFBWZXb&sig=sVIcYa0cjpQr7edoOXvgpKI5fmY&hl=en&ei=muBiS_eHEY6OkQXem7HwBg&sa=X&oi=book_result&ct=result&resnum=10&ved=0CC0Q6AEwCQ#v=onepage&q=object%20modeling%20%2B%20system%20analysis%20phase&f=false
http://www.ansa.co.uk/ANSATech/95/Training/147401.pdf
http://www.lib.ru.ac.th/knowledge/pcweb/mis/MISLESSION_3PDF.pdf
Posted by
