ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

Ch04

?Download as PPT, PDF?
?
ÏôÃÀÁ«
ÏôÃÀÁ«

The document discusses requirements analysis techniques including interviews, JAD sessions, questionnaires, document analysis and observation. It describes strategies for requirements analysis like business process automation, improvement and reengineering. Finally, it explains that the system proposal is the result of planning and analysis phases and includes an executive summary, requirements definition and system models.

1 of 37
Downloaded 45 times
Chapter 4: Requirements Analysis
Objectives Understand how to create a requirements definition. Become familiar with requirements analysis techniques. Understand when to use each requirements analysis technique. Understand how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation. Understand when to use each requirements-gathering technique.
The SDLC and Requirements The SDLC transforms the existing (as is) system into the proposed (to be) system Requirements determination step is the single most critical step of the entire SDLC Studies show that more than half of all system failures are due to problems with requirements
REQUIREMENTS DETERMINATION
Defining a Requirement A statement of what the system must do or what characteristic it must have During analysis, requirements are written from the perspective of the businessperson Two kinds of requirements: Functional Nonfunctional
Nonfunctional Requirements
Requirements Definition Report Correct Unambiguous Complete Consistent Verifiable Modifiable Traceable Ranked for importance
A Bad Requirement Initial Specification : Software will not be loaded from unknown sources onto the system without first having the software tested and approved. Critique : Ambiguous ¨C if the software is tested and approved, can it be loaded from unknown sources? (not) Testable ¨C it is stated as a negative requirement making it difficult to verify. (not) Traceable ¨C a unique identifier is missing. Re-specification : 3.4.5.2 Software shall be loaded onto the operational system only after it has been tested and approved.
Determining Requirements Requirements are best determined by systems analysts and business people together Techniques available to the systems analyst: Interviews Questionnaires Observation Joint application development (JAD) Document analysis
REQUIREMENTS ANALYSIS STRATEGIES
Requirements Analysis Strategies The basic process of analysis is divided into: Understanding the as-is system Identifying improvements Developing requirements for the to-be system There are 3 requirements analysis strategies Business process automation Business process improvement Business process reengineering
Business Process Automation BPA leaves the basic way in which the organization operates unchanged and uses computer technology to do some of the work Low risk, but low payoff Planners in BPA projects invest significant time in understanding the as-is system using: Problem analysis Root cause analysis
Problem Analysis Users and managers identify problems with the as-is system and describe how to solve them in the to-be system Tends to solve problems rather than capitalize on opportunities Improvements tend to be small and incremental
Root Cause Analysis Users are not asked for solutions, but for: A list of (prioritized) problems All possible root causes for those problems Analysts investigate each root cause to find: Solutions for the highest priority problems Root causes that are common to multiple problems
Root Cause Analysis Example
Business Process Improvement BPI makes moderate changes to the way in which the organization operates to take advantage of new opportunities offered by technology or to copy what competitors are doing Common activities: Duration analysis Activity-based costing Informal benchmarking
Business Process Reengineering BPR changes the fundamental way in which the organization operates Spends little time understanding the as-is, because their goal is to focus on new ideas and new ways of doing business Popular activities: Outcome analysis Technology analysis Activity elimination
Selecting the Appropriate Strategies
REQUIREMENTS-GATHERING TECHNIQUES
Five Basic Steps of Interviews Selecting interviewees Designing interview questions Preparing for the interview Conducting the interview Post-interview follow-up ºÝºÝߣ
Selecting Interviewees Based on information needed Often good to get different perspectives Managers Users Ideally, all key stakeholders ºÝºÝߣ
Interviewing Strategies How can order processing be improved? How can we reduce the number of times that customers return ordered items? How can we reduce the number of errors in order processing (e.g., shipping the wrong products)? Top-down Bottom-up High-level: Very general Medium-level: Moderately specific Low-level: Very specific
Post-Interview
Joint Application Development Allows the project team, users, and management to work together to identify requirements for the system Often the most useful method for collecting information from users Key roles: Facilitator Scribe
JAD Meeting Room JPEG Figure 5-5 Goes Here
The JAD Session Tend to last 5 to 10 days over a three week period Prepare questions as with interviews Formal agenda and ground rules Facilitator activities Keep session on track Help with technical terms and jargon Record group input Help resolve issues Post-session follow-up
Managing Problems in JAD Sessions Reducing domination Encouraging non-contributors Side discussions Agenda merry-go-round Violent agreement Unresolved conflict True conflict Use humor
Questionnaires A set of written questions used to obtain information from individuals Often used for large numbers of people from whom information and opinions are needed Common technique with systems intended for use outside the organization Response rates vary, but typically are significantly less than 50%
Questionnaire Steps Selecting participants Using samples of the population Designing the questionnaire Careful question selection Administering the questionnaire Working to get good response rate Questionnaire follow-up Send results to participants
Good Questionnaire Design Begin with non-threatening and interesting questions Group items into logically coherent sections No important items at the very end Do not crowd a page with too many items Avoid abbreviations Avoid biased or suggestive items or terms Number questions to avoid confusion Pretest to identify confusing questions Provide anonymity to respondents
Document Analysis Provides clues about existing ¡°as-is¡± system Typical documents Forms Reports Policy manuals Look for user additions to forms Look for unused form elements
Observation Users/managers often don¡¯t remember everything they do Checks validity of information gathered other ways Behaviors change when people are watched Careful not to ignore periodic activities Weekly ¡­ Monthly ¡­ Annual
Other Techniques Throw-away prototyping Role playing CRC cards with use cases Mind/concept mapping
Selecting Appropriate Techniques
THE SYSTEM PROPOSAL
The System Proposal The result of the planning and analysis phases Typically includes: Executive summary System request Work plan Feasibility analysis Requirements definition Evolving system models
Summary Requirements determination Requirements analysis strategies Requirements-gathering techniques The system proposal

