''Extracted from LimitsOfUserStories''

UserStories are great. 

When using them I find that I have been saying to myself "You have been using this style to describe the functionaliy of a system for years, what makes this any different?" I can answer by saying "Before it was on scrap paper and emails to others, this is more directed". A measured step to add a little bit of formalism without sacrificing the usability of the process goes a long way. 

The trouble I am in now is that I am trying to use the same style to describe EVERYTHING I am doing. This is the intense desire to have 'one mechanism'. But what I end up with is a bunch of stories that describe everything lumped into the one category.

I have had some success in placing stories into categories. Uncomplicated enough to get pass the quagmire of 'everything'. 

Why do I have the desire to write a UnitTest for this? 

Here are my categories:
 1. Business/Feature       "Display the account history for the client"
 2. Techincal/Architecture "The current (whatever ex:AccountService) needs data from the old (whatever ex:Mainframe)
 3. Technical/Science      "The data is persisted in some proprietary data structure, the service needs it in XML"
 4. Technical/Engineering  "The system must have a minimum response time of 3 seconds"
 5. Technical/Construction "The system should be written in Python"
 6. Business/Admin         "This joker needs to pay me for (whatever)"

----
Categories could run along the lines of traditional requirements engineering:
 

Functional Requirement == "When cancel is clicked the action should be stopped!"
 
Non-Functional Requirement == "It would be great if it was written in Python and utilized our RDBMS licence"
 
Process Constraint == "Task A must be completed within 30 seconds"
 
Just some thoughts, Richard Quinn