Discussion :

[Tueur_a_gage]

Hello

Je cherche à catégoriser mes UC par ordre d'importance. Pour l'instant je leur ai donné comme termes :
- Essentiel
- Utile
- Confort

Existe-t-il une norme UML pour cela ? il me semble me souvenir de qq chose comme Primordiale, ...

Merci

[ego]

Perso je ne connais pas de norme à ce sujet.
Dans le RUP, Rational propose : Critical, Important, Useful pour les valeurs de l'attribut "Bénéfice" du point de vue de la partie-prenante/utilisateur.

Ci-dessous, je te joins un extrait du RUP.......donc en anglais mais bon....

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
Features, Supplementary Requirements, and Use Cases  
Status: Indicates whether the requirement has been reviewed and accepted by the "official channel". Example values are Proposed, Rejected, Approved.

 This may be a contractual status, or a status set by a working group capable of making binding decisions.  

Benefit: The importance from the stakeholder(s) viewpoint.

Critical (or primary). These have to do with the main tasks of the system, its basic function, the functions for which it is being developed. If they are missing the system fails to fulfill its primary mission. They drive the architectural design and tend to be the most frequently exercised use cases. 
Important (or secondary). These have to do with the support of the system's functions, such as statistical data compilation, report generation, supervision, and function testing. If they are missing the system can still (for a while) fulfill its fundamental mission, but with degraded service quality. In modeling, less importance will be attached to them than to critical use cases 
Useful (nice to have). These are "comfort" features, not linked to the system's primary mission but that help in its use or market positioning. 
Effort: Estimated effort days to implement the requirement.  

E.g. This could be categories such as Low, Medium, High. E.g. Low = <1day, Medium = 1-20 days, High = >20 days.

In defining Effort, it should be clearly indicated which overheads &#40;management effort, test effort, requirements effort etc.&#41; is included into the estimate.

Size&#58; Estimated non-comment source lines of code &#40;SLOCs&#41;, excluding any test code.

You may wish to distinguish between new and re-used SLOCs, in order to better compute cost estimates. 

Risk&#58; % likelihood that implementation of the requirement will encounter significant undesirable events such as schedule slippage, cost overrun, or cancellation. 

E.g. This could be categories such as Low, Medium, High.  E.g. Low = <10%, Medium = 10-50%, High = >50%.

Another option for Risk is separately tracking Technology Risk  - % likelihood of running into serious difficulty implementing the requirement because of lack of experience in the domain and/or required technologies.  Then overall risk can be computed as a weighted sum based on other attributes, including size, effort, stability, technology risk, architectural impact, and organizational complexity. 

Organizational Complexity&#58; Categorization of control over the organization developing the requirement.

Internal&#58; In-house development at one site 
Geographic&#58; Geographically distributed team 
External&#58; External organization within the company.   
Vendor&#58; Subcontract or purchase of externally developed software. 
Architectural Impact&#58; Indicates how this requirement will impact the software architecture.

None&#58; Does not affect the existing architecture. 
Extends&#58; Requires extending the existing architecture. 
Modifies&#58; The existing architecture must be changed to accommodate the requirement.   
Stability&#58; Likelihood that this requirement will change, or that the development teams' understanding of the requirement will change. &#40;>50% = High, 10..50% = Medium, <10%=Low&#41;

Target Release&#58; The intended product release in which the requirement will be met. &#40;Release1, Release1.1, Release2, ...&#41;

Hazard Level / Criticality&#58; Ability to affect health, welfare, or economic consequences, typically as a result of the software failing to perform as required.

Negligible&#58; Cannot result in significant personnel injury or equipment damage. 

Marginal&#58; Can be controlled without personnel injury or major system damage. 

Critical&#58; Can cause personnel injury or major system damage, or will require immediate corrective action for personnel or system survival. 

Catastrophic&#58; Can cause serious injury or death, or complete system loss. 

Hazards may also be identified as separate requirements types, and linked to associated use cases.  You may also wish to track hazard probability, corrective actions and/or preventative measures.

Interpretation&#58; In some cases where the requirements form a formal contract, it may be difficult and costly to change the wording the requirements.  As the development organization gains a better understanding of a requirement, it may be necessary to attach interpretation text, rather than simply change the official wording of the requirement.

Use Case
In addition to the above, it is also useful to track the following use case attribute&#58;

%Detailed&#58; Degree to which the Use Case has been elaborated&#58;

10%&#58; Basic description is provided.. 

50%&#58; Main flows documented. 

80%&#58; Completed but not reviewed.  All preconditions and postconditions fully specified. 

100%&#58; Reviewed and approved.

[Tueur_a_gage]

Hello

je crois que cela répond à mes questions : Critical, Important et Useful...

Nous étions partis sur Critique, Important et Confort... psa si loin !

merci pour l'info