TMF1913 System Analysis & Design Learning Unit 1 PDF

TMF1913 SYSTEM ANALYSIS & DESIGN Learning Unit 1: Assuming the Role of the System Analyst Adapted or modified by the SA&D Team Semester 1, 2024-2025 Learning Objectives » Understand the need for systems analysis and design in organizations. » Realize what the many roles...

TMF1913 SYSTEM ANALYSIS & DESIGN Learning Unit 1: Assuming the Role of the System Analyst Adapted or modified by the SA&D Team Semester 1, 2024-2025 Learning Objectives » Understand the need for systems analysis and design in organizations. » Realize what the many roles of the systems analyst are. » Demonstrate phases in the systems development life cycle (SDLC) » Comprehend the fundamentals of three development methodologies: ⋄ SDLC ⋄ Object-oriented Systems Analysis and Design ⋄ The Agile approach » Understand how to improve efficiency for users who are knowledge workers using either structured methods or agile modeling. Major Topics » Need for Systems Analysis and Design Image Source: Google » Roles of systems analysts » Phases in the systems development life cycle (SDLC) as they relate to Human-Computer Interaction (HCI) factors » Fundamentals of three system development methodologies » Open Source Software (alternative of traditional software development) Information - A Key Resource » Fuels business and can be the critical factor in determining the success or failure of a business » Needs to be managed correctly » Managing computer-generated information differs from handling manually produced data Image Source: https://www.righttoinformation.wiki/explanations/information Need for Systems Analysis and Design » Installing a system without proper planning leads to great user dissatisfaction and frequently causes the system to fall into disuse » Lends structure to the analysis and design of information systems » A series of processes systematically undertaken to improve a business through the use of computerized information systems Question List the advantages of using systems analysis and design techniques in approaching computerized information systems for business. Roles of the Systems Analyst » The analyst must be able to work with people of all descriptions and be experienced in working with computers Three Consultant primary Supporting expert roles: Agent of change Qualities of the Systems Analyst Problem Communicator solver Strong Self- personal and disciplined professional and self- ethics motivated  Class Activity » Find examples of people or yourself who use systems. » List the systems, the position titles of the users, and the business functions that the systems support. Systems Development Life Cycle (SDLC) » The systems development life cycle is a phased approach to solving business problems. » Developed through the use of a specific cycle of analyst and user activities. Consists of seven phases, each phase has unique user activities. Incorporating Human-Computer Interaction (HCI) Considerations » The demand for analysts who are capable of incorporating HCI into the systems development process keeps increasing, as companies begin to realize that the quality of systems and the quality of work life can be improved by taking a human- centered approach at the outset of a project. » HCI is that aspect of a computer that enables communications and interactions between human and computer. » Implementing HCI into SDLC implies emphasizing people rather than the work to be done or the IT that is involved. SDLC Phase 1: Identifying Problems, Opportunities, and Objectives » Critical to the success of the rest of the project, because no one wants to waste time addressing the wrong problem. Problems generally the reason the analyst was called in in the first place. Opportunities situations that the analyst believes can be improved through the use of computerized information systems. Objectives how can the business reach its objectives by addressing specific problems or opportunities. SDLC Phase 1: Identifying Problems, Opportunities, and Objectives ACTIVITY OUTPUT Interviewing user management Feasibility report containing problem definition and Summarizing the knowledge obtained objective summaries from which management can make Estimating the scope of the project a decision on whether to proceed with the proposed Documenting the results project. SDLC Phase 2: Determining Human Information Requirements » Determining human needs of the users involved. » Uses activities to pose and answer questions concerning human-computer interaction: ⋄ What are the users strengths and limitations? WHO the people who are involved WHAT the business activity Trying to understand what WHERE the environment in which the information work takes place users need to WHEN the timing perform their jobs. how the current procedures are HOW performed why the system uses the current WHY system SDLC Phase 2: Determining Human Information Requirements Activity Output ▪ Interviewing ▪ The analyst understands how users accomplish their work ▪ Sampling and investing hard when interacting with a data computer ▪ Questionnaires ▪ Begin to know how to make the new system more useful ▪ Observe the decision maker’s and usable behavior and environment ▪ Know the business functions ▪ Prototyping ▪ Have complete information on the: ▪ Learn the who, what, where, when, how, and why ▪ People ▪ Goals of the current system ▪ Data ▪ Procedures involved  SDLC Phase 3: Analyzing System Needs Activity Create data flow, Analyze the Complete the data Prepare and present activity, or sequence structured decisions dictionary the system proposal diagrams made Output Recommendation on what, if anything, should be done SDLC Phase 4: Designing the Recommended System » Uses the information collected earlier to accomplish the logical design of the information system Activity Output Design procedures for data entry Model of the actual Design the human-computer interface system Design system controls Design database and/or files Design backup procedures SDLC Phase 5: Developing and Documenting Software Activity Output System analyst works with programmers to Computer develop any original software programs Works with users to develop effective System documentation documentation Programmers design, code, and remove syntactical errors from computer programs Document software with help files, procedure manuals, and Web sites with Frequently Asked Questions (FAQs) SDLC Phase 6: Testing and Maintaining the System » Testing should take place first with sample data and then with actual data. » Testing is done by both the programmers and the analyst. » The maintenance started here is carried out routinely throughout the life of the system. updates may be performed via a vendor site on the Web. Test the information system System maintenance Output Maintenance documentation Problems, if any Updated programs Activity Documentation SDLC Phase 7: Implementing and Evaluating the System Activity Output Train users Analyst plans smooth Trained personnel conversion from old system Installed system to new system Review and evaluate system Some Researchers Estimate that the Amount of Time Spent on Systems Maintenance May Be as Much as 60% of the Total Time Spent on Systems Projects The Impact of Maintenance » Maintenance is performed for two reasons: ⋄ Removing software errors ⋄ Enhancing existing software » Over time, the cost of continued maintenance will be greater than that of creating an entirely new system. At that point, it becomes more feasible to perform a new systems study. Resource consumption over the system life Question What are the reasons for enhancing existing system? Fundamentals of Three System Development Methodologies » Structured Analysis and Design together with the Systems Development Life Cycle (SDLC) ⋄ Traditional approach ⋄ Using CASE tools approach » Object-oriented Systems Analysis and Design » The Agile approach or Agile modeling Image source: https://www.udemy.com/course/your- complete-guide-to-agile-scrum-kanban/ Case Tools » CASE tools are productivity tools for systems analysts that have been created explicitly to improve their routine work through the use of automated support ⋄ any tool used to automate some activity associated with system or software development which includes web development, mobile application development, e- commerce development etc. » Real CASE tools can be categorized into 3 following levels: ⋄ Upper — support analysis and design phases ⋄ Lower — support coding phase ⋄ Integrated — also known as I-CASE support analysis, design and coding phases Reasons for using Case Tools Increasing analyst productivity automates the drawing and modifying of diagrams automates the sharing of work thus reducing the time to collaborate with group members facilitates interaction among team members by making diagramming a dynamic, interactive process Improving analyst-user CASE tools foster greater, more meaningful communication communication among users and analysts. Integrating life cycle activities integration of activities through the underlying use of technologies makes it easier for users to understand how all the life cycle phases are interrelated and interdependent. Accurately assessing maintenance enable users to analyze and assess the changes impact of maintenance changes. Object-Oriented (O-O) Systems Analysis and Design » Alternate approach to the structured approach of the SDLC that is intended to facilitate the development of systems that change rapidly in response to dynamic business environments » Analysis is performed on a small part of the system followed by design and implementation » The cycle repeats with analysis, design, and implementation of the next part and this repeats until the project is complete » Examines the objects of a system  Object-Oriented (O-O) Systems Analysis and Design Define the use Develop and case model: document the Use case diagram system Use case scenarios Create UML Modify the UML diagrams diagrams Develop class Draw statechart diagrams diagrams  Choosing a Method When to use Object- When to use SDLC oriented Systems have been developed The problems modeled lend and documented using SLDC themselves to classes It is important to document each An organization supports the step UML learning Upper level management feels Systems can be added gradually, more comfortable or safe using one subsystem at a time SDLC Reuse of previously written There are adequate resources software is a possibility and time to complete the full It is acceptable to tackle the SDLC difficult problems first Communication of how new systems work is important Strategies for Improving Efficiency Can Be Implemented Using Two Different Development Approaches Open Source Software » An alternative of traditional software development where proprietary code is hidden from the users » Open source software is free to distribute, share, and modify » Characterized as a philosophy rather than simply the process of creating new software ⋄ Examples: Linux Operating System, Apache Web Server, Mozilla Firefox » Contributions to the open community and differentiation from the open community are for the following reasons: ⋄ Cost ⋄ Managing resources ⋄ Time it takes to bring a new product to the market Open Source Communities Four Types of Open Source Communities General structure Ad hoc Environment Six Key Goals Standardized Dimensions that Differentiate Open Source Communities Methods Organized User community Commercial Licensing Summary » Information is a key resource » Integration of traditional systems with new technologies » Roles and qualities of the systems analyst » The Systems Development Life Cycle (SDLC) » Fundamentals of three system development methodologies ⋄ Structured Analysis and Design together with the Systems Development Life Cycle (SDLC) ⋄ Traditional approach ⋄ Using CASE tools approach ⋄ Object-oriented Systems Analysis and Design ⋄ The Agile approach or Agile modeling » Open source software TMF1913 SYSTEM ANALYSIS & DESIGN Learning Unit 4: Agile Modeling and Prototyping Adapted or modified by the SA&D Team Semester 1, 2024-2025 Learning Objectives » Understand the roots of agile modeling in prototyping and the four main types of prototyping » Use prototyping for human information requirements gathering » Understand the agile modeling and the core practices that differentiate it from other development methodologies » Learn the importance of values critical to agile modeling » Understand how to improve efficiency for users who are knowledge workers using either structured methods or agile modeling Agile Modeling, but First Prototyping » Agile modeling is a collection of innovative, user-centered approaches to system development » Prototyping is an information-gathering technique useful in seeking ⋄ Revision plans ⋄ Innovations ⋄ Suggestions ⋄ User reactions Image Source: User experience design, Illustration by Claire Murray Prototyping Four kinds of prototypes Patched-up Nonoperational First-of-a-series Selected features  Four Kinds of Prototypes Patched-Up Prototype Non Operational Scale Models A system that works but is patched up A nonworking scale model that is set up or patched together to test certain aspects of the design A working model that has all the A nonworking scale model of an features but is inefficient information system might be produced when the coding required by the Users can interact with the system application is too expensive to prototype Retrieval and storage of information but when a useful idea of the system can maybe inefficient. be gained through prototyping of the input and output only. 5  Four Kinds of Prototypes First-of-a-Series Prototype Selected Features Prototype Creating a pilot Building an operational model that Prototype is completely operational includes some, but not all, of the features that the final system will Useful when many installations of the have same information system are planned Some, but not all, essential features A full-scale prototype is installed in one or are included two locations first, and if successful, duplicates are installed at all locations Built in modules based on customer usage patterns and Part of the actual system other key factors  Prototyping Two main problems with the System Development Life Cycle (SDLC) Extended time required to go through the development life Prototyping as an cycle alternative to the SDLC User requirements change over time Rather than using prototyping to replace the SDLC use prototyping as a part of the SDLC Drawbacks include prematurely shaping a system before the problem or opportunity is thoroughly understood Drawbacks to Supplanting Using prototyping as an alternative may result in producing a the SDLC with Prototyping system that is accepted by specific groups of users but is inadequate for overall system needs Guidelines for Developing a Prototype » Prototyping is a superb way to elicit feedback about the proposed Work in Build the system and about how readily it is manageable prototype fulfilling the information needs of its modules rapidly users. Modify the » The first step of prototyping is to Stress the prototype in user estimate the costs involved in interface successive iterations building a module of the system. Work in Manageable Modules » It is imperative that an analyst work in manageable modules » One distinct advantage of prototyping is that it is not necessary or desirable to build an entire working system for prototype purposes » A manageable module allows users to interact with its key features but can be built separately from other system modules » Module features that are deemed less important are purposely left out of the initial prototype Build the Prototype Rapidly » Speed is essential for successful prototyping » Analysts can use prototyping to shorten this gap by using traditional information-gathering techniques to find information requirements » Make decisions that bring forth a working model » Putting together an operational prototype rapidly and early in the SDLC allows an analyst to gain insight about the remainder of the project » Showing users early in the process how parts of the system actually perform guards against overcommitting resources to a project that may eventually become unworkable Modify the Prototype in Successive Iterations » Making a prototype modifiable means creating it in modules that are not highly interdependent » The prototype is usually modified several times » Changes should move the system closer to what users say is important » Each modification is followed by an evaluation by users Stress the User Interface » Use the prototype is to get users to further articulate their information requirements » They should be able to see how the prototype will enable them to accomplish their tasks » The user interface must be well-developed enough to enable users to pick up the system quickly » Online, interactive systems using GUI interfaces are ideally suited to prototypes » Sometimes the quickest way to prototype is through the modular installation of COTS software. Some COTS software is elaborate and expensive, but highly useful. » Example: Catholic University’s use of the ERP COTS software package called PeopleSoft, which is handling many of its web-based functions.  Pros and Cons of Prototyping Potential for changing the system early in its development Advantages of Opportunity to stop development on a system Prototyping that is not working Possibility of developing a system that more closely addresses users’ needs and expectations It can be difficult to manage prototyping as a project in the larger systems effort Disadvantages of Prototyping Users and analysts may adopt a prototype as a completed system Stress the User Interface » Honest involvement » Experimenting with the prototype » Giving open reactions to the prototype » Suggesting additions to or deletions from the prototype Image Source: User experience design, Example of a prototype evaluation form Illustration by Claire Murray Agile Modeling » Agile methods are a collection of innovative, user-centered approaches to systems development Values and Principles of Agile Modeling » Communication » Simplicity » Feedback » Courage The Basic Principles of Agile Modeling 1. Satisfy the customer through delivery of working software 2. Embrace change, even if introduced late in development 3. Continue to deliver functioning software incrementally and frequently 4. Encourage customers and analysts to work together daily 5. Trust motivated individuals to get the job done 6. Promote face-to-face conversation 7. Concentrate on getting software to work The Basic Principles of Agile Modeling 8. Encourage continuous, regular, and sustainable development 9. Adopt agility with attention to mindful design 10. Support self-organizing teams 11. Provide rapid feedback 12. Encourage quality 13. Review and adjust behavior occasionally 14. Adopt simplicity Four Basic Activities of Agile Modeling » The agile analyst needs to identify the amount of effort that will go into each activity and balance that with the resources needed to complete the project. » Coding - the most valuable thing that we receive from code is “learning.” Coding Testing » Testing - the agile approach views automated tests as critical. » Listening - in the agile approach, listening is done in the extreme. Listening Designing » Designing - a way of creating a structure to organize all of the logic in the system. Coding » Coding is the one activity that it is not possible to do without » The most valuable thing that we receive from code is “learning” » Code can also be used to communicate ideas that would otherwise remain fuzzy or unshaped Testing » Automated testing is critical » Write tests to check coding, functionality, performance, and conformance » Use automated tests » Large libraries of tests exist for most programming languages » These are updated as necessary during the project » Testing in the short term gives extreme confidence in what you are building » Testing in the long term keeps a system alive and allows for changes longer than would be possible if no tests were written or run Listening » Listening is done in the extreme » Developers use active listening to hear their programming partner » Because there is less reliance on formal, written communication, listening becomes a paramount skill » A developer also uses active listening with the customer » Developers assume that they know nothing about the business so they must listen carefully to businesspeople Designing » Designing is a way of creating a structure to organize all the logic in the system » Designing is evolutionary, and so systems are conceptualized as evolving, always being designed » Good design is often simple » Design should allow flexibility » Effective design locates logic near the data on which it will be operating » Design should be useful to all those who will need it as the development effort proceeds Four Resource Control Variables of Agile Modeling When these four control variables are properly included in the planning, there is a state of balance between the resources and the activities needed to Time Quality complete the project. Cost Scope Four Basic Activities of Agile Modeling 1. Short releases - the development team compresses the time between releases of their product. Short 40-hour work 2. 40-hour work week - agile development teams releases week purposely endorse a cultural core practice in which the team works intensely together during a typical 40-hour work week. 3. Onsite customer - a user who is an expert in the business aspect of the systems development Onsite Pair work is onsite during the development process. customer programming 4. Pair programming - you work with another programmer of your own choosing. Agile Core Practices  The Agile Development Process Listen for user stories Draw a logical workflow model Create new user stories based on the logical model Develop some display prototypes Create a physical data model using feedback from the prototypes and logical workflow diagrams Writing User Stories » Spoken interaction between developers and users » Seeking first and foremost to identify valuable business user requirements » The goal is prevention of misunderstandings or misinterpretations of user requirements User stories can be recorded on cards  in which a list is derived Product Scrum backlog from product specifications. » Scrum is a high-intensity a dynamically changing list methodology. Sprint of tasks to be completed in backlog the next sprint. » It is just one of the approaches that adopts the philosophy of agile a 30-day period in which the modeling. Sprint development team transforms the backlog into software that » For additional note, please watch can be demonstrated. this video: a brief meeting in which https://www.scrumalliance.org/about- scrum/overview?wvideo=p7novk9lc6 Daily scrum communication is the number-one rule. working software that can Demo be demonstrated to the customer. Scrum Image source: What is Scrum? - An Overview, URL: https://www.ics.ie/news/view/1653 Six Vital Lessons That Can Be Drawn from the Agile Approach to Systems Comparing Agile Modeling and Structured Methods Improving the efficiency of systems development Risks inherent in organizational innovation Lessons Learned from Agile Modeling Short releases allow the system to evolve through the use of short releases, the development team compresses the time between releases of their product, improving the product later as the dynamic situation demands. Pair programming enhances overall quality fosters good communication, identifying with the customer, focusing on the most valuable aspects of the project first, testing all code as it is developed, and integrating the new code after it successfully passes its tests. Onsite customers are mutually beneficial to the business and the agile development team customers serve as a ready reference and reality check, and the focus of the system design will always be maintained via their presence. Lessons Learned from Agile Modeling (con’t) The 40-hour work week improves worker effectiveness even the hardest-hitting developers are susceptible to errors and burnout if they work too hard for too long a period. Balanced resources and activities support project goals the resource control variables of time, cost, quality, and scope need to be properly balanced with the activities of coding, designing, testing, and listening. Agile values are crucial to success it is essential to the overall success of the project that analysts wholeheartedly embrace the values of communication, simplicity, feedback, and courage in all of the work that they do. Strategies for Improving Efficiency Can Be Implemented Using Two Different Development Approaches Adopting New Information Systems Involves Balancing Several Risks Fit of development team culture » In consultation with users, analysts Programmers/ analysts individual rights must consider the risks that Best time to innovate organizations face when adopting new methodologies. » Shows many of the variables that need to be considered when Training cost for analysts Impact of agile methodologies assessing the risk of adopting and programmers organizational innovation. Client’s reaction to new methodology Summary » Prototyping » Patched-up system » Nonoperational » First-of-a-series » Selected-features » Prototype development guidelines » Prototype disadvantages and advantages » Users’ role in prototyping Summary » Agile modeling » Five values of the agile approach » Principles of agile development » Agile activities » Agile resources » Core practices of the agile approach » Stages in the agile development process » User stories » Agile lessons » Scrum methodology » Open source software Adapted or modified by the SA&D Team Semester 1, 2024-2025 ▪ Understand that organizations and their members are systems and that analysts need to take a systems perspective. ▪ Depict systems graphically using context-level data flow diagrams, and entity-relationship models, use cases, and use case scenarios. ▪ Recognize that different levels of management require different systems. ▪ Comprehend that organizational culture impacts the design of information systems. 2 Levels of management Design of organizations Organizational cultures 3 ▪ Organizations as systems ▪ Depicting systems graphically ▪ Data flow diagram (DFD) ▪ Entity-relationship model/ diagram (ERD) ▪ Use case modeling ▪ Levels of management ▪ Organizational culture 4 ▪ Influenced by levels of management decision makers that cut horizontally across the organizational system ▪ Operations ▪ Middle management ▪ Strategic management ▪ Influenced by organizational cultures and subcultures 5  as Systems ▪ Conceptualized as systems designed to accomplish predetermined goals and objectives ▪ Composed of smaller, interrelated systems serving specialized functions ▪ Specialized functions are reintegrated to form an effective organizational whole ▪ System and subsystem boundaries and environments impact on information system analysis and design. 6 ▪ All systems and subsystems are interrelated and interdependent ▪ All systems process inputs from their environments ▪ All systems are contained by boundaries separating them from their environments ▪ System feedback for planning and control ▪ An ideal system self-corrects or self-regulates itself. /ENVIRONMENT 7 Question What does it mean with interrelatedness and interdependence of systems? 8 Feedback is received both internal and external to the organization. Anything external to an organization’s boundaries is considered to be an environment. 9  Physical location Community Demographic profile (education, income) Market factors Economic Competition State and local Political government Federal, state, Legal regional, local laws, and guidelines 10  Free flow of information Output from one system becomes input to Open another Restricted access to information Limited by numerous rules Closed Information only on a “need to know” basis 11 ▪ A virtual organization has parts of the organization in different physical locations ▪ Computer networks and communications technology are used to bring virtual teams together to work on projects Organizations of remote workers, Image source: Microsoft clip art 12 ▪ Possibility of reducing costs of physical facilities ▪ More rapid response to customer needs ▪ Helping virtual employees to fulfill their familial obligations to children or aging parents Virtual Organizations, Image source: Microsoft clip art 13  Allows system analyst to understand businesses before they begin their tasks It is important that members of subsystems realize that they are interrelated with other subsystems Problems occur when each manager thinks that his/her department is the most important Bigger problems may occur when that manager rises through the ranks 14 Outputs from one department serve as inputs for another such that subsystems are interrelated. 15 In his/her new position, the former manager may still think of his/her old department as the most important. The potential for this problem to occur exists in almost any business. If the analyst interviews this manager early on, he/she may get a distorted view of the company structure. 16 Question Why it is important for system analysts to take a Systems Perspective? 17 ▪ Enterprise Systems or Enterprise Resource Planning (ERP) describes an integrated organizational information system ▪ Software that helps the flow of information between the functional areas within the organization ▪ ERP systems include: ▪ manufacturing components ▪ sales and operations planning ▪ distribution ▪ managing the supply train 18 Image source: https://www.javatpoint.com/erp-full-form ▪ ERP can affect every aspect of the organization, including: ▪ Design of employees’ work ▪ Skills required for job competency ▪ Strategic positioning of the company Image source: https://i.pinimg.com/ ▪ Problems with implementation: ▪ Difficult to analyze a system currently in use and then fit the ERP model to that system ▪ Companies tend to design their business processes before ERP is implemented 19 ▪ Many issues must be overcome for the ERP installation is to be declared a success: User acceptance Integration with legacy systems and the supply chain Upgrading functionality (and complexity) of ERP modules Reorganizing work life of users and decision makers Expanded reach across several organizations Strategic repositioning of the company 20  Context-level data flow diagrams Entity-relationship model Use case modeling Image source: All images are from Microsoft clip art 21 ▪ Focus is on the data flowing into and out of the system and the processing of the data ▪ Shows the scope of the system: ▪ What is to be included in the system ▪ The external entities are outside the scope of the system ▪ The basic symbols of a Data Flow Diagram (DFD) Process: transforms incoming data into outgoing information, the content level has only one process representing the entire system. Entity: entity, a person, group, department, or system that supplies or receives information. Data flows: the lines that connect external entities to the process. 22 Example of a context-level data flow diagram for an airline reservation system 23 ▪ Focus is on the entities and their relationships within the organizational system ▪ Another way to show the scope of a system ▪ Entity-relationship diagrams help the analyst understand the organizational system and the data stored by the organization. ▪ Relationships show how the entities are connected ▪ Three types of relationships: ▪ One-to-one ▪ One-to-many ▪ Many-to-many Example: An entity-relationship diagram 24 showing a many-to-one relationship Examples of Different Types of Relationships in E-R Diagrams Attributes (in E-R Diagrams) ▪ Data attributes may be added to the diagram. Patron Name Patron Patron address Patron phone Patron credit card 25 1) List the entities in the organization 2) Choose key entities to narrow the scope of the problem 3) Identify what the primary entity should be 4) Confirm the results of the above through data gathering 26 ▪ Describes what a system does without describing how the system does ▪ A logical model of the system ▪ Use case is a view of the system requirements ▪ Analyst works with business experts to develop requirements ▪ A use case always provides three things: ▪ An actor that initiates an event ▪ The event that triggers a use case ▪ The use case that performs the actions triggered by the event 27  Refers to a particular role of a user of the system Actor Similar to external entities; they exist outside of the system An oval indicating Use case symbols the task of the use case Arrows and lines used to diagram Connecting lines behavioral relationships 28 ▪ System scope defines its boundaries: ▪ What is in or outside the system ▪ Project has a budget that helps to define scope ▪ Project has a start and an end time ▪ Actors are always outside of scope ▪ Communication lines are the boundaries and define the scope 29 30 STEP 1 Review the business specifications and identify the actors involved STEP 2 May use agile stories Identify the high-level events and develop the STEP 3 primary use cases that describe those events and how the actors initiate them STEP 4 Review each primary use case to determine the possible variations of flow through the use case STEP 5 The context-level data flow diagram could act as a starting point for creating a use case 31 32 Four Steps Use agile stories, problem Determine if The use case Ask about the definition there are any ends when the tasks that must objectives, user iterative or customer goal is be done requirements, or looping actions complete a features list 33 ▪ Identify all the actors in the problem domain ▪ Actions that need to be completed are also clearly shown on the use case diagram ▪ The use case scenario is also worthwhile ▪ Simplicity and lack of technical detail 34 Identify all the actors in the systems analyst can concentrate on what humans want and need to use the system, extend their capabilities, and the problem domain enjoy their interaction with technology. Actions that need to be completed are also this makes it easy for the analyst to identify processes and aids in communication with other analysts on the team clearly shown on the use and business executives case diagram The use case scenario is because a lot of the information the users impart to the analysts are in story form, it is easy to capture on the use also worthwhile case scenario form. Simplicity and lack of used to show the scope of a system, along with the major features of the system and the actors that work with technical detail those major features. 35 effectiveness in communicating with users capturing of user stories 36 Management in organizations exists on three broad, horizontal levels which is Operational Control, Managerial Planning and Control, and Strategic Management. Each level carries its own responsibilities, and all work toward achieving organizational goals and objectives in their own ways. 37  Make decisions using predetermined rules that have Operations predictable outcomes Control Oversee the operating details of the organization Make short-term planning and control decisions about Managerial resources and organizational Planning and objectives Control Decisions may be partly operational and partly strategic Look outward from the organization to the future Make decisions that will guide middle Strategic and operations managers Management Work in highly uncertain decision- making environment Define the organization as a whole 38 ▪ Different organization structure ▪ Leadership style ▪ Technological considerations ▪ Organization culture ▪ Human interaction ▪ All carry implications for the analysis and design of information systems 39 Operations managers need internal information that is of a repetitive, low-level nature highly dependent on information that captures current performance large users of online, real-time information resources need for past performance information and periodic information is moderate have little use for external information that allows future projections Middle management in need of both short and longer-term information need for information in real time need current information on performance as measured against set standards highly dependent on internal information need for historical information, along with information that allows prediction of future events Strategic management highly dependent on information from external sources that supply news of market trends and the strategies of competing corporations high need for information of a predictive nature 40 need for periodically reported information ▪ Organizations have cultures and subcultures ▪ Learn from verbal and nonverbal symbolism Definitions of organizational culture, Image source: BuisnessDictionary.com 41 Verbal Symbolism Myths Metaphors Visions Humor Nonverbal Symbolism Shared artifacts Trophies, etc. Rites and rituals Promotions Birthdays, etc. Clothing worn Office placement and decorations 42 ▪ Organizational fundamentals ▪ Organizations as systems ▪ Levels of management ▪ Organizational culture ▪ Graphical representation of systems ▪ DFD ▪ ERD ▪ Use case diagrams and scenarios ▪ Levels of managerial control ▪ Operational ▪ Middle management ▪ Strategic ▪ Organizational culture 43 ▪ Design DFD Diagram 0 ▪ https://youtu.be/Ik85hZkyYPA ▪ Design Entity-Relationship Model ▪ https://youtu.be/Tg_8UYoKoQ8 ▪ Use case modelling ▪ https://youtu.be/RMuMz5hQMf4 44 TMF1913 SYSTEM ANALYSIS & DESIGN Learning Unit 3: Information Gathering: Interactive Methods Adapted or modified by the SA&D Team Semester 1, 2024-2025 Major Topics » Interviewing » Questionnaires » Interview preparation » Writing questions » Question types » Using scales » Arranging questions » Design » The interview report » Administering » User Stories » Joint Application Design (JAD) » Involvement » Location Learning Objectives » Recognize the value of interactive methods for information gathering. » Construct interview questions to elicit human information requirements and structure them in a way that is meaningful to users. » Understand the purpose of stories and why they are useful in systems analysis. » Understand the concept of JAD and when to use it. » Write effective questions to survey users about their work. » Design and administer effective questionnaires. This Photo by Unknown Author is licensed under CC BY-SA-NC What is Requirements Determination? » A requirement is a vital feature of a new system which may include processing or capturing of data, controlling the activities of business, producing information and supporting the management. » Requirements determination involves studying the existing system and gathering details to find out: what are the requirements, how it works, and where improvements should be made. Major Activities in Requirement Determination Requirements Requirements Anticipation Requirements Investigation Specifications Predicts the characteristics It is studying the current Includes the analysis of of system based on previous system and data which determine the experience which include requirement specification, certain problems or features documenting its and requirements for a new features for further description of features for system. analysis. new system, and specifying what It can lead to analysis of It is at the heart of areas that would otherwise information requirements system analysis where will be provided. go unnoticed by analyst documenting inexperienced analyst. Includes analysis of and describing system But if shortcuts are taken and factual data, bias is introduced in features using fact- identification of essential conducting the investigation, finding techniques, requirements, and then Requirement prototyping, and selection of Requirement- Anticipation can be half- computer assisted baked. fulfillment strategies. tools. Interviewing » Interviewing is an important method for collecting data on human and system information requirements » Interviews reveal information about: ⋄ Interviewee opinions ⋄ Interviewee feelings ⋄ Goals ⋄ Key HCI concerns Image source: http://bluestudies.com/cv-interview-skills-info-session/ Interview Preparation read and understand as much background information about the interviewees 1 Reading background material and their organization as possible. E.g. corporate website, current annual report, corporate news letter, any publication sent out to explain the organization to the public, Standard & Poor’s trying to build a common vocabulary to phrase interview questions and to maximize the interview time. 2 Establishing interview objectives four to six key areas concerning HCI, information processing and decision- making behavior. 3 Deciding whom to interview include people at all levels who will affected by the system in some manner. strive for balance so that as many users’ needs are addressed as possible. 4 Preparing the interviewee call ahead; keep to 45 minutes to an hour at the most. 5 Decidingstructure on question types and write questions to cover the key areas of HCI and decision making that you discovered when you ascertained interview objectives. Interview Question Types Open- ended Closed Open-Ended Interview Questions » Open-ended interview questions allow interviewees to respond how they wish, and to what length they wish » Open-ended interview questions are appropriate when the analyst is interested in breadth and depth of reply Source: http://www.orafitnessinstitute.com.au/open-ended-questions/ This Photo by Unknown Author is licensed under CC BY Open-Ended Interview Questions » Consider the term open-ended. “Open” actually describes the interviewee’s options for responding. They are open. » The response can be two words or two paragraphs. » Some examples of open-ended questions are shown here. Source: https://www.w3computing.com/systemsanalysis/open-ended-closed-interview- questions/ This Photo by Unknown Author is licensed under CC BY  Open-Ended Interview Questions Puts the interviewee at ease Allows the interviewer to pick up on the May result in too much irrelevant interviewee’s vocabulary detail Provides richness of detail Possibly losing control of the Advantages interview Disadvantages Reveals avenues of further questioning that may have gone untapped May take too much time for the Provides more interest for the interviewee amount of useful information gained Allows more spontaneity Potentially seeming that the interviewer is unprepared Makes phrasing easier for the interviewer Possibly giving the impression that the interviewer is on a “fishing expedition” Useful if the interviewer is unprepared Closed Interview Questions » Closed interview questions limit the number of possible responses » Closed interview questions are appropriate for generating precise, reliable data that is easy to analyze » The methodology is efficient, and it requires little skill for interviewers to administer A closed question limits the response available to the interviewee. You may be familiar with closed questions through multiple-choice exams in college. You are given a question and five responses, but you are not allowed to write down your own response and still be counted as having correctly answered the question. Source: https://home.magpi.com/tip-open-ended-questions/ Closed Interview Questions » The possible responses are closed to the interviewee, because he or she can only reply with a finite number such as “None,” “One,” or “Fifteen.” Some examples of closed questions are shown here. » Closed interview questions limit the respondent’s options. » The examples were selected from different interviews and are not shown in any particular order. Source: https://www.w3computing.com/systemsanalysis/open-ended-closed-interview-questions/ Closed Interview Questions ADVANTAGES DISADVANTAGES Saving interview time Boring for the interviewee Easily comparing interviews Failure to obtain rich detailing Getting to the point Missing main ideas Keeping control of the Failing to build rapport between interview interviewer and interviewee Covering a large area quickly Getting to relevant data Bipolar Questions This type of closed question limits the interviewee even further by allowing a choice on either “pole” » Bipolar questions are those that Examples of bipolar questions are listed here: may be answered with a “yes” or “no”, “true or false” and “agree” or “disagree” » Bipolar questions should be used sparingly » A special kind of closed question Source: https://www.w3computing.com/systemsanalysis/open-ended-closed-interview- questions/ Image source: http://jacobyip.com/are-closed- ended-questions-leading-questions/ Attributes of Open-Ended and Closed Interview Questions Thus, as the interviewer, you must think carefully about the question types you will use. Both open-ended and closed questions have advantages and drawbacks, as shown in the figure. Notice that choosing one question type over the other actually involves a trade- off; although an open-ended question affords breadth and depth of reply, responses to open-ended questions are difficult to analyze. Probes » A third type of question is the probe or follow-up » Probing questions elicit more detail about previous questions » The purpose of probing questions is: » To get more meaning » To clarify » To draw out and expand on the interviewee’s point » The strongest probe is the simplest: the question, “Why?” » Other probes are “Can you give me an example of a time you did not find the system trustworthy?” and “Will you elaborate on that for me?” » May be either open-ended or closed Probes » Probes allow the systems analyst to follow up on questions to get more detailed responses. The examples were selected from different interviews and are not shown in any particular order. Source: https://www.w3computing.com/systemsanalysis/open-ended-closed-interview-questions/ Arranging Questions Pyramid Funnel Diamond Starting with closed Starting with open- Starting with closed, questions and working ended questions and moving toward open- toward open-ended working toward closed ended, and ending questions questions with closed questions Pyramid Structure Pyramid Structure for Interviewing Goes from Specific to General » Begins with very detailed, Questions often closed questions » Expands by allowing open- ended questions and more generalized responses » Is useful if interviewees need to be warmed up to the topic or seem reluctant to address the topic Funnel Structure » Begins with generalized, open- ended questions » Concludes by narrowing the possible responses using closed questions » Provides an easy, nonthreatening way to begin an interview » Is useful when the interviewee Funnel structure for feels emotionally about the interviewing begins with broad questions then topic funnels to specific questions Diamond Structure Diamond-shaped structure for interviewing combines the pyramid and funnel structures » A diamond-shaped structure begins in a very specific way » Then more general issues are examined » Concludes with specific questions » Combines the strength of both the pyramid and funnel structures » Takes longer than the other structures Closing the Interview Image source: Google search Always ask “Is Summarize and there anything provide Ask whom you Set up any Thank them for else that you feedback on should talk with future their time and would like to your next appointments shake hands. add?” impressions Interview Report » Write as soon as possible after the interview » Provide an initial summary, then more detail » Review the report with the respondent Image source: https://www.sabusinesshub.co.za/section/preview.php?SectionId=2&SubsectionId=16&ContentId=602 Stories » Stories originate in the workplace » Organizational stories are used to relay some kind of information » When a story is told and retold over time it takes on a mythic quality » Isolated stories are good when you are looking for facts » Enduring stories capture all aspects of the organization and are the ones a systems analyst should look for Purposes for Telling a Story Systems analysts can use storytelling as a complement to other information gathering methods There are four purposes for telling a story: Validating stories are Experiential Explanatory used to stories stories tell convince Prescriptive describe what why the people that stories tell the the business organization the listener how or industry is acted a organization to act like certain way made the correct decision Joint Application Design (JAD) » Joint Application Design (JAD) can replace a series of interviews with the user community » JAD is a technique that allows the analyst to accomplish requirements analysis and design the user interface with the users in a group setting Joint Application Design (JAD) Where to hold JAD Meetings Users are restless and want something new Offsite Comfortable The organizational culture supports surroundings joint problem-solving behaviors Minimize distractions Conditions that support the use of JAD Analysts forecast an increase in the number of ideas using JAD Attendance Schedule when participants can attend Personnel may be absent from their Agenda jobs for the length of time required Orientation meeting  Who Is Involved All project team members must be committed to the JAD approach and become involved. Executive a senior person who will introduce and conclude the JAD session. sponsor IS Analyst gives an expert opinion about any disproportionate costs of solutions proposed. Users try to select users that can articulate what information they need to perform their jobs as well as what they desire in anew or improved computer system. Session leader someone who has excellent communication skills to facilitate appropriate interactions. Observers analysts or technical experts from other functional areas to offer technical explanations and advice. Scribe formally write down everything that is done. Joint Application Design (JAD) Benefits of JAD Time is saved, compared JAD requires a large with traditional block of time to be interviewing available for all session participants Rapid development of systems If preparation or the follow- Drawbacks of using up report is incomplete, Improved user the session may not be ownership of the system successful Creative idea production The organizational skills is improved and culture may not be conducive to a JAD session JAD Questionnaires Questionnaires are useful in gathering information from key organization members about: what people in the Through the use of questionnaires, the analyst may be seeking to quantify what was found in Attributes organization say they interviews. want In addition, questionnaires may be used to what people think is determine how widespread or limited a sentiment Beliefs actually true expressed in an interview really is. Conversely, questionnaires can be used to survey what organizational Behavior members do a large sample of system users to sense problems or raise important issues before interviews are scheduled. properties of people or Characteristics things Planning for the use of Questionnaires » Organization members are widely dispersed » Many members are involved with the project » Exploratory work is needed » Problem solving prior to interviews is Open-ended necessary Try to anticipate the response you will get Well suited for getting opinions Closed Use when all the options may be listed When the options are mutually exclusive  Open-ended questions used for questionnaires- examples Source: https://www.w3computing.com/systemsanalysis/writing-questions-questionnaires/ Responses to open-ended questions can help analysts gain rich, exploratory insights as well as breadth and depth on a topic. Although open-ended questions can be written easily, responses to them are difficult and time consuming to analyze. Closed questions on questionnaires help ensure responses- examples Source: https://www.w3computing.com/systemsanalysis/writing-questions-questionnaires/ Closed questions should be used when the systems analyst is able to list effectively all the possible responses to the question and when all the listed responses are mutually exclusive, so that choosing one precludes choosing any of the others. Questionnaire Language Use the language of respondents whenever possible. Keep Simple wording simple. Work at being specific rather than vague in wording. Avoid Specific overly specific questions as well. Short Keep questions short. Do not patronize respondents by talking down to them Not patronizing through low-level language choices. Avoid bias in wording. Avoiding bias also means avoiding Free of bias objectionable questions. Target questions to the correct respondents (that is, those Addressed to those who are knowledgeable who are capable of responding). Don’t assume too much knowledge. Ensure that questions are technically accurate before Technically accurate including them. Appropriate for the reading Use software to check whether the reading level is level of the respondent appropriate for the respondents. Using Scales in Questionnaires Scaling The process of assigning numbers or other symbols to an attribute or characteristic for the purpose of measuring that attribute or characteristic the writing of closed questions with either ordered or unordered answers Measurement Scales The two different forms of measurement scales are: Nominal Interval  Example: Nominal Scales What type of software do you use the most? » Nominal scales are used to classify things 1 = Word Processor » It is the weakest form of measurement 2 = Spreadsheet » Data may be totaled (of each classification) 3 = Database 4 = An Email Program Interval Scales » An interval scale is used when the intervals are equal and there is no absolute zero » Due to this characteristic, mathematical operations can be performed on the questionnaire data, resulting in a more complete analysis. E.g. the Fahrenheit or Centigrade scale The example above is definitely not that of an interval scale, but by anchoring the scale on either end, the analyst may want to assume the respondent perceives the intervals to be equal. If the systems analyst makes this assumption, more quantitative analysis is possible.  Validity and Reliability Getting the same results if the same Reliability of scales refers questionnaire was administered again under to consistency in response the same conditions For example, if the purpose of the Validity is the degree to questionnaire is to determine whether the which the question organization is ready for a major change in measures what the analyst computer operations, do the questions intends to measure measure that? Image source: http://keydifferences.com/difference-between-validity-and-reliability.html Problems with Scales » The actual construction of scales is a serious task. » Careless construction of scales can result in one of the following problems: Leniency Central tendency Halo effect Caused by easy raters Occurs when respondents rate When the impression formed in Solution is to move the everything as average one question carries into the next question “average” category to the left Improve by making the For example, if you are rating an or right of center differences smaller at the employee about whom you have two ends a very favorable impression, you Adjust the strength of the may give a high rating in every descriptors category or trait, regardless of Create a scale with more whether or not it is a strong point of the employee’s. points Solution is to place one trait and several items on each page Designing the Questionnaire A well-designed, relevant questionnaire can help overcome some resistance to respond. Allow ample white space Allow ample space to write or type in responses Make it easy for respondents to clearly mark their answers Be consistent in style When you design questionnaires for the Web, apply the same rules you use when designing paper questionnaires. Ways to capture responses when designing a Web Survey Planning for the use of Questionnaires » As you order questions, you must think about your objectives in using the questionnaire and then determine the function of each question in helping you to achieve your objectives. » It is also important to see the questionnaire through the respondent’s eyes. Some guidelines for ordering questions are: Introduce less controversial Cluster items questions first of similar Place most content important together questions first Administering Questionnaires » Deciding who will receive the questionnaire is handled in conjunction with the task of setting up objectives for its results. » Administering questionnaires has two main questions: Who in the How should the organization should questionnaire be receive the administered? questionnaire? Methods of Administering the Questionnaire » The choice of administration method is often determined by the existing business situation. » Options for administering the questionnaire include the following: Allowing respondents to Personally handing out Convening all self-administer the blank questionnaires and concerned respondents questionnaire at work and taking back completed together at one time drop it in a centrally ones. located box. Administering the questionnaire electronically Mailing questionnaires to either via email or on the Web. employees at branch sites Reduced costs and supplying a deadline, Collecting and storing the results electronically instructions, and return Response are a little lower then other methods, but postage. may result in less guarded answers Summary » Interviewing » Interview preparation » Question types » Arranging questions » The interview report » Stories » Joint Application Design (JAD) » Involvement and location » Questionnaires » Writing questions » Using scales and overcoming problems » Design and order » Administering and submitting TMF1913 SYSTEM ANALYSIS & DESIGN Learning Unit 5: Using Data Flow Diagrams Adapted or modified by the SA&D Team Semester 1, 2024-2025 Learning Objectives » Comprehend the importance of using logical and physical data flow diagrams (DFDs) to graphically depict movement for humans and systems in an organization. » Create, use, and explode logical DFDs to capture and analyze the current system through parent and child levels. » Develop and explode logical DFDs that illustrate the proposed system. » Derive physical DFDs based on logical DFDs you have developed. » Understand and apply the concept of partitioning of physical DFDs. Major Topics » Data flow diagram symbols » Basic Rules » Data flow diagram levels » Creating data flow diagrams » Logical and Physical data flow diagrams » Partitioning » Communicating using data flow diagrams  Do YOU have these questions in your mind? WHO use WHERE to DFD? use DFD? WHY DFD? WHAT is in DFD? 4 WHEN to do DFD? HOW to draw DFD?  5 You can refer to the Guideline Pocketbook, “How to Construct a Data Flow Diagram”  Data Flow Diagrams » Graphically characterize data, DFD is a processes and flows in a business diagram to system conceptualize » Depict: how data (data » System inputs flow) move through » Processes the organization, the processes or » Outputs transformation that the data undergo, what the outputs (data flow) are and where the data is stored (data store) Data flow diagrams are structured analysis and design tools that allow the analyst to comprehend the system and subsystems visually as a set of interrelated data flows. Advantages of the Data Flow Approach » Freedom from committing to the technical implementation too early » Understanding of the interrelatedness of systems and subsystems » Communicating current system knowledge to users » Analysis of the proposed system  A double square for an external entity Basic DFD An arrow for movement of data from Symbols one point to another (data flow) A rectangle with rounded corners for the occurrence of a transforming process An open-ended rectangle for a data store The four basic symbols used in data flow diagrams, their meanings, and examples External Entities » Represent another department, a business, a person, or a machine » A source or destination of data, outside the boundaries of the system » Should be named with a noun Data Flow » Shows movement of data from one point to another » Described with a noun » Arrowhead indicates the flow direction » Represents data about a person, place, or thing Process » Denotes a change in or transformation of data » Represents work being performed in the system » Naming convention: » Assign the name of the whole system when naming a high-level process » To name a major subsystem attach the word subsystem to the name » Use the form verb-adjective-noun for detailed processes Data Store » A depository for data that allows examination, addition, and retrieval of data » Named with a noun, describing the data » Data stores are usually given a unique reference number, such as D1, D2, D3 » Represents a: » Database Temporary data stores, Data stores represent a such as scratch paper » Computerized file person, place, or or a temporary thing which is why » Filing cabinet computer file are not they are named with a included on the data noun flow diagram  Basic Rules The data flow A process must Must not be any diagram must have both an freestanding have at least input and output objects one process data flow A data store must External entities be connected to should not be at least one connected to one process another Rules Rules At least one input data flow and at least one Example output data flow for a process X X Output data flows usually have different names than input data flows for a process Data flows only in one direction Every data flow connects to at least one process. Data from one external entity cannot move directly to another external entity X Data from one data store cannot move directly to another data store X Rules for Using DFD Symbols » Data flow that connects: YES NO A process to another process √ A process to an external entity √ A process to a data store √ An external entity to another external entity √ An external entity to a data store √ A data store to another data store √  17 Give ONE example that shows the flow of data from input, through a process and produce output. (Choose something that you are familiar with) For example, Bake a Cake.  18 Think of a process that Produce Grade Report. Give me at least: » one input » one output Data Flow Diagram Levels » Data flow diagrams are built in Context layers Diagram » The top level is the context level » Each process may explode to a lower level Level 0 DFD » The lower-level diagram number is the same as the parent process number » Processes that do not create a Level 1 DFD child diagram are called primitive Figure shows how these levels of detail are related to one another. Creating the Context Diagram » The highest level in a data flow diagram » Contains only one process, representing the entire system » The process is given the number 0 » All external entities, as well as major data flows are shown Drawing Diagram 0/Level-0 » The explosion of the context diagram » May include up to nine processes » Each process is numbered » Major data stores and all external entities are included Start with Work Examine the data Analyze a backward the data Take note flow from well- from an flow to or of any an entity on defined output data from a data fuzzy areas the input process flow store side Greater Detail in Diagram 0 / Level-0 Creating Child Diagrams » Each process on Diagram 0 may be exploded to create a child diagram » A child diagram cannot produce output or receive input that the parent process does not also produce or receive » The child process is given the same number as the parent process » E.g. Process 3 would explode to Diagram 3. On Diagram 3, the processes would be numbered 3.1, 3.2, 3.3, and so on. This allows the analyst to trace a series of processes through many levels of explosion. » Entities are usually not shown on the child diagrams below Diagram 0 » If the parent process has data flow connecting to a data store, the child diagram may include the data store as well » When a process is not exploded, it is called a primitive process The process on Diagram 0 that is exploded is called the parent process, and the diagram that results is called the child diagram Differences between the Parent Diagram (above) and the Child Diagram (below)  25 Steps in Developing Data Flow Diagrams  26 HOW to draw/construct a DFD? A Journey to Produce a DFD HOW? Step 1: List down Business Activities (Alert with Verbs and Nouns) Step 2: Create a Context Diagram Step 3 : Create a Level-0 Diagram Step 4: Create a Level-1 (Child Diagram) Step 5: Check for Errors and Naming The Journey shows step by step to draw/construct a DFD: List down business activities. Determine various External 1 Entities (EE), Data Flows (DF), Processes (P) and Data Stores (DS). Alert with any kind of verbs and nouns. For each business activity: i. Identify the possible DF input(s) and DF output(s) ii. For each input (DF),where does the data come from. Does the data (DF) come from a source (EE) or a process (P) or a file (DS)? iii. For each output (DF), where does the data (DF) go to? Does the data is sent to another process (P) or a sink /destination (EE) or stored to a file (DS) ?  Create a Context Diagram contains ONE process representing the entire 2 system, and shows EE and DF to and from the system. DO NOT show any detailed processes (P) or data stores (DS). Create a Level-0 Diagram, the next level. Show processes (P), but keep them 3 general. Show data stores (DS) at this level. 4 Create a Level-1 Diagram (if any) – to be continued 5 Check for errors and make sure the labels/naming you assigned to each process (P) and data flow (DF) are correct and meaningful.  29 Relationship between DFD levels Data Flow Diagrams Errors Forgetting to include a data flow or pointing an arrow in the wrong direction Connecting data stores and external entities directly to each other Incorrectly labeling processes or data flow Including more than nine processes on a data flow diagram Omitting data flow Creating unbalanced decomposition (or explosion) in child diagrams Checking the Diagrams for Errors » Forgetting to include a data flow or pointing an arrow in the wrong direction Checking the Diagrams for Errors » Connecting data stores and external entities directly to each other Typical Errors that Can Occur in a Data Flow Diagram (Payroll Example) Question: List down rules for using DFD symbols Logical and Physical Data Flow Diagrams Logical DFD Physical DFD Focuses on the business and how the business operates Shows how the system will be implemented Not concerned with how the system will be constructed Describes the business events that Depicts the system take place and the data required and produced by each event Features common to both logical and physical data flow diagrams Features common to both logical and physical data flow diagrams Logical Data Flow Diagram Example Physical Data Flow Diagram Example Developing Logical Data Flow Diagrams » Better communication with users » centered on business activities. » More stable systems » based on business events and not on a particular technology or method of implementation. » Better understanding of the business by analysts » Flexibility and maintenance » Elimination of redundancy and easier creation of the physical model Developing Physical Data Flow Diagrams » Clarifying which processes are performed by humans and which are automated » Describing processes in more detail » Sequencing processes that have to be done in a particular order » Identifying temporary data stores » Specifying actual names of files and printouts » Adding controls to ensure the processes are done properly Physical data flow diagrams contain many items not found in logical data flow diagrams  Create Read CRUD Matrix Update Delete » Physical data flow diagrams are often more complex than logical data flow diagrams simply because of the many data stores present in the system. » The acronym CRUD is used for Create, Read, Update, and Delete. » A CRUD matrix shows which programs or processes add, read, update, or delete master file records. » Intermediate data stores » consist of transaction files used to store data between processes. CRUD Matrix » These are the activities that must be present in a system for each master file » A CRUD matrix is a tool to represent where each of these processes occurs in a system Event Modeling and Data Flow Diagrams » An input flow from an external entity is sometimes called a trigger because it starts the activities of a process » Events cause the system to do something and act as a trigger to the system » An approach to creating physical data flow diagrams is to create a data flow diagram fragment for each unique system event used to create a data flow diagram by analyzing each event and the data used and produced by An event the event table every row in an event table represents a data flow diagram fragment and is used to create a single process on a data flow diagram Event Modeling and Data Flow Diagrams An event response table for an internet storefront  47 Event Modeling and Data Flow Diagrams 1. A dataflow diagram fragment is represented by one row in the table. 2. Each DFD fragment is a single process on a