Software Engineering I - Chair for Applied Software Engineering

More documents

Recommendations

Info

Order of steps when formulating use cases • First step: Name the use case • Use case name: ReportEmergency • Second step: Find the actors • Generalize the concrete names (“Bob”) to participating actors (“Field officer”) • Participating Actors: • Field Officer (Bob and Alice in the Scenario) • Dispatcher (John in the Scenario) • Third step: Concentrate on the flow of events • Start with informal natural language © 2008 Bernd Bruegge Introduction into Software Engineering Summer 2008 34
Requirements Elicitation: Difficulties and Challenges • Communicate accurately about the domain and the system • People with different backgrounds must collaborate to bridge the gap between end users and developers • Client and end users have application domain knowledge • Developers have solution domain knowledge • Identify an appropriate system (Defining the system boundary) • Provide an unambiguous specification • Leave out unintended features => 3 Examples. © 2008 Bernd Bruegge Introduction into Software Engineering Summer 2008 35
Page 1 and 2: Software Engineering I: Software Te
Page 3 and 4: Software Lifecycle Definition • S
Page 5 and 6: Software Lifecycle Activities ...an
Page 11 and 12: What is the best Software Lifecycle
Page 13 and 14: What does the Customer say? © 2008
Page 15 and 16: Techniques to elicit Requirements
Page 17 and 18: More Definitions • Scenario: “A
Page 19 and 20: Scenario-based Design • Focuses o
Page 21 and 22: A Visionary Scenario (1954): The Ho
Page 23 and 24: How do we find scenarios? • Don
Page 25 and 26: Scenario example: Warehouse on Fire
Page 27 and 28: After the scenarios are formulated
Page 29 and 30: How to find Use Cases • Select a
Page 31 and 32: Use Case Example: ReportEmergency F
Page 33: Allocate a Resource (cont’d) •
Page 37 and 38: Defining the System Boundary is dif
Page 39 and 40: Example of an Ambiguous Specificati
Page 41 and 42: Requirements Process :problem state
Page 43 and 44: Types of Requirements • Functiona
Page 45 and 46: Types of Nonfunctional Requirements
Page 47 and 48: Types of Nonfunctional Requirements
Page 49 and 50: Some Quality Requirements Definitio
Page 51 and 52: What should not be in the Requireme
Page 53 and 54: Requirements Validation (2) • Cla
Page 55 and 56: Tools for Requirements Management (
Page 57 and 58: Prioritizing requirements • High
Page 59 and 60: Nonfunctional Requirements (Questio
Page 61 and 62: Nonfunctional Requirements (3) Syst
Page 63 and 64: Nonfunctional Requirements (5) Reso
Page 65 and 66: Exercise • Reverse engineer the r
Page 67 and 68: Exercise Solution • Available inf

Software Engineering I - Chair for Applied Software Engineering

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?