Related
I am trying to find an easier CAPTCHA to use with my website. I currently have reCAPTCHA but the users are struggling to get the words right the first time.
I have came across Confident CAPTCHA (here) and would like to know what you guys think about it.
Has anyone used it before?
How safe is it?
Are there similar CAPTCHA's, excluding reCAPTCHA?
Interesting captcha, I have not seen this one before.
I will try to address your second question about How safe is it?. There are no docs available or sample code to check so the analysis is based on using it a few times.
It seems like it should be reasonably secure. I see that it uses a 3rd party service, so you will rely on API calls to generate the HTML markup and validate the captcha.
In their demo, you are required to choose 4 images out of a total of 9 which means the probability of guessing the correct value is about 0.000330688% (1/9 * 1/8 * 1/7 * 1/6).
It essentially works by creating an alpha captcha code based on the sequence of images you choose. So the server generates a random challenge (cat, vehicle, drink, house) and associates each element with a random letter from the range [A-Z].
Clicking the sequence of images creates a captcha code based on the letter assigned to each image (e.g. PKIR) if cat = P, vehicle = K, drink = I, house = R that gets placed in a hidden input and submitted with the form.
Therefore the only way to pass the captcha is to come up with a code that agrees with the sequence of images on the server side.
I would conclude it is relatively secure in that there is no way to defeat the captcha solely on the client side (see this question for example). Since there is no reason for them to ever present anything related to the solution to the client (browser); it would seem logical that the only way to get the correct captcha code is to select the correct images in the correct sequence.
Conclusion:
At first glance, the captcha seems secure (no easy bypasses).
This specific captcha may be more difficult to farm out to human solvers (a positive)
Depending on the number of objects and images in the database, it may be possible to generate a database of words to images.
One potential downfall to the captcha is that certain words may require a moderate level of understanding the English language; non-English speaking users may be completely cut off or at least have to put in additional effort to translate words to their native language.
You may want to do a usability check of this captcha on mobile devices (just a thought).
That's my 2 cents, I hope that helps you out.
I'm using it with ads and well, this is very secure.
About english language, the api support many languages and adapt the questions based on the browser language.
I have used GoogleTranslation to help people who have spoken language out of the ConfidentCaptcha reach.
No problem so far. They are very responsive, a very good support.
About mobile, if you don't use ads, you have a special mobile mode, which make it very easy and adapted to the tiny devices.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So if a user story is a something nebulous like:
As a sales rep, I would like to capture the contact information so that I can follow up later on.
I'm not even sure if that's a valid user story but I'm sure it's close enough.
Then there are details/tasks for implementing that user story.
And I'm sure "The sales rep should be able to tab from one textbox to another." is one of the requirements. How do we capture/track this? Is this part of the user story or is it something that's to be considered separately?
A user story captures the essence of a feature, not the details, a story is a support for the discussion.
So, to answer your question, details are transmitted orally during a discussion, because face to face discussion is the most effective communication media. If you feel the need, details can be captured as notes on the back of the card (if you are using cards) or... in a "notes" field if you are using an electronic tool. Actually, I usually use a "how to demo" field too to capture a high-level description of how this story will be demonstrated at the sprint demo and use very brief "notes" for any other info, clarifications, references to other sources of info, etc (credits to Henrik Kniberg's famous Index card generator). If find this very handy, especially when using executable specifications.
PS: your story is perfectly valid and its a good practice to include the benefits in your template ("As a role, I want action so that benefits").
User stories should be short statements in 1 to 3 sentences.
http://en.wikipedia.org/wiki/User_story
I want to be able to tab from one textbox to another is another user story.
You can track these things in a tool like www.rallydev.com, or just any type of task tracking tool (SharePoint, Excel even ... etc.).
Next thing you do is prioritize.
Just taking a rough stab...
As a sales rep,
I want all data entry and navigation to be accomplished using the keyboard
so that I don't have to take my hands off the keyboard
(and so that we comply with accessibility guidelines).
Or
As a business,
We want all our products to be fully usable using only keyboard input
So that we can sell to customers who require accessible software.
The first part belongs to a "business requirements" document (usually written by a business analyst). The first generations of this document are quite high level, but the final versions (several iterations later) are pretty detailed.
http://www.tdan.com/view-articles/6089
The second part (about tabbing) is part of another document - "UX spec" (shows all screens and describes user interaction). This one is usually written by a different person/team (Product or UX team).
http://uxdesign.com/ux-defined-2
http://www.uxmatters.com/mt/archives/2007/05/sharing-ownership-of-ux.php
Yes, that is problem we also have a lot. On the one hand, user stories need to be conscise, on the other hand all the nitty gritty details must be put somewhere.
We use XPlanner, and we solve this by putting the short description into the text body of the user story. Then we use XPlanners "notes" feature (arbitrary text or files that can be attached to a user story) for the details.
That way we can add as much information as necessary to a user story, without cluttering up the user story text itself. You can also refer to external documentation, if you don't want to have everything in XPlanner.
This approach works quite well for us.
Agree with others, that this is viable story, but capture the (derived) requirements may be better captured elsewhere.
Software Developers and Business types are familiar with different terminology some what may simple to understand by one (data structures) may mean nothing to another. The User Stories is a tool or a means by which business user can convey a message as a starting point which is expanded on (with tests, details, etc).
Oral Communication can be effective, but the effectiveness is dependent on the receivers ability to hear and comprehend the meaning of the message. This is where oral communication can fail. Different types of communication offerring more or less formal forms of communication. Vocal communication is an "informal form of communication" which risks the message being misheard, misinterpretted, and misunderstanding. Just like the game played as a child, where one child whispers a message to another child, who tells another, until all have heard it...When the last child tells the message to the group it usually has been misinterpreted then misinterpretted again, causing a degraded message.
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 1 year ago.
Improve this question
Code can be perfect, and also perfectly useless at the same time. Getting requirements right is as important as making sure that requirements are implemented correctly.
How do you verify that users' requirements are addressed in the code you're working on?
You show it to the users as early and as often as possible.
Chances are that what they've asked for isn't actually what they want - and the best way of discovering that is to show them what you've got, even before it's finished.
EDIT: And yes, this is also an approach to answering questions on StackOverflow :)
You write tests that assert that the behavior the user requires exists. And, as was mentioned in another answer, you get feedback from the users early and often.
even if you talk with the user, and get everything right, the user might have gotten it wrong. They won't know until they use the software that they didn't want what they asked for. the surest way is to do some sore of prototype that allows the user to "try it out" before you write the code. you could try something like paper prototyping
If possible, get your users to write your acceptance tests. This will help them think through what it means for the application to work correctly. Break the development down into small increments that build on each other. Expose these to the customer early (and often), getting them to use it, as others have said, but also have them run their acceptance tests. These should also be developed in tandem with the code under test. Passing the test won't mean that you have completely fulfilled the requirements (the tests themselves may be lacking), but it will give you and the customer some confidence that you are on the right track.
This is just one example of where heavy customer interaction pays off when developing code. The way to get the most assurance that you are developing the right code is having the customer participating in the development effort.
How do you verify that users' requirements are addressed in the code you're working on?
For a question put in this form the answer is "You can't".
The best way is to work with users from the very first days, show them prototypes and incorporate their feedback continuously.
Even so, at the end of the road, there will likely be nothing resembling what was originally discussed and agreed on.
Ask them what they want you to build before you build it.
Write that down and show them the list of requirements you have written down.
Get them to sign off on the functional design.
Build a mock up and confirm that it does what they want it to.
Show them the features as it is being implemented to confirm that they are correct.
Show them the application when it's finished and allow them to go through acceptance testing.
They still wont be happy but you will have done everything you can.
Any features that are not in the document they signed off can be considdered change requests which you can charge them extra. Get them to sign off everything you show them, to limit your liability
by using development method that often controls alignement between the implementation and the requirements.
For me, the best way is to involve a "expert customer" to validate and test in a interative way as often as possible the implementation ....
If you don't, you risk to have, as you said, a very beautiful soft perfectly useless....
you can try personas; a cohort of example users that use the system.
quantify their needs, wants, and make up scenarios of what is important to them; and what they need to get done with the software.
most importantly- make sure that the users (the persona's) goals are met.
here's a post I wrote that explains it in more detail.
You write unit tests that expect an answer that supports the requirements. If the requirement is to sum a set of numbers, you write
testSumInvoice()
{
// create invoice of 3 lines of $1, $2, $3 respectively
Invoice myInvoice = new Invoice().addLine(1).addLine(2).addLine(3);
assertTrue(myInvoice.getSum(), 6);
}
If the unit test failed, either your code is wrong or possible was changed due to some other requirement. Now you know that there is a conflict between the two cases that needs to be resolved. It could be as simple as updating the test code or as complex as going back to the customer with a newly discovered edge case that isn't covered by the requirements.
The beauty of writing unit tests is it forces you to understand what the program should do such that if you have trouble writing the unit test, you should revisit your requirements.
I don't really agree that code can be perfect...but that's outside of the real question. You need to find out from the users prior to any design or coding is done what they want - ask them 'what does success look like', 'what do you expect when the system is complete', 'how do you expect to use it'...and video tape the response, mindmap it, or wireframe it and than give review it with them to ensure you captured the most important aspects. You can than use those items to verify the iterative deliveries...expect the users to change their mind/needs over time and once they have 'it in their hand' (IKIWISI - I Know It When I See It)...and record any change requests in the same fashion.
AlbertoPL is right: "Most of the time even the users don't know what they want!"
And if they know, they have a solution in mind and specify aspects of that solution instead of just telling the problem.
And if they tell you a problem, they may have other problems without being aware that these are related by having a common cause or a common solution.
Thus, before you implement mockups and prototypes, go and watch the use of what the customer already has or what the staff is still doing by hand.
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
I am from an XP background. I know the process very well and have solid working experience with it. I have found it to be the best way to develop software.
I find myself in the position of a process doctor of sorts and this creates much self examination and revaluation of my own understandings.
A very common thing I hear is that some work can’t be made into stories. I personally don’t believe this. The excuses include
Its too big (The developer will have nothing to show until the end of 5 weeks).
it’s a complicated algorithm or abstract concept (will take 5 weeks to write and nothing to show).
This question is to get hints, tips or suggestions.
I am looking for hints, tips, and suggestions as to how to address these and similar perceived problems (and more if you can think of them).
I will mark the answer that has the most information on how to get around users/developers who wont write stories and address their many excuses as to why not (I have only listed a few and there are many more).
Here are a few resources that I've collected over time and that might help:
Patterns for Splitting User Stories
Story Weight Reduction Toolkit
Twenty Ways to Split Stories
Ways to split user stories
Too big or too complicated, there is always a way to put a story on diet (maybe you won't obtain the final result in one iteration but this doesn't mean you can't and, well, there will be more than one iteration).
So basically, your question is "What can I do if people claim a task is too big for a user story, and can't be split up.
In my experience, almost any problem can be split up. Ask them if they can implement a simplified version, leave out advanced features, maybe even use default values in some places; basically anything to produce something that gives meaningful (i.e. testable) results within one iteration.
Remember: The point of an iteration is not to deliver complete functionality, but just useful and testable functionality.
This splitting can be difficult, but it forces you to consider what you really need first, which is very valuable. The developers may bitch about it (I often do myself :-)), but it's really necessary. Breaking down big tasks into manageable user stories is at the very heart of all agile methods.
That said, if the task really, really, really cannot be broken down (think complex mathematical algorithm in a research setting, that takes weeks to even understand the basics of), then your iteration is too short. The iteration needs to be long enough to produce meaningful results. And if most of your problems are so hard that they take 2-3 months to get anything done, then that's your iteration length. But I've never seen a project where that was really the case...
Usually when you get "it's too big", what they are really saying is "I only have a vague idea how this should work". You need to work with them to better define it until it becomes possible to split it into logical parts that can be more easily managed.
users/developers who wont write stories
Users aren't supposed to write user stories. They aren't supposed to tell you user stories. You can expect them to talk about how they work, the problems that bother them and what they would like to have to facilitate their everyday work.
You, in your turn, is supposed to listen to them and take notes. If they allow, use a tape recorder or a camera. Then you bring the collected information back when you replay it and identify what you call user stories. You discuss them with the team and when you have agreement you have use cases to target in your development.
What role developers play, is up to you. If they just coders, they don't take part in the process.
If they in part act as consultants, then they help define user stories.
The "algorithmic specification" problem is common.
Many people prefer to write code and don't really care who the user is or what they do.
I try to get them to focus by asking these questions.
What action can the person take? What could they possibly do with the information? If they have some responsibility, they can take action to deny, approve, hold, reject, reprocess, stop, start, something. If the user can't take any action, you need to ask if they're really stake-holders.
What decision do they have to make? How do the decide which action (if any) to take? We can't automate that decision -- that's why people are in the loop.
What information does this person need to make the decision to take action.
Information-Decision-Action.
We only write software to prepare information for people to make decisions so they can take action.
If that's not the focus, then the stories get out of control.
Its basically the duty and responsibility of the product owner. And there can be any requirements/task that cannot be split into User Stories. I found many such discussions on SCrum Master Forums
If development team claims that the story is too big and can not fit within the sprint.. take their feedback and try to split the story with must have and nice to have tasks and try to split it based on that.
check this flowchart.. can be a help: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf
Are use cases just multiple user stories??
What are the benefits of using user stories over use cases.. and vice-versa... When to use one over other...
Does all agile methodologies uses user stories??
Actually, the original use cases (see Jacobson's OOSE) were pretty lightweight, much as user stories are now. Over time, they evolved until a common format for "use cases" now is a complicated document with inputs, outputs, inheritance, uses relationships, pseudocode, etc. Programmers, in general, try to convert everything into programming.
In any case, the attempt to defined what distinguishes a "use case" from a "user story" fro a "scenario" is pretty futile, as it's hard to find two authorities who agree.\
Personally, I find the pattern "[Actor] [verbs] [noun] to get [business value]" helpful. If it gets over about a paragraph of text, it may be too big.
When it comes down to it "agile" is just a label, and people disagree over exactly what it means. Similarly people call very different things "use cases."
In my experience the primary difference between the two is that a user story is focused on the user, and is usually shorter and less formal - ideally, it should easily fit on a postcard. It probably doesn't give details of error handling etc.
Use cases can be much more formal (although some people write them informally too) - they focus on every interaction with the system, and may well go into more detail about several different systems/actors/etc within the same use case.
That's just my experience though - chances are everyone will have used these tools in different ways. I wouldn't get too hung up about labels - just use what works for your project.
Use cases aren't compilations of user stories.
User stories are generally much simpler than use cases. I think use cases try to cover absolutely everything to do with the behaviour of some aspect of the system. That is, all behaviours, all error paths and all exception handling.
The recommended template for a user is:
As a (role) I want (something) so that (benefit)
(Thanks Mike Cohn for providing this simple template)
Descriptions of behaviour expressed like this are more agile.
This sort of template lets you describe behaviour using different levels of detail. For example:
for those stories being implemented in a much later sprint, you can describe behaviour in a high level sort of way, e.g. as an ops team member I want to monitor the system remotely so that I can determine system health while on the road.
for those stories being implemented in the next sprint, you can describe behaviour is a slightly more detailed way, e.g. as an ops team member I want to have a dedicated ops only login so that I can check system health.
for those stories being implemented in the current sprint, you can describe behaviour in a highly detailed way, e.g. as an ops team member I want to have a web interface so that I can check current status of the ingest ftp server.
IMHO Use cases are much more carved in stone! And hence can be a problem to update after the initial version.
HTH
cheers,
Rob
In one word, no.
Use Cases are typically detailed specifications laying out how some particular piece of functionality is going to work, or how a specific user is going to utilize the system. It typically is in the voice of a specific user (or Actor) and is fairly self-contained.
A user story on the other hand is "an invitation for discussion". It is typically one or two sentences. Here is one good resource for that. And Mike Cohn's User Stories Applied is well worth it.
The typical syntax is "As a <user> I need <functionality> to achieve <business value>", or "To achieve <business value> as a <user> I need <functionality>" which drives home the value of the story.
User stories are not meant to be stand-alone, but meant to invite discussion of the story between the developer and the customer (or customer proxy).
You can think of a usecase as a user story, but not the other way around. A usecase will cover multiple "endings" to the story, special requirements (e.g. form fields must be entered in format xyz, and show error message 123 if the user enters a field in the wrong format). Also, a usecase can include additional references to external documents, such as security guidelines.
User Stories is a tool used in Agile development to make sure you create the product your user really needs.
It describes rather why you should make this or that feature instead of HOW or WHAT feature.
From my personal experience, it's a great way to balance the client's and developer's vision to create a better product.
Unlike US aUse Case focuses on WHO uses your product. Here is the difference.
I'd say there is no other such instrument for an Agile developer as User Stories. If you want to learn how to write them successfully, check out this post.