+1
Capability as described in this way gets closer to the "thing" (black box?) that really does stuff because otherwise the idea of things like QoS don't make sense.
My path to doing this was connecting Capability to the more generic notion of the Resource, and I really think Michael and I are closer on this than some of the dialog might indicate.
Ken On Jun 4, 2008, at 10:59 AM, Jeffrey A. Estefan wrote: Folks, I recommend that we leverage the world of requirements engineering here. As many of you know, in the circle of requirements engineering, requirements are typically characterized in terms of functional requirements (what the system is suppose to do) and other than functional requirements (how well the system is suppose to do "it"). The latter is usually cited to as either "non-functional" requirements or "quality attribute" requirements. These other than functional requirements really address required levels of service or qualities of service (QoS). Many folks in this world suggest that functionality and capability are synonymous. I've seen this used over and over again throughout the systems engineering world and in the literature. We could simply adopt that perspective; however, I argue that capability corresponds to not only how a system (or, in our world, a SOA service ) meets BOTH the required functionality and quality attributes. In other words, in our world, Capability is a description of not only what the service can do but how well it can do it, and Functionality is just a description of what the service can do, independent of how well it can do it. In that sense, Functionality is really a subset of Capability. I really think it's just that simple, but then I have a simple mind! My two cents... - Jeff
------------------------------------------------------------------------------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 |