Priority for use cases

[jps]

The documentation states: ‘The priority of this element as compared to other project elements. Only applies to Requirement, Change and Issue types, otherwise ignored. Valid values are: "Low","Medium" and "High"’

It would be highly valuable to us, and I'm sure to the majority of your user community, to have "priority" available for use cases in particular and probably other classifiers in general.

Thanks!

[Christiaan]

I fully agree. Software requirements is all about priority, this includes use cases! Personally, I find this decision of EA inconsistent. I have this on several other aspects too. It makes my colleagues and me wonder, they did it here, why didnt they put it here too??....

[Bruno.Cossi]

Hi,

I have never really felt a need for priority on Use Cases, but thinking about it, you could use the Tag values. Would that help?

Bruno

[jps]

I actually started down that path but it does not really get me what I want.

I would like to be able to CSV import/export the priority along with the complexity, name, guid, and other items.  It really seems strange that this would not be part of what is (should be) every users primary requirements artifact, the use case.

[sargasso]

Strangely(?) enough, we use a use case priority level that is derived from the priorities of the associated requirements, not from an overall "impression" of the use case priority itself.

(I have no objection to having a priority attribute associated with use case elements by the way).

Both internal and externalised requirements have a priority attribute.  During the analysis of requirements we extract all requirements by use case and use a bit of spreadsheet magic to produce a matrix of use cases categorised by overall requirement priority and requirement stability, or by priority and difficulty.

(Hint, hint: we would like to see Stability added as a requirement element attribute - its already in the automation model).

My way of thinking is that each and every use case is of equal necessity to the system as a whole - IOW how can one use case be of "less" value than another.

In terms of implementation cycles though - with a limited budget of either in time or money - it is realistic to think that a specific requirement is of more value than another (i.e. it has a higher ROI).  Similarly, under constrained budgets, less well formed requirments impose higher costs and higher risks than stable, well formed requirements.  Finally, under severly constrained budgets, the difficulty of implementing a specific requirement is often an important factor in the release scope negotiations.

So, although I support your request for a use case priority attribute, I think its value is fairly low.

(My 20c)
Bruce

[mchiuminatto]

Hi there.

I agree with Sargasso that from the requirements point of view, the requirements have the priority attribute. But from the architectural point of view and on the context of a use case driven process, some use cases have more importance than others based on risks and architecture significance.

We are building some automated tools to query the EA database repository and I find useful the priority associated to use cases for queries that filters or order the use case list based upon the priority value.

Have a nice weekend.

[jps]

Hi there.

I agree with Sargasso that from the requirements point of view, the requirements have the priority attribute.

I’m not really sure how either of you are using “requirements” along with use cases.  We take the view that the Use Case Model is the primary requirements artifact.  As Cockburn puts it, use cases "are not all of the requirements - they are only the behavioral requirements but they are all of the behavioral requirements."  Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, 2001.  In my experience, if I look across the categorization of a set of requirements and do not see that the behavioral, (aka functional) requirements do not make up the vast majority, the team has no real idea what it is they are to implement.

Don’t get me wrong, we absolutely record non-behavioral requirements that make up what RUP calls the Supplementary Spec.  These, however, are not nearly as important as the use cases to our entire software lifecycle.  For us, the use cases drive the estimate, the iteration plans, the architecture (though not entirely), analysis, design, and testing.  

We use Use Cases in a similar way to XP’s User Stories when it comes to planning, which for us makes assigning a priority to use cases very important.  Bruce, you nailed the reason for having a priority on use cases in the last paragraph of your last post.

I can understand that for some customers this may have a low value, but for us (where we have over 100 licenses, and growing) it would be very helpful.

[mchiuminatto]

I understand the use cases as behavioral requirements expressed as one or more dialogs (scenarios) between system and actors, plus the non-behavioral requirements (non-functional requirements as performance, availability etc.) as you stated.

If I'm right, sargasso was talking about the Actor' s needs or requests that are the input to "find use cases" activity in the requirements workflow. From this point of view, if you define a use case is because some actor needed, so if you take the whole set of actors, all the use cases are important for some actors for some reason. But if we wear the architecture glasses or the risk management glasses some use cases look bigger and brighter than others.

[Tom_Andries]

Not to downplay the importance of Use Cases, but when you don't get to educate your business analysts, you might e.g. recieve a word document with a process perspective, an operational perspective and a customer perspective. Use Cases in that case, are IT stuff, whether you (I) like it or not. Or, you might have a very "mature" business environment where to perform business process modeling. Again, risks that Use Cases are the first IT requirements artifact in such environment is not little.
One is not necessarily better then the other. I recall the old promgrammer's adagio "if it works, don't fix it".
That said,  taking the real topic of priority on use cases, I agree EA should implement this feature on every element possible. It's one of the greatest values of EA to include project-related elements such as these (and requirements, and issues, and ...) beyond UML.

I’m not really sure how either of you are using “requirements” along with use cases.  We take the view that the Use Case Model is the primary requirements artifact.  Don’t get me wrong, we absolutely record non-behavioral requirements that make up what RUP calls the Supplementary Spec.  These, however, are not nearly as important as the use cases to our entire software lifecycle.  For us, the use cases drive the estimate, the iteration plans, the architecture (though not entirely), analysis, design, and testing.  

We use Use Cases in a similar way to XP’s User Stories when it comes to planning, which for us makes assigning a priority to use cases very important.  Bruce, you nailed the reason for having a priority on use cases in the last paragraph of your last post.

I can understand that for some customers this may have a low value, but for us (where we have over 100 licenses, and growing) it would be very helpful.