This question already has answers here:
include or extend in UML?
(2 answers)
Closed 11 months ago.
I have this diagram. The staff receives an email when his letter is approved. Do I need add an include relationship between two use cases? If I did that, it means the staff needs to approve letter to receive an email. It's different from the description.
Definitely not. The simple reason is, that Receive Email is no use case. It is a pure function, likely used in some yet unknown use case. A use case brings added value to its actor. And receiving an email has no added value (like the dreaded Login).
It's hard to judge whether Approve Letter is a valid use case. It seems like a bit trivial. Probably if it's a certain letter in a certain process. As such, I would not let it go through as use case.
As always I recommend to read Bittner/Spence about use case modeling.
Related
We had a developer to come up with a prototype for a bot for bookkeeping questions and we understand that the bot is not perfect. Our biggest challenge was to ensure that after 2-3 failed attempts for the bot to receive an appropriate response, the bot moves on to the next question and that's it. Our previous developer claimed that it's not possible, is that true or not? Currently the bot just gives up after a couple of attempt and that's it.
I am not a tech person and I would really appreciate some help on this.
Hypothetical example of the ideal scenario:
Q: What accounting software do you use?
A: askdnjsajld
Q: Didn't get that. What accounting software do you use?
A: asdkjnajksdn
Q: I am sorry, didn't get that. Let's move on to the next question... When would you like to receive your financials?
A: month-end
Thank you for your help!
Yes, this is possible, although the exact details of how you do this depend on how you're handling responses from the user in the first place.
The most important thing to keep in mind to handle this, however, is to remember that Intents represent what the user says and not how you handle it or how you reply.
That last bit gives the simplest answer to your question - you can, of course, reply however you want the bot to reply after each round. It sounds like you were able to implement logic that says if it got a result it didn't want - you can extend that to add a counter that just uses the next question as its reply after a number of tries.
The more difficult part is to make sure that you know what question the user is replying to, and to make sure you capture the right value in case they try to go back and answer a previous question.
The general solution to this problem is twofold:
Have one Intent that accepts the direct answer to the question you're currently on, but have it triggerable only with certain Input Contexts being set. Then set that Context to be valid when you ask the question, and remove the Context when the question is answered.
Have other Intents that specifically respond to how the user might phrase the question if they were going back to answer it.
For example, if you have asked "What software do you use?" you might set the Context "ask-software-used". You would then have two Intents:
One with an Input Context of "ask-software-used" that accepts just valid software names.
Another with no Input Context, but which might have training phrases such as
"I'm using XXXX software"
"We are working with the XXXX package"
once the user does answer the question, clear the "ask-software-used" Context, ask the next question, and set its Context.
You can also use this to keep track of how many times you've had to repeat the question, waiting for an answer. If that counter hits the limit, do the same thing: clear the Context, ask the next question, and set its Context.
I want to ask the users a few questions in my welcome intent and depending on their answers give them a particular output.
My problem is that, once the user answers the first question, the agent exits my welcome intent and tries to match with the next intent.
I thought I could solve this by matching it back to the welcome intent.
So ideally it should have gone like this :
Welcome intent -> 1st question -> user answer -> Welcome intent ->2nd question -> and so on
But actually this happens :
Welcome intent -> 1st question -> user answer ->Welcome intent -> 1st question
It will keep asking the first question.
To solve this , I started maintaining a flag for each question.
If question 1 was answered I would set its flag true and then use it to skip the first question when the welcome intent is matched for the second time.
This is a very convoluted way to do it and probably far from the best way to do it.
Can anyone point me in the right direction to implement it?
Thank you.
Edit : I have given up my old method. Let me explain what I want to do and then I can get guidance on the way I should implement it.
I have 16 different outputs and I would like to show one of them to the user depending on their answer to 4 questions. Each question will only have two answers as options and depending on the option chosen by the user for each question , I will pick one of the 16 outputs and display it to the user.
How do I accomplish this using diaglogflow node.js?
First of all remember that an Intent captures what the user says or does and not what you do with that information or how you reply to it. That part is best handled by your fulfillment. While we can use Contexts to limit which Intents will be considered for a user response they are probably most useful in this case to store your state and keep track of which questions have been asked and answered.
Under this scheme, your Intents remain responsible for capturing input and your fulfillment examines this input, changes state based on this input, and sends a reply based on the new state (what it needs to ask next). If the user's responses will be mostly the same (free form, or from the same set of phrases), you can even use the same Intent to capture this input and the fulfillment would use the state and input to determine what logic to execute. If you need different types of input, and thus different Intents, their handlers can still call common functions to do the processing and change the state/reply.
This is further discussed in Thinking for Code: Design conversations not logic
You can use the concept of the follow-up intents in Dialogflow Console to create a chain of questions/answers.
Here is an example of my chain of questions/answers:
Though I still strongly advise you to study also how input/output context works. Especially if you want to collect all user reply parameters in the one final fulfillment of the last step to avoid storing the user inputs in fulfillments attached to every intent of the chain.
I am trying to jump to a random question with followup event, and at the same time store the question number in the context. But dialogflow only jumps to the event without storing the question number. Is there a way to do followup event and store a context in one intent?
app.intent('Quiz - random', (conv) => {
let rand = Math.floor(Math.random() * quiz_len) + 1;
conv.data.current_qns = rand;
conv.followup(`quiz-question${rand}`);
});
Not really. The point of using conv.followup() is to make it as if the new Intent is the one that was actually triggered by the user. Remember - Intents represent what the user is saying not what you're replying with. You can include a parameter with the redirect, which I guess you can use to send the question, but this still would be the equivalent of a parameter sent by the user.
It isn't entirely clear why you feel you need to direct to a different Intent. Is it just to ask the question as part of the reply? Go ahead and ask it in the Intent handler you're in and store the number in the context directly.
Update
You've indicated in the comments that you want to structure things so you have a "random dispatcher" that then redirects to an Intent to ask a question, and that Intent has a Followup Intent that accepts the right answer (and possibly ones that deal with wrong answers).
This requires you to build a lot of extra Intents for all the various questions, and then the conditions on each question. This requires you to re-build this structure every time you want to add a new question.
Dialogflow works very well to navigate the structure of a conversation - so you don't need to use it to navigate specific questions, answers, and responses. Remember - Intents model what a user says in broad terms, not how our agent responds.
Here is a structure that might work better:
There is an Intent that handles the user asking for a random question. The Intent fulfillment for this (ie - the handler function in your webhook) does the following:
Selects a question
Sets a context to indicate which question is being asked
Sends the context and the question to the user
There is another Intent that handles user responses. All user responses. If this is a multiple choice question, you can set very specific phrases, but otherwise you may need to make this a Fallback Intent that has the context specified above as an Input Context.
Your handler for this compares the answer.
If correct, you clear the context, say so, and ask if they want another question. (Which would then loop to the Intent specified in step 1.)
If incorrect, you make sure the context is still valid and tell them they're wrong. Possibly increase a counter so you don't let them guess indefinitely.
This means you're only building two Intents that handle the question itself. You should add a few more. Here are a few to think about:
What happens if the user doesn't say anything at all? The "No Input" scenario should be handled differently than a bad answer.
If you're asking a multiple choice question, perhaps you'll use a list and need to handle a list response.
Finally, if you're using a list, you may want to do something fancy and use Dialogflow's API to set a Session Entity Type for just that question. This allows you to set what you're expecting (with some aliases) for what is correct and incorrect, and then use a Fallback Intent for the context to say that what the user said didn't make sense.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What's a good way to capture user stories when you have features that are common across multiple UI modes?
For example, imagine a commercial flight information system, something someone might use to answer the question "When is flight UA211 expected to land?"
As is often the case, the feature of providing schedule information is common underlying functionality, even though you might ask for it via a desktop web browser, a mobile browser (where you want to apply different style to make it more usable), and maybe even via SMS shortcodes.
Now, that certainly could be a single user story ("As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time"). But that seems wrong (and would probably be an epic story, anyway).
You can make it separate user stories ("As a desktop user...", "As a smartphone user...", etc), which I've done in the past, and the team just knows to estimate the first one to include all of functionality, and the subsequent ones to estimate only UI implementation.
A third option is to make the underlying functionality a story isolated from the presentation layer, and then have UI stories: "As a flight info system front end, I want to get flight status information so that I can present it to the user", "As a desktop user, I want to see flight arrival... etc". But that seems artificial.
Thoughts?
dwh
I think the problem is that you are trying to tie the UI functionality to the backend too tightly.
For example, if you break it into a simple story:
A user may want to know the flight status given the flight number.
OK, now, given that you implement that, now you can look at which platforms will be calling this, as, one part of agile is not to over-develop, but in this case, if you have a business need to support mobile and desktop devices, then you should look at implementing this as a REST service, since that is the simplest solution for both to work with.
So the REST service solves the first story above.
Now, you will find that there are other specifics for each platform. For example, is there something on the phone that may already have the information, for example, did the traveller go to a trip site and already enter his info, then you may want to go there, assuming that the traveller is in the users contacts.
Or, if the user is just going to enter a flight number and that is it, then why not just do it as a webpage, as that is the simplest approach that supports both concepts. Then, if you have a url that supports GET, and outputs as HTML then you can easily display.
So, my first story was too simple, you may want to consider whether it is possible to return different types of data, so a user may want to have HTML, PDF, json or xml, but for each of these there should be a business need.
Unfortunately it is hard to answer your question as there are too many unknowns, which is why you are having a difficult time. If you ask the wrong question then you do have an epic, but if you can just break it down to a few simple stories then it becomes much easier to solve.
I would recommend the second option.
As you suggested, the first sounds like too much for a single story, and a story should always fit into a single iteration.
With the third option, the big problem is that you aren't delivering business value at the end of the story, which is generally a bad practice.
There are other ways you could split this work though. You could initially develop a very cut-down, barebones version which would work across all clients, and then refine each of them in subsequent stories.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am new to writing use cases.I heard that Use cases are non-technical expressions .
I have the following task for which i have to write Use case.
(I reduced the requirement for your understanding)
Registered Customer of ABC company logged in to the system with credentials to retrieve
the complete Address of particular service provider.He searches the service provider on TextBox.The System communcates with database and displays the result on monitor.
I am technical guy,
I have to write use case to explain the behavior of the system to the client.
I have written Use case as follows :
Use case Name: Address Locating System
Primary Actor: Customer
Stakeholder: ABC Company
Precondition: Customer Successfully Logged in to the system
Success Scenarios:
Customer Enter the search term in the box provided.
System searches the search terms for matches.
System Supplies the address to the Customer.
Extension Point: Client is informed when no successful match
Post condition: None
Questions.
Is the Use Case described above, correct?
Do really tech people need to write Use cases?
Whenever I need to write a Use Case, I pick up my copy of UML Distilled and use its suggested format. There are variations in the formats, so this isn't the only way. In any case it's a good reference to have on your desk. You might also check out Writing Effective Use Cases; I haven't read that one, though.
If you'd like a free example, see:
http://ontolog.cim3.net/cgi-bin/wiki.pl?UseCasesMartinFowlerSimpleTextExample
I might avoid the "in the box provided" bit - that's an implementation detail that might change. I might also change 2 to just "System searches for matches."
And yes, technical people do need to write Use Cases readable by non-technical domain experts.
I would say that this is your use case:
Registered Customer of ABC company
logged in to the system with
credentials to retrieve the complete
Address of particular service
provider.He searches the service
provider on TextBox.The System
communcates with database and displays
the result on monitor.
There is no need to do all the formatting, special headings, numbering etc. Give it a title and you are done. For presentation to a client,
I'd use use case diagrams, and not show even this amount of detail unless asked.