Requirement Elicitation - School of Information Technologies
Contents
1. a Use cases should only occasionally be written for these subfunction goals 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Finding primary actors scenarios and use cases m Choose the system boundary a Is it just a software application the hardware and application as a unit that plus a person using it or an entire organization a Identify the primary actors and goals Define use cases that satisfy user goals name them according to their goals 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Identify primary actors a Questions for identifying actors a Which user groups are supported by the system to perform their work a Which user groups execute the system s main functions a Which user groups perform secondary functions such as maintenance and administration a With what external hardware or software system will the system interact a See textbook for a more detailed list of questions 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Primary actor and system boundary a Primary actor and user goals depend on system boundary Frap Sai TPP ga Pitali lt kkh Tae r tiere 8 POG pawn h d coe Died ov aaa 7 giner Ceaceur N Gal wy rwu2. 6 8 pm Wednesday Aug 11 CO MP5028 O bject Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Express extend relationship in use case text Process Sale Handle gift certificate payment Extension Point VIP customer step 1 f payment step 7 f Trigger Customer wants to pay with gift Main Success Scenario certificate 1 Customer arrives at a POS checkout with Extension point Payment in Process Sale goods and or services to purchase A Level subfunction 7 Customer pays and system handles payments Main Success Scenario 1 Customer gives gift certificate to cashier 2 Cashier enters gift certificate ID Table 3 6 base use case description Table 3 7 extending use case description 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney 23 E xtend vs indude relationships m Direction of the relationship a For include relationship the event triggering the target use case is described in the flow of event of the source use case a For extend relationships the event triggering the source the extending use case is described in the source use case The base use case have no knowledge of the extending use case a The purpose of adding include and extend relationships is to reduce or remove redundancies from the use case model 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 0 2004 Y
3. 2004 Ying ZHOU School of IT University of Sydney Functional Requirements What are functional requirements a Describe the interactions between the system and its environment independent of its implementation a Features capabilities Functional requirements are explored and recorded in use cases model Excerpt from functional requirements of SatWatch SatWatch is a wrist watch that displays the time based on its current location SatWatch uses GPS satellites Global Positioning System to determine its location and internal data structures to convert this location into a time zone When political boundaries change the watch owner may upgrade the software of the watch using the WebifyWatch device provided with the watch and a personal computer connected to the Internet Table 3 1 functional requirements of Sat Watch 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney 14 Non functional requirements a Aspects of the system that are not directly related to the functional behavior of the system a Quality requirements a Usability a The ease with which a user can learn to operate prepare inputs for and interpret outputs of a system or component a Reliability m The ability of a system or component to perform its required functions under stated conditions for a specified period of time a Performance Quantifiable attributes of the syste
4. HR amp F Phil in Systems 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney What s wrong here Informal information gathering Implied functionality Erroneous or un communicated assumptions Inadequately defined requirements A casual change process 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Requirement Requirement a A feature that the system must have or a constraint that it must satisfy to be accepted by the client Two questions need to be answered a How can we identify the purpose of a system a Crucial is the definition of the system boundary What is inside what is outside the system These two questions are answered in the requirements process The requirements process consists of two activities a Requirements Elicitation Definition of the system in terms understood by the customer Problem Description a Requirements Analysis a Technical specification of the system in terms understood by the developer Problem Specification 6 8 pm Wednesday Aug 11 CO MP5028 O bject Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Products of requirements process a Requirement elicitation results in the specification of aho the system that the client understands S x functional Anal
5. a system 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney 14 How do we find scenarios Ask yourself or the client the following questions a What are the primary tasks that the system needs to perform a What data will the actor create store change remove or add in the system a What external changes does the system need to know about a What changes or events will the actor of the system need to be informed about 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Identifying use cases a A use case is a collection of related success and failure scenarios that describe actors using a system to support a goal Sample use case and associated scenarios Handle return Main success scenario Alternate Scenarios If the credit back transaction is rejected If the item identifier is not found in the system Table 3 2 sample use case for a POS system 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney How to specify a use case Name of Use Case Primary actor s a Description of Actors involved in use case Actors represent external entities that interact with the system Actor can be human or an external system Stakeholders and interests List Preconditions a State w
6. digit code that identifies a product Usually Universal Product symbolized with a bar code placed on products Code Table 3 8 data dictionary sample 6 8 pm Wednesday Aug 11 CO MP5028 O bject Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney 25 Identifying nonfunctional requirements Nonfunctional requirements typically includes conflicting requirements Few systematic methods for eliciting nonfunctional requirements In practice analyst use a taxonomy of nonfunctional requirements to generate check lists of questions to help the client and the developer on the nonfunctional aspects of the system Example questions for eliciting nonfunctional requirements see handout 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Documenting Requirement Elicitation The Results of the requirements elicitation and the analysis activities are documented in the Requirement Analysis Document RAD Introduction Current System Proposed system a Overview functional requirements nonfunctional requirements system models Glossary 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and Design 2004 2004 Ying ZHOU School of IT University of Sydney D iscussion questions I m Getting information from interview transcript Please refer to the class handout 6 8 pm Wednesday Aug 11 CO MP5028 Object
7. 4 Ying ZHOU School of IT University of Sydney Fact finding techniques cont a Interviewing a Advantages and disadvantages Allows the analyst to be responsive and adapt to what the user says Can probe in greater depth about the person s work than be achieved with other methods Time consuming and the most costly form of fact gathering Can be subject to bias if the interviewers has a closed mind about the problem Different interviewees might provide conflicting information a Appropriate situations Appropriate in most projects 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Fact finding techniques cont a Observation a Advantages and disadvantages Provide first hand experience of the way that the current system operates Observation can be used to verify information from other sources or to look for exceptions to the standard procedure Baseline data about the performance of the existing system and of users can be collected People may behave differently under observation Required a trained and skilled observer for it to be most effective a Appropriate situations Essential for gathering quantitative data about people s jobs 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Fact finding techniques cont a Document sampling Collect copies of blank an
8. Gaul ere sates Ghoul Proch Joab DOO CAVA e OU 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney 38 19 Types of actors Primary actor a Has user goal fulfilled through using services of the system under discussion a To find user goals and drive the use case a Example cashier a Supporting actor a Provide a service to the system under discussion a To clarify external interfaces and protocols a Example automated payment authorization service a Offstage actor a Has an interest in the behavior of the use case but is not primary or supporting a Ensure all necessary interests are identified a Example government tax agency 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Use case diagram system boundary NextGen _ communication U di i AW e o la relationship among AN N aomp actors and use ma NS Bed Aitrzatin p 2 cases NE AN ae Use case diagram i Process Rental SI racer and use case relationships are aa 1 secondary in use vacan Seen Sales Activity case work Use case sem T A EFE are text documents Race HR System Doing use case work _ means to write text 9 saa oi f aes A A System Saks Ni Administrator N fee We Figure 3 3 use case diagra
9. Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney 27
10. Requirement E licitation CO MP5028 Object Oriented Analysis and Design 2004 Ying ZHOU School of IT University of Sydney Agenda Problem in requirement elicitation Requirement process Types of requirements Fact finding techniques Requirement elicitation process a Use case model a Data dictionary and non functional requirements 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Requirements Elicitation m Mih Hello Phil We re having a problem with the e employee system you programmed for us Cp An employee just changed her name to Sparkle Starlight and we can t get the system Maria in HR to accept the name change Can you help She married some guy named Starlight Phil in Systems 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 0 2004 Ying ZHOU School of IT University of Sydney Requirements Elicitation cont m Mir s No she didn t get married just changed her name That s the problem It looks like we can change a name only if Kp someone s marital status changes Maria in HR Well yeah never thought someone might just change her name don t remember you telling me about this possibility when we talked about the system That s why you can get to the Change Name dialog box only from the Change Marital Status dialog box Phil in Systems 6 8 pm Wednesd
11. ay Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Requirements Elicitation cont TY 6 Maria in HR Phil in Systems 6 8 pm Wednesday Aug 11 0 assumed you knew that people could legally change their name anytime they like We have to straighten this out by Friday or Sparkle won t be able to cash her paycheck Can you fix the bug by then It s not a bug never knew you needed this capability I m busy now can probably fix it by the end of the month Next time tell me these things earlier and please write them down CO MP5028 O bject O riented Analysis and D esign 2004 Ying ZHOU School of IT University of Sydney Requirements Elicitation cont mY ie Maria in HR Phil in Systems 6 8 pm Wednesday Aug 11 2004 What am going to tell Sparkle She s really going to be ticked if she can t cash her check Hey Maria it s not my fault If you d told me in the first place that you had to be able to change someone s name at any time this wouldn t have happened You can t blame me for not reading your mind CO MP5028 O bject Oriented Analysis and Design 2004 Ying ZHOU School of IT University of Sydney Requirements Elicitation cont m Mir s Yeah well this is the kind of thing that A makes me hate computer systems Call me as soon as it s fixed will you Maria in
12. d completed documents during the course of interviews and observation sessions Carry out a statistical analysis of documents in order to find out about patterns of data Advantages and disadvantages Can be used to gather quantitative data Can be used to find out about error rates in paper documents a May not be able to reflect future situation Appropriate situations a First type always appropriate Statistical approach is appropriate in situations where large volumes of data are being processed 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and Design 2004 2004 Ying ZHOU School of IT University of Sydney 12 Fact finding techniques Q uestionnaires Questionnaires a Advantages and disadvantages An economical way of gathering data from a large number of people Result from a well designed questionnaire can be processed by computer Good questionnaires are difficult to construct Not able to follow up or probe more deeply a Appropriate situations Views or knowledge of a large number of people need to be obtained Appropriate for information systems that will be used by the general public 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Use case model a Requirement elicitation is a very challenging activity Requires collaboration of people with different backgrounds a Users with application domain knowledge a Deve
13. hat must always be true before starting a scenario in the use case Postconditions a State what must be true on successful completion of the use case Flow of Events Basic flow and alternative flows a Free form informal natural language Special Requirements a Nonfunctional Requirements Constraints Technology and Data Variations List a Technical variations in how something must be done 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney A sample use case a Preface elements Process Sale Primary Actor Cashier Stakeholders and interests sales person wants sales commissions updated Government tax agencies want to collect tax from every sale Preconditions Cashier is identified and authenticated Postconditions Sale is saved Tax is correctly calculated Accounting and inventory are updated Commissions recorded Table 3 3 sample use case description 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and Design 2004 2004 Ying ZHOU School of IT University of Sydney 16 A sample use case cont Main Success Scenario Basic Flows 1 customer arrives 2 Cashier starts a new sale 3 cashier enters item identifier Extensions Alternative Flows a At any time system fails 1 Cashier restarts system 2 System reconstruct prior state 3a Invalid identifier System signals error and rejects entry 3 6a Customer asks ca
14. ing ZHOU School of IT University of Sydney Heuristics for extend and include relationship Use extend relationships for exceptional optional or seldom occurring behavior Use include relationship for behavior that is shared across two or more use cases Do not over structure the use case model A few longer use case two pages long are easier to understand and review than many short ones eg 10 lines long Always use the include relationship between use cases rather than a mixture of include and extend 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Identifying initial analysis objects How to bridge the terminology gap between developers and users a Identify the participating objects for each use case and collect them into a Glossary data dictionary 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Heuristics for identifying initial analysis objects a Terms that developers or uses must clarify to understand the use case Recurring nouns in the use cases Real world entities that the system must track Real world processes that the system must track Data sources or sinks Always use application domain terms Payment Validation by an external payment authorization authorization service that they will make or guarantee the payment to the seller UPC 12
15. ket needs a Example Interface to an existing game Bumpers 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney D iscussion Question a Specify which of these statements are functional requirements and which are nonfunctional requirements The TicketDistributor must enable a traveler to buy weekly passes The TicketDistributor must be written in Java The TicketDistributor must be easy to use The TicketDistributor must always be available The TicketDistributor must provide a phone number to call when it fails 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and Design 2004 2004 Ying ZHOU School of IT University of Sydney 10 Fact finding techniques Background reading a Company reports organization charts policy manuals job descriptions reports and documentation of existing systems a Advantages and disadvantages Helps the analyst to get an understanding of the organization before meeting the people who work there Allows the analyst to prepare for other types of fact findings May provide formally defined information requirements for the current system Do not match up to reality a Appropriate situation a When the analyst is not familiar with the organization being investigated Useful in the initial stages of investigation 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 200
16. kout period Performance requirement SatWatch should display time correctly in all 24 time zones Performance requirement SatWatch should accept upgrades to its onboard via the Webify Watch serial interface Supportability requirement 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Nonfunctional requirements for SatWatch cont a Constraints for SatWatch a All related software associated with SatWatch including the onboard software will be written using Java to comply with current company policy Implementation requirement a SatWatch complies with the physical electrical and software interface defined by WebifyWatch API 2 0 Interface requirement 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Types of Requirements Elicitation a Greenfield Engineering a Development starts from scratch no prior system exists the requirements are extracted from the end users and the client a Triggered by user needs a Example Develop a game from scratch Asteroids a Re engineering a Re design and or re implementation of an existing system using newer technology a Triggered by technology enabler a Example Reengineering an existing game a Interface Engineering a Provide the services of an existing system in a new environment a Triggered by technology enabler or new mar
17. loper with solution domain knowledge design knowledge implementation knowledge m Bridging the gap between user and developer a Scenarios Example of the use of the system in terms of a series of interactions with between the user and the system a Usecases Abstraction that describes a class of scenarios 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney 13 Identifying scenarios Scenarios a A scenario is a specific sequence of actions and interactions between actors and the system under discussion Scenarios can have many different uses during the software lifecycle a Requirements Elicitation As is scenario visionary scenario a Client Acceptance Test Evaluation scenario a System Deployment Training scenario 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Types of Scenarios As is scenario a Used in describing a current situation Usually used in re engineering projects The user describes the system Visionary scenario a Used to describe a future system Usually used in greenfield engineering and reengineering projects a Can often not be done by the user or developer alone Evaluation scenario a User tasks against which the system is to be evaluated Training scenario a Step by step instructions that guide a novice user through
18. m Response time throughput availability accuracy a Supportability a The ease of change to he system after deployment a Adaptability maintainability 6 8 pm Wednesday Aug 11 CO MP5028 O bject Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Nonfunctional requirements cont Constraints a Implementation requirements The use of specific tools programming languages or hardware platforms Interface requirements Constraints imposed by external systems including legacy systems and interchange formats Operations requirements Constraints on the administration and management of the system in the operational setting Packaging requirements Constraints on the actual delivery of the system Legal requirements Concerned with licensing regulation and certification issues 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Nonfunctional requirements for SatWatch Quality requirements for SatWatch a Any user who knows how to read a digital watch and understands international time zone abbreviations should be able to use Sat Watch without the user manual Usability requirement As the SatWatch has no buttons no software faults req quang the resetting of the watch should occur Reliability requirement SatWatch should display the correct time zone within 5 minutes of the end of a GPS blac
19. m for a POS system 6 8 pm Wednesday Aug 11 CO MP5028 O bject Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney 20 Relating use cases Important types of use case relationships Include Extends a Include a A use case uses another use case functional decomposition Extend a A use case extends another use case 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney lt lt Include gt gt functional decomposition Problem a A function in the original problem statement is too complex to be solvable immediately Solution a Describe the function as the aggregation of a set of simpler functions The associated use case is decomposed into smaller use cases Figure 3 4 include relationship for functional decomposition 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney 21 lt lt include gt gt reuse of common functionality Problem a Some partial behavior is jose common across several Process Sale use cases N cincludes Solution Q to S a The include association AC n IC aane C aet A from a use case A to a S o Aa 7 __ Payment N Payment A Payment k customer A includer S Z ipdudes use case B indicates that poa o NY Serve an instance of the use te se Comi case A perfor
20. ms all the u se behavior described in the Cekin use case B a EE a EE ATN n E Figure 3 5 lt lt include gt gt relationship for reuse common functionality 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and Design 2004 2004 Ying ZHOU School of IT University of Sydney Express include relationship in use case text Handle Credit payment Process Sale Main Success Scenario Level subfunction 1 Customer arrives Main Success Scenario 1 Customer enters their credit account information 2 System sends payment authorization request _ OIO to an external payment authorization Extensions service system and request payment 7b Paying by credit include handle credit approval payment 3 7c Paying by check include handle check Extensions payment 7 Customer pays and system handles payment 2a System detects failure to collaborate with external system Table 3 4 base use case description Table 3 5 include use case description 6 8 pm Wednesday Aug 11 CO MP5028 O bject Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney lt lt extend gt gt existing use cases Problem a The functionality in the original problem statement needs to be on extended _ extmrion rin Solution Paes ee a An extend association i from a use case A to a use case B indicates that use case B is an extension of use case A Figure 3 6 Extend relationship
21. shier to remove an item from the purchase 1 Cashier enters item identifier for removal from sale 2 System display updated running total Special requirements Credit authorization response within 30 seconds 90 of the time Touch screen UI on a large flat panel monitor Technology and Data Variations List 3 item identifier entered by bar code laser scanner 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Goals and scope of a use case a What is a valid use case a The EBP use case guideline a For requirement analysis for a computer application focus on use cases at the level of elementary business processes EBPs EBP a A task performed by one person in one place at one time in response to a business event which adds measurable business value and leaves the data in a consistent state E g Approve credit or Price order a Acommon use case mistake is defining many use cases at too low a level that is as a single step subfunction or subtask within an EBP 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Use cases and goal a An EBP level use case is called a user goal level use case a Find the user goal a Define a use case for each Subfunction goals and use cases a Sub goals that support a user goal eg identify myself and be validated
22. ysis results in an Z a pen analysis model that the developers can interpret Figure 3 1 Products of requirement process 6 8 pm Wednesday Aug 11 CO MP5028 O bject Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney System Specification vs Analysis Model m Both models focus on the requirements from the user s view of the system a System specification uses natural language derived from the problem statement a The analysis model uses formal or semi formal notation for example a graphical language like UML a The starting point is the problem statement 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Activities in requirement elicitation Identifying actors Identifying scenarios Identifying user cases Refining use cases Identifying relationships among user cases Use case diagram a Identifying non functional requirements 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004 2004 Ying ZHOU School of IT University of Sydney Types of Requirements m FURPS a Functional requirements a Nonfunctional requirements a Usability Reliability Performance Supportability ancillary and sub factors constraints or pseudo requirements Implementation Interface Operations Packaging Legal 6 8 pm Wednesday Aug 11 CO MP5028 Object Oriented Analysis and D esign 2004
Download Pdf Manuals
Related Search