Wikipedia “Non-Functional Requirement” ⇒ “A requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.”

• Qualities 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 Quality, a Non-Functional Desirement or Requirement.)
Relate the Quality with one or more of the Capabilities by citing the handles of those capabilities.(http://www.omgwiki.org/MBSE/doku.php?id=mbse:modelmgt:capabilities)

• [NONFUNC-INFORM-101] When exhibiting [CAP-INFORM-301] (Notify Subscribers of Changes to Published Content) an ideal MLM-S should express the changes as members of a change set that is necessary, sufficient, succinct, well-formed, self-contained, and not verbose.
  • Consider, for example: the journal of a Journaling Filesystem; a Tracked Resource Set of OSLC Providers; or the Delta XML of changes for an XML Document; DITA

• [FUNC-PERF-100] Response time expresses the observed time for the performance of any of the defined capabilities including [CAP-STORE-101] , [CAP-PROV-201] , [CAP-INFORM-301] , [CAP-SEC-401] , [CAP-ANAL-501]

• [FUNC-PERF-200] Transaction Rate expresses the number of simultaneous operations performed by users of the capabilities including [CAP-STORE-101] , [CAP-PROV-201] , [CAP-INFORM-301] , [CAP-SEC-401] , [CAP-ANAL-501].

John, absolutely, there are qualities or rather qualifiers like these for almost every capability. The intention here is not to identify the set of general qualities (e.g. “Cost”, “Reliability”, “Utility over Time”, etc.) but to state an objective or subjective goal or hard constraint for such a quality as it qualifies one or more of our capabilities.

Let's take FUNC-PERF-100, “Response Time” – inarguably applicable to CAP-STORE-101, as it qualifies the stakeholders' expectations for storing and retrieving information. Can you rephrase your qualifier as something more definitive? Perhaps something like:

• [FUNC-PERF-100] When exhibiting [CAP-STORE-101] (Provide Retrieval and Persistent Storage of Models, Model Elements, and Model Configuration Items) an ideal MLM-S should provide a positive acknowledgement or negative denial of the storage operation request within 500 ms of the request for human interfacing and within 100 ms of the request for programmatic APIs (e.g. REST) regardless of the distance between the client and the servers and regardless of the quantity of data to be read or written. Of course, when the quantity is “very large”, it may be necessary to acknowledge the request before the actual operation completes.

I realize that this is not easy to do; no one every promised anyone that architecting enterprise systems was easy. Doing this is also time-consuming. Yes and fortunately we have no enforceable deadlines. Take as much time as you can afford, when you can afford it.

Source: here