Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My understanding is that the first step of defining user stories is to define roles. The problem with role-based systems is that this form of authorization is often too coarse-grained. Hence, people created task-based authorization where roles are still used to lump tasks into groups (see for example rhino security . At least that's my understanding.

How do I write user stories for task based authorization? Any feedback would be very much appreciated. Many thanks!

share|improve this question
up vote 3 down vote accepted

I'm not sure, but I think you may be confusing story roles with authorization roles. The user story should not tell you how to implement something. The following user story is an example of user voice form using a role:

As a manager, I need to be able to add a new Foo Report to my Bar so that I can analyze all Foos and look for issues.

In my experience, the intention here is not to prescribe how to implement authorization, but instead to provide the developer with an idea of the type of person that is using this feature. You may also use a persona, such as "Bob", instead of the role to capture demographics and information about the type of user using the Foo Report. This gives you the context in how the feature will be used.

This should not mean that an authorization role of "Manager" should be created. You can implement your security however you like, so long as a user that is like "Bob the manager" can be given access to report on the Foos in their Bar.

Since my teams work with a lot of security roles on their projects, we use personas instead to avoid the possibility of confusion within the team.

(BTW: My apologies if this is not what you meant, perhaps you are using user roles in a way that I am not familiar with)

share|improve this answer
Thanks. Very much appreciated. Yeah, they mention personas in 'User stories applied'. I still think manager = admin = highest authorization ... – csetzkorn May 29 '13 at 13:34
Perhaps you are right. But manager might only have highest authorization within a specific department, or perhaps they have specific users over which they have highest authorization. When you go to implement the story, you'll take the acceptance criteria and then define your security model to allow users like that to have the correct access. If task-based security lets you do that, go for it! – Jay S May 29 '13 at 13:39
I should add, if you are trying to write the user story, you should define it without the security implementation details. Write acceptance criteria that define in what way the user is restricted (or not restricted) and let the development team figure out how to make the system meet that criteria. Your testers should then write test cases based on the acceptance criteria to ensure that the implementation meets the needs. – Jay S May 29 '13 at 13:43
I am now writing my user stories very generic: User can X and Y I then add constraints: This only applies if the user has the task/activity Z. – csetzkorn May 29 '13 at 14:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.