1 / 38

Fact Finding Techniques and Structured Methodology

Fact Finding Techniques and Structured Methodology. OUTLINE OF CLASS. Discussion Fact Finding Interviews, Questionnaires, Prototypes etc. Ethics and Strategy Structured Analysis and Design Structured Programming (COBOL) Systems Analysis Strategies. What is Fact-Finding?.

Download Presentation

Fact Finding Techniques and Structured Methodology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


Presentation Transcript

  1. Fact Finding Techniquesand Structured Methodology

  2. OUTLINE OF CLASS • Discussion • Fact Finding • Interviews, Questionnaires, Prototypes etc. • Ethics and Strategy • Structured Analysis and Design • Structured Programming (COBOL) • Systems Analysis Strategies

  3. What is Fact-Finding? • Fact-finding is the formal process of using research, interviews, questionnaires, sampling, and other techniques to collect information about systems, requirements, and preferences. It is also called information gathering or data collection.

  4. When do you perform fact-finding? • Fact-finding is most crucial to the systems planning and systems analysis phases that the analyst learns about the vocabulary, problems, opportunities, constraints, requirements, and priorities of a business and a system.

  5. What Fact-Finding Methods are Available? 1. Sampling of existing documentation, forms, and databases 2. Research and site visits 3. Observation of the work environment 4. Questionnaires 5. Interviews 6. Prototyping

  6. Traditional Methods for Determining Requirements • Interviewing and Listening • Gather facts, opinions and speculations • Observe body language and emotions • Guidelines • Plan • Checklist • Appointment • Be neutral • Listen • Seek a diverse view

  7. Traditional Methods for Determining Requirements • Interviewing (Continued) • Interview Questions • Open-Ended • No pre-specified answers • Close-Ended • Respondent is asked to choose from a set of specified responses • Additional Guidelines • Do not phrase questions in ways that imply a wrong or right answer • Listen very carefully to what is being said • Type up notes within 48 hours • Do not set expectations about the new system

  8. Traditional Methods for Determining Requirements • Administering Questionnaires • More cost-effective than interviews • Choosing respondents • Should be representative of all users • Types of samples • Convenient • Random sample • Purposeful sample • Stratified sample

  9. Traditional Methods for Determining Requirements • Questionnaires • Design • Mostly closed-ended questions • Can be administered over the phone or in person • Vs. Interviews • Interviews cost more but yield more information • Questionnaires are more cost-effective • See table 7-4 for a complete comparison

  10. Traditional Methods for Determining Requirements • Interviewing Groups • Advantages • More effective use of time • Enables people to hear opinions of others and to agree or disagree • Disadvantages • Difficulty in scheduling • Nominal Group Technique • Facilitated process to support idea generation by groups • Individuals work alone to generate ideas which are pooled under guidance of a trained facilitator

  11. Traditional Methods for Determining Requirements • Directly Observing Users • Serves as a good method to supplement interviews • Often difficult to obtain unbiased data • People often work differently when being observed

  12. Analyzing Procedures and Other Documents • Types of information to be discovered: • Problems with existing system • Opportunity to meet new need • Organizational direction • Names of key individuals • Values of organization • Special information processing circumstances • Reasons for current system design • Rules for processing data

  13. Analyzing Procedures and Other Documents • Four types of useful documents • Written work procedures • Describes how a job is performed • Includes data and information used and created in the process of performing the job or task • Business form • Explicitly indicate data flow in or out of a system • Report • Enables the analyst to work backwards from the report to the data that generated it • Description of current information system

  14. What is Prototyping? • The prototyping approach is an iterative process involving a close working relationship between the designer and the users. • Prototyping is an engineering technique used to develop partial, but functional versions of a system or applications. When extended to system design and construction, a prototype can evolve into the final, implemented system.

  15. Two ‘flavors’ of prototyping are applicable to systems analysis: • Feasibility prototyping is used to test the feasibility of a specific technology that might be applied to the business problem. • Discovery prototyping (sometimes called requirements prototyping) is used to ‘discover’ the users’ business requirements by having them react to a ‘quick-and-dirty’ implementation of those requirements.

  16. How you work with Prototyping Tools? • Prototypes can be quickly developed using many of the 4GLs and object-oriented programming languages available today. • Prototypes can be built for simple outputs, computer dialogues, key functions, entire subsystems, or even the entire system.

  17. Each prototype system is reviewed by end-users and management, who make recommendations about requirements, methods, and formats. • The prototype is then corrected, enhanced, or refined to reflect the new requirements. • The revision and review process continues until the prototype is accepted.

  18. Fact-Finding Ethics • More often than not during your fact finding exercises you may come across or be analyzing information which is sensitive in nature. • The analyst must take great care to protect the data they have been entrusted with. • Washington, D.C. is the home of the Computer Ethics Institute, a nonprofit research, education and policy study organization. • It strives to make people more aware of computer ethics and to use computers more responsibly. • One of their primary goals is to make computer ethics part of the standard school curriculum and to promote more awareness they have published The Ten Commandments of Computer Ethics.

  19. A Fact-Finding Strategy • Always better to collect as many facts as possible before using interviews (from existing documents, forms, reports, and files). • If appropriate, observe the system in action. • Given all the facts that you've already collected, design and distribute questionnaires to clear up things you don't fully understand. • Conduct your interviews (or group work sessions, such as JAD or RAD). • Follow up.

  20. Strategies for Systems Analysis and Problem Solving • Modern Structured Analysis • Model • Model-driven development • Process Models - Data Flow Diagrams (DFDs)

  21. Structured Systems Analysis and Design Methodology (SSADM) • A systems approach to the analysis and design of information systems. • Involves the application of a sequence of analysis, documentation and design tasks. • Uses a combination of text and diagrams throughout the whole life cycle of a system design, from the initial design idea to the actual physical design of the application.

  22. SSADM (cont.) • SSADM uses a combination of three techniques: • Logical Data Modeling • Data Flow Modeling • Entity Behavior Modeling

  23. Structured programming • A subset or subdiscipline of procedural programming, one of the major programming paradigms. It is most famous for removing or reducing reliance on the GOTO statement (also known as "go to"). • Break larger pieces of code into shorter subroutines (functions, procedures. methods, blocks, or otherwise) that are small enough to be understood easily.

  24. COBOL • COBOL is a third-generation programming language. Its name is an acronym, for COmmon Business Oriented Language, defining its primary domain in business, finance, and administrative systems for companies and governments. • COBOL did not support local variables, recursion, dynamic memory allocation, or structured programming constructs. Support for some or all of these features has been added in later editions of the COBOL standard.

  25. Structure of COBOL (Example) • See handout (COBOL.doc) downloadable from BB or my Websitehttp://www.nku.edu/~sakaguch/ifs310/COBOL.doc • COBOL has four divisions (Identification, Environment, Data, and Procedure), with Procedure division taking care of all the logics of the program.

  26. Structure Chart

  27. What is System Analysis? • Systems analysis is the dissection of a system into its component pieces for purposes of studying how those component pieces interact and work. • Systems analysis is (1) thesurvey and planning of the system and project, (2) the study and analysis of the existing business and information system, and (3) the definition of business requirements and priorities for a new or improved system. A popular synonym is logical design.

  28. The Survey Phase • Survey Problems, Opportunities, and Directives • Negotiate Project Scope • Plan The Project • Present The Project

  29. Outputs of Survey Phase • Project Charter • Problem Statement • Scope Statement

  30. The Study Phase • Model the Current System • The overriding modeling strategy is information hiding. • Data, Process, and Geographic Modeling • Analyze Problems and Opportunities • cause/effect analysis.

  31. The Study Phase (cont.) • Establish System Improvement Objectives and Constraints • Modify Project Scope and Plan • Present Findings and Recommendations

  32. The Definition Phase • Outline Business Requirements • Model Business System Requirements • Logical models depict what a system is, or what a system must do – not ‘how’ the system will be implemented. Because logical models depict the essence of the system, they are sometimes called essential models

  33. Model Business System Requirements • Data Modeling • Process Modeling • Geographic Modeling (Network Modeling) • Object Modeling

  34. The Definition Phase (cont.) • Build Discovery Prototypes (opt.) • Prioritize Business Requirements • Timeboxing is a technique which develops larger fully functional systems in versions. • Modify the Project Plan and Scope

  35. Deliverables • Business Requirements Statement • “Big Picture” of the system • Trigger of the systems design

  36. Assignment Project • Objectives • To be familiar with the tools of Systems Analysis and Design. • Assignment 1 is a tutorial for MS Visio which will be used to create diagrams (such as DFDs and ER diagrams) • Next week, we discuss Process Modeling and Data Flow Diagrams (DFDs) and practice a series of DFDs as a group project.

More Related