Information Systems Requirement Gathering using FAST Framework: Critical Analysis

Transcription

1 Information Systems Requirement Gathering using FAST Framework: Critical Analysis Zin Myint Naung (G H) Phyoe Mon Mon Oo (G B) {ZI0001NG; Abstract The paper intends to Information system requirement gathering by using the FAST framework. We will present how each FAST phase can be applied to real-life example of identifying system requirements and satisfying those requirements with the system. In addition, discuss how FAST methodology critically contributes to the software knowledge area (knowledge, process, communication). Finally, we will conclude with what are the limitations of our paper and how we will accomplish in future that dealing with this title. 1. Introduction A requirement is a property that is essential for an Information System to perform its functions. Information system requirement gathering is the essential part for developing the information system [14]. There are many requirement gathering methods in information development process. FAST stands for The Framework for Application of Systems Thinking, covers the software life-cycle from requirements capture to maintenance, evolution and re-uses [5]. FAST is a design strategy that is repository-based. Phases and the individual activities included in phases communicate across a shared repository. Work in one phase can and should overlap work in another phase, so long as the necessary information is already in the repository. A single locale for all documentation helps the developer keep track of changes to a project and in finding omissions or errors [3]. 1.1 FAST phases versus Classic Phases The classical system development model consists of discontinuous phases. As this model emphasizes planning in early stages, it ensures design faults before they develop. The classical model is also document-driven, so that the results of each phase are documents that serve as

2 milestone to track the development progress. In addition, its concentrated document and planning make it work well for projects in which quality control is a major concern [1][11]. The FAST phases consist of several non-overlapping stages. The model begins with establishing system requirements and software requirements and continues with architectural design, detailed design, coding, testing, and maintenance [3]. But the classical model serves as a baseline for many other system development lifecycle models and it can work wells on mature products and weak teams [1]. Classic Phases FAST Phases Project System System System Initiation Analysis Design Implementation Scope Definition Problem Analysis Requirement Analysis Logical Design Decision Analysis (a system analysis transition phase) Physical design and Integration Construction and testing Installation and delivery 2. Using FAST framework Table 1 Compares the FAST phases to the Classic phases

3 This section discusses eight phases of FAST framework specifically focusing on first four phases that will cover the process of information system requirement gathering. Each phase works on the requirement of system and passes the deliverables that are generated by itself to the next phase [3]. Figure 2-1 Process View of FAST framework 2.1 Scope Definition This phase performs the primary measures in term of the function, capacity and content of a project. The participants of this phase are system owners, project managers and system analysts. The scope definition should include schedules and objectives of the project, budget constraints, tasks, deliverables and resources required of the project. The project team starts to give the boundaries of verifiable end products, outcomes or deliverables to the system owner. The project deliverables are split into manageable tasks and set up sources and milestones that can supply

4 assessment on the whole project. Moreover, the important outcome and deliverable of the project scope are problem statement and statement of work. The performance of the problem statement in this phase is only to record and classify the problem, not for solving. The statement of work is an agreement that defines the deliverables, timelines and work motions to expand the system (Schwallbe, 2009) [13]. To give a clear statement and description, this paper will use internet banking as a real life example. The norms of the project scope of internet banking involve its assessments and account creation. The purpose of the scope is to computerize the system, pre-checking all required objects and automatically process the transactions used in banking [7]. Internet banking categorizes a meticulous set of technological solutions for the improvement and the delivery of financial services, which react upon the open architecture of the internet [10]. All the above statements and problems carry into the next phase as the deliverables after categorizing all the problems and outcomes. 2.2 Problem Analysis The problem analysis phase describes the requirements of the existing system and analyzes the problems to get better understanding on the project. The system users also get actively involved in this phase as business subject matter experts. The deliverables of this phase is the requirement documents that show precisely what is to be developed in the next phases. Burback, 1998 stated The requirement document tries to capture the requirements from the customer s perspective by defining goals and interactions at a level removed from the implementation details. It is stated in a formal language based on mathematical logic and presented to system owners and users [12]. Kelly M, ( ) explained that one thing in the problem analysis is to formulate the problem and it split the problem up into its parts and express them [9]. In this problem analysis phase, internet banking has some serious problems while banking through the internet and the project team needs to analyze on these problems like the people who are not eased of use with the internet, clicking a wrong button while transferring account, any leakage of information with PIN number and password, technical difficulties, accessibility and performance, Trojan attacks, etc. (Bora, 2010) [2]. However, many banks have issued the procedures to overcome all these problems related in authentication (Using One-time password)

5 and setting the session time-out in the problem analysis phase. At the end of this phase, the system owners might reject or edit the requirement documents after reviewing. 2.3 Requirement Analysis In Requirement Analysis phase, we need to define and prioritize the business requirements in according to the real world market needs. In this phase consist of system users, systems analyst and project managers to determine business requirements that are based on the business's goals, processes, need for business information and system interface requirements. System designers are omitted in order to avoid the consideration of any technical potential or solutions as they are dependent on system analysts to validate with the users to define business requirements before applying any technological design. In real life, for example developing of internet banking system, system analyst facilitates with the system users in order to meet real world business requirements and benefits. In order to meet the objectives of business requirements and benefits, the systems analyst required to find the financial information services and markets using electronic communication and computation such as e-payment, e-trading and e-banking [4]. In the mean times, system analyst need to consider issue in internet banking system such as security issue, in case of occur technical difficulties and connectivity problems while accessing internet banking transactions etc. System analyst need to confirm with the users those requirements through the way of interviews, questionnaires and facilitated meetings. The system requirement can be identified by documenting user needs in using systems analysis tools and techniques. 2.4 Logical Design After the requirement analysis phase, system analyst can illustrate the internet banking system models in order to validate the business requirements for completeness and consistency. The logical design phase is normally interpreted business requirements into system models to show the system independent of any possible technical solution. In this phase include system analysts, system users and the project managers. Usually project managers need to ensure that system model meets in standards, structured analysis and design. System analyst can draw system models to classify in logical data models, logical process models and logical interface models

6 that represent data and information requirements (Knowledge), business processes requirements (Process) and system interface requirements (Communication) [3]. Many different object diagrams can be drawn for a logical system models and specifications, represent the state of the system as individual objects, as attribute values stored inside these objects, or as link between objects [6]. The following data flow diagram shows funds transfer in internet banking system. Figure 2-1 Data Flow Diagram of Fund Transfer [2] 2.5 Other Phases Next four phases of FAST framework includes Decision Analysis, Physical Design and Integration, Construction and Testing, Installation and Delivery. Due to the topic matter of our

7 discussion, we will not be covering details on these four phases as we merely focus on Requirement Gathering through FAST framework and analyzed it critically. Brief definitions of these phases are mentioned below [3]. Decision Analysis: Known as transition phases because it makes the transition from the business concerns of system owners and users to the technology concerns of system designers and builders. System proposal is an output of this phase. Physical Design and Integration: Transformation business requirement into technical solutions. Physical database, software and interface design are built in this phase. Two approaches can be used in Design by specification and Design by prototyping. In practice, some combination of these approaches is usually performed. Construction and Testing: Implementation and testing of a system that fulfils business requirement and physical design specifications. Databases, commercial software packages (either built or buy), system user interface are implemented and tested. Installation and Delivery: Convert functional system from construction and testing phase (development environment) into operational system (production environment). Training and accepting users feedbacks are also involved. 3. Critical Analysis (FAST framework) Below Figures 3-1 shows the contribution of FAST framework towards software requirement knowledge areas KPC (Knowledge, Process & Communication) [3]. Notice that the diagram only covers first four phases of FAST framework that addresses requirement gathering process.

8 Figure 3-1 Contribution of FAST framework towards software requirement knowledge areas (Knowledge, Process, and Communication) FAST methodology follows the nature of classic sequential methodologies such as Waterfall Model. Sequential methodologies are less acceptable in modern age application development environment. Bentley & Whitten (2007) brought four alternative routes for FAST methodology namely: (1) Model-Driven Development Strategy, (2) Rapid Application Development Strategy, (3) Commercial Application Package Implementation Strategy (4) Hybrid Strategies (combination of different methodologies) [3]. Four strategies mentioned above have their own advantages for instance Model-Driven Development Strategy derives models for each process while Rapid Application Development Strategy allows us to combine phases that leads to time-saving system development. Commercial Application Package Implementation Strategy is very useful if our system includes various third

9 party sub-application components while Hybrid Strategies allows us to combine above mentioned three strategies alternatively according to our system development needs. From the perspective of critical analysis, we would like to propose Hybrid Strategy by combining Rapid Application Development Strategy and Commercial Application Package Implementation Strategy in conjunction with FAST methodology that composed new system development strategy. Since FAST itself has the nature of sequential approach, above strategies can be capsulated with FAST framework to form better methodology. In other words, from the perspective of critical thinking, FAST it stands little in real-life application development. Next, FAST introduces eight phases in total however; some phases can be combined together. For instance, Scope Definition and Problem Analysis phases can be combined together for smaller information system development process. Such combination of phases are widely use in Rapid Application Development methodology. FAST as a phased development methodology allows user to involve with the systems that are intentionally incomplete. It is hard to include most important and useful features in the first version of functional system while managing the users expectation along the way [8]. 4. Limitations and Future Works This paper only discussed information system requirement gathering using FAST methodology and critically appraised it. The first four phases were outlined thoroughly with real life example (Internet Banking System) as these phases belong to information system requirement gathering. First limitation here is that, this could only cover the first four phases of the FAST methodology and the other four phases were still not discussed in our paper. Second limitation, we did not include the actual feedbacks, questionnaires, survey or interviews from those system analysts and developers who already experienced using FAST methodology as a system development methodology.

10 Two limitations mentioned above can be transformed as future works of our paper and this will guide for other students and researchers to evaluate and critically appraise FAST methodology in more details. Next future work we would like to describe is to critically appraise our proposed Hybrid Strategy that we mentioned under critical analysis section of our paper. After analyzing our proposed Hybrid Strategy, we can clear see what are the advantages (in terms of contribution towards Knowledge, Process and Communication) and differences of our proposed methodology in comparison with former FAST methodology. 5. Conclusion In system development environment, requirement gathering is a vital process as if this process failed, then the whole system has to rebuild and that would lead to high cost and time. To avoid this problem, understanding on how to approach system development methodology is essential from the point project management view. Although our research on this paper contains some limitations we discussed in previous section, our real-life examples and critical analysis on FAST framework bring how to use system development methodology effectively to certain extent. References [1] Ali Munassar, Nabil Mohammed, & Govardhan, A. (2010). A comparison between five processes management models. Advances in Computational Sciences and Technology, 3(3), [2] Bora, C. (n.d.). Internet banking problem. Retrieved November 7, 2010 from [3] D. Lonnie, Bentley, & L.Whitten, Whitten. (2007). System analysis and desighn for the global enterprise (7 th ed.). New York: McGraw-Hill Irwin. [4] Dillman, D. A. (2000). Mail and Internet Surveys: The Tailored Design Method (2nd ed.). New York: Wiley. [5] FAST. (n.d.). Retrieved November 7, 2010 from [6] Ibrahim A.S.Muhamadi, A.A Zaidan, S.Raviraja, M.A Zaidan, B.B Zaidan, Chengetai Mapundu, Auto Notification Service for the Student Record Retrieval System Using Electronic Mail Message (EMM), International Journal of Computer Science and Network Security (IJCSNS), Vol.9, No.8, pp , ISSN : , 30 August (2009), Seoul, Korea.

11 [7] Internet banking project document. (n.d.). Retrieved November 6, 2010 from [8] Introduction to system analysis and design. (2005). Retrieved November 8, 2010 from [9] Kelly, M. (2010). "Software Development Life Cycle; Step 1: Problem Analysis ", Retrieved November 6, 2010 from [10] Online banking system. (n.d.). Retrieved November 7, 2010 from [11] Project lifecycle models: how they differ and when to use them. (n.d.). Retrieved November 8, 2010 from [12] Ronald L.R, Burback. (1998). The analysis phase. Retrieved November 7, 2010 from [13] Schwallbe, K. (2009). Information Technology: Project Management. [14] Wright, David. (2006). Integrating business analysis artifacts for information system requirements. Retrieved November 7, 2010 from ifacts%20for%20information%20system%20requirements.pdf