Class Note for EECS 448 with Professor Niehaus at KU 4
Class Note for EECS 448 with Professor Niehaus at KU 4
Popular in Course
Popular in Department
This 11 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at Kansas taught by a professor in Fall. Since its upload, it has received 17 views.
Reviews for Class Note for EECS 448 with Professor Niehaus at KU 4
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 02/06/15
Determining What the Client Needs Requirements Primary objective of the requirements WF is to determine what features should be in the product to satisfy the needs of the client Client will almost always not know all of their needs at a sufficient level of detail Clients also often lack the proper vocabulary for describing their needs in ways SWEs can use Chapter 10 SWE must determine the needs of the client that the product software will satisfying in some way or other EECS 448 Software issues are hard to understand for SWE Dr Douglas Niehaus 39 Harder for Cllent EECS 44B 1 Dr Douglas Niehaus 2009 EECS 44B 2 Dr Douglas Niehaus 2009 Overview of Requirements WF Business Model First step is to gain an understanding of the target Describes the business process being address by domain in which the product offers a problem the product and is thus key to understanding product solution requirements and is fundamental to analysis Eg banking Space exploration printing or home Provides an understanding of the client s activities automation as the case may be as a whole and how the problem addressed by the Once the SWE understands the relevant aspects of PFQdUCi ms m conteXt the domain they can build a business model 39 BUIIdlng a bUSIneSS mOdel UML diagrams describing the client s business 39 SWE mUSt educate themselves abOUt target processes as a set of use cases domain to learn the vocabulary and issues Model of activity is then used to determine the initial 39 SWE must learn the Var39ou Pus39mss processes set of requirements Models are tested by explaining them to others and comparison to the real world 39 39teiat39ve process In Vlrtually all cases Models of the processes are refined through ReqUIrements discovery and then refinement further investigation EECS 44B 3 Dr Douglas Niehaus 2009 EECS 44B 4 Dr Douglas Niehaus 2009 Interviewing Interviewing Interviewing is the primary technique to gain this knowledge in many cases but not all Reasoning from first principles Books WWW etc SWE placing themselves in the role of the client Depends on the subject matter Two fundamental types of questions Closedended require a specific answer What is a maximum acceptable response time Openended asked to encourage speaking out WhyHow is the current software supporting this business process unsatisfactory What do you find annoying EECS 448 Dr Douglas Niehaus 2009 Interviewing Two basic kinds of interviews Structured Preplanned questions that are frequently closedended Unstructured Starts with a few prepared closedended questions but Subsequent questions are in response to previous answers and issues raised Subsequent questions are likely to be more open ended and designed to explore new issues raised Iteration is key what you learn in one interview influences what you do before and in the next EECS 44B 6 Dr Douglas Niehaus 2009 Interviewing Too little structure can be inefficient Knowledge revealed is too scattered New knowledge usually comes from Unexpected answers to closedended question Inability of client to answer closedended questions Openended questions What annoys youquot SWE is a detective Answers are clues to further relevant questions Detailed domain knowledge is key to picking up on subtle clues or implications of answers SWE need to advise clients on best use of computers Not all processes benefit from software support EECS 44B 7 Dr Douglas Niehaus 2009 Interviewing well is difficult interviewer must Be well informed about target domain Aware they still have much to learn Detect clues that they are confused or something they believe to be true is in conflict with what they are hearing gt New questions to reconcile conflict Remain open minded about client needs Listen carefully while suppressing preconceived notions about the problem domain Take good notes After the interview it is advisable to write a report describing what relevant issues Be prepared for everyone to disagree This is good It focusses clarificationaddition EECS 44B 8 Dr Douglas Niehaus 2009 Interviewing Other Techniques Report should include the growing glossary Other techniques can fill in gaps left by interviewing Opportunity to refine entries and their definitions Used as supplements to interviewing as well Need to redefine existing terms or add new Questionnaire definitions are key clues about misunderstandings Sent to relevant Client community members Practising usecase descriptions and how they relate to the business model is key to debugging SWE xvgaelnaigsvvgsrs may be Imponantly dlfferent than understanding of the problem domain Socratic method of focussing on the structure of arguments and missing pieces is powerful I I I I More generally using basic methods of debate to Drawback is that it cannot pose further questions test arguments describing business models and their 39nI response to answers g39Ven solutions among group members is powerful 39 BUSIHeSS Forms Define the vocabulary of a given process Different information Possibly more accurate EECS 44B 9 Dr Douglas Niehaus 2009 EECS 44B 10 Dr Douglas Niehaus 2009 Other Techniques Other Techniques Business Forms Scenarios should39include expected operations and Define information flow as they are passed among exceptlons 0r Optlons workers Clients can often describe scenarios far more richly Operating Procedures Job Descriptions than they can answer queStlonS More internalized knowledge often unconscious Scenarios can be described in many ways List actions H d Story Board Series of scenes and commentary 39 uman or VI 90 camera Tree nodes are screens branches actions 39 can take a long time to analyse Scenarios provide concrete components for clients Can be annoying to employees and SWEs to discuss Scenarios describe how a product is used to Scenarios gt use cases play an important role in 00 accomplish a given purpose analysis EECS 44B 11 Dr Douglas Niehaus 2009 EECS 44B 12 Dr Douglas Niehaus 2009 Manuals for existing SW Direct observation of clients Need written permission in most cases Use Cases Use Cases A model is a set of UML diagrams representing components of a product being developed Use case is primary UML diagram used for business modelling Use case models interaction among I userslenVIronment and product In completing a specrfIc scenario Highlights a specific set of functions Related to each other in supporting this and other use cases Excellent for generating tests Excellent for organizing iterative refinement EECS 448 13 Dr Douglas Niehaus 2009 Initial Requirements Initial requirements drawn up based on initial business model Requirements are refined as the model is refined Requirements change frequently Handle changes by updating list of requirements and how they correspond to sets of use cases Two categories Functional and nonfunctional Functional Actions the product must perform Often expressed in terms of inputoutput Handled during requirements and analysis WFs EECS 448 15 Dr Douglas Niehaus 2009 Actors users of the product Components of the outside world May fall into several categories May be other software products UML stick figure with label SW components rectangles Business Activity label inside oval Banking Software Product Teller ustomer EECS 448 14 Dr Douglas Niehaus 2009 Initial Requirements Nonfunctional Requirements Specify properties of a product Platform constraints response time reliability May wait until design workflow Require more detailed knowledge Focus on properties of an architecture May not be available until RampA are complete Handle as early as possible gt RampA Book illustrates requirements WF with an art dealer case study Specialized domain knowledge about paintings and other aspects of art business EECS 448 16 Dr Douglas Niehaus 2009 Initial Requirements Vocabulary for categorizing paintings Medium oil water pastel pencil Subject portrait landscape still life Quality Masterpiece Masterwork other All become domain glossary elements Landscape a painting of a scene in nature Masterpiece a painting of undoubted excellence Mnsterworlt an inferior painting by an artist who previously or subsequently has painted a masterpiece Medium a classification criterion the material with which an artwork is painted see also oil watercolor Oil 3 medium abbreviation for quotoilbased paintquot Other painting a painting that s neither a masterpiece nor a masterwork Portrait a painting of one or more people Quality at dassir icat on criterion 3 painting is classi ed as a masterpiece mastenvork or other painting depending on its quality Still life a painting of inanimate objects Subiect a classification criterion subjects include landscape portrait and still life Watercolor a medium abbreviation for quotwatcrrbascd paintquot EECS 448 17 Dr Douglas Niehaus 2009 Initial Requirements Initial version can be quite simple Serves a basis for discussion reaction refinement Several quick iterations often produce better results than trying to do too much at each stage Brief Description The Produce a Report use case enabia Osbert Oglesby to obtain information on paintings he has bought or sold in the past year St b 5 D 39 ti Osbert Oglesby Nap y 2quot Strip 7quot 0t applicable at Li39IIS initial stage Art Dealer Brief Description seuer The Buy a Painting use case enables Osbert O lesb 9 Y to buy a painting StepbyStep Description Q Not applicable at this initial stage Osbert Brief Description Buyer The Se39l i a Painting use case enables Osbert Oglesby to sell a painting Step byStep Description Not applicable at this initial stage EECS 448 19 Dr Douglas Niehaus 2009 Initial Requirements Art Dealer interview Considered utility of laptop supporting business Considered dealer39s activities and concerns Painting pricing Algorithm for establishing maximum price Software should detect trends in art market Historical information storage and analysis Software should produce reports Initial model Activities Buy Sell Report Use cases Buy Sell Report EECS 448 18 Dr Douglas Niehaus 2009 Initial Requirements Discussion with Art Dealer extracts initial requirements from the initial use cases Discussion can also identify more use cases Initial descriptions are expanded in response to Information emerging from client InterVIew OO analysis concentrates on refining precision of the descriptions iteratively Brief Description The Buy a Painting use case enables Osbcrt Oglcsby to buy a painting StepbyStep Description I Osbert inputs details of the painting he is considering buying 2 The software product responds with the maximum purchase price he should offer 3 If the seller accepts Osbert39s offer to buy the painting Osbert enters further details Note Details of the algorithm for determining the maximum price will be obtained later EECS 448 20 Dr Douglas Niehaus 2009 Requirements Refinement Iterative refinement Data for each painting is refined by examining current records maintained manually forms Painting Description Artist title date Classification dimensions medium subject Purchase date seller data price Target selling prices common markup Maximum purchase price as predicted Sale date buyer actual selling prices Other data for maximum price algorithm needed by consultant developing it EECS 448 21 Dr Douglas Niehaus 2009 Requirements Refinement uricr Dcmilmnn 01 rm use an r luulu Harri linljl 1 lu s 001ng Step byrstrp omripriun I FRI ML ir lull Llleciequh m39 39hr Ninth11 S N mil rng bupllq lhesearz Cusl mum rm rr prudm r 391 Jitl c mos Ilrrhr 2 maxmum pm re re uctm pn wupuwjgd arnujllu Mar 1 w Sum I Il39 r pmmllxlrll lila m rmurlrw mars pir r mpmm lawn m mm mm Lul39Jlm nrir mlwrr l nu g TC CCrt r39rrnr m r an aurl marks H at n9 tl39t so l A39re ndllrr r 04ng lhc mm r quotcm m or39r39ulnl 4 1 LOT nl l but arm y r m u 4 a Llre tenrmwten lf re I 00 ll lc L uylhe parrling Immulrrug uumtutl u lvsuldr rm39u nl s I purchzse p rze 09 mqu mm we ll ll urns10mm Mlxu39un mm largrlsrlmgp rlw due mum m 04 all ml w EECS 448 23 Dr Douglas Niehaus 2009 Requirements Refinement Report Types Current reports examined forms Needs discussed Data to be included identified Sorting and averaging needs identified Trend detection Consistency of higher prices for an artist Buy a work by that artist Related reports Works sold Prices exceeding targets EECS 448 22 Dr Douglas Niehaus 2009 Requirements Refinement Report Date 00142004 Oahuc 051951017 7 Qallaccor cf Fine Art EDUGHT PAINTINGS Report Date 00142004 oabezc Ogleaby 7 Collector at Fine Art SOLD PAINTINGS CUBBIPICHTION 39Mastcrwoxk MET NAME HananAr sues PRICE 54300 PURCHASE mun 02002004 TITLE TabchMountnin enemas 10103 123000 maomzcmxom Mantelwork LAM mum Hacznyar TARGET PRICE 254450 0223 3200 05112000 I MLE Tublci ountain SELLING PRICE 270000 CLASSIFICATION masterwork LAST NAME Hazayar sues muse 51500 PURCHASE DATE 03052004 TITLE walkexi ay PURCHASE PRICE 75000 CLASSIFICATION Masterwork SALE DA L E 06122004 LAST m Hazayar l I walkexjay TARGET PRICE 161250 SELLING macs 205000 cussn mm39mn other LAST mus Amman SUGG prune L5400 00mins mas 04102000 TITLE Applesltand0ranges 0011mm mum 2000 IASSIPTSM ION 39ozher LAST NAME Mann TARGET PRICE 4300 DATE 07132004 Applesiandioranges 32ING PRICE 300 Average Katie L65 Average ratio 11 Repcxt Date own2004 ashes Uglesay Collector of Fine Arc TRENDS Arr Lat David Hat zayar CLASSIFIEATIOV masterwork SALE DATE Mill2004 TARGET PRICE 264450 TITLE Tableihountain SELLING PRICE 270003 CLASSIFICATION masterwork SALE DATE 05122004 TARGET PRICE 161250 TITLE wa karjay SELLING PRICE 205 000 EECS 448 24 Dr Douglas Niehaus 2009 Test WorkFlow While performing the requirements WF group members must constantly try and check their work Explain use cases to others SQA group can check things Initially one is looking for Omissions errors of fact and contradictions Art Dealer case study uses fashionability coefficient Process identified a desired quantifier Semantics of it permit varying by month Use cases and descriptions extended Changes can happen at any time because insight can happen at any time EECS 448 25 Dr Douglas Niehaus 2009 Classical Requirements Phase In one sense there can be no objectoriented requirements phase as Aim is to determine client needs Requirements WF has nothing to do with how the product is to be structured Policy not yet mechanism In another sense the entire approach is 00 since It is model oriented and the world is littered with objects of one kind or another Use cases and the components of their descriptions form the basis of requirements WF Modelling components are generally objects EECS 448 27 Dr Douglas Niehaus 2009 Test WorkFlow Realizing the product must permit the dealer to change the coefficient the interface requirements are extended Online versions of diagrams and documents are thus vital as they are frequently changed Osherl Oglesby Art Dealer g g Sell a Painting Produce a Report gtl Seller gtl Osbert w 39lt m Update a Fashionahlllty Coefficient Figure 1022 EECS 448 26 Dr Douglas Niehaus 2009 Classical Requirements Phase Classical requirements phase Starts with requirements elicitation Followed by requirements analysis Next is to draw up a list of requirements Usual next step is to build a rapid prototype RP Implements the key functionality underlying the requirements providing something concrete for the client to react to Feedback from client supports adjustment to RP and requirements Building a RP emphasizing the userinterface is advisable rather than internal components All aspects should be traceable EECS 448 28 Dr Douglas Niehaus 2009 Classical Requirements Phase Rapid Prototyping Traceability ensures all relevant aspects of the A RP is a hastily built version of the software requirements can be related to aspects of the exhibiting key interface andor functionality features specifications design and code of the target product Traceability can be applied to RP as well A RP reflects the features the client sees Numbering requirements components helps with Omits the hidden aspects traceability RP gives the client a concrete target for reaction Clients review requirements and express priorities Developers observe and discuss reactions 39 categories essential highly deSirab39e nice etC Only bad reaction is no reaction as all reactions Come requirements may be corrected or deleted provide information Several iterations of refinement may be required Dislike and the reasons for it are often more informative than any other reaction Adjustments to RP can be used to foster agreement between developers and clients EECS 44B 29 Dr Douglas Niehaus 2009 EECS 44B 30 Dr Douglas Niehaus 2009 Rapid Prototyping Rapid Prototyping RP agreed on by clients and developers is a valuable Concerns about maintainability of interpreted resource for writing specifications languages for permanent implementation are not Important aspects of RP relevant to RP Built as quickly and cheaply as possible RP particularly popular for user interfaces Enabling clients and developers to agree as Advantage of PythonGTK and equivalents is that the quickly as possible RP may be the final implementation Build for change as much as possible perrQT RubyQT etc Fourth Generation and Interpreted languages have been used for RP GUI designers generating code are also used Smautark prolog Lisp in roast Performance sensitive aspects of an application can HTML Perl Visual Basic Python today be 39mplergelnted separately and wrapped by Sometimes also good for major parts of final Interprete anguages product particularly those not performance SWIG and other tools can do this automatically dependent Python wrappers for CC libraries for example EECS 44B 31 Dr Douglas Niehaus 2009 EECS 44B 32 Dr Douglas Niehaus 2009 Rapid Prototyping RP is a viable technique that can lead to successful development but there are several risks Ease of changing the RP can tempt a client into making many changes not just refinements Speed for changing RP can lead client into thinking all development will be just as fast Throwing a RP away can seem wasteful to clients Advantage of Python and other wrappers since the main components can be in CC EECS 44B 33 Dr Douglas Niehaus 2009 Human Factors Explicit study of how humans tend to interact with software using a variety of interfaces for various types of data Encouraging users to play with RP and other representations of UI helps ensure satisfaction through userfriendliness Several established metaphors were once innova ons Menus various buttons windows icons drag anddrop scroll bars Also conventions about fonts capitalization keyboard shortcuts standard menu items Producers often extend conventions across many products even across companies EECS 44B 35 Dr Douglas Niehaus 2009 Testing During Requirements Phase Essential that a range of users have a chance to interact with RP Can be different from client Key is a large enough reaction set to generalize Individual reactions can be outliers SQA group can provide feedback by organizing sets of testers and ensure suggestions reviewed by client RP have been used instead of written specifications Fast and gives a concrete example to work from However in case of disagreements a RP cannot stand as a legal statement of contract Both is stronger as one can comparecontrast words and RP EECS 44B 34 Dr Douglas Niehaus 2009 CASE Tools for Requirements WF Drawing program specifically supporting UML Can link to document sections and descriptions OnIine changes to diagrams are easier although machine drawn are usually less appealing GUI design tools Can generate CC code Can be complex to properly track relationships of widgetssignals and handlers Learning curve makes this less attractive for 448 Also after doing GUI by hand you understand what a GUI designer is doing much better CASE tools always reflect designers assumptions about process which may not fit your situation as well Can have steep learning curves EECS 44B 36 Dr Douglas Niehaus 2009 CASE Tools for Requirements WF Metrics for Requirements WF CASE Tools are popular in many organizations Key feature of requirements WF is how quickly the Strengths outweigh weaknesses requirements team can determine the clients needs Existing CASE workbenches extended for UML 39 user39 metr39C 393 reqU39fementS VOIatlllty System Architect and Software through Pictures 39 Keep words Of rqu39rements Changes 00 CASE tools AnalySIs can determine rate of convergence R dT th Orlackofit 089 an 099 er Convergence rate evaluation can be applied to any 39 Open source AFQOUML method for eliciting requirements Another measure is how many requirements change during later phases Initiated by developers review requirements WF Initiated by clients warn about moving target problem and further changes held to minimum EECS 44B 37 Dr Douglas Niehaus 2009 EECS 44B 38 Dr Douglas Niehaus 2009 Metrics for Requirements WF Challenges of Requirements WF How often RP features and components are used Deciding on the essential elements of a good during testing solution to the real problem is hard Popularity or difficulty Requires cooperation of potential users May feel threatened b chan es resulting from computerization andt e pro uct Negotiation can be difficult Scaling down what the client wants Products cannot do everything Compromising among client managers with their own possibly competing sets of concerns Gaining access to key domain knowledge can reqUIre access to key client workers Commitment of client organization EECS 44B 39 Dr Douglas Niehaus 2009 EECS 44B 40 Dr Douglas Niehaus 2009 Challenges of Requirements WF Conclusions Conflicting opinions and agendas among developers Discovering requirements is the least defined aspect can also require negotiation and compromise of SWE because it is so strongly affected by the Flexibility and objectivity are essential qualities for target domain developers eliciting requirements Requires communication with clients and sometimes Approach each interview without preconceptions SUbtle deteCtiVe Work Should not make assumptions about requirements 39 NOtlalWayS the ObViOUS reasons many people Bein objective about your own opinions is an deC39de to StUdy computers I exce ent exercise but is aso very hard But often the most Interestin and along With Every application project is different and aoalys39s and des39gn amongt e mOSt Cre i t39Ve reqUIrements phase must discover all unique aspects 39 SOIVlng neW orOblems 395 mUCh less We defined and Solving the last problem doesn t help meSSIerlthan most class aSSIgnments Real job of SWE so get used to It EECS 44B 41 Dr Douglas Niehaus 2009 EECS 44B 42 Dr Douglas Niehaus 2009
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'