![]() Consider events triggered inside the system. Let's take a recruitment system and identify the events that can happen outside it.Īn Applicant (external) could trigger the following events:įor the applicant to carry out the above tasks, the system must have the following functionalities (use cases):Ģ. Think of the system as a black box - what events would it be required to respond to? This step allows you to examine the scope of the system without considering its internal workings. Use cases are thus, a combination of existing system functions and newly requested functions.ġ. ![]() The analyst would typically list all the stakeholders who are likely to interact with the system, think through their roles and identify what they would need to get their work done.īy analyzing existing systems and asking users how they would like to use the new system, the analyst can come up with an array of use cases. This is a rather obvious approach that involves talking to users and getting them to discuss their goals for the new system. ![]() Beyond the coffee-break test, there are 3 recommended techniques for identifying use cases. That is, once the user has completed a use case, s/he can take a coffee-break without feeling guilty. How can the analyst ensure that all the use cases (system functionalities) are captured? An interesting approach by Alistair Cockburn suggests that analysts identify use cases with the “coffee-break test”. A use case can be defined as an activity performed by the system in response to an event.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |