Book Notes – Systems Analysis & Design Chapter 1 Systems Development Life Cycle (SDLC) – process of understanding how an IS can support business needs by designing a new system, building it, and delivering it to users. Key person in SDLC is the systems analyst, who analyzes the business situation, identifies opportunities for improvement, and designs and IS to implement them. Primary objective of a systems analyst is to create value for an organization, which for most companies means increasing profits. The goal is to enable the organization to perform work better, so it can earn greater profits or serve its constituents more effectively. 4 fundamental phases: planning, analysis, design, and implementation. Planning Planning phase – the fundamental process of understanding why an IS should be built and determining how the project team will go about building it. This phase has 2 steps: – 1. Project initiation – system’s business value to org. is identified. System request – presents a brief summary of a business need, and it explains how the system that supports the need will create business value. The IS dept. works together with the person/dept. that generated the request (a.k.a. project sponsor) to conduct a feasibility analysis. The feasibility analysis examines key aspects of a proposed project: ∙ The idea’s technical feasibility (Can we build it?) ∙ The economic feasibility (Will it provide business value?) ∙ The organizational feasibility (If we build it, will it be used? – 2. Once the project is approved, it enters project management. The project manager creates a workplan, staffs the project, and puts techniques in place to help the project team control and direct the project through entire SDLC. Analysis Analysis phase – answers the questions of who will use the system, what the system will do, and where and when it will be used. The project team investigates any current system(s), identifies opportunities for improvement, and develops a concept for the new system. This phase has 3 steps: – 1. Analysis strategy – developed to guide the project team’s efforts. Includes an analysis of current system (as-is system) and its problems and then ways to design new system (to-be system). – 2. Requirements gathering – through interview or questionnaires. The analysis of this info leads to the development of a concept for a new system. The system concept is then used as a basis to develop a set of business analysis models, which describe how the business will operate if the new system is developed. – 3. The analyses, system concept, and models are combined into a document called the system proposal, which is presented to the project sponsor and other key decision makers who decide whether the project should continue to move forward. Design Design phase – decides how the system will operate, in terms of hardware, software, and network infrastructure; the user interface, forms, and reports; Book Notes – Systems Analysis & Design and specific programs, databases, and files that will be needed. The phase has 4 steps: – 1. Design strategy – clarifies whether the system will be developed by company’s own programmers, system will be outsourced to another firm, or company will buy an existing software package. – Architecture design – describes the hardware, software, and network infrastructure to be used. Interface design – specifies how the users will move through the system and the forms and reports that the system will use. – Database and file specifications – define exactly what data will be stored and where they will be stored. – Program design – defines the programs that need to written and exactly what each program will do. The collection of deliverables is the system specification that is handed to the programming team for implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised. Another decision is made by project sponsor/approval committee about whether to terminate/continue the project. Implementation Implementation phase – when the system is actually built/purchased. This phase generally gets the most attention, because for most systems it is the longest and most expensive single part of the development process. This phase had 3 steps: – 1. Construction – system is built and tested to ensure it performs as designed. Testing is one of the most critical steps in implementation. Most org. give more time and attention to testing than actually the writing of the program. – 2. Installation – process by which the old system is turned off and the new one is turned on. It may include a direct cutover approach (where new system immediately replaces the old one), a parallel conversion strategy (where the old and new systems are operated for a month or two until it is clear that there are no bugs in new system), a phased conversion strategy (where the new system is installed in one part of the org. as a trial and then gradually installed in others). One of the most important aspects of conversion is the development of a training plan to teach users how to use the new system and help manage the changes caused by the new system. – 3. Analyst team establishes a support plan for the system. This plan usually includes a formal/informal post-implementation review as well as a systematic way for identifying major and minor changes needed for the system. Methodologies Methodology – formalized approach to implementing the SDLC (i.e., it is a list of steps and deliverables). Many different systems development methodologies; also, many ways to categorize them – one way is by looking at whether they focus on business processes or data that support the business. Process-centered methodology – emphasizes process models as core of system concept; they would focus first on defining the processes.Book Notes – Systems Analysis & Design Data-centered methodologies – emphasize data models as core of system concept; they would focus first on defining the contents of the storage areas and how the contents were organized. Object-oriented methodologies – attempt to balance the focus between process and data by incorporating both into one model; they would focus first on defining major elements of system and look at processes and data involved with each element. Another important factor in categorizing methodologies is the sequencing of the SDLC phases and amount of time and effort devoted to each. Structured Design Waterfall Development – Waterfall development – analysts and users proceed in sequence from one phase to the next (moves forward from phase to phase). – Traditional structured design uses one set of diagrams to represent the processes and a separate set of diagrams to represent data. – 2 key advantages of the waterfall approach are that it identifies system requirements long before programming begins and it minimizes changes to the requirements as the project proceeds. – 2 key disadvantages are that the design must be completely specified before programming begins and that a long time elapses between the completion of the system proposal in the analysis phases and the delivery of the system (usually months or years). – A system can also require significant rework because the bus. environment has changed from the time that the analysis phase occurred. Parallel Development – Parallel development – attempts to address the problem of long delays between analysis phase and delivery of system. – It performs a general design for whole system and then divides the project into series of distinct subprojects that can be designed and implemented in parallel. – Main advantage of this method. is that it can reduce the time to deliver a system; thus there is less chance for rework. – It still suffers from problems caused by paper documents. Adds a new problem sometimes subprojects are not completely independent, design decisions made in one subproject can affect another, and end of project can require significant integration efforts. Rapid Application Development (RAD) RAD – attempt to address both weaknesses of structured design methodologies by adjusting the SDLC phases to get some part of system developed quickly and into hands of the users. This way, users can better understand the system and suggest revisions that bring system closer to what is needed. Phased Development – Phased development – breaks an overall system into series of versions that are developed sequentially. – Most important requirements are bundled into the first version of the system. – This meth. Has the advantage of quickly getting a useful system into hands of users, it provides business value sooner….Book Notes – Systems Analysis & Design Prototyping – Prototyping – performs the analysis, design, and implementation phases concurrently, and all 3 phases are performed repeatedly in a cycle until the system is completed. Throwaway Prototyping … Agile Development Extreme Programming Scrum Selecting Appropriate Development Methodology Clarity of User Requirements Familiarity with Technology System Complexity System Reliability Short Time Schedules Schedule Visibility Typical Systems Analyst Roles & Skills
- Analyzing the key business aspects of the system. - Identifying how the system will provide business value. - Designing the new business processes and policies.
- Identifying how technology can improve business processes. - Designing the new business processes. - Designing the information system. - Ensuring that the system conforms to IS standards.
- Ensuring the system conforms to infrastructure standards. - Identifying infrastructure changes needed to support the system.
Change management analyst
- Developing and executing a change management plan. - Developing and executing a user training plan.
- Managing the team of analysts, programmers, technical writers, and other specialists. - Developing and monitoring the project plan. - Assigning resources. - Serving as the primary point of contact for the project.
How many people are needed to work on the project?
Don't forget about the age old question of evolution of animal behavior rutgers
Characteristics of Object-Oriented Systems Classes & ObjectsBook Notes – Systems Analysis & Design Classes – general template we use to define and create specific instances, or objects. Object – an instantiation of a class. Attributes – describe information about the object, such as a patient’s name, birth date, address, and phone number. Attributes are also used to represent relationships between objects. State – of an object, is defined by the value of its attributes and its relationships with other objects at a particular point in time. Behaviors – specify what the object can do. Methods & Messages Methods – implement an object’s behavior; an action that the object can perform. Messages – information sent to objects to trigger methods. Encapsulation & Information Hiding Encapsulation – combination of process and data into a single entity. Information hiding – only info required to use a software module be published to the user of the module.; info required to be passed to the module and the info returned from that module are published. Inheritance Inheritance – an information systems development characteristic used to identify higher-level/general classes of objects. Subclasses – specific classes. A-kind-of relationship – relationship between the class and its superclass. Concrete class – any class that has instances Abstract class – classes that do not produce instances because they are used merely as templates for other more specific classes. Polymorphism & Dynamic Binding Polymorphism – the same message can be interpreted differently by different classes of objects. Dynamic binding – technique that delays typing the object until run-time. Static binding – the typed of object is determined a compile-time. Object-Oriented Systems Analysis & Design (OOSAD) Use-Case Driven – means that use cases are primary modeling tools defining the behavior of the system. – Use case – describes how the user interacts with the system to perform some activity. They are simple because they focus only on one business process at a time. Architecture-centric – Architecture-centric – the underlying architecture of the evolving system specification drives the specification, construction, and documentation of the system. – Functional (external) view – describes the system in terms of attributes, methods, classes, and relationships. – Behavioral (dynamic) view – describes the behavior of the system in terms of messages passed among objects and state changes within an object. Iterative & Incremental Benefits of OOSADBook Notes – Systems Analysis & Design The Unified Process Phases – Phases – of the Unified Process support an analyst in developing IS in an iterative and incremental manner. – Inception – a business case is made for the proposed system; similar to the planning phase of a traditional SDLC approach. It includes a feasibility analysis that should answer the following questions: ∙ Do we have the technical capability to build it (technical feasibility)? ∙ If we build it, will it provide business value (economic feasibility)? ∙ If we build it, will it be used by the organization (organizational feasibility)? – Elaboration – analysis and design workflows are the primary focus during this phase; it continues with developing the vision document, including finalizing the business case, revising the risk assessment, and completing a project plan in sufficient detail to allow stakeholders to be able to agree with constructing the final system. – Construction – focuses heavily on programming the evolving IS. This phase is concerned with the implementation workflow. However, the requirements workflow and the analysis and design workflows are also involved. The configuration and change management workflow, with its version-control activities, becomes extremely important during the construction phase. – Transition – addresses aspects typically associated with the implementation phase of a traditional SDLC approach. Its primary focus is on the testing and deployment workflows. Workflows – Engineering workflows: deal with the activities that produce the technical product (i.e., the information system. ∙ Business Modeling – uncovers problems and identifies potential projects within a user org. ∙ Requirements – includes eliciting both functional and nonfunctional requirements. ∙ Analysis – addresses the creation of analysis model of the problem domain. ∙ Design – transitions the analysis model into a form that can be used to implement the system: the design model. ∙ Implementation – create an executable solution based on the design model (i.e., programming). ∙ Testing – increase the quality of the evolving system. ∙ Deployment – includes activities such as software packaging, distribution, installation, and beta testing. – Supporting workflows: focus on the managerial aspects of IS development. ∙ Project Management – supports incremental and iterative development, so IS tend to grow/evolve over time. ∙ Configuration & Change Management – keep track of the state of the evolving system. ∙ EnvironmentBook Notes – Systems Analysis & Design Extensions to the Unified Process – Production Phase – Operations & Support Workflow – Infrastructure Management Workflow – Existing Workflow Modifications & Extensions ∙ Testing ∙ Deployment ∙ Environment ∙ Project Management ∙ Configuration & Change Management The Unified Modeling Language (UML) UML – provides a common vocabulary of object-oriented terms and diagramming techniques. Version 2.0 has 14 diagrams in 2 major groups: Structure diagrams – provide a way to represent data and static relationships in an IS. The structure diagrams include: class, object, package, deployment, component, and composite structure diagrams. Behavior diagrams – provide analyst with a way to depict the dynamic relationships among the instances/objects that represent the business IS. The behavior diagrams support analyst in modeling the functional requirements of an evolving IS. The behavior diagrams include: activity, sequence, communication, interaction overview, timing, behavior state machine, protocol state machine, and use-case diagrams.
Class Illustrate relationship Analysis, Design between classes modeled in the system. Object Illustrate relationships Analysis, Design between objects modeled in in the system; used when actual instances of the classes will better communicate the model. Package Group other UML elements Analysis, Design together to form higher level constructs; implementation. Deployment Show physical architecture Physical Design, of system; can also be used Implementation to show software components being deployed onto the physical architecture. Component Illustrate physical Physical Design relationships among the software components; implementation. Composite Structure Design Illustrate internal structure Analysis
How much will the project cost the organization?
Don't forget about the age old question of the connection between structure and ________ is a basic concept of biology.
Book Notes – Systems Analysis & Design
of a class (i.e., the relationships among the parts of a class)
Activity Illustrate business Analysis, Design workflows independent of classes, the flow of activities in a use case, or detailed design of a method. Sequence Model behavior of objects Analysis, Design within a use case; focuses on the time-based ordering of an activity. Communication Model behavior of objects Analysis, Design within a use case; focus on communication among set of collaborating objects of an activity. Interaction Overview Illustrate overview of the Analysis, Design flow of control of a process. Timing Illustrate interaction among Analysis, Design set of objects and state changes they go through along a time axis. Behavioral State Machine Examine behavior of one Analysis, Design class. Protocol State Machine Illustrate dependencies Analysis, Design among different interfaces of a class. Use-Case Capture business Analysisrequirements for the system and illustrate interaction between the system and its environment.
What is the purpose of the project?
Don't forget about the age old question of walpmart
Book Notes – Systems Analysis & Design Chapter 2 Project management – process of planning and controlling the development of a system within a specified time frame at a minimum cost with the right functionality. Feasibility analysis – plays in important role in deciding whether to proceed with a IS development project. It examines the technical, economic, and organizational pros and cons of developing the system, and it gives the org. a slightly more detailed picture of the advantages of investing in the system as well as any obstacles that could arise. Project Identification Emerging technology – technology that is still being developed and is not yet viable for widespread business use. Project sponsor – someone who recognizes the strong business need for a system and has an interest in seeing the system succeed. Business requirements – what the IS will do, or the functionality it will contain; the features and capabilities the IS will have to include. Tangible value – can be quantified and measured easily. Intangible value – an intuitive belief that the system provides important, but hard-to-measure. System Request System request – document that describes the business reasons for building a system and the value the system is expected to provide. Most system request include 5 elements:
Person who initiates the project and who serves as the primary point of contact for the on the business side.
- Several members of the Finance department - VP of Marketing project - IT Manager - Steering committee - CIO - CEO
The business-related reason for initiating the system.
- Increase sales - Improve market share - Improve access to info - Improve customer service - Decrease product defects - Streamline supply acquisition - Processes
The business capabilities that the system will provide.
- Provide online access to info - Capture customer
If you want to learn more check out harry ellis unt
Book Notes – Systems Analysis & Design
demographic info - Include product search capabilities - Produce management reports - Include online user support
The benefits the system will create for the organization.
- A 3% increase in sales - A 1% increase in market share - Reduction in headcount by 5 FTEs - $200,000 cost savings from decreased supply costs - $150,000 savings from removal of existing system
Special Issues or Constraints
Issues that are relevant to the implementation of the system and decisions made by the committee about the project.
- Government-mandated deadline for May 30 - System needed in time for the Xmas holiday - Top-level security clearance needed by project team to work with data
We also discuss several other topics like leo vocabulary
Feasibility Analysis Feasibility analysis – identifies the important risks associated with the project that must be addressed if the project is approved. The typical process and format for the feasibility analysis includes 3 types: Technical feasibility – the extend to which the system can be successfully designed, developed, and installed by the IT group. Can we build it? Economic feasibility – identifies the financial risk associated with the project. It is determined by identifying costs and benefits associated with the system, assigning values to them, and then calculating the cash flow and ROI. Should we build it?
Steps for Conducting Economic Feasibility
1) Identifying Costs and Benefits
List the tangible costs and benefits for project. Include both one-time and recurring costs.
2) Assigning Values to Costs and Benefits
Work with business users and IT professionals to create numbers for each of the costs and benefits. Even intangibles should be valued it at all possible.
Book Notes – Systems Analysis & Design
3) Determining Cash Flow
Project what the cots and benefits will be over a period of time, usually 3-5 years. Apply a growth rate to the numbers, if necessary.
4) Determining Net Present Value (NPV)
Calculate what the value of future costs and benefits are if measured by today’s standards. You will need to select a rate of growth to apply the NPV formula.
5) Determining Return on Investment (ROI)
Calculate how much money the organization will receive in return for the investment it will make using the ROI formula.
6) Determining the Break-Even Point
Find the first year in which the system has greater benefits than costs. Apply the break-even formula using figures from that year. This will help you understand how long it will take before the system creates real value for the organization.
7) Graphing the Break-Even Point
Plot the yearly costs and benefits on a line graph. The point at which the lines cross is the break-even point.
We also discuss several other topics like value imposition in counseling
– Identifying Costs and Benefits ∙ Development costs – tangible expenses incurred during the construction of the system. (i.e., salaries for project team, hardware/software expenses, consultant fees, training, office space and equipment) ∙ Operational costs – tangible costs required to operate the system. (i.e., salaries for operation staff, software licensing fees, equipment upgrades, communications charges) ∙ Tangible benefits – revenues and cost savings the system enables the org. to collect or the tangible expenses the system enables the org. to avoid. ∙ Intangible benefits – difficult to incorporate into economic feasibility analysis but should still be listed. Other examples below:
- Vendor installation - Data conversion costs
- Hardware repairs - User training
- Increased sales
- Increased market share
Book Notes – Systems Analysis & Design
- Reductions in staff - Reductions in inventory - Reductions in IT costs - Better supplier prices
- Increased brand recognition - Higher quality products - Improved customer service - Better supplier relations
Present Value (PV)
Amount of an investment today compared to that same amount in the future, taking into account inflation and time.
Amount (1+interestrate)n n = number of years in future
Net Present Value (NPV)
Present value of benefit less the present value of costs.
PV Benefits−PV Costs
Return on Investment (ROI)
Amount of revenues or cost savings results from a given investment.
Total benefits−Total costs Total costs
Point in time at which the costs of the project equal the value it has delivered.
Yearly NPV −Cumulative NPV Yearly NPV * Use the Yearly NPV amount from the first year in which the project has a positive cash flow. Add the above amount to the year in which the project has a positive cash flow.
Project Selection Portfolio management – takes into consideration the different kinds of projects that exist in an organization – large and small, high risk and low risk, strategic and tactical. Ways to Classify Projects
What is the size? How many people are needed to work on the project?
How much will the project cost the organization?
What is the purpose of the project? Is it meant to improve the technical infrastructure? Support a current business strategy? Improve operations? Demonstrate a new innovation?
How long with the project take before completion? How much time will go by before value is delivered to the business?
Book Notes – Systems Analysis & Design
How likely is it that the project will succeed or fail?
How much of the organization is affected by the system? A department? A division? The entire corporation?
Return on investment
How much money does the organization expect to receive in return for the amount of project costs?
Traditional Project Management Tools Work Breakdown Structures Gantt Chart Network Diagram Project Effort Estimation The science of project management is in making trade-offs among 3 important concepts: the functionality of the system, the time to complete the project, and the cost of the project. Use-case points – unique features of use cases and object orientation. Use-case models have 2 primary constructs: Actor – represents a role that a user of the system plays, not a specific user. Use case – represents a major business process the system will perform that benefits the actor(s) in some manner. Technical factor value (TFactor) Environmental factor value (EFactor) Creating and Managing the Workplan Workplan – dynamic schedule created by the project manager that records and keeps track of all tasks that need to be accomplished over course of project. Evolutionary Work Breakdown Structures & Iterative Workplans Most approaches to developing convetional WBSs tend to have 3 problems: – They tend to be focused on the design of the IS being developed. – They tend to force too many levels of detail very early on in systems development process for large projects or they tend to allow too few levels of detail for small projects. – Because they are project specific, they are very difficult to compare across projects. Evolutionary WBSs allow analyst to address all three problems by allow development of an iterative workplan. – Evolutionary WBSs are organized in a standard manner across all projects: by workflows, phases, and the specific tasks accomplished during an individual iteration. – They are created in an incremental and iterative manner. – Because to structure of ev. WBS is not tied to any specific project, they enable the comparison of the current project to earlier projects. Managing Scope Scope – schedule and cost overruns that occur after the project is under way. It happens when new requirements are added to the project after the original project scope was defined and frozen. Timeboxing Steps for Timeboxing 1. Set the date for system delivery. 2. Prioritize the functionality that needs to be included in the system. 3. Build the core of the system (the functionality ranked as most important).Book Notes – Systems Analysis & Design 4. Postpone functionality that cannot be provided within the time frame. 5. Deliver the system with core functionality. 6. Repeat steps 3 through 5 to add refinements and enhancements. Refining Estimates Hurricane model Managing Risk Risk management – process of assessing and addressing the risks associated with developing a project. Risk assessment – document that tracks potential risks along with an evaluation of the likelihood of each risk and its potential impact on the project. Staffing the Project Characteristics of a Jelled Team Have a very low turnover during a project. Have a strong sense of identity. The strong sense of identity tends to lead the team into feeling a sense of eliteness. During the development process, jelled teams feel that the team owns the IS being developed and not any one individual member. They really enjoy (have fun) doing their work. Staffing Plan Staffing plan – lists the roles and the proposed reporting structure that are required for the project. Motivation
Assign unrealistic deadlines
Few people will work hard if they realize that a deadline is impossible to meet.
Ignore good efforts
People will work harder if they feel like their work is appreciated. Often, all it takes is public praise for a job well done.
Create a low-quality product
Few people can be proud of working on a project that is of low quality.
Give everyone on the project a raise
If everyone is given the same reward, then high quality people will believe that mediocrity is rewarded —and they will resent it.
Make an important decision without the team’s input
Buy-in is very important. If the PM needs to make a decision that greatly affects the members of her team, she should involve them in the decision-making process.
Maintain poor working conditions
A project team needs a good work environment or motivation will decrease. This includes lighting, desk space, technology, privacy from interruptions, and reference resources.
Handling ConflictBook Notes – Systems Analysis & Design Group cohesiveness – (attraction that members feel to the group and other members) contributes more to productivity than do project members’ individual capabilities/experiences. Project charter – sometimes developed by the project manager that lists the project’s norms and ground rules. Conflict-Avoidance Strategies Clearly define the plans for the project. Make sure the team understands how the project is important to the organization. Develop detailed operating procedures and communicate these to the team members. Develop a project charter. Develop schedule commitments ahead of time. Forecast other priorities and their possible impact on the project. Environment & Infrastructure Management CASE Tools (Computer-aided software engineering) – category of software that automates all or part of the development process. Standards – formal rules for naming files, forms that must be completed when goals are reached, and programming guidelines. Documentation – standards that include detailed info about the tasks of the Unified Process.Book Notes – Systems Analysis & Design Chapter 3 Defining a Requirement Requirement – a statement of what the system must do or what characteristics it must have. Functional requirement – a process a system has to perform or information it needs to contain. Ex., requirements that state that a system must have the ability to search for available inventory, or to report actual and budgeted expenses. Nonfunctional requirements – behavioral properties that the system must have, such as performance and usability. Ex., ability to access the system using a Web browser is considered a nonfunctional requirement.
Physical and technical environments in which the system will operate.
- System should be able to fit in a pocket/purse. - System should be able to integrate with the existing inventory system. - System should be able to work on any Web browser.
Speed, capacity, and reliability of the system.
- Any interaction between user and system should not exceed 2 seconds. - System should receive updated inventory info every 15 minutes. - System should be available for use 24 hours a day, 365 days per year.
Who has authorized access to the system under what circumstances.
- Only direct managers can see personnel records of staff. - Customers can see their order history only during business hours.
Cultural & Political
Cultural, political factors and legal requirements that affect the system.
- System should be able to distinguish between United States and European currency. - Company policy says that we buy computers only from Dell. - Country managers are permitted to authorize customer user interfaces within their units. - System shall comply with insurance industry standards.
Lsalkdf Requirements Definition Report – straightforward text report that simply lists the functional and nonfunctional requirements in an outline format. Book Notes – Systems Analysis & Design Requirements are numbered in a legal/outline format. Requirements are first grouped into functional and nonfunctional requirements; within each of those headings, they are further grouped by type of nonfunctional requirement or by function. Most obvious purpose of the requirements definition is to provide the info needed by the other deliverables in analysis, which include functional, structural, and behavioral models, and to support activities in design. Most important purpose of req. def. is to define the scope of the system. Determining Requirements Most effective approach is to have both business people and analysts work together to determine business requirements. 3 kinds of strategies have become popular to help analysts ascertain what the users want: Business process automation (BPA) – BPA leaves the basic way the organization operates unchanged and uses computer technology to do some of the work. Can make org. more efficient but has least impact on the business. – 2 popular BPA techniques: ∙ Problem analysis – asking the users and managers to identify problems with as-is system and describe how to solve them in the to-be system. ∙ Root cause analysis - a method of problem solving used for identifying the root causes of faults or problems. 1. Analyst starts by having users generate a list of problems with current system and then prioritize problems in order of importance. 2. Starting with most important, users and/or analysts generate all possible root causes for the problems. 3. Each possible root cause is investigated until true root causes are identified. Business process improvement (BPI) – BPI makes moderate changes to the way the org. operates in order to take advantage of new opportunities offered by technology or to copy what competitors are doing. Can improve efficiency and effectiveness. – 3 popular BPI activities: ∙ Duration Analysis – requires a detailed examination of the amount of time it takes to perform each process in current as-is system. 1. Analysts determine total amount of time it takes to perform a set of bus. Processes for a typical input. 2. Then they time each individual step (subproccesses) in the bus. Process. 3. Time to complete the basic steps are totaled and compared to the total overall process. A significant difference between the two indicates that this part of the process is badly in need of major overhaul. o Processes in which many different people work on small parts of the inputs are prime candidates for process integration or parallelization. Process integration – changing the fundamental process so that fewer people work on the input, which often requires Book Notes – Systems Analysis & Design changing the processes and retraining staff to perform a wider range of duties. Process parallelization – changing the process so that all individual steps are performed at the same time. ∙ Activity-Based Costing – examines the cost of each major process/step in a business process. 1. Analysts identify costs associated with each of basic functional steps/processes. 2. They identify the most costly processes. 3. They then focus their improvement efforts on them. ∙ Informal Benchmarking – studying how other organizations perform a business process to learn how your org. can do something better. It helps the org. by introducing ideas that employees may never have considered but have potential to add value. 1. Managers and analysts thing about other org. or visit them as customers to watch how the bus. process is performed. Business process reengineering (BPR) – BPR means changing the fundamental way the org. operates, eliminating current way of doing business and making major changes to take advantage of new ideas and technology. – 3 popular BPR activities: ∙ Outcome Analysis – focuses on understanding fundamental outcomes that provide value to customers. 1. Analysts encourage managers and project sponsors to pretend they are customers and to think carefully about what the org. products/services enable the customers to do – and what they could enable customers to do. ∙ Technology Analysis 1. Analysts and managers develop a list of important and interesting technologies. 2. Then they systematically identify how every technology could be applied to the bus. process and identify how the bus. would benefit. ∙ Activity Elimination 1. Analysts and managers work together to identify how the org. could eliminate each activity in bus. process. 2. Then determine how the function could operate without it. 3. Then anticipate what effects are likely to occur. Creating Requirements Definition It is an iterative process where the analyst collects info with requirements gathering techniques (e.g., interviews, document analysis, etc.). To create a requirements definition, the project team: 1. Determines the kinds of functional and nonfunc. req. that they will collect about the system. 2. Analyst(s) uses variety of req.-gathering techniques (e.g., interviews, observation, etc.) to collect info, and then list the business req. that were identified from that info. 3. Analyst(s) work with entire project team and business users to verify, change, and complete the list and help prioritize importance of req. that were identified.Book Notes – Systems Analysis & Design Selecting Appropriate Strategies 4 characteristic of Analysis Strategies: Potential Business Value – varies with the analysis strategy on how the business has potential to improve. Project Cost – very important. Breadth of Analysis – refers to scope of analysis, or whether analysis includes bus. processes within a single bus. function, processes that cross the org., or processes that interact with those in customers or supplier org. Risk – the likelihood of failure due to poor design, unmet needs, or too much change for the org. to handle.
Potential business value
Breadth of analysis
Requirements-Gathering Techniques (shorten to R-GT) Interviews Most common used R-GT. 5 basic steps to the interview process: 1. Select Interviewees ∙ Create an interview schedule listing all people who will be interviewed, when, and for what purpose. 2. Design Interview Questions ∙ 3 types of interview questions: o Closed-ended – require a specific answer. Used when analyst is looking for specific, precise info. o Open-ended – leave room for elaborating on the part of the interviewee. Designed to gather rich info. Give interviewee more control over the info revealed during the interview. o Probing – follow up on what has just been discussed in order to learn more; often used when interviewer is unclear about an interviewee’s answer. Encourage interviewee to expand on/confirm info from a previous response. Signal that interviewer is listening and interested in the topic under discussion. ∙ Interview process 1. Begins with unstructured interviews o Interviews that seek broad and roughly defined info. o Interviewer has general sense of the info needed but has few closed-ended questions to ask. Most challenging interviews to conduct because they require the interviewer to askopen-ended questions and probe for important info on the fly. 2. As project progresses, analyst conducts structured interviewsBook Notes – Systems Analysis & Design o Specific set of questions are developed before the interviews. o Usually more closed-ended questions. ∙ 2 approaches to organizing interview questions: o Top-down interview – interviewer starts with broad, general issues and gradually works toward more-specific ones. Appropriate strategy for most interviews. Enables the interviewee to become accustomed to the topic before he/she needs to provide specifics. Enables interviewer to understand the issues more before moving to the details because interviewer might not have sufficient info at start of interview to ask very specific questions. * Enables interviewers interviewee to raise set of big-picture issues, before being informed on details, so interviewee is less likely to miss important issues. o Bottom-up interview – interviewer starts with very specific questions and moves to broad questions. May be preferred when analyst already has gathered a lot of info about issues and needs to fill in holes with details. Appropriate if lower-level staff members feel threatened or unable to answer high-level questions. 3. Prepare for the Interview ∙ Interviewer should… 1. Have a general interview plan listing the questions to be asked in appropriate order. 2. Anticipate possible answers and provide follow-up with them. 3. Identify transitions between related topics. 4. Prepare the interviewee, notifying them the reason for the interview and the areas that will be discussed, far in advance so he/she has time to think about the issues and organize his/her thoughts. 4. Conduct the Interview ∙ Goal is for interviewer to build rapport with interviewee(s), so they trust the interviewer and is willing to give honest answers/opinions. Interviewer should appear professional and an unbiased seeker of info. 1. Interview should start with explanation of why interviewer is there and why he/she has chosen to interview the person. 2. Interviewer moves into planned interview questions. ∙ Record all the info the interviewee provides. Take careful notes, write everything down the interviewee says. ∙ Interviewer should not be afraid to ask dumb questions. ∙ One good strategy to increase understanding during an interview is to periodically summarize key points that the interviewee is communicating. This avoids misunderstanding and demonstrates the interviewer is listening. 3. Facts are separated from opinion. ∙ Interviewee might state an opinion, useful for interviewer to follow up with a probing question requesting support for the statement. ∙ Differences in facts and the interviewee’s opinion can point out key areas for improvement.Book Notes – Systems Analysis & Design 4. As interview draws to a close, interviewee(s) should have time to ask questions or provide info that they deem important but was not part of interview plan. 5. Last step in interview, interviewer should briefly explain what will happen. ∙ Interviewer should not prematurely promise certain features in new system or a specific delivery date. 5. Post-Interview Follow-up ∙ After interview is over, analyst needs to prepare an interview report that describes the info from the interview. ∙ Report contains interview notes, info collected over the course of the interview and is summarized in a useful format. ∙ In general, interview report should be written within 48 hours of the interview. ∙ Often, interview report is sent to interviewee(s) with a request to read it and inform analyst of clarifications or updates. Joint Application Development (JAD) – info-gathering technique that allows the project team, users, and management to work together to identify requirements for the system. JAD is a structure process in which 10-20 users meet together under the direction of a facilitator skilled in JAD techniques. o Facilitator – person who sets the meeting agenda and guides the discussion but does not join in the discussion. Must be an expert in bot group-process techniques and systems-analysis and design techniques. 1 or 2 scribes assist the facilitator by recording notes, making copies, etc. Often use computers and CASE tools to record info. JAD group meets for however long it takes to discuss all issues and the needed info is collected. A problem with JAD is that it suffers from traditional problems associated with groups. o People are reluctant to challenge opinions of others o Few people often dominate the discussion o Not everyone participates A new form of JAD called electronic JAD (e-JAD) attempts to overcome these problems by using groupware. o Each participant uses special software on a networked computer to send anonymous ideas/opinions to everyone else. 1. Select Participants Participants are selected based on the info they can contribute in order to provide a broad mix of organizations levels and to build political support for the new system. Facilitator should be an expert in JAD or e-JAD techniques and has experience with business under discussion. 2. Design a JAD Session Most JAD sessions last 5-10 days spread over a 3 week period. Most e JAD sessions last 1-4 days in a 1 week period. Most JAD sessions are designed to collect specific info from users, and this requires developing a set of questions before the meeting.Book Notes – Systems Analysis & Design JAD sessions are structured –they must be carefully planned. Closed-ended questions are rarely used because they don’t ignite open and frank discussion that is typical for a JAD. Best to proceed top-down. 3. Preparing for a JAD Session ∙ * Participants should understand what is expected of them. ∙ … ? 4. Conducting a JAD Session ∙ Must have formal ground rules. Common ground rules include: o Following the schedule o Respecting others’ opinions o Accepting disagreement o Ensuring that only one person talks at a time ∙ JAD facilitator performs 3 key functions: 1. She ensures that the group sticks to the agenda. 2. She must help the group understand the technical terms/jargon that surround the system-development process and help the participants understand the specific analysis techniques used. 3. She records the group’s input on a public display area such as a whiteboard, flip chart, or computer display. She structures the info the group provides and helps group recognize key issues and important solutions. Under no circumstances should facilitator insert her opinions into the discussion. She must remain neutral the whole time. 5. Post-JAD Follow-up ∙ JAD post-session report is prepared and circulated among session attendees. Questionnaires – set of written questions used to obtain info from individuals. Often used when a large number of people from whom info and opinions are needed. Common technique with systems intended for use outside the organization or for systems with business users spread across many geographic locations. Good process for questionnaires follows 4 steps: 1. Identify individuals whom questionnaire will be sent. ∙ Standard approach is to select a sample of people who are representative of an entire group. 2. Designing a Questionnaire ∙ Questions must be clearly written and leave little room for misunderstanding, so closed-ended questions tend to be used. o Opinion questions often ask respondents the extent to which they agree/disagree. (e.g., Are network problems common?) o Factual questions seek more precise values. (e.g., How often does a network problem occur; once an hour, once a day, once a week?) ∙ Questions should be consistent in style. Most important step is to have several colleagues review the questionnaire and then pretest it with a few people drawn from the groups to whom it will be sent. Good Questionnaire DesignBook Notes – Systems Analysis & Design Begin with nonthreatening and interesting questions. Group items together into logically coherent sections. Do not put important items at the very end of the questionnaire. Do not crowd a page with too many items. Avoid abbreviations. Avoid biased or suggestive items or terms. Number questions to avoid confusion. Pretest the questionnaire to identify confusing questions. Provide anonymity to respondents.
3. Administering the Questionnaire ∙ Key issue is getting participants to complete the questionnaire and send it back. ∙ Commonly used techniques include: o Clearly explaining why the questionnaire is being conducted and why the respondent has been selected o Stating a date to return questionnaire by o Offering an inducement to complete it o Offering to supply summary of questionnaire responses 4. Questionnaire Follow-up ∙ Process returned questionnaire and develop a questionnaire report soon after questionnaire deadline. ∙ This ensures the analysis process proceeds in timely fashion and that respondents receive their requested copies of the results promptly. Document Analysis Project team reviews documentation of the as-is system to understand and examine it. Observation The act of watching processes being performed, is a powerful tool for gathering info about the as-is system because it enables the analyst to see the reality of a situation. Often used to supplement interview info. Selecting Appropriate Techniques Type of Information Some techniques are more suited for different stages of analysis process, whether understanding the as-is system, identifying improvements, or developing to-be system. Interviews and JAD sessions are commonly used in all 3 stages. Document analysis and observation usually are most helpful for understanding as-is, although occasionally provide info on current problems that need improving. Questionnaires often used to gather info about as-is system and general info about improvements. Depth of Info Refers to how rich and detailed the info is that the technique produces and extent to which the tech. is useful for obtaining facts/opinions and understanding why those facts/opinions exits. Interviews and JAD sessions are useful for providing good depth of rich and detailed info and helping analyst understand reasons behind them.Book Notes – Systems Analysis & Design Document analysis and observation are useful in obtaining facts. Questionnaires provide a medium depth of info, soliciting facts/opinions with little understanding of why they exist. Breadth of Info Refers to range of info and info sources that can be easily collected using the chosen technique. Questionnaires and document analysis are both easily capable of soliciting a wide rang of info from a large number of sources. Interviews and observation require analyst to visit each info source individually, taking more time. JAD sessions are in the middle because many info sources are brought together at the same time. Integration of Info All techniques suffer integration problems to some degree. JAD sessions are designed to improve integration because all info is integrated when it is collected, not afterward. User Involvement Refers to amount of time and energy the intended users of new system must devote to analysis process. User involvement can have a significant cost, and not all users are willing to contribute valuable time and energy. Questionnaires, document analysis, and observation place least burden on users, whereas JAD sessions require the greatest effort. – Cost ∙ Questionnaires, document analysis, and observation are low-cost techniques. ∙ Interviews and JAD sessions generally have moderate costs. Alternative Requirements Documentation Techniques Throwaway prototyping Use cases Role-playing CRC cards with use case-based scenarios Concept mapping Concept maps represent meaningful Recording user stories on story cards Task lists The System Proposal System proposal typically includes an executive summary, the system request, the workplan, the feasibility analysis, the requirements definition, and the evolving models that describe the new system. The evolving models include functional models, structural models, and behavioral models. The executive summary provides all critical info in a very concise form; it is a summary of the complete proposal.