This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: 1 Requirements Elicitation CS 442 Software Engineering II Instructor: Ugo Buy January 24, 2012 2 Requirements elicitation • Process of researching work domains in an effort to define SRS of future product • Mostly, the responsibility of core development team 1 . Non-CS, non-software experts cannot frame product description in technically accurate terms 2. Not just an issue in software: If you are not a doctor, you cannot diagnose a patient (just report symptoms) • Can be tedious, painstaking work (examine documents, read problem reports, interview people, etc.) 3 Elicitation in perspective • Blastoff has identified scope of work (with adjacent systems), stakeholders, project objectives • Now, we need to: 1. Understand work in detail 2. Determine what portion of this work will be performed by product 3. Define SRS Must study work and adjacent systems 4 Elicitation guidelines • Generally keep an open mind as to what system should do • Understand the “work context”: (R&R, page 72) “The work context includes anything that you are permitted to change, and anything that you need to understand to decide what can and should be changed.” “The further away from the anticipated automated system you look, the more and innovative your product is likely to be” 5 Business events and use cases • Business events and use cases help developers break analysis of “work” into pieces – Let developers work in parallel – Manage complexity of “work” – Similar to breaking code into classes, methods, etc. • Business event: Events that originate in adjacent systems and cause work to be performed — Action-triggered events — Time-triggered events 6 Business events and use cases (cont’d) • Use case: Interaction between adjacent system and “work” or product – Business use case: Business activities performed in response to business event – Product use case: Functional behavior of product in response to external event • Actor: An adjacent system involved in a use case – Single actor could be involved in multiple use cases 2 7 Example of use case • OOAD example: Someone buys a painting from OO Osbert Overby Art Dealer Buy a painting OO buyer 8 Business event identification 1. Starting from context diagram from blastoff, consider each information flow between “work” and an adjacent system 2. Analyze flow – What makes the flow happen? Focus on non-timed events – Discover the “root cause” for the flow – Question current practice 3. Redraw context diagram? – Include adjacent system in “work”? 9 Example of event identification • LAS operator receives phone call from patient or police department – Is this a good event? This is standard practice • But what was the root cause?...
View Full Document
This note was uploaded on 02/23/2012 for the course COMP 553 taught by Professor Ajay during the Spring '12 term at Ill. Chicago.
- Spring '12
- Software engineering