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  Role Responsibilities Business analyst - Analyzing the key business aspects of the  system. - Identifying how the system will provide  business value. - Designing the new business processes and policies. Systems analyst - Identifying how technology can improve  business processes. - Designing the new business processes. - Designing the information system. - Ensuring that the system conforms to IS  standards. Infrastructure analyst - 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. Project manager - 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. Diagram Name Used to… Primary Phase Structure 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) Behavioral Diagrams 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: Element Description Examples Project Sponsor 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 Business Need 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 Business Requirements 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 Business Value 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: Development Costs Operational Costs - Vendor installation - Data conversion costs - Hardware repairs - User training Tangible Benefits Intangible Benefits - 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

Cost-Benefit Analysis Calculation Definition Formula 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 Break-Even Point 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 Size What is the size? How many people are needed to work  on the project? Cost How much will the project cost the organization? Purpose 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? Length 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 Risk How likely is it that the project will succeed or fail? Scope 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 Motivational DON’TS Reasons 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.   Nonfunctional Requirement Description Examples Operational 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. Performance 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. Security 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.

BPA BPI BPR Potential business  value Low-moderate Moderate High Project cost Low Low-moderate High Breadth of analysis Narrow Narrow-moderate Very broad Risk Low-moderate Low-moderate Very high

 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.

References: