This article proposes intentionality-based solution design and build as a contemporary restatement of a classical business analysis principle: requirements should initially describe need, purpose, outcome, constraint, and value before specifying the mechanics of implementation. The argument is that this principle has become more important in the age of generative AI, low-code development, automation, and composable architecture. As the friction of producing technical artefacts declines, the decisive bottleneck shifts from technical construction to the disciplined articulation of intent. Poorly expressed intent can now generate wrong solutions faster; well-structured intent can accelerate discovery, design, validation, governance, and delivery. The article positions intentionality as a design constraint, governance asset, and strategic capability for business analysts, product owners, architects, and executives.

Introduction:
Modern software and enterprise transformation initiatives often begin with a problem statement but rapidly become conversations about platforms, user interfaces, integrations, workflows, automation engines, data repositories, and technical architecture. This movement is understandable. Organisations are under pressure to deliver quickly, stakeholders often express needs through the language of familiar tools, and technology vendors naturally frame problems in terms of their own solution categories. Yet this pattern creates a persistent risk: the solution is defined before the business intent has been clarified.

This risk is not new. Requirements engineering and business analysis have long argued that early analysis should distinguish the problem to be solved from the solution to be built. Standards such as ISO/IEC/IEEE 29148 describe requirements engineering as a lifecycle discipline concerned with requirements processes, work products, attributes, and characteristics, rather than merely a front-end documentation activity (ISO/IEC/IEEE, 2018). The International Institute of Business Analysis similarly defines business analysis as the practice of enabling change by defining needs and recommending solutions that deliver value (IIBA, 2015).

What is new is the delivery environment. Generative AI, low-code platforms, AI-assisted development tools, automation suites, and composable architecture have reduced the time and effort required to generate artefacts. AI-assisted coding experiments have found significant productivity effects; one controlled experiment reported that developers using GitHub Copilot completed a programming task 55.8% faster than a control group (Peng et al., 2023). Field experiments at large organisations have also found suggestive productivity gains in pull-request throughput among developers using Copilot (Cui et al., 2025). At the organisational level, McKinsey’s 2025 global AI survey reported broad regular use of AI across business functions, while also noting that most organisations had not yet scaled the technology effectively (McKinsey, 2025).

These trends change the nature of the problem. When building becomes faster, ambiguity becomes more dangerous. A team can now produce prototypes, user stories, test cases, code, workflows, reports, and documentation from weakly formed instructions. The strategic question is therefore no longer only, “Can we build this?” It is increasingly, “Have we expressed the intent clearly enough that the right solution can be generated, configured, selected, governed, validated, and improved?” This article argues that intent is becoming a primary design asset.

The Legacy Principle: Requirements Before Solutions:
The principle behind intentionality-based solution design is deeply rooted in requirements engineering and business analysis. Classical requirements practice distinguishes between business objectives, stakeholder needs, solution requirements, transition requirements, and design decisions. The purpose of this distinction is not bureaucratic; it protects the organisation from confusing the expression of need with the premature selection of mechanism.

Boehm and Basili (2001) argued that finding and fixing defects after delivery can be far more expensive than addressing problems during requirements and design. This insight is often interpreted as an argument for better testing, but its deeper implication is that early misunderstanding is expensive. A technically elegant system can still fail if it automates the wrong process, optimises the wrong behaviour, produces the wrong decision, or satisfies a local stakeholder preference while undermining enterprise value.

Pohl (2010) characterises requirements engineering as the disciplined elicitation, negotiation, documentation, validation, and management of requirements. Wiegers and Beatty (2013) similarly emphasise the importance of business objectives, user needs, and measurable acceptance conditions. In business analysis, the BABOK tradition separates business requirements from solution requirements to preserve a line of sight from organisational need to implemented capability (IIBA, 2015).

The classical business analyst has therefore served, at least in part, as a guardian against premature solutioning. When a stakeholder says, “We need a new portal,” the business analyst asks: What outcome is expected? Which users are underserved? Which operational burden should decline? Which decision must improve? Which risks must be controlled? Which measures will demonstrate success? The discipline insists that a “portal” is not inherently a requirement; it is a candidate solution. The requirement may be reduced call-centre demand, improved customer task completion, regulatory traceability, better transparency, or a lower cost-to-serve.

This legacy principle remains valid. However, AI-enabled delivery gives it new urgency.

Why AI Changes the Importance of Intent:
Generative AI and low-code tools alter the economics of solution delivery by reducing the marginal cost of producing technical artefacts. Generative AI can create text, code, conversations, images, and other content in response to prompts or instructions, while low-code tools use higher-level abstractions, prebuilt components, and visual models to reduce manual programming effort (AWS, 2026; Liu et al., 2024). Prompt engineering research also shows that task-specific instructions can strongly shape model behaviour without changing the underlying model parameters (Sahoo et al., 2024).

This is precisely why intent becomes more important. AI systems are not mind readers. They respond to prompts, examples, patterns, data, constraints, and feedback. If the business intent is vague, the AI-assisted delivery process may produce plausible but misdirected outputs: generic epics, superficial user stories, brittle test cases, attractive but irrelevant prototypes, or code that satisfies a stated feature while violating an unstated business rule. NIST’s Generative AI Profile highlights the need to manage generative AI risks in design, development, use, and evaluation, reinforcing the point that AI outputs require governance rather than passive acceptance (NIST, 2024). OWASP’s work on large language model application risks similarly stresses prompt injection, insecure output handling, supply-chain vulnerabilities, and the need to validate generated outputs (OWASP, 2025).

The paradox is clear: AI can accelerate delivery, but it can also accelerate error. The faster an organisation can generate artefacts, the more important it becomes to know what those artefacts are supposed to accomplish. In a manual delivery environment, ambiguity often reveals itself slowly. In an AI-enabled environment, ambiguity can be instantly operationalised. This makes intent a scarce organisational resource. The constraint is not merely access to tools; many organisations can acquire similar tools. The differentiator is the capacity to define desired outcomes, decision logic, user behaviour, policy constraints, operating models, and success measures with enough precision that AI-enabled systems can assist meaningfully.

Defining Intentionality-Based Solution Design and Build:
Intentionality-based solution design and build may be defined as an approach to enterprise solution delivery in which the desired capability, operational effect, user outcome, decision logic, governance constraint, risk boundary, and success measure are deliberately expressed before technical solution mechanics are selected or generated. It treats intent as the primary input to solution activation, with technology serving as the adaptive mechanism through which intent is realised. This definition distinguishes intent from desire. A desire may be expressed as “we need a chatbot,” “we need a new CRM,” or “we need an AI workflow.” Intent asks what those proposed mechanisms are meant to achieve. For example, the intent may be to reduce avoidable service interactions, improve the accuracy of triage decisions, shorten cycle time, increase compliance evidence, reduce manual reconciliation, or improve confidence in a complex transaction.

Intentionality-based design does not reject technical design. Rather, it sequences it more intelligently. Technical feasibility, architecture, cybersecurity, data quality, integration design, scalability, accessibility, and performance remain essential. However, these are treated as means of realising intent, not substitutes for it. The technical architecture should be judged by how well it supports the business capability, not by how impressively it uses contemporary technology. This approach connects naturally to capability-based planning and business architecture. The TOGAF Standard positions enterprise architecture as a method for aligning business and technology change (The Open Group, 2022). Capability-based planning asks what the organisation must be able to do, rather than which system it should buy first. Design thinking adds a human-centred lens, focusing on desirability, feasibility, and viability (Brown, 2008). Domain-driven design similarly insists that software should reflect the concepts, rules, and language of the business domain rather than merely the preferences of technical implementation (Evans, 2003; Fowler, 2020).

Intentionality-based design is therefore not a wholly new discipline. Its contribution is to integrate these traditions around a sharper claim: in AI-enabled delivery, intent is no longer just an input to requirements; it is the principal control surface for solution generation.

The Athlete Analogy: Intent, Action, and Hidden Mechanics:
Athletic performance offers a useful analogy. A skier carving a turn, a swimmer entering a stroke, a sprinter leaving the blocks, or a tennis player serving does not consciously manage every neurological signal, muscle contraction, joint angle, and biomechanical adjustment in real time. Skilled movement depends on training, feedback, embodied learning, pattern recognition, and automaticity. Research on motor learning has found that external focus—attention directed toward the intended effect of movement—can enhance performance and learning compared with excessive internal focus on body mechanics (Wulf and Lewthwaite, 2016). The analogy should not be overstated. Athletes still require coaching, technique, conditioning, constraints, practice, and correction. Poor mechanics can cause failure or injury. Yet during performance, the athlete’s conscious attention is often better directed toward the intended action and outcome than toward every hidden mechanism of execution.

Similarly, in AI-enabled solution delivery, the business should not begin by over-specifying every technical mechanism. It should begin by expressing the intended capability and operational result. A business user should not have to decide prematurely whether the solution requires a relational database, event-driven architecture, a workflow engine, a vector store, an API gateway, a robotic automation script, or a large language model. Those options matter, but they should emerge from the intent, constraints, and context. The athlete analogy also highlights the role of feedback. Intent alone is insufficient. The athlete acts, senses, adjusts, and improves. Likewise, intentionality-based solution design requires iterative validation: prototypes, simulations, user testing, architecture review, data assessment, security analysis, and benefit measurement. The focus on intent does not eliminate mechanics; it prevents mechanics from hijacking purpose.

Practical Examples:
A customer self-service portal illustrates the distinction. A technical-mechanics-first approach begins with the portal: login, dashboard, forms, notifications, content pages, CRM integration, and case creation. An intentionality-based approach begins differently. The deeper intent may be to reduce call-centre effort by shifting high-volume, low-complexity tasks to assisted digital channels; increase customer confidence by making status, eligibility, and next steps transparent; improve completion rates through clearer guidance; and maintain evidence of consent, identity, and compliance. Once that intent is clear, the solution may still include a portal, but it may also include proactive notifications, decision trees, service design changes, content simplification, call deflection analytics, or assisted agent workflows.

Insurance first-notice-of-loss automation provides a second example. A weak requirement might be “build an online claims intake screen.” The intent is richer: classify claim complexity, identify exceptions, route simple claims for straight-through processing, preserve adjuster attention for high-judgement cases, maintain auditability, and improve claimant transparency. The difference matters. A form captures data; a capability changes operating behaviour. In socio-technical terms, the solution must account for both technical workflow and the human organisation of work (Trist and Bamforth, 1951; Pasmore, 2019).

Consent management and privacy compliance offer a third example. A technical-mechanics-first approach might focus on implementing a cookie banner or consent platform. Intentionality-based design asks what lawful, trustworthy, and traceable consent means across the operating model. The intent may include preference capture, consent withdrawal, downstream synchronisation with marketing and service systems, evidence retention, jurisdictional compliance, and customer trust. The system is therefore not merely a user interface component; it is a compliance and trust capability.

Vendor selection is another case. Organisations often evaluate platforms by feature checklists. However, a long checklist can obscure strategic fit. Intentionality-based selection asks which platform best enables future operating capability, adaptability, integration, governance, cost control, and benefits realisation. A platform that satisfies many features but undermines the target operating model is inferior to one that supports the intended capability architecture.

Finally, consider AI-assisted backlog generation. A vague prompt such as “create user stories for a customer portal” will likely produce generic stories. A precise intent statement—identifying user segments, desired behavioural outcomes, business rules, policy constraints, service-level targets, data dependencies, accessibility standards, compliance evidence, and benefit measures—can produce stronger epics, acceptance criteria, test scenarios, and governance checks. The AI is not replacing analysis; it is amplifying the quality of the analysis provided to it.

Intent as a Design Constraint and Governance Asset:
Well-defined intent becomes a traceability anchor. Requirements traceability has long been recognised as a difficult but important problem in systems development because it connects stakeholder needs to specifications, design decisions, tests, and change control (Gotel and Finkelstein, 1994). In intentionality-based design, the traceability chain begins not with a feature but with an intended outcome. A disciplined intent statement can connect: business goal → capability → user outcome → process change → decision requirement → data requirement → functional requirement → non-functional constraint → architecture decision → control → test case → benefit measure. This chain supports governance because it makes design decisions explainable. It also supports change control because proposed changes can be evaluated against the original intent rather than against the inertia of the current design.

Systems thinking reinforces this point. Meadows (1999, 2008) argued that system goals and paradigms are powerful leverage points because they shape system behaviour more deeply than isolated parameters. In enterprise delivery, intent functions as a system goal. If the intent is wrong, local optimisation follows. If the intent is explicit, contested assumptions can be surfaced before they become embedded in software. In AI-enabled delivery, this governance role becomes even more important. AI-generated artefacts may appear coherent while still misrepresenting business rules, omitting constraints, or inventing details. Therefore, intent must be structured, testable, and governable. It should include not only what the solution should do, but what it must not do, what evidence it must preserve, what risks it must control, and how success will be measured.

