Guideline: Categorizing Method Elements Using Standard Categories
This guideline describes how to define standard categories and assign elements to these categories.
Relationships
Main Description

Standard Categories provide a means to categorize core method content in line with the best practices for creating structured methods. Standard Categories are linked to a specific method content type.  The Standard Category types are:

  • Disciplines
  • A discipline is a category of tasks that are related to a major area of concern within the overall IT environment. A task can belong to only one discipline.  For example, on a software development project, it is common to perform certain requirements tasks in close coordination with analysis and design tasks. Separating these tasks into separate disciplines makes the tasks easier to comprehend. Disciplines can be organized using Discipline Groupings.
         
  • Initial recommendations are to develop separate discipline groupings for each major context and standardize on the set of disciplines within that context, allowing for overlap between contexts where appropriate. While disciplines may have many similarities to domains for some areas, no formal relationship between the two has been defined. Disciplines are currently intended to be independent of role sets.
       
  • In general, the following are some criteria that affect how you assign tasks to specific disciplines in your method:
    • Number of tasks: The more tasks you have, the more there is a need to organize them into disciplines
    • Published representation of the method: How do consumers of the method want to see the tasks organized; define disciplines for those organizational elements
    • Governance: How the tasks are governed; define separate domains for tasks that are governed differently

Processes can also be associated with disciplines as Reference Workflows.  

Note: In some cases, the disciplines and domains are the same (i.e., the same set of names is used for both).  This approach minimizes the number of different ways you categorize things, which some see as an advantage.

  • Domains
  • A domain is a refineable, logical, categorization of related work products grouped together based on timing, resources, or relationship. While a Domain categorizes many work products, a work product belongs to only one Domain. Domains can be further divided into sub-domains.
      
  • Domains are seen by some to be more context-neutral than disciplines (i.e., disciplines tend to be more context-specific).
  • It is recommended that only parent work products be mapped to a domain, not child work products. This will yield a more pleasing tree structure in the published web site because child work products will only show up under their parent. If child work products are assigned to a domain, then they will also be displayed in the tree view at the ‘top level’ under the discipline, as well as under its parent.
     
  • In general, the following are some criteria that affect how you assign work products to specific domains in your method:
    • Number of work products: The more work products you have, the more there is a need to organize them into domains
    • Published representation of the method: How do consumers of the method want to see the work products organized; define domains for those organizational elements
    • Governance: How the work products are governed; define separate domains for work products that are governed differently

Note: In some cases, the domains and disciplines are the same (i.e., the same set of names is used for both).  This approach minimizes the number of different ways you categorize things, which some see as an advantage.

  • Work Product Kinds
  • A work product kind is another category for grouping work products.  A work product can have many work product kinds. As an example, you might want to have a series of work product kinds that correspond to the overall intent of work products, such as specification, plan, or model.  The use of work product kinds is optional.

  • In general, the following are some criteria that affect how you assign work products to specific work product kinds in your method:
    • Type of work product: Different work product kinds can be defined for artifacts vs outcomes
    • Number of work products: The more work products you have, the more there is a need to organize them into work product kinds
    • Published representation of the method: How do consumers of the method want to see the work products organized; do they want to see an alternate organization for the work products, in addition to the domain organization.  Define role sets for those organizational elements..

Work product kinds are usually more general than domains and usable across contexts.

  • Role Sets
  • A role set is used to categorize roles with certain commonalities together. For example, in a software development environment, an Analyst role set could be used to group together roles such as Business Process Analyst, System Analyst and Requirements Specifier. Each of these roles work with similar techniques and have overlapping skills, but may be responsible for performing certain tasks and creating certain work products. Role sets can be organized using role set groupings.
  • In general, the following are some criteria that affect how you define role sets and how you assign roles to specific role sets:
    • Number of roles: The more roles you have, the more there is a need to organize them into role sets
    • Published representation of the method: How do consumers of the method want to see the roles organized; define role sets for those organizational elements
    • Governance: How the roles and role sets are governed; define separate role sets for roles that are governed differently
  • Tools
  • A tool is a category for tool mentors. Tools can also provide general descriptions of a tool and it's general capabilities. 

You should define a standard category any time you have a need to categorize method elements.  Multiple levels of categories are possible, but you should only define what you need to manage your method content.  For example, if your method only contains two tasks, do you really need a discipline?

An important part of defining an element is naming it.  For recommendations on naming standard categories, see Guideline: Method Element Naming Conventions.

You may also want to capture guidance on how to decide what tasks belong in the discipline in the Key considerations property of the category.

Once the categories are defined, method elements can be assigned to them and the resulting categories can be used to access the information in the method, as well as in custom categories as part of navigation views.  For more information on custom categories, see Guideline: Categorizing Method Elements Using Custom Categories.

Standard categories cannot be packaged in separate packages in plug-ins, thus alternative categorization schemes must be defined in separate plug-ins.

Guidance can also be associated with standard categories. Such guidance should be applicable to the category as a whole, and should not be all guidance that is associated with each of the elements categorized to that category.

    

Special instructions when authoring in the UMF: When categorizing method elements for practices that are to exist within the Unified Method Framework (UMF), there are some constraints with regards to the definition and use of standard categories.  For more information, see Guideline: Standard Categories in the UMF.

More Information