Preamble
Beyond varying names, requirements have often been classified into four basic categories:
- Process requirements deal with organization and business processes independently of the part played by supporting systems.
- Application requirements deal with the part played by supporting systems in the realization of processes requirements..
- Quality of Service requirements deal with users experience independently of symbolic contents.
- Technical requirements deal with the implementation of systems functions independently of users experience.
Yet, regardless of the soundness of these categories, their effectiveness varies with contexts, and contexts have been drastically disrupted with enterprises immersion in digital environments.
Digital Disruption
With the generalization of digital environments and the ensuing intermingling of business processes and IT two established distinctions are losing their grip, first between processes and applications, and then between users and systems.
For processes, the blurring is to concern non deterministic operations (heuristics, non modal logic, learning, …) that used to be the prerogative of humans but are now commonly carried out by artificial brains set in applications (a), user interface (d), or elsewhere (b). As a corollary, user interfaces are losing their homogeneity, as single systems with established codes of conduct are being replaced by an undefined number of unidentified agents (c, d).
Lest they drive enterprises into dead ends requirements have to map their systems according to the new digital territories. Not surprisingly, that can be best achieved using the symbolic/non symbolic distinction.
Requirements associated with symbolic contents.. Given that symbolic expressions can be reformulated, the granularity of these requirements can always be adjusted as to fall into single domains and therefore under the authority of clearly identified owners or stakeholders.
Requirements not dealing with symbolic contents. Since they cannot be uniquely tied to symbolic flows between systems and business contexts, nothing can be assumed regarding the identity of stakeholders. Yet, as they target systems features and behaviors, they can still be associated with architecture levels: enterprise, functional, technical.
Functional Requirements
As commonly understood, functional requirements cover business concerns and the part supported by systems; as such they can be aligned with enterprise architecture capabilities, symbolic (roles, business entities, business logic), and non symbolic (physical objects and locations, time-frames, events, processes execution).
In order to deal with the blurring induced by digital flows, requirements should ensure the transparency and traceability of interactions:
- Transparency: users should be continuously aware of the kind of agent in charge behind the screen.
- Traceability: users should be able to ask for explanations about every outcome.
As noted above, such requirements cannot be circumscribed to users interfaces or even applications as they involve the whole of the knowledge architecture . To that end functional requirements should be organized in relation to enterprise architecture capabilities, and include the necessary extensions for knowledge architecture:
- When agents/roles assignments remain open requirements should include communication (natural, symbolic, or digital) and cognitive capabilities.
- Assuming that requirements are not limited to modeled information, the distinction between data, information, and knowledge should be explicit.
- Likewise for non deterministic reasoning used in business logic.
Requirements concerning the digital capabilities of entry-points and time-frames of processes execution are to be added in order to associate functional and quality of service requirements.
Non Functional Requirements
Non functional requirements (NFRs) are meant to encompass whatever remain which cannot be tied to symbolic representations.
As should be expected for leftover categories, non functional requirements are by nature a mixed bag of overlapping items straddling the line between systems and applications depending on whether they directly affect users experience (quality of service), or are of the sole concern of architects and engineers (technical requirements).
The heterogeneity of non functional requirements is compounded by the mirror impact of the digital transformation on functional ones when business requirements (e.g high-frequency trading) combine performances with “intelligent” computing (e.g. machine learning capabilities).
Yet, that is not to say that the distinction is arbitrary; in fact it conveys an implicit policy regarding architecture capabilities: defining elapse time as functional means that high-frequency traders will be supported by their own communication network and workstations, otherwise they will be dependent upon the company technical architecture, managed by a separate organizational unit, governed by its own concerns and policies.
On that account the digital transformation may help to clarify the issue of non functional requirements because all requirements, functional or otherwise can now be framed uniformly and therefore discriminate more easily.
FURTHER READING
- Digital Transformation & Homeostasis
- Entropy & Homeostasis
- Knowledge-based Models Transformation
- Focus: Data vs Information
- Modeling Paradigm
- EA: Maps & Territories
- Ontologies & Enterprise Architecture
- Ontologies as Productive Assets
- Requirements Reuse
- Models Transformation & Agile Development