Software engineering, as a discipline, could benefit from a more rigorous grounding in Philosophy, e.g., by referring to the concept of “computational artefact” [T]:
Let us think of a toaster simply as a machine in which you put in a slice of fluffy bread, push down the lever and take out a slice of toasted bread. In terms of logic, you perform an AND operation, since without both putting in the bread (B) and pushing the lever (L), you take out nothing. So, from the pure perspective of logic, we could describe the toaster as a machine computing B ∧ L . This could make the toaster a suitable device for use as a stock market advisor. Say, the rule is: buy when the price is at 13 and the sun shines. We can implement this with our toaster by putting in bread if the sun shines and pushing the lever each time the price hits 13. Therefore, each time a slice of toasted bread pops out, we know that this is the time to buy. [P]
Notice, that in the former case, despite our logic perspective, we still use the toaster for its physical output: toasted bread. In the latter case we are purely considering its logical result: stating either true or false.
Furthermore, when the purpose is solely to produce logical results, physical outcomes are merely annoying by-products, which has led us to build machines based on metal strips, relays, transistors, integrated circuits and so on, that produce just small amounts of heat, noise, etc., instead of piles of toasted bread.
In strive for our main interest, that of the relationship between Computational Artefacts and Software Requirements, we next look at ways of describing the intention behind such a logic machine. As we already know, intention is not only expressed in terms of input/output pairs, but also by formulas. However, why should we do this? What are the advantages of stating an intention in a language over expressing it as cases?
For instance, we could take these inputs (the ones with output 1)
(0, 1, 1), (1, 0, 0), (1, 1, 1)
and rewrite them as a propositional formula
(¬A ∧ B ∧ C) ∨ (¬A ∧ B ∧ -C) ∨ (A ∧ B ∧ C)
So, what have we gained? At first glance, we achieved the same in a more bloated language. However, propositional language allows us to rewrite the formula as
B ∧ (A ∨ C)
which may be closer to the way in which certain readers prefer to think of it. This way, the choice of an appropriate perspective fosters understanding among stakeholders, which is, by the way, an important, although often neglected, contribution of requirements analysis. Moreover, here in our simple world, the language allows us to formally prove the correspondence between the requirements and the design, when the latter namely, the program, is also written as a propositional formula. These considerations are heading towards formal methods, a subject area highly important in specialized domains such as safety critical systems, but with limited relevance (at least in its ‘heavy weight’ guises) for the greatest proportion of software development. [Z]
Summing up, we used a very elementary setting of machines built for logic purposes and provided a first insight into various ways of expressing the underlying intentions. Here, the intangible concept of understanding may play a central role for requirements analysis. Lots more to muse about. So, stay tuned.
[T] As discussed in:
R. Turner (2018) “Computational Artifacts (Theory and Applications of Computability)”
Springer Berlin Heidelberg
[P] For a broader account on what it takes for a physical system to perform a given computation and for a computation to be implemented in a physical system, see:
G. Piccinini (2017) “Computation in Physical Systems”
in The Stanford Encyclopedia of Philosophy, Summer 2017 Edition
Link: Computation in Physical Systems
[Z] For lightweight formal methods, see for example:
A. Zamansky, M. Spichkova, G. Rodríguez-Navas, P. Herrmann, J.O. Blech (2018) “Towards Classification of Lightweight Formal Methods”