Download Software Engineering: Understanding Requirements Elicitation and Analysis and more Study notes Software Engineering in PDF only on Docsity! 1 CSE 435: Software Engineering K. Stirewalt Requirements elicitation/analysis Part I: Elicitation Topics: – Problem statements, requirements, and elicitation CSE 435: Software Engineering K. Stirewalt “Because computers can serve so many purposes, the practice of sw development is less specialized than the established engineering disciplines. That’s why [software engineers] should start by describing the problem in a way that’s rarely necessary in other engineering disciplines, where the diversity of problems to be solved is much smaller. The automotive engineer designing a sports car does not need to ask whether the car must be capable of carrying 15 people, traveling underwater, carrying a ten ton load, or moving backwards at 100mph.” -- Michael Jackson CSE 435: Software Engineering K. Stirewalt Cost of requirements errors by phase Analysis Design Testing Post-deployment CSE 435: Software Engineering K. Stirewalt “Gulf” between client and developer perspectives on software requirements DeveloperCustomer CSE 435: Software Engineering K. Stirewalt “Bridging” the gulf DeveloperCustomer Requirements Specification CSE 435: Software Engineering K. Stirewalt The requirements specification Critical artifact, for many reasons: – freezes “what” is to be developed • should be no new requirements added once development begins • equivalent to a “project handout” in a programming course – part of the “contract” between client and developer Two schools of thought on notion of “freezing” reqts 1. It is a myth to think we can freeze requirements; therefore, we must develop software assuming new reqts will arrive after development begins 2. It is vain to think we can develop a quality system if new reqts are added after development begins; therefore, the reqts spec should be thorough and subjected to quality assurance Waterfall processes subscribe to the second view 2 CSE 435: Software Engineering K. Stirewalt Issues Given the critical nature of the requirements specification, important to get it right! Meta-requirements (i.e., reqts of a reqts spec): – consistent – complete – understandable by both client and developer Question: Why might these meta-requirements be difficult to satisfy? CSE 435: Software Engineering K. Stirewalt Completeness/consistency problems Consistency problems: – Multiple interpretations of similar terms • developer’s vocabulary vs. client’s – Concepts “built upon” undefined concepts/terms • E.g., scheduling system based on notion of “constraint” • But constraint never really defined – E.g., is a “recurring commitment” one or multiple constraints? Completeness problems: – Customer may have only a fuzzy understanding of what he or she wants – Developer lacks “implicit knowledge” of client domain CSE 435: Software Engineering K. Stirewalt Addressing obstacles XX X X Writing/ rhetoric Readability XXXCompleteness XXXConsistency Analysis/ synthesis Elicitation Skill Obstacle CSE 435: Software Engineering K. Stirewalt Elicitation techniques CSE 435: Software Engineering K. Stirewalt Client View of Domain Clients can’t be expected to have rigorous or formal view of domain Hence, can’t be expected to completely be aware of domain-problem relationship Some knowledge is explicit – Easier to get at... Some knowledge is implicit – Many constraints are implicit – Hard to get at... CSE 435: Software Engineering K. Stirewalt Technique: Initial client interview Goal: Discover as many requirements as you can in a limited amount of time Implications: – Essentially an information-extraction process – Ask open-ended questions • ask them in more than one way – Your analysis should be very limited • OK to ask follow up questions, but don’t get bogged down analyzing one requirement, or you will run out of time • Never (during this interview): – suggest a “better way to think about it” – express opinions on answers