Risks and Counterarguments:
A balanced account must acknowledge several objections. The first is that technical feasibility cannot be ignored. Some constraints are inherently technical: cybersecurity, latency, data residency, interoperability, accessibility, scalability, disaster recovery, and regulatory compliance. A solution intent that ignores these constraints is not strategic; it is incomplete. The response is that intentionality-based design is not anti-technical. It is a sequencing discipline. Architects, engineers, security specialists, data professionals, and vendors should be involved early, but their role is to test, enrich, constrain, and realise intent rather than prematurely define it. Technical discovery should inform intent, not replace it.

A second objection is that intent can be ambiguous, political, or contested. Different stakeholders may hold conflicting views of success. For example, a self-service capability may be intended by executives to reduce cost, by customers to improve convenience, by compliance teams to preserve audit evidence, and by operations teams to reduce rework. This is not a weakness of intentionality-based design; it is precisely why the approach is needed. Ambiguity exists whether or not it is documented. Intentionality-based design makes that ambiguity visible.

A third objection concerns AI itself. AI-generated outputs can be plausible but wrong, vulnerable to misuse, or misaligned with organisational policies. NIST and OWASP both emphasise that generative AI requires risk management, validation, and security controls rather than blind trust (NIST, 2024; OWASP, 2025). This means intentionality-based design must include human review, validation, testing, red-teaming where appropriate, and traceable acceptance criteria.

A fourth objection is that excessive abstraction can delay delivery. This is valid. Intentionality-based design should not become a philosophical exercise detached from implementation. Its purpose is not to produce perfect abstractions; it is to reduce waste by establishing enough clarity to guide iterative delivery. The best version of the approach combines intent clarity with agile validation: express intent, generate options, test assumptions, refine, and build incrementally.

Implications for Business Analysts, Product Owners, Architects, and Executives:
The rise of AI-enabled delivery changes professional roles. The business analyst becomes more important, not less. If AI can generate drafts of requirements, user stories, process flows, test cases, and prototypes, then the business analyst’s value shifts toward judgement: clarifying intent, detecting ambiguity, structuring decision logic, validating assumptions, maintaining traceability, and ensuring that AI-generated artefacts remain aligned to business value. The business analyst becomes an “intent architect” or “capability interpreter.” This role translates ambiguous desire into structured, testable, governable intent. It requires business architecture fluency, requirements engineering discipline, facilitation skill, domain understanding, systems thinking, and enough technical literacy to understand constraints without being captured by them.

Product owners also benefit. A product backlog should not be a list of disconnected features; it should be an evolving expression of value, behaviour, risk, and learning. User stories are useful when they preserve a relationship between user, need, and outcome, but they become weak when reduced to formatted development tickets (Cohn, 2004). Intentionality-based design strengthens product ownership by giving prioritisation a clearer basis.

Solution architects gain a stronger foundation for design decisions. Architecture can be evaluated against intent: Does this integration pattern support the required operating model? Does this data architecture preserve the evidence needed for compliance? Does this platform support future capability evolution? Does this AI component introduce risks that conflict with the intended governance boundary?

Executives have perhaps the greatest responsibility. They must avoid treating AI adoption as a substitute for strategic clarity. Competitive advantage will not come merely from owning tools that competitors can also buy. It will come from superior clarity about which capabilities matter, which outcomes justify investment, which risks are acceptable, and which measures indicate value.

Conclusion:
Intentionality-based solution design and build restates an old principle for a new era. Requirements should begin with need, purpose, outcome, constraint, and value before moving into technical implementation. Yet the principle is no longer merely a matter of good analysis hygiene. In an AI-enabled delivery environment, it becomes a strategic necessity. As generative AI, low-code platforms, automation tools, and composable architectures make construction faster, the cost of unclear intent rises. Organisations can now produce the wrong artefacts more quickly, more convincingly, and at greater scale. Conversely, organisations that express intent with discipline can use AI to accelerate discovery, prototyping, backlog creation, decision modelling, validation, testing, and governance.

The central claim is therefore strong: as AI reduces the effort required to generate technical artefacts, the bottleneck in solution delivery moves upstream from technical construction to the disciplined articulation of business intent. Technical mechanics are becoming more adaptive, but intent remains a human, strategic, and organisational responsibility.

How Requirementum can Help: 
Requirementum QGR directly aligns with the conclusion of this article: as AI-enabled delivery reduces the effort required to generate technical artefacts, organisations require stronger methods for clarifying business intent, structuring requirements, governing delivery, and validating that solutions remain aligned to measurable outcomes. Requirementum QGR provides expert-guided, AI-enabled advisory services that help organisations move from ambiguous business need to disciplined digital capability by clarifying scope, stakeholders, requirements, risks, assumptions, governance needs, vendor-selection criteria, and implementation readiness. Its services include Requirements & Solution Discovery, AI Readiness & Delivery Governance, Vendor / Platform Selection Readiness, and Implementation Readiness & Recovery, each of which supports the article’s central argument that technology should be guided by well-formed intent rather than premature technical solutioning. In this respect, Requirementum QGR operationalises intentionality-based solution design by helping organisations translate strategy, requirements, and domain expertise into governable, testable, and implementation-ready capability.

REFERENCES: 
AWS (2026) What is generative AI? Amazon Web Services. Available at: AWS generative AI overview.
Beck, K. et al. (2001) Manifesto for Agile Software Development. Available at: https://agilemanifesto.org.
Boehm, B. and Basili, V.R. (2001) ‘Software defect reduction top 10 list’, Computer, 34(1), pp. 135–137.
Brambilla, M., Cabot, J. and Wimmer, M. (2017) Model-Driven Software Engineering in Practice. 2nd edn. Cham: Springer.
Brown, T. (2008) ‘Design thinking’, Harvard Business Review, 86(6), pp. 84–92.
Cohn, M. (2004) User Stories Applied: For Agile Software Development. Boston: Addison-Wesley.
Cui, K.Z., Demirer, M., Jaffe, S., Musolff, L., Peng, S. and Salz, T. (2025) The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. MIT.
Evans, E. (2003) Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley.
Fowler, M. (2020) Domain-Driven Design. Available at: MartinFowler.com.
Gotel, O.C.Z. and Finkelstein, A.C.W. (1994) ‘An analysis of the requirements traceability problem’, Proceedings of the First International Conference on Requirements Engineering, pp. 94–101.
IIBA (2015) A Guide to the Business Analysis Body of Knowledge (BABOK Guide). Version 3. Toronto: International Institute of Business Analysis.
ISO/IEC/IEEE (2018) ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. Geneva: ISO.
Liu, Y. et al. (2024) ‘An empirical study on low-code programming using model-driven techniques’, arXiv preprint.
McKinsey & Company (2025) The State of AI: Global Survey 2025. New York: McKinsey & Company.
Meadows, D.H. (1999) Leverage Points: Places to Intervene in a System. Hartland, VT: The Sustainability Institute.
Meadows, D.H. (2008) Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing.
NIST (2024) Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Gaithersburg, MD: National Institute of Standards and Technology.
OWASP (2025) OWASP Top 10 for Large Language Model Applications. Open Worldwide Application Security Project.
Pasmore, W. (2019) ‘Sociotechnical systems design and organisation change’, Journal of Change Management, 19(2), pp. 67–85.
Peng, S. et al. (2023) ‘The impact of AI on developer productivity: Evidence from GitHub Copilot’, arXiv preprint.
Pohl, K. (2010) Requirements Engineering: Fundamentals, Principles, and Techniques. Berlin: Springer.
Sahoo, P. et al. (2024) ‘A systematic survey of prompt engineering in large language models: Techniques and applications’, arXiv preprint. The Open Group (2022) The TOGAF Standard, 10th Edition. San Francisco: The Open Group.
Trist, E.L. and Bamforth, K.W. (1951) ‘Some social and psychological consequences of the longwall method of coal-getting’, Human Relations, 4(1), pp. 3–38.
Wiegers, K. and Beatty, J. (2013) Software Requirements. 3rd edn. Redmond, WA: Microsoft Press.
Wulf, G. and Lewthwaite, R. (2016) ‘Optimizing performance through intrinsic motivation and attention for learning: The OPTIMAL theory of motor learning’, Psychonomic Bulletin & Review, 23, pp. 1382–1414.
‍