Kiến trúc máy tính và hợp ngữ - Chapter 4: Requirements determination

Chapter 4:Requirements DeterminationObjectivesUnderstand 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 RequirementsThe SDLC transforms the existing (as is) system into the proposed (to be) systemRequirements determination step is the single most critical step of the entire SDLCStudies show that more than half of all system failures are due to problems with requirementsREQUIREMENTS DETERMINATIONDefining a RequirementA statement of what the system must do or what characteristic it must haveDuring analysis, requirements are written from the perspective of the businesspersonTwo kinds of requirements:FunctionalNonfunctionalNonfunctional RequirementsRequirement typeExampleOperationalThe system should be able to fit in a pocket or purseThe system should be able to integrate with the existing inventory system.PerformanceAny interaction between the user and the system should not exceed 2 seconds.The system should receive updated inventory information every 15 minutes.SecurityOnly direct managers can see personnel records of staffCustomers can see their order history only during business hours.Cultural & PoliticalThe system should be able to distinguish between United States and European currencyThe system shall comply with insurance industry standards.Requirements Definition ReportCorrectUnambiguousCompleteConsistentVerifiableModifiableTraceableRanked for importanceA Bad RequirementInitial Specification: Software will not be loaded from unknown sources onto the system without first having the software tested and approved.Critique:Ambiguous – if the software is tested and approved, can it be loaded from unknown sources?(not) Testable – it is stated as a negative requirement making it difficult to verify.(not) Traceable – 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 RequirementsRequirements are best determined by systems analysts and business people togetherTechniques available to the systems analyst:InterviewsQuestionnairesObservationJoint application development (JAD)Document analysisREQUIREMENTS ANALYSIS STRATEGIESRequirements Analysis StrategiesThe basic process of analysis is divided into:Understanding the as-is systemIdentifying improvementsDeveloping requirements for the to-be systemThere are 3 requirements analysis strategiesBusiness process automationBusiness process improvementBusiness process reengineeringBusiness Process AutomationBPA leaves the basic way in which the organization operates unchanged and uses computer technology to do some of the workLow risk, but low payoffPlanners in BPA projects invest significant time in understanding the as-is system using:Problem analysisRoot cause analysisProblem AnalysisUsers and managers identify problems with the as-is system and describe how to solve them in the to-be systemTends to solve problems rather than capitalize on opportunitiesImprovements tend to be small and incrementalRoot Cause AnalysisUsers are not asked for solutions, but for:A list of (prioritized) problemsAll possible root causes for those problemsAnalysts investigate each root cause to find:Solutions for the highest priority problemsRoot causes that are common to multiple problemsRoot Cause Analysis ExampleBusiness Process ImprovementBPI 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 doingCommon activities:Duration analysisActivity-based costingInformal benchmarkingBusiness Process ReengineeringBPR changes the fundamental way in which the organization operatesSpends little time understanding the as-is, because their goal is to focus on new ideas and new ways of doing businessPopular activities:Outcome analysisTechnology analysisActivity eliminationSelecting the Appropriate StrategiesBusiness Process AutomationBusiness Process ImprovementBusiness Process ReengineeringPotential benefitLow–moderateModerateHighProject costLowLow–moderateHighBreadth of analysisNarrowNarrow-moderateVery broadRiskLow–moderateLow–moderateVery highREQUIREMENTS-GATHERING TECHNIQUESFive Basic Steps of InterviewsSelecting intervieweesDesigning interview questionsPreparing for the interviewConducting the interviewPost-interview follow-upSlide 20Slide 21Selecting IntervieweesBased on information neededOften good to get different perspectivesManagersUsersIdeally, all key stakeholdersInterviewing StrategiesHowcan orderprocessing beimproved?How can we reduce thenumber of times that customers return ordered items?How can we reduce the number oferrors in order processing (e.g., shippingthe wrong products)?Top-downBottom-up High-level:Very general Medium-level:Moderately specific Low-level:Very specificPost-InterviewJoint Application DevelopmentAllows the project team, users, and management to work together to identify requirements for the systemOften the most useful method for collecting information from usersKey roles:FacilitatorScribeJAD Meeting RoomJPEG Figure 5-5 Goes HereThe JAD SessionTend to last 5 to 10 days over a three week periodPrepare questions as with interviewsFormal agenda and ground rulesFacilitator activitiesKeep session on trackHelp with technical terms and jargonRecord group inputHelp resolve issuesPost-session follow-upManaging Problems in JAD SessionsReducing dominationEncouraging non-contributorsSide discussionsAgenda merry-go-roundViolent agreementUnresolved conflictTrue conflictUse humorQuestionnairesA set of written questions used to obtain information from individualsOften used for large numbers of people from whom information and opinions are neededCommon technique with systems intended for use outside the organizationResponse rates vary, but typically are significantly less than 50%Questionnaire StepsSelecting participantsUsing samples of the populationDesigning the questionnaireCareful question selectionAdministering the questionnaireWorking to get good response rateQuestionnaire follow-upSend results to participantsGood Questionnaire DesignBegin with non-threatening and interesting questionsGroup items into logically coherent sectionsNo important items at the very endDo not crowd a page with too many itemsAvoid abbreviationsAvoid biased or suggestive items or termsNumber questions to avoid confusionPretest to identify confusing questionsProvide anonymity to respondentsDocument AnalysisProvides clues about existing “as-is” systemTypical documentsFormsReportsPolicy manualsLook for user additions to formsLook for unused form elementsObservationUsers/managers often don’t remember everything they doChecks validity of information gathered other waysBehaviors change when people are watchedCareful not to ignore periodic activitiesWeekly Monthly AnnualOther TechniquesThrow-away prototypingRole playing CRC cards with use casesMind/concept mappingSelecting Appropriate TechniquesInterviewJADQuestion-nairesDocument AnalysisObservationType of informationAs-is, improves, to-beAs-is, improves, to-beAs-is, improvesAs-isAs-isDepth of infoHighHighMediumLowLowBreadth of infoLowMediumHighHighLowInfo integrationLowHighLowLowLowUser involvementMediumHighLowLowLowCostMediumLow-mediumLowLowLow-mediumTHE SYSTEM PROPOSALThe System ProposalThe result of the planning and analysis phasesTypically includes:Executive summarySystem requestWork planFeasibility analysisRequirements definitionEvolving system modelsSummaryRequirements determinationRequirements analysis strategiesRequirements-gathering techniquesThe system proposal