Requirements AnalysisRequirementsSlide 3Slide 4Analysis PrinciplesReviewing a requirements documentWhy is requirements analysis difficult?Slide 8First Law of Software EngineeringReasons for changing requirementsRequirements ProductsAnalysis: Steps to followUse CasesAnalysis: Object ModelSlide 15Slide 16Object Model: Steps to followAnalysis: Dynamic modelDynamic Model: Steps to followAnalysis: IterationSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis11Requirements AnalysisRequirements AnalysisDefining the WHATSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis2RequirementsRequirementsSpecify functionalitymodel objects and resourcesmodel behaviorSpecify data interfacestype, quantity, frequency, reliabilityproviders, receiversoperational profile (expected scenarios)stress profile (worst case scenarios)Software Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis3RequirementsRequirementsSpecify interfaces Control interfaces (APIs)User interfaces - functionality and styleHardware interfacesSpecify error handlingIdentify potential modificationsSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis4RequirementsRequirementsIdentify necessary constraintsperformance, security, reliabilityIdentify areas of riskalternatives to be exploredSpecify validation plansSpecify documentation to be providedSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis5Analysis PrinciplesAnalysis PrinciplesDocument reason for specific requirementsPrioritize requirements High, medium, lowIgnore implementation detailsNeed to know feasible solutions can be developedIf feasibility is a concern, then propose alternatives to be exploredBe prepared to changeSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis6Reviewing a requirements documentReviewing a requirements documentIs it ambiguous?Carefully define terms and use these termsIs it consistent?Is it complete?Vague requirementsOmitted requirementsIs it verifiable?Is it realistic?Does it plan for change?Does it not overly constrain the problem?Have alternatives been considered and explored?Is it clearly presented?Precise, concise, cleardiagram complex objects and behaviorsIs it what the customer wants?Software Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis7Why is requirements analysis difficult?Why is requirements analysis difficult?Communication: misunderstandings between the customer and the analystAnalyst doesn’t understand the domainCustomer doesn’t understand alternatives and trade-offsProblem complexityInconsistencies in problem statementOmissions/incompleteness in problem statementInappropriate detail in problem statementSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis8Why is requirements analysis difficult?Why is requirements analysis difficult?Need to accommodate changeHard to predict changeHard to plan for changeHard to forsee the impact of changeSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis9First Law of Software EngineeringFirst Law of Software Engineering “No matter where you are in the system lifecycle, the system will change, and the desire to change it will persist throughout the lifecycle.”Software Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis10Reasons for changing requirementsReasons for changing requirementsPoor communicationInaccurate requirements analysisFailure to consider alternativesNew usersNew customer goalsNew customer environment New technologyCompetitionSoftware is seen as malleableChanges made after the requirements are approved increase cost and scheduleSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis11Requirements ProductsRequirements ProductsSpecification documentAgreement between customer and developerValidation criteria for softwarePreliminary users manualPrototypeIf user interaction is importantIf resources are availableReview by customer and developer Iteration is almost always requiredSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis12Analysis: Steps to followAnalysis: Steps to followObtain a problem statementDevelop use cases (depict scenarios of use)Build an object model and data dictionaryDevelop a dynamic model state and sequence diagramsVerify, iterate, and refine the modelsProduce analysis documentSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis13Use CasesUse CasesHigh-level overview of system useIdentify scenarios of usageIdentify actors of the system:External entities (e.g., users, systems, etc.)Identify system activitiesDraw connections between actors and activitiesIdentify dependencies between activities (i.e., extends, uses)Software Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis14Analysis: Object ModelAnalysis: Object ModelOrganization of system into classes connected by associationsShows the static structureOrganizes and decomposes system into more manageable subsystemsDescribes real world classes and relationshipsSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis15Analysis: Object ModelAnalysis: Object ModelObject model precedes the dynamic model becausestatic structure is usually better definedless dependent on detailsmore stable as the system evolvesSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements Analysisquirements Analysis16Analysis: Object ModelAnalysis: Object ModelInformation comes fromThe problem statement and use casesExpert knowledge of the application domainInterviews with customerConsultation with expertsOutside research performed by analystGeneral knowledge of the real worldSoftware Engineering CSE470: ReSoftware Engineering CSE470: Requirements