Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Software Engineering: Effective Requirements Elicitation and Analysis - Prof. Betty Cheng, Study Guides, Projects, Research of Software Engineering

Insights from b. Cheng's cse 435 software engineering course on the importance of requirements elicitation and analysis in software development. Topics like problem statements, requirements, elicitation techniques, consistency and completeness issues, and the role of client interviews. It also discusses the significance of the requirements specification as a critical artifact and the challenges of satisfying meta-requirements.

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 07/28/2009

koofers-user-bd6
koofers-user-bd6 🇺🇸

10 documents

1 / 9

Toggle sidebar

Related documents


Partial preview of the text

Download Software Engineering: Effective Requirements Elicitation and Analysis - Prof. Betty Cheng and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity! 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 Analysis Desig n Test ing Post-dep loym ent 2 CSE 435: Software Engineering B. Cheng “Gulf” between client and developer perspectives on software requirements DeveloperCustomer http://www1.istockphoto.com/file_thumbview_approve/325621/2/istockphoto_325621_airplane_silhouette.jpg CSE 435: Software Engineering B. Cheng “Bridging” the gulf DeveloperCustomer 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 5 CSE 435: Software Engineering B. Cheng Question Structure is Critical What is the client’s problem? – what, precisely, if the problem to be solved? When does the problem occur? – what generates the problem? – situations, are they new or old? Transient? Where does the problem occur? – what are the problem domain boundaries? How is the problem handled now? Why does the problem exist? Remember, this is a diagnosis / information extraction process CSE 435: Software Engineering B. Cheng Sample System: Smart Cruise Requirements Safety zone Achieve desired trail distance Coast zone Closing zone About 400 ft - acquires target vehicle. Closing speed low enough to control. Starts coasting to match speed Safe zone Maintain proper trail distance - speeds match Closing speed too high. Issues warnings to avoid this condition This is what we want CSE 435: Software Engineering B. Cheng Closed-ended questions Q: When a vehicle cuts in front of the car, you have to slow down quickly and not hit it, right? A: Yes You learned absolutely nothing . 6 CSE 435: Software Engineering B. Cheng Open-ended questions Q: What happens when a car cuts in front of you? A: Well, if the lead car is too close, the driver has to intervene or else a crash results. I guess we need a warning light in this case. If the car is moving faster, you don’t have to do anything. He’s pulling away. I guess the only time brakes are used is when the closing speed is too high for the distance and yet within the capabilities of the system to slow down. But I guess if a collision is imminent, we should max out the braking. Now, we learned something... Clarification New reqt! CSE 435: Software Engineering B. Cheng Dialogue with different responses Q: Tell me what should happen if a car cuts in front of our car too close to avoid a collision? Q: What? Are you nuts? We should at least try to stop. Shouldn’t we? A: Perhaps... Not good You are done at at this point, and still unresolved. A: I guess since there is nothing the system can do, turn off the controller and hope the driver brakes in time. Q: We have quite a bit of braking power in the system. What would happen if we used it here? A: Well, I guess it could avoid a collision and at least get the car slowed down but the attorneys tell me we don’t want the system active when a collision occurs. Ah ha! Non-technical constraint Much better CSE 435: Software Engineering B. Cheng From elicitation to analysis... Your interview should result in a large volume of facts which must be analyzed to derive requirements – Here “analysis” involves both analysis and synthesis – Synthesis: attempt to compose a coherent “model” of the problem requirements A model can be analyzed to: – identify potentially inconsistent facts, and – infer facts that should be true Both of these issues must be clarified, often via a second client interview 7 CSE 435: Software Engineering B. Cheng Putative questions Asks about a situation in a way that tests your model of the domain SWE: “If a lead vehicle turns, or otherwise is not in front of the car anymore, the car can resume the previous speed, correct?” CLIENT: “Yes, exactly.” Very specific question that tests the idea of cruise plus collision avoidance CSE 435: Software Engineering B. Cheng Sample Interview I SWE: Could you tell me about the cruise control system? CLIENT Yes, normal cruise control holds a fixed speed. What we want is to make the car "smart" so that it slows down when there is a vehicle in front of it. SWE: What does a driver currently do in this situation? CLIENT Currently, the driver can step on the brakes to disengage the cruise, or turn the cruise off completely. Or, not use the cruise. SWE: Why is turning off the cruise this way a problem? Establish facts, but open ended. It’s seemingly obvious what happens “now” I.e., Why do you need “smart” Cruise? Try to get at the motivation For the problem CSE 435: Software Engineering B. Cheng Sample Interview II CLIENT In an urban environment, say I-75 in Detroit, using the cruise becomes irritating, but really we are more interested in avoiding collisions. SWE: Tell me more about the collision avoidance aspect, please. CLIENT If we limit how close a lead vehicle can get, and control the speed while the car is in trail, the chances of a collision can be greatly reduced. SWE: How would a system avoid a collision in a typical scenario? CLIENT Suppose the driver is following a truck, but at a higher speed than the truck. As the car closes, the system could alter the speed to match the speed of the truck. SWE: What does the slowdown profile look like? The system is mis-named. This is good info open, info gathering Looking for process/behavior information Specific request for facts
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved