This small paper tries to tease apart a good definition for non-functional requirements. He makes a good point in the dependence of classification on how the requirement is represented. For example, there is a difference between stating "The data shall prevent any unauthorized access to customer data" from "The database shall grant access to the customer data only to those who have been authorized by their user name and password". But note that the second requirement is more restrictive than the first and includes an implementation detail that was not present in the first; username and password. There was an implied design step between the two that introduced functional requirements to meet the original non-functional requirement. When authorized by the username and password, the system grants access. The first requirement leaves that detail unspecified allowing the designer latitude in how the requirement is met. The first requirement could be satisfied with retinal scans or other bioinformatic data that could no longer become part of the system specified by the second requirement. It seems that all non-functional requirements ultimately reduce to functional requirements and this makes sense since they must be implemented using the formalism of functional design. What makes the study interesting is doing this decomposition of non-functional requirements into functional specification in such a way as to aid in the construction of test cases that determine whether or not the requirement was met.
Where I seem to be going in my interest is being rigorous in the input to the design process so as to provide a solid base for the more rigorous look at the design process itself. The outcome of the design process should ultimately be fixed by the validation of this product against the specification and the verification that it behaves as intended.
I had a conversation with Earl in which he agreed that functional versus non-functional seems to make little sense in most usage. But he resisted my assertion that there is any relationship to any notion of a mathematical function at its core. His resistance is fueling my desire to get to the bottom of this so I can turn back to a more rigorous understanding of what is meant by software "quality."
In section 4.2 this paper offers a definition that embodies the point I was trying to make with Earl. "A concern is a matter of interest in a system. A concern is a functional or behaviorial concern if its matter of interest is primarily the expected behavior of a system or system component in terms of its reaction to a given stimuli and the functions and data required for processing the stimuli and producing the reaction." Where I think this moves the conversation forward is the way it brings attention to the stimulus/response of the system as the primary differential. After hearing Earl's comments I feel I need to gain a better grasp of the formal definitions but informally in the undergrad curriculum functional is always defined in terms of a component that accepts multiple input variables and returns a single result. It is defined by its signature and the unit of abstraction for design. If I'm allowed this definition of function for the moment, a functional requirement is one that specifies the response given the state and input to the system. Simply stated then, the functional measure of conformance to the functional specification is whether or not when the system is in the specified state and presented with the specified input, if the system produces the specified response.
Of course this type of functional specification is one that the paper refers to as a "hard" requirement (I believe) and one that is either always met or it is judged to not meet the specification. I infer that what the paper means by "soft" requirement is one where some probability function is specified that defines the tolerance allowed for the behavior.
This leads me to two points that I believe need to be explored. The first point is the temporal aspect of behavior and the second is how systems and requirements are decomposed or aggregated in a complex system.
There are advanced logics that address the temporal component and I had briefly studied one of the temporal specification languages that addressed these temporal concerns. However it is clearly understood in the literature that these languages stand apart from the more common ones which do not. To be able to distinguish between a deadlock and an underpowered processor is vital in analysis of design. But at the level of specification or requirements it is expressed as a constraint on the functionality at some level. Perhaps an interrupt is only presented for a fraction of a second. The system must recognize and remember the interrupt within that time parameter or the system will not function as intended. OCL and other specification languages allow this additional information to be captured in the specification model. But I think it is important that it supplements, not replaces, the stimulus response aspect of the system.
The other aspect of the specification is how it is expressed at different levels of decomposition. Something like the overall usability of the system has a cascade of specifications as it is decomposed into the design. When the requirement includes the requirement to allow an arbitrary number of "undo" steps in the system, it begins to constrain various sub-specifications to the parts of the design. This includes both behavior and information representation choices and even has business implications that the user must be made aware of as the ability to backout a transaction may entail the "undoing" of later transactions that depended upon this state of the system.
I think the levels of specification and behavior that I see can most easily be seen in the difference between an requirement-in-use like the usability requirement from above, and a requirement-of-ownership like maintainability.
The system that is being specified for a requirement-in-use is not just the software but also the software plus the hardware and human environment in which the software is deployed. There is a continual surprise when testing fails to uncover an error from a common business transaction due to the lack of sufficient understanding of the domain compounded with the lack of end-user involvement in the specification and test preparation for the system. To think of this as only a software requirement will perpetuate this mismatch and ensure we do not find a solid foundation. But most important is to note how this differs from the requirement-of-ownership like maintainability.
In use, the system of interest is the production software, hardware and business environment. This environment either does not include the human organizations concerned with the future versions or the planning for that change. It does not include the development environment. Even more dramatically for a compiled language the system-in-use does not even require the source code. These are two distinct systems that overlap in the production software code and some interfacing organizational units. At the macro level the metric for a software change includes the variables for the size or complexity of the change, the skill set of the resources to be allocated to the change, the development environment deployed to support the maintenance and the required time and cost for that change. The response would be quantified by the achievement of some level of MTTF or defects detected against some standardized test bed.
These definitions are not just academic exercises. They become the foundation which supports the engineering of the system and the basis for an unbiased and objective assessment of whether the system met its specifications. It is these specifications, and the attributes of the product produced from them, that provides the basis for the assessment of the product composite quality.
Human beings, I have noticed are well equipped to judge and group things together better than animals. We are a people who build societies that support and maintain personal responsibility and are accountable to one another. These are ideas that we have grown up, taught in school and reinforced by our families and society. We are people experienced in responsibility-driven activities. It is a principle that we use daily in our activities and throughout our lives.
ReplyDeleteSo what does this mean? I have learned to make piles. I have learned that if I do something, it should be for a purpose or a goal. I have experienced that I have to account for my activity to others, and while I do something, it is best that I concentrate on doing that one thing, rather than a diluted set of extraneous activities, and if I choose to do that one thing, I should do it simply – not simpler; and do it well so I don’t have to do it over again.
Thanks Dave. You are the first to post anything here, and as far as I know the first to read anything I wrote.
ReplyDeleteYour note reminds me of the Gladwell book, Blink. Gladwell often talks about the minds ability to make very rapid decisions about the world and one of the most important distinctions he starts with are those which enhance survivability. Being able to distinguish a lion in the brush can mean the difference between having sex that night or becoming the lion's dinner that afternoon. The distinction is made at a visceral level with no conscious thought. Snakes, in particular, seem to excite some very primitive nerve patterns.
But of course this is not the kind of pile building you are talking about. Those are more learned and pull from some higher order consciousness. I agree they are purpose driven and represent the way be abstract the world around us reducing groups of things to some attribute that is of interest to us. We have lists of things-to-pay, things-to-do, and things-I-want-to-do-before-I-die. The only commonality between these different activities is a difference in their relationship to us. Given the list without the header, only people very close to us could guess what ties those together.
The evolutionary innovation of the human brain seems to be that ability to think in those abstract ways. That ability falls off pretty quickly as you move away from the higher order animals (I'd say primates but they are finding some rather impressive ability in elephants and porpoises). What is even more remarkable about humans is our capacity for both a spoken language where phenomes can be interpreted by another human and understood as transmitted thought. Our written language goes one step higher.