UPDM 2.1 “Capability” ⇒ “A high level specification of the enterprise's ability.”

• Capabilities are placed here after peer discussion of the Proposed Set

• State your proposals here.
  

(Follow a pattern of [Tag Alias] Imperative Verb Phrase describing a Capability, not a Requirement, Feature, or Benefit.)

• [CAP-STORE-101] Provide Retrieval and Persistent Storage of Models, Model Elements, and Model Configuration Items.
• [CAP-PROV-201] Record and Provide Provenance Properties (5W+H) on Curated Model Content.
• [CAP-INFORM-301] Notify Subscribers of Changes to Published Content.
• [CAP-SEC-401] Allow Access to Authorized Content; Reject Discovery of Unauthorized Content.
• [CAP-ANAL-501] Compare two or more Graphs of Model Content and Identify Differences at Optional levels of Granularity.

Source: here

Capabilities are distinct from features and benefits. They are an in-between state that connect the feature to the benefit. You can say that they lead your customer into understanding how the features you have deliver the benefit.

I have a fingerprint scanner on my computer that stores my passwords. This saves me five minutes every time I would forget a password and have to look it up or re-set it. The fingerprint scanner is the feature, storing my passwords is the capability and saving me five minutes is the benefit. The way to create a capability or to spot one is to look for the phrase that answers the question “What does this allow me to do?”

Capabilities aren't really benefits. Benefits are feelings and emotions while capabilities tend to be actions or tasks. This distinction is important because when your customers are choosing a solution to their problem, they may be focused on a task or capability that they want. If your product description only lists features and benefits—your customer may pass you by because they don't see the connection between what you offer and what they are trying to accomplish.