Requirements Revisited

Tell, Spell, Edit, Edict (Samuel)

Preamble

Requirements expressed at the enterprise level can be of any kind and nothing can be assumed upfront about their footprint. Nevertheless, some boundaries can be established with regard to existing processes and information models; that can be achieved by combining ontologies (for assets representation) and generative AI (for requirements elicitation).

Enterprise Architecture

To begin with, requirements should be assessed with regard to their footprint on enterprise architecture:

  • Business domain requirements describe activities independently of the part played by supporting systems
  • Functional requirements deal with the part of activities supported by systems
  • Capability requirements are about functions shared across business processes
  • Quality of service (QoS) requirements refer to supporting systems capabilities independently of functional contents.
  • Technical requirements define constraints on the implementation of systems capabilities independently of their specific functional contents.
Requirements Taxonomy

Once sorted out corresponding specifications could be used to organize engineering processes:

  • Business cases (BC), between enterprises and environments
  • Use cases (UC), between enterprises and systems, with Agile cases (AC) for stand-alone projects without organizational or technical dependencies (ensuring shared ownership continuous deliveries)
  • Function cases (FC), between systems
  • Technical cases (TC), within systems
Requirements overview

and thus identify requirements footprints in models:

  • Descriptive models, for organization and business processes, and objects (Computation independent models)
  • Prescriptive models, for the representation of processes and managed business objects (Platform independent models)
  • Technical models, for the implementation of descriptive models (Platform specific models)

Ontologies can thus be used to represent both models dependencies and life cycles.

Ontological Prism

Requirements at enterprise level entail references to business models, existing architecture components, and current or planned projects. Given the variety of the contexts involved, such references may point to terms or models, the former with meanings set by domains, the latter set in actual (managed) or virtual (planned) modes.

For long dedicated modeling and programming languages have been used to support the different engineering undertakings, with consistency and interoperability being considered at best as afterthoughts. But ontological prisms can provide the symbolic gears ensuring the consistency of representations and the interoperability of functions and tools:

  • Data/facts, for whatever can be known about environments, including actual systems and business processes
  • Information/categories, for models of the symbolic representations managed by enterprises
  • Knowledge/concepts, for the symbolic representations used to define enterprises’ objectives and value chains
Ontological Prism: EA Use cases & Engineering interfaces

Then, language models can be added to iron out semantic discrepancies.

Language Models

Requirements, whether business, functional, or technical, often involve different organisational entities pertaining to overlapping business domains and technical layers, usually set across different time frames. Aside from proprietary platforms, attempts to maintain some continuity across conceptual or semantic silos have been limited to ad-hoc and cumbersome procedures; but the development of generative language technologies is opening new perspectives, as it’s the case for requirements’ capture and elicitation:

  • Transcripts and document are elicited (a)
  • Language models are built from current information schemas and used to analyse elicited requirements (b)
  • Ontologies are used to align analysed requirements with domain-specific business objectives, and regroup them with regard to organisational, functional, and operational constraints (c)
Requirements & Language models

Coupling ontological prisms with language models could thus ensure a semantic continuity and conceptual consistency between objectives, requirements, and specifications.

Requirements Cycle

Ontological modalities

The aim of ontologies is to add knowledge modalities to conceptual graphs:

  • Extensional (empiric), for the ways facts are known: observed, assessed, managed, etc
  • Intensional (conceptual), for the nature and intents of knowledge: nominal, virtual, concrete, etc
  • Logical (symbolic), for the representation of knowledge: identification, agency, communication, etc

EA frameworks with such built-in modalities can support declarative and iterative processes, the aim being to abstract away imperative control flows and rely instead on conditions about objectives, resources, and outcomes. Such requirements processing can be best achieved through OODA decision-making cycles.

OODA Template

The Observation, Orientation, Decision, Action (OODA) decision-making template can be applied to the processing of EA requirements:

  • Observation, for the capture and elicitation of any kind of requirements verbal or textual, structured or otherwise. It can be done through some kind of parsing (syntax, facts, data), with or without generative assistance
  • Orientation, analysis of requirements. That calls for reasoning capabilities (semantics, categories, information)
  • Decision, for assignments to work units. That would rely on judgment and imply transparency and accountability
  • Action, for the packaging of work units into projects. Done through experience (implicit and explicit knowledge)
Requirement Roundabout

