Requirements Elicitation

Transcription

1 Computer Siene Program, The University of Texas, allas Requirements Eliitation Why is it diffiult? What to eliit? What are RE Proesses? A Framework for intial model onstrution & subsequent reengineering 3 fundamental onerns: understand (formally) desribe attain an agreement on the problem Problem omain (at g, banking, loan poliies, et.) Eliitation determine what s really needed, why needed, whom to talk to aquire as muh knowledge as possible Speifiation produe a (formal) RS model: translate "vague" into "onrete", et. make various deisions on what & how Validation assure that the RS model satisfies the users needs reqs. Reqs. models Eliitation Speifiation Validation Request more Validation results omain Feedbak omain

2 Why is it diffiult? A wiked problem f many soures ustomers, tellers, other employees databases, files, hapters, literature, standards, legal issues surveys of similar appliations (what are they, who are they, how suessful are they) f different views on wants and needs f different notations, mental models Eliitation reqs. omain Problem omain f unertainties o we know whom to talk to? o they know what they want/need? o they hange their minds? (at g, banking, loan poliies, et.) f many soures domain experts (aountants, bankers, loan managers, et.) databases, files, hapters, literature, standards, legal issues Why is it diffiult? Soures of requirements [SEI] Unonstrained (many opinions of a group of mgrs) SS Environment for the Sw Reqs. efn Proess Manufaturers of OS Corporate Atg System Enhanements to Corporate Atg System Highly Constrained Airline Flight Control System Missile Guidane System (analysis of dos; speialized domain K. from engineers) % of Reqs Gathered from People Plenty of a priori knowledge Well-established disipline Well-defined produt & proess Fration of reqs. eliited from people inreases as onstraints on the sw reqs. proess derease

3 g g g g Eliitation Why is it diffiult? A wiked problem f many soures ustomers, tellers, other employees databases, files, hapters, literature, standards, legal issues surveys of similar appliations (what are they, who are they, how suessful are they) f different views on wants and needs f different notations, mental models reqs. f unertainties o we know whom to talk to? o they know what they want/need? o they hange their minds? omain Problem omain (at g, banking, loan poliies, et.) f many soures domain experts (aountants, bankers, loan managers, et.) databases, files, hapters, literature, standards, legal issues the "say-do" problem: people know how to do things they normally don t desribe (tait knowledge); desriptions of suh things may be highly inaurate identifiation proess omplex (repetitive interations) ommuniation, oordination proess omplex requirements volatility: Reqs. hange beause the problem being solved hanges, beause people s pereption hanges, beause some involved persons were not ontated or were ontated but not in an appropriate manner. What to eliit? Four s of RE FRs, NFRs Problem omain aountants, bankers, loan mgrs Subjet System System) FRs, NFRs Enterprise Model tellers, lients, mgrs,... eveloper anlalysts, speifiers, designers, mgrs FRs, NFRs FRs, NFRs

4 Jet Propulsion Laboratory (JPL) [Kelly92] nearly 2/3 requirements are due to omission of key information => tehniques of ompleteness => setting the sope => identifying system operations => identifying goals/objetives The Naval Researh Laboratory Navy A-7E ariraft s [Boehm, operational emaro, flight program et al.] ongoing researh sine the mid-70 s 77% of requirements errors were nonlerial 49% inorret fats 31% omission 13% inonsisteny 2% 5% misplaement ambiguity 33% automated of requirements tools an errors detet were a signifiant deteted by number manual of review errors FRs, NFRs Problem omain aountants, bankers, loan mgrs eveloper Subjet anlalysts, speifiers, designers, mgrs Major themes of the ourse Types of Errors Error detetion and removal in defining Why, What & How Four s of RE Enterprise Model System System) FRs, NFRs FRs, NFRs tellers, lients, mgrs,... FRs, NFRs Major themes of the ourse Error detetion and removal Coneptuality Formality Natural language ustomer/users Semi-formal notations Formalisms modellers/ speifiers Clarity shall, will, must, should, et. => formailty (ritiality) A or B => formality (inlusive-or/exlusive-or) mostly A => formality (A in ases C1, C2,..., Cn) perhaps/ould/may/might A => formality (A in ases C1, C2,..., Cn) by and large, often, frequently A => formality (A in ases C1, C2,..., Cn) A or ~A => formally ignore as tautology, but may mean something

5 Major themes of the ourse Error detetion and removal Coneptuality Formality Natural language ustomer/users Semi-formal notations Formalisms modellers/ speifiers Consisteny A and ~A A implies B A ~B => formally false, ignorable, but ould be typo modus ponens A or B ~A ~B Slow hildren at play => semanti issue Major themes of the ourse Error detetion and removal Coneptuality Formality Natural language ustomer/users Semi-formal notations Formalisms modellers/ speifiers Corretness (external Consisteny) When two trains approah eah other at a rossing, both shall ome to a full stop and neither shall start up again until the other is gone. [Kansas legislature, early 1890 s] => senario analysis and/or => formalism Call forwarding: (B -> C); (A -> C); ( -> A) (B -> C); (C -> B)

