03-RequirementsElicitation01-notes

03-RequirementsElicitation01-notes - Requirements...

Info iconThis preview shows pages 1–4. Sign up to view the full content.

View Full Document Right Arrow Icon
1 CSE 435: Software Engineering B. Cheng Requirements elicitation/analysis Part I: Elicitation Topics: – Problem statements, requirements, and elicitation CSE 435: Software Engineering B. Cheng 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 B. Cheng Cost of requirements errors by phase "OBMZTJT %FTJHO 5FTUJOH 1PTU±EFQMPZNFOU
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
2 CSE 435: Software Engineering B. Cheng “Gulf” between client and developer perspectives on software requirements Developer Customer ht p:/ www1.istockphoto.com/file_thumbview_approve/325621/2/istockphoto_325621_airplane_silhouet e . jpg CSE 435: Software Engineering B. Cheng “Bridging” the gulf Developer Customer Requirements Specification CSE 435: Software Engineering B. Cheng 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
Background image of page 2
3 CSE 435: Software Engineering B. Cheng 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 B. Cheng 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?
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 4
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 9

03-RequirementsElicitation01-notes - Requirements...

This preview shows document pages 1 - 4. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online