More Related Content

Ch04

  • 2. Objectives Understand how to create a requirements definition. Become familiar with requirements analysis techniques. Understand when to use each requirements analysis technique. Understand how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation. Understand when to use each requirements-gathering technique.
  • 3. The SDLC and Requirements The SDLC transforms the existing (as is) system into the proposed (to be) system Requirements determination step is the single most critical step of the entire SDLC Studies show that more than half of all system failures are due to problems with requirements
  • 5. Defining a Requirement A statement of what the system must do or what characteristic it must have During analysis, requirements are written from the perspective of the businessperson Two kinds of requirements: Functional Nonfunctional
  • 7. Requirements Definition Report Correct Unambiguous Complete Consistent Verifiable Modifiable Traceable Ranked for importance
  • 8. A Bad Requirement Initial Specification : Software will not be loaded from unknown sources onto the system without first having the software tested and approved. Critique : Ambiguous ¨C if the software is tested and approved, can it be loaded from unknown sources? (not) Testable ¨C it is stated as a negative requirement making it difficult to verify. (not) Traceable ¨C a unique identifier is missing. Re-specification : 3.4.5.2 Software shall be loaded onto the operational system only after it has been tested and approved.
  • 9. Determining Requirements Requirements are best determined by systems analysts and business people together Techniques available to the systems analyst: Interviews Questionnaires Observation Joint application development (JAD) Document analysis
  • 11. Requirements Analysis Strategies The basic process of analysis is divided into: Understanding the as-is system Identifying improvements Developing requirements for the to-be system There are 3 requirements analysis strategies Business process automation Business process improvement Business process reengineering
  • 12. Business Process Automation BPA leaves the basic way in which the organization operates unchanged and uses computer technology to do some of the work Low risk, but low payoff Planners in BPA projects invest significant time in understanding the as-is system using: Problem analysis Root cause analysis
  • 13. Problem Analysis Users and managers identify problems with the as-is system and describe how to solve them in the to-be system Tends to solve problems rather than capitalize on opportunities Improvements tend to be small and incremental
  • 14. Root Cause Analysis Users are not asked for solutions, but for: A list of (prioritized) problems All possible root causes for those problems Analysts investigate each root cause to find: Solutions for the highest priority problems Root causes that are common to multiple problems
  • 16. Business Process Improvement BPI makes moderate changes to the way in which the organization operates to take advantage of new opportunities offered by technology or to copy what competitors are doing Common activities: Duration analysis Activity-based costing Informal benchmarking
  • 17. Business Process Reengineering BPR changes the fundamental way in which the organization operates Spends little time understanding the as-is, because their goal is to focus on new ideas and new ways of doing business Popular activities: Outcome analysis Technology analysis Activity elimination
  • 20. Five Basic Steps of Interviews Selecting interviewees Designing interview questions Preparing for the interview Conducting the interview Post-interview follow-up ºÝºÝߣ
  • 21. Selecting Interviewees Based on information needed Often good to get different perspectives Managers Users Ideally, all key stakeholders ºÝºÝߣ
  • 22. Interviewing Strategies How can order processing be improved? How can we reduce the number of times that customers return ordered items? How can we reduce the number of errors in order processing (e.g., shipping the wrong products)? Top-down Bottom-up High-level: Very general Medium-level: Moderately specific Low-level: Very specific
  • 24. Joint Application Development Allows the project team, users, and management to work together to identify requirements for the system Often the most useful method for collecting information from users Key roles: Facilitator Scribe
  • 25. JAD Meeting Room JPEG Figure 5-5 Goes Here
  • 26. The JAD Session Tend to last 5 to 10 days over a three week period Prepare questions as with interviews Formal agenda and ground rules Facilitator activities Keep session on track Help with technical terms and jargon Record group input Help resolve issues Post-session follow-up
  • 27. Managing Problems in JAD Sessions Reducing domination Encouraging non-contributors Side discussions Agenda merry-go-round Violent agreement Unresolved conflict True conflict Use humor
  • 28. Questionnaires A set of written questions used to obtain information from individuals Often used for large numbers of people from whom information and opinions are needed Common technique with systems intended for use outside the organization Response rates vary, but typically are significantly less than 50%
  • 29. Questionnaire Steps Selecting participants Using samples of the population Designing the questionnaire Careful question selection Administering the questionnaire Working to get good response rate Questionnaire follow-up Send results to participants
  • 30. Good Questionnaire Design Begin with non-threatening and interesting questions Group items into logically coherent sections No important items at the very end Do not crowd a page with too many items Avoid abbreviations Avoid biased or suggestive items or terms Number questions to avoid confusion Pretest to identify confusing questions Provide anonymity to respondents
  • 31. Document Analysis Provides clues about existing ¡°as-is¡± system Typical documents Forms Reports Policy manuals Look for user additions to forms Look for unused form elements
  • 32. Observation Users/managers often don¡¯t remember everything they do Checks validity of information gathered other ways Behaviors change when people are watched Careful not to ignore periodic activities Weekly ¡­ Monthly ¡­ Annual
  • 33. Other Techniques Throw-away prototyping Role playing CRC cards with use cases Mind/concept mapping
  • 36. The System Proposal The result of the planning and analysis phases Typically includes: Executive summary System request Work plan Feasibility analysis Requirements definition Evolving system models
  • 37. Summary Requirements determination Requirements analysis strategies Requirements-gathering techniques The system proposal

Editor's Notes

  • #8: Source: IEEE Standard 830-1998: IEEE Recommended Practice For Software Requirements Specifications