1. Deliverables and Outcomes
1.1. Deliverables for Requirements Determination:
1.1.1. From interviews and observations
1.1.1.1. Traditional Methods for Determining Requirements
1.1.1.1.1. Observing workers
1.1.1.1.2. Studying business documents
1.1.2. From existing written documents
1.1.3. From computerized sources
2. The Process of Determining Requirements
2.1. Good Systems Analyst Characteristics:
2.1.1. Impertinence—question everything
2.1.2. Impartiality—consider all issues to find the best organizational solution
2.1.3. Relax constraints—assume anything is possible
2.1.4. Attention to details—every fact must fit
2.1.5. Reframing—challenge yourself to new ways
2.2. Interview
2.2.1. Interviewing individuals
2.2.1.1. Listen Carefully
2.2.1.2. Plan the interview
2.2.1.3. review notes within 48 hours
2.2.1.4. be neutral
2.2.2. Interviewing groups
2.2.2.1. Contradictions and inconsistencies between interviewee
2.2.2.2. Follow up discussion are time consuming
2.2.2.3. New interviews may reveal questions
2.3. Observing
2.3.1. Watching users do their jobs
2.3.2. Used to obtain more firsthand and objective measures of employee interaction
2.3.3. can cause people to change their normal operating behaviour
2.3.4. time consuming and limited time to observe
2.4. Reading Document
2.4.1. Review of existing business document
2.4.2. Can give a historical and "Formal" view of system requirements
2.4.2.1. Formal systems: the official way a system works as described in organizational documentation
2.4.2.2. Informal system: the way a system actually works
3. Contemporary Methods for Determining System Requirements
3.1. Joint Application Design (JAD)
3.1.1. CASE tools during JAD
3.1.1.1. Upper case tools are used
3.1.1.2. Enables analysts to enter system model dirctly into CASE
3.1.1.3. Screen design and prototype can be done during JAD
3.1.2. Brings together
3.1.2.1. JAD Participants:
3.1.2.1.1. Session Leader
3.1.2.1.2. Users
3.1.2.1.3. Managers
3.1.2.1.4. Sponsor
3.1.2.1.5. Systems Analysts
3.1.2.1.6. Scribe
3.1.2.1.7. IS Staff
3.2. Identifying Processes to Reengineer
3.2.1. Key business processes
3.2.1.1. Structured, measured set of activities designed to produce specific output for a particular customer or market
3.2.1.2. Focused on customers and outcome
3.2.1.3. Same techniques as requirements determination are used
3.2.2. Which activities need radical change?
3.2.2.1. Importance of activity
3.2.2.2. Feasibility of change
3.2.2.3. Level of dysfunction of current activity
3.3. Disruptive Technologies
3.3.1. Information technologies must be applied to radically improve business processes.
3.3.2. Disruptive technologies are technologies that enable the breaking of long-held business rules that inhibit organizations from making radical business changes.
3.4. System prototypes
3.4.1. Using Prototyping During Requirements Determination
3.4.1.1. Convert requirements to working version of system
3.4.1.2. Once the user sees requirements converted to system, will ask for modifications or will generate additional requests
3.5. Requirements Determination using Agile Methodologies
3.5.1. Requirements Determination using Agile Methodologies
3.5.1.1. Replace traditional SDLC waterfall with iterative analyze–design–code–test cycle
3.6. Radical Methods for Determining System Requirements
3.6.1. Business Process Reengineering (BPR): search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services
3.6.1.1. BPR Goals
3.6.1.1.1. Reorganize complete flow of data in major sections of an organization.
3.6.1.1.2. Eliminate unnecessary steps.
3.6.1.1.3. Combine steps
3.6.1.1.4. Become more responsive to future change.
3.6.1.2. KEY BPR
3.6.1.2.1. Structured
3.6.1.2.2. Focused on customer and outcome
3.6.1.2.3. Same techniques and requirements determination are used
3.7. CASE
3.7.1. CASE Tools
3.7.1.1. Help discover requirements to meet changing business conditions
3.7.1.2. Used to analyze existing systems