Requirements processes are then set as roundabouts with entrance and exit conditions, and iteration rules in-between.

EA Requirements Roundabouts

Requirements enter roundabouts as indeterminate consignments and exit as either stand-alone or phased work units.

Observation: Capture & Elicitation

Given that requirements can be expressed in any kind of multi-modal (textual, numerical, graphical, …) documents and/or datasets, the primary objective is to parse requirements chunks into some agreed upon syntax, e.g. neural networks or XML.

Observation: Capture & Elicitation

Then, since requirements are supposed to be set in bounded (semantic) contexts, thesauruses and language models trained through generic and specific resources can help with the elicitation of what should-be (asserted, expected, planned, …) compared to what currently is (managed, observed, assessed, …).

Orientation: Analysis

The aim of orientation is to put requirements into an enterprise architecture perspective, i.e. mapping them to current organisational and operational contexts. To that end three kinds of embedded anchors are introduced in language models for:

  • Systems legacy components, as identified in operational repositories
  • Managed categories, for business domains and entities identified in database schemas
  • Defining business concepts, as identified in organisational thesauruses
Orientation: Analysis

Ontological modalities can then be used to train language models in analysing requirement chunks:

  • Legacy (extensional modalities), for the assessment of systems and processes as they are
  • Concepts (intensional modalities), for the alignment of requirements with business models, goals, and plans
  • Categories (logical modalities), for the translation of textual requirements into formal specifications

Adding ontological (or knowledge) modalities to requirements will help to decide how and when they are best engineered.

Decision: Work units

Once requirements are aligned with business concepts, managed categories, and legacy components, work units and milestones can be defined and requirements distributed thereof, taking into account organisational, functional, and operational constraints. Taking a leaf from lean manufacturing, work units can be handled across four engineering workshops:

    • Enterprise workshop: where enterprise architects (EA), system architects (SA) and business analysts (BA) identify business objects and anchors (#) as well as their semantics (descriptive models, aka computation independent models)
    • Domains workshop: where business analysts and system architects define the corresponding representations to be managed by systems (prescriptive models, aka platform independent models)
    • Applications workshop: where business analysts and software engineers (SE) define and develop the corresponding implementations by systems (technical models, aka platform specific models)
    • Systems workshop: where software engineers and process managers (PM) define and manage deployed configurations.
Sorting out Requirements

Assuming that responsibilities are better defined with regard to specific operational and organisational contexts, they are just introduced as guidelines.

Decisions are carried out iteratively with a primary focus on work units regrouping stand-alone requirements that could be met in time capsules independently of external events, i.e. without constraints on the contents and scheduling of intermediate deliveries. Conversely, phased work units call for grouped decisions conditioned by organizational, functional, technical, or delivery dependencies.

Decisions on work units can be supported by non-symbolic as well as symbolic schemes, the former with pattern matching applied to semantic networks, the latter with expertise from ontological modalities. At first, four basic profiles should be considered:

  • Stand-alone applications, business or otherwise, for self-contained requirements that can be met without affecting shared assets (Agile cases)
  • Business applications, for requirements with overlapping footprint on shared assets (Use cases)
  • Services, for requirements affecting shared assets without direct impact on user interfaces (Function cases)
  • Modernisation, for requirements affecting implementations (System cases)
Projects Patterns

It must be stressed that stand-alone work units are like low-hanging fruits to be picked at will; moreover, the demarcation with higher-hanging ones is not fixed and can be redrawn as and when requirements are elicited and/or refactored. It ensues that the sorting out of stand-alone projects doesn’t have to be done in concert and can be carried out iteratively.

Action: Projects

As illustrated by Waterfall development models, phased solutions often come with a critical caveat as they rely on the implicit assumption that time can be suspended (or falls reversed) and requirements kept frozen until projects’ completion; iterative processes, declarative control, and ontological modalities can help with that issue.

Iterative processes enable time to be suspended and decisions put off until the “last responsible moment,” when further delays on commitments would reduce the range of options or the expected returns. With ontological modalities, decisions about requirements could thus be weighted by some kind of shelf life, and actions carried out accordingly.

Summarily, projects should thus be managed through two time frames, a business one set by environments, an engineering one set by enterprises. Deliveries for use and function cases must be synchronised along both time frames, system cases synchronised along engineering time frames, and agile cases only compatible with both time frames.

Further Readings

Kaleidoscope Series

Other Caminao References