6 Major themes of the ourse Error detetion and removal Coneptuality Formality Natural language ustomer/users Semi-formal notations Formalisms modellers/ speifiers Completeness hard => eliitation tehniques (logial formalism is modern philosophy) => use of "ontologial" primitives goals, agents, deisions, rationale entities, ativities, onstraints => use of "epistemologial" primitives Major themes of the ourse Error detetion and removal Coneptuality Formality Natural language ustomer/users Semi-formal notations Overspeifiation algorithms (sorting, searhing, routing, serialization, normalization, et.) data strutures (stak, queue, tree, graph, heap, et.) Tehnially unsolvable problems sheduling, pattern reognition, et. Formalisms modellers/ speifiers Also, do not worry at this time about aquiring the resoures to build the house. Your first priority is to develop detailed plans and speifiations. One I approve these plans, however, I would expet the house to be under roof within 48 hours. While you are designing this house speifially for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a onsensus of the population in my area that they like the features this house has. I advise you to run up and look at my neighbor s house he onstruted last year. We like it a great deal. It has many features that we would also like in our new home, partiularily the 75-foot swimming pool. With areful engineering, I believe that you an design this into our new house without impating the final ost.

7 E Teleologial view of systems tel-e-ol-o-gy n., pl. -gies. 1. The philosophial study of design or purpose in natural phenomena. 2. The use of ultimate purpose or design as a means of explaining natural phenomena. [webster] A system has a set of goals it seeks to attain; a system s behavior is explained in terms of its goals. -> traeability, justifiability E.g., Library System within library use only via /phone send an early notie send an overdue notie via mail why? it takes time and money Alternatives to ensure books are regularly available what s regular availability? books in shelf why? to satisfy book request why? to make the system effetive high-level goal E Teleologial view of systems -> Goal-ireted Strategy post a goal refine the goal do everything to meet the goal onsider alternatives analyze tradeoffs Eliitation Problem omain F Goal-ireted Strategy -> Goal struture Goals initially stated by the lient are inrementally refined into subgoals traditionally /OR deompositions goal1 goal1 OR goal2 goal3 goal2 goal3 to satisfy the parent, satisfy all its desendants to satisfy the parent, satisfy any of its desendants

8 E F Goal-ireted Strategy 1: Classial Logi Approah F Expressive Power "Propositional and prediate logi provide all the basi onepts needed for a systemati engineering design methodology" [C. A. Hoare, Mathematial Models for Computing Siene, Oxford Univ. Rpt., Aug. 1994] Example: "good old vending mahine" step 1: identify the top goal ---> "serve_ustomer" identify more domain-speifi goals ---> "dispensing ash", "serving offee", "vending andy bars", "shining shoes", et. => domain analysis step 2: examine what is (really) needed to satisfy the goal. - what produt the ustomer wants - if the vending mahine an dispense the ustomer s hoie (has suffiient inventory?) - if the ustomer has the resoures (ash or redit ard) and is ready to pay for the seletion - if the ustomer has deposited more money than neessary for the purhase - if the seletion and any hange were properly dispensed. E Goal-ireted Strategy 1: Classial Logi Approah F Example: "good old vending mahine" F ustomer_seletion(produt) seletion_availability(produt) ---> Exeutable speifiation (e.g., in Prolog) serve_ustomer ustomer_payment(produt, Payment) vend_payment(produt, Refund) serve_ustomer :- ustomer_seletion(produt) seletion_availability(produt),, ustomer_payment(produt, Payment), vend_payment(produt, Refund).

9 E Goal-ireted Strategy 1: Classial Logi Approah F Example: "good old vending mahine" step 3: inremental expansion E.g., the ustomer needs to know about the hoies, and these hoies should be displayed in some form; the mahine should be able to aept the ustomer seletion. serve_ustomer ustomer_seletion(produt) seletion_availability(produt) ustomer_payment(produt, Payment) display_hoies vend_payment(produt, Refund) get_ustomer_hoie(produt) F ---> Exeutable speifiation (e.g., in Prolog) serve_ustomer :- ustomer_seletion(produt) seletion_availability(produt) ustomer_payment(produt, Payment), vend_payment(produt, Refund). ustomer_seletion(produt) :- display_hoies, get_ustomer_hoie(produt).,, E Goal-ireted Strategy 1: Classial Logi Approah F Example: "good old vending mahine" step 4: how-to elaboration serve_ustomer vertial_diaplay F ustomer_seletion(produt) seletion_availability(produt) ustomer_payment(produt, Payment) display_hoies vend_payment(produt, Refund) get_ustomer_hoie(produt) OR OR mouse_seletion(produt) horizontal_display button_seletion(produt) voie_seletion(produt) ---> Exeutable speifiation (e.g., in Prolog) serve_ustomer :- ustomer_seletion(produt) seletion_availability(produt),, ustomer_payment(produt, Payment), vend_payment(produt, Refund). ustomer_seletion(produt) :- display_hoies, get_ustomer_hoie(produt). display_hoies :- vertial_diaplay. display_hoies :- horizontal_display.

10 E Goal-ireted Strategy 1: Classial Logi Approah F Example: "good old vending mahine" serve_ustomer ustomer_seletion(produt) vertial_diaplay seletion_availability(produt) ustomer_payment(produt, Payment) display_hoies vend_payment(produt, Refund) get_ustomer_hoie(produt) OR OR mouse_seletion(produt) horizontal_display button_seletion(produt) voie_seletion(produt) => ependeny => Traeability: From design to requirements From requirements to design => Rational esign basis for alternatives, tradeoffs, rationale (avoid any erroneous, aidental design) (ensure every requirement is met)