CoreX

An introduction
to the universal process
and blueprint for the design
of software applications

Craig Errey

ii
 Copyright

Copyright © 2021 by Craig Errey

All rights reserved. This book or any portion thereof may not be reproduced or used in any manner
whatsoever without the express written permission of the copyright holder except for the use of brief
quotations in a book review.

Front cover image: The Sea Cliff Bridge, By Silas Baisch, https://unsplash.com/photos/-3vU48G830k

First Edition: June 2021

Sydney, Australia

www.solvegroup.com.au

iii
 About the author
The first thing you need to know about Craig is that he’s an organisational psychologist. Yep, you
read that right.
Now, you’re probably wondering: “What on earth would a psych know about software engineering?”
Frankly, nothing – if you think that software engineering is primarily concerned with planning and
writing code.
But it’s not. It’s about people, first and foremost. It’s about designing tools to help people get things
done. It’s about amplifying human capability, ingenuity and creativity. And that has to start with
understanding people, how they think, how they work, what helps them be their best, and what
doesn’t. That’s something that Craig, as a psychologist, knows quite a lot about.
One of Craig’s key strengths is quickly figuring out the root cause of problems in how people go about
their work. So, when Craig talks about ‘requirements’, he’s actually talking about work requirements,
not software requirements – those come later.
For nearly 30 years, Craig has worked on requirements and UI design for many of the largest
organisations in Australia including Commonwealth Bank, Telstra, and the NSW government. These
apps are used by millions of people, both staff and customers, every day. He’s seen a lot of IT people
struggle to deliver the best they can with what they know and the very little they’re given.
The journey to CoreX started around 20 years ago, but it was only in the last few years that he truly
understood the root cause of the stubbornly low success rate of enterprise apps. And it wasn’t a
people problem. Like almost any other work-related problem, it was the environment they’re in, and
tools they use, that made it hard to be successful.
Having great processes and great tools allows people to do great things – and through CoreX, that’s
Craig’s focus. CoreX is about lifting everyone in IT so they can all design brilliant applications that
make a positive difference to the working lives of people.
Craig reckons that when you spend half your waking life at work, you’d really want to be doing your
best whether you’re making the tools or using the tools.
Having also been involved in many IT projects over the years, with far too many of them not working
out as expected, I’ve never seen anything quite like CoreX. I hope you find it as compelling as I do.
Eric Imbs, Sydney, 2021

iv
Table of contents
1 CoreX in a nutshell ..................................................................................................................... 1
2 CoreX solves the requirements problem .................................................................................... 2
3 The CoreX process: Requirements gathering, Visual requirements modelling, UI design ........ 4
4 CoreX starts with work requirements ......................................................................................... 4
5 The fundamental elements of software applications .................................................................. 6
6 The five requirements models, with four being visual ................................................................ 6
The domain model ........................................................................................................... 7
The workflow model ......................................................................................................... 7
The entity model............................................................................................................... 8
Business rules model ....................................................................................................... 9
Conceptual user interface design .................................................................................. 10
7 Connecting requirements gathering to requirements models to the UI and to development ... 11
8 Key principles in CoreX ............................................................................................................ 12
Key principle 1: Define the problem to be solved before designing the solution ........... 12
Key principle 2: Human-centred design is not about giving people what they say they
want ................................................................................................................................ 12
Key principle 3: Start with the future state, rather than the current state, to stop legacy
thinking ........................................................................................................................... 13
Key principle 4: Non-functional requirements must be converted to functional
requirements .................................................................................................................. 13
9 Key techniques in CoreX .......................................................................................................... 13
Key technique 1: Progressive decomposition with numerical constraints ..................... 13
Key technique 2: Near total separation of concerns across the models........................ 13
Key technique 3: Co-design with preparation ................................................................ 14
Key technique 4: Create the requirements models in two phases: conceptual then
detailed ........................................................................................................................... 14
10 Using CoreX ............................................................................................................................. 15
Real digital transformation: connect your application to change and strategy .............. 15
Buy or build? Actually, you can leave your options open .............................................. 15
Combine the best of Agile and Waterfall to build enterprise applications...................... 16
11 Who is CoreX for? .................................................................................................................... 16

v
CoreX: An introduction to the universal process and blueprint for the design of software applications

1 CoreX in a nutshell
CoreX is the universal process and blueprint for the design of software applications. It is to software
engineering what architecture is to civil engineering. It creates a simple, precise, and shared
understanding between business and IT. It completely replaces ambiguous and incomplete written
requirements with a precise and comprehensive set of visual models to specify the work requirements
for the application that combine the typically separate business, user, functional and non-functional
requirements.
There are three steps in CoreX: Requirements gathering, Visual requirements modelling, and User
interface design. Requirements gathering defines the organisational and work performance problems
to solve. Job analysis and design (JAD), from organisational psychology, is the primary method to
define the work people need to do with the app. This step collects all the information necessary to
create the visual requirements models.
Visual requirements modelling defines the solution to the work performance problems through the
design and behaviour of the application. This step converts the written requirements into a set of five
visual models by extracting the nouns, adjectives, verbs and adverbs from JAD. The five models are
the domain model, workflow model, entity model, business rules model and the conceptual user
interface design and collectively represent the work requirements.
The final step, user interface design, extends the conceptual UI design created during requirements
modelling to complete the design blueprint for the application. The user interface presents the nouns,
adjectives, verbs and adverbs according to the capabilities of the target platform to support people
getting their job done. A classic GUI uses the noun-verb approach, while speech and similar
command-first UIs use a verb-noun approach. CoreX can be used with any interface type including
speech, touch, interactive voice response (IVR) and classic graphical user interfaces (GUIs).
CoreX works whether you buy or build, and you can use it with Agile, DevOps, or any other
development methodology, platform, technology or framework. Keep the CoreX visual models at the
business level to test the market for both buy and build solutions. If you decide to build, continue the
progressive decomposition using the models as the framework for detailed technical software
requirements. Then in development, the nouns and adjectives correspond to the database, while the
verbs and adverbs correspond to the functionality and code of the application. The business rules
mediate the relationship between data, functionality, and the user interface. CoreX creates a clear line
of sight between requirements, visual modelling, user interface design and development.

Craig Errey Page 1

2 CoreX solves the requirements problem
For the last 25 years, the average success rate for enterprise applications that launch on time, on
budget and work as expected is a low, persistent 29 percent 1.

Another 22 percent of projects fail and are scrapped. The remaining 49 percent are late and over
budget, iteratively and slowly lurching their way towards the original goal. The result is an
astronomical accumulation of technical debt from:
• wasted time and rework
• endless variations and enhancements
• huge cost blow-outs
• loss of productivity from a poor user experience
• and scrapped software.

Can you imagine if buildings, tunnels, vehicles, chemical plants, or electronic devices had the same
low success rate?
Software is at the core of operations for just about every business, but it’s not having the business
improvement impact it should and people’s work performance isn’t getting better. And most apps will
struggle to ever pay themselves back.
The 2020 forecast in IT expenditure for enterprise software and IT services 2 means that the global
cost of the IT failure rate is $275 billion of projects scrapped and $690 billion being late and over
budget. That’s a minimum technical debt, every year, of $275 billion, and probably at least $600 billion
if we then include half of the challenged amount!

1
https://www.standishgroup.com
2
https://www.gartner.com

Craig Errey Page 2

The good news is that the root cause is clear. And the problem is not with developers, software
vendors, IT consultants or your own team. The root cause is that software engineering is the only one
of the five major engineering disciplines that does not have a universal process and blueprint for its
products.

In the absence of a blueprint, we only have written requirements to rely on to describe the apps we
need. Written requirements are inherently ambiguous, incomplete and open to interpretation.
Would you ever describe a new skyscraper, compound, engine or device in words, without a complete
and accurate visual blueprint? Never! And no-one ever said a thousand words is better than a picture.
Yet businesses continue to commission multi-million-dollar enterprise applications, critical to their
operations, without such a blueprint. 61% of respondents to a survey on requirements methods
reported using natural language to express requirements3.
That low success rate is simply unacceptable in any other engineering discipline. This is what we call
the requirements problem, otherwise known as, ‘That's not what I asked for’.

3
Kassab, M., Neill, C. & Laplante, P. State of practice in requirements engineering: contemporary data. Innovations Syst Softw
Eng 10, 235–241 (2014). https://doi.org/10.1007/s11334-014-0232-4

Craig Errey Page 3

3 The CoreX process: Requirements
gathering, Visual requirements
modelling, UI design

There are three main steps in CoreX that create the design blueprint for software applications:
1. Requirements gathering focuses primarily on understanding the performance problem to
be solved in the workplace, and the best ways to solve it, including supporting change
management initiatives
2. Visual requirements modelling converts the written requirements information into a set of
visual requirements models to clearly and unambiguously specify the application’s design
and behaviour to solve the problem.
3. User interface design completes design blueprint for the application by designing all user
interfaces for the application.
CoreX is a fusion of many different ideas, principles and techniques from psychology, software
engineering, UI design and other related disciplines. It completely replaces the need for written
requirements with rapidly created visual models based on job analysis and design from organisational
psychology. Let’s go into the fundamentals of how CoreX works, starting with the new concept of
work requirements.

4 CoreX starts with work requirements

The purpose of enterprise apps is to help people get their job done quickly, easily, the right way, and,
hopefully, with enjoyment. Therefore, when I talk about requirements, I don’t mean traditional
software requirements, I mean work requirements. Work requirements is a new type of
requirement that include both what the application must do and how it must work to support people’s
jobs and improve productivity and other business outcomes in the business case. This distinction is
important because software requirements tend to be very specific, granular and often focussed on the
functionality of the application. They’re generally not strictly about exactly how people will use the
functionality to get their work done.

Craig Errey Page 4

In CoreX, the main requirements gathering technique is job analysis and design (JAD) from
organisational psychology. It underpins the majority of organisational psychology practices4, 5
including organisation design, workforce planning, selection, training, performance management,
remuneration and succession planning. It's a highly structured and very fast process to define the key
result areas (KRAs), key performance indicators (KPIs) and the key tasks (KTs) of a job, along with
the competencies (knowledge, skills, abilities and other attributes) people need perform well in the
job.
Visual requirements modelling converts the written job descriptions from JAD into a set of visual
models to describe both what and how the application will represent people’s work. This way, the
models integrate the typically separate6 business, user, functional and non-functional requirements.
Business requirements are reflected in the job KPIs and targets, such as productivity, waste, sales,
and profit, aggregated across groups of people holding the same job, and then hierarchically grouped
to senior levels in the organisations and ultimately to the business case. User requirements are
defined by the KRAs and KTs that people need to do. Functional requirements are also reflected in
the KTs, but requirements modelling goes into much greater detail to describe exactly how the task
will be implemented to help people accomplish their tasks in the right way. Finally, in CoreX, the most
important non-functional requirement is usability, which is the extent to which the application helps
people get their work done efficiently, effectively and with satisfaction. The user interface is a core
requirements model and, when combined with the other models, specifies the exact design and
behaviour of the application needed to present the work to be done and create a fast, easy and
relevant digital workspace for people.
Basing the models on the job is also the means to control change and uncertainty in requirements.
These are typically caused by the ambiguity and incompleteness of written requirements as well as
not using an appropriate and independent frame of reference to anchor decisions. Now, when we
evaluate requirements, we use the job as a boundary:
• All requirements that map to the job are in scope.
• All requirements that do not map to the job are not in scope.
• Any part of the job that does not have corresponding requirements means that people can’t
do that part of their job in the app.
• Any requirement that is changed means the job may also have changed in some way.
- If the job has changed, then the change is accepted and the job description is
updated, too.
- If the job hasn’t changed, then the requirement should generally be left as it was.
• Any new requirement you want to add is cross checked against the job to decide if it’s in or
out of scope.
• Any requirement that is descoped is checked against the job because it means that some
people can no longer do that part of their job in the app.
Scope management is now well informed with clear consequences for the decisions made. It stops
continuous change, scope creep, and descoping an app so much that it ends up having virtually no
relevance for people. It doesn’t mean we can’t make changes or descope things, it means the effects
are clear and obvious. If a requirement must be descoped, it’s better to descope the entire
surrounding KRA rather than have people partially use the new app as well as the old app or, at
worst, use Excel or other manual processes as a workaround.
The visually modelled work requirements do the same thing as architectural plans do for the built
environment – understanding how people will use what you’re going to build for them. Those plans

4
Muchinsky, Paul M. Psychology Applied to Work: An Introduction to Industrial and Organizational Psychology. 8th Edition.
Belmont, CA: Thomson/Wadsworth, 2006
5
Conte, J. M. and Landy, F. Work in the 21st Century: An Introduction to Industrial and Organizational Psychology, 6th Edition.
New York : Wiley, 2018
6
Software Requirements (Developer Best Practices) 3rd Ed. Wiegers, K. E., Beatty, J. (2013). Microsoft Press. (chapter 1)

Craig Errey Page 5

are also the framework for technical requirements including structural engineering, hydraulics,
electrical and lighting that are all based directly on the same plans. The CoreX visual models are the
framework for the technical requirements that come later, if your preference is to build your solution.

5 The fundamental elements of software

applications
When we visually model the requirements: what exactly are we modelling? Typical concepts such as
the code and database, or states and sequences from UML, or software architecture concepts such
as the Model–View–Controller, aren’t appropriate due to their complexity and need for specialised
skills and knowledge. Also, they’re only relevant if you’re developing your solution, and not if you
prefer a commercial-off-the-shelf solution.
Requirements gathering yields a large quantity of information, much of it written, including the job
descriptions from JAD. It turns out that the fundamental elements being visually modelled are,
ironically, extracted from the written language and are familiar to everyone: nouns, adjectives, verbs
and adverbs (NAVAs).
The nouns are the data, people, and things being represented in the application and the adjectives
are the attributes of a noun (i.e., entity) and ensure people can tell various instances of nouns apart.
Verbs are the actions that can be performed with or to a noun and its adjectives. Adverbs modify
verbs, adjectives and other adverbs and are used to determine how, in what way, when, where and to
what extent the verb, adjective and other adverb is carried out. They add fine control to performing the
verbs. When extracting the elements, it is essential to use a controlled vocabulary to ensure each
word means the same thing wherever it appears. No synonyms should ever be used.
These four fundamental elements connect the entire software development lifecycle of requirements
gathering, visual requirements modelling, user interface design and software development. If your
preference is to buy, then keep the visual requirements models at the business and work level of
detail and don’t go technical.

6 The five requirements models, with four

being visual
Visual requirements modelling converts and organises the written information into the five
requirements models: the domain model, workflow model, entity model, business rules model and the
conceptual user interface design.
The models specifically organise the fundamental elements. The nouns and adjectives are
represented in the entity model, while the verbs and adverbs (paired with nouns and adjectives) are
represented in the workflow model. The business rules, just like the concept of grammar in language,
determine how the elements are used, that is, in simple terms, which verbs and adverbs can operate
on which nouns and adjectives by which people. The user interface presents the nouns, adjectives,
verbs and adverbs. The noun–verb paradigm is used in modern graphical user interfaces and the
verb–noun paradigm is used in speech and command-based UIs. Finally, in development, the nouns
and adjectives broadly correspond to the database and the verbs and adverbs correspond to the
functionality (i.e., the code) of the application.
Just five models, using conventional visual representations and proper separation of concerns, are
needed to represent the work requirements that precisely and comprehensively specify the design
and behaviour of the application. This makes CoreX far simpler, easier and faster for non-technical
people than using approaches like the Unified Modelling Language (UML). UML comprises 14
diagrams7 that are designed for building software and, as such, is not appropriate for situations where

7
https://www.omg.org/spec/UML/

Craig Errey Page 6

the preference is to buy. Other challenges with UML is that the choice of which models to use is at the
discretion of the BA and that there is overlap in a number of the diagrams which, together, can lead to
inconsistency if the models get out of sync and incompleteness if some models aren’t selected.
The first four models in CoreX are user interface (UI) independent, while the fifth – the conceptual UI
design – reflects the nature and capabilities of the target platform. This means the same foundation is
used with different UI platforms including speech, touch, interactive voice response (IVR) and classic
graphical user interfaces (GUIs) – resulting in a consistent experience across each.
When the visual models have been completed, you can use the more detailed and complex diagrams
from UML, or similar, if required, if you choose to build. The CoreX models are the framework for the
detailed technical requirements, just like an architect’s plan for a building is the framework for the
detailed structural, hydraulic and other engineering specifications.

The domain model

CoreX starts with the domain model. It summarises all the key information collected during
requirements gathering including the key concepts, disciplines, processes, practices, major functional
areas, workflows, activities and decisions of the work being done and its context.
The domain model typically uses a mind map or similar conceptual relationship diagram. You can use
both types of diagram, and you can create as many as you need depending on the breadth and
complexity of the domain. It also supports scope boundaries where sections of the model can be
broadly marked as in and out of scope.
Understanding the domain is essential to design a usable and intuitive experience for people. This
happens when the application is familiar to people because it accurately reflects the core concepts
they know from the domain and their work in the user interface through, for example, the words in
navigation, showing a workflow or presenting relevant data. When people can recognise the familiar
domain concepts, it activates people’s knowledge and skills about their job and this makes for a user-
friendly experience.
The example uses the mind mapping technique and shows how the model starts with the Level 1
concepts, shown at the left, and is progressively decomposed into greater detail as we move to the
right. Generally, the models are constrained to have three to five concepts at Levels 1 and 2, with 10
– 15 concepts at Level 3 and deeper. Content from here, along with other requirements information,
will be transferred to remaining requirements models.

The workflow model

The workflow is the backbone of the application. It is a diagrammatic representation of the KRAs, KTs
and decisions in people’s jobs. It uses standard flowchart notation, but with a reduced set of symbols
compared to, say, Business Process Model and Notation 8. The verbs and adverbs, paired with nouns
and adjectives, are represented in the task / process symbol and the decision symbol handles either
user decisions or testing of business rules to determine branching. However, other business rules

8
https://www.omg.org/spec/BPMN/

Craig Errey Page 7

such as constraints, roles and permissions, or swim lanes are not used in the workflow model. These,
and the full set of BPMN concepts are either handled at much deeper levels or in the business rules
model. This makes the workflow model simpler to create, read and understand.
The workflow model should represent best practice in how people do their work to meet individual and
organisational goals and key performance indicators (KPIs). It starts at a high level, containing three
to eight KRAs or KTs and generally one or two key user decisions. The workflow is progressively
decomposed to deeper levels of detail.
The example shows a level
1 workflow on the left,
generally representing the
main KTs of a job. The
second KTs has been
decomposed, as shown in
Level 2, and then the
second KT on the right
branch has been further
decomposed. Generally the
workflow model has thee to
eight KTs and one or two
decisions at level 1, and
then 10 – 15 KTs and 3 – 5
decisions at Level 2 and
deeper.
The workflow is
decomposed through to deeper levels of detail and shows user triggers for activities, task sequences,
data being operated on and business rules tested to check for error conditions and control flow.
Eventually, the KTs are decomposed into system tasks – comprising domain, application and
interaction tasks – that correspond to executable code blocks that operate on the paired entities:
• Domain tasks represent functionality specific to a work domain, such as video processing
effect.
• Application tasks are generic operations, such as delete, copy and paste.
• Interaction tasks appear in the UI, such as drag and drop.
CoreX uses a controlled set of around seventy application and interaction tasks that are sufficient to
support virtually any enterprise application.

The entity model

The entity model is representation of the concepts (i.e. people, data and things) and their relationship
with one another similar to a conceptual / logical data model. It also uses progressive decomposition
and starts with a Level 1 representation of the core three to eight entities that are most important in
the work or job. Entities can also be added and related to others at lower levels even if they are not
contained within a parent entity.
The entity model uses the basic relationships of association, composition, containment and
inheritance. However, all other constraints and business rules, such as cardinality, are handled in the
business rules model. In CoreX entity modelling, all entities are plural and all relationships are many-
to-many. This makes the entity model simple to create and read, and allows for significantly easier
future scalability and flexibility when manifested in the underlying database. The entity model is
progressively decomposed until it transitions to a classic entity-relationship diagram or other data
modelling approach of your choice.

Craig Errey Page 8

 The following example
shows an entity model
at Level 1 comprising
four entities. Entity 3 is
then decomposed to
four Level 2 entities.
Note there are two
additional entities,
Entity 5 and Entity 6,
shown below this
expansion. These
entities are not
contained within
higher-level entities as
would occur in the
workflow model.

Business rules model

The business rules model is not visual in nature
as it comprises the written statements, algorithms,
regular expressions, and similar, that describe an
organisation’s policies, processes, procedures
and rules, as well as those imposed from the
context in which the business operates, such as
legislative requirements. The business rules
model cross-binds entities, tasks and the UI to
ensure the correct operations are performed on
the correct data at the correct time by the correct
roles.
This model ensures that:
• information entered and used within the
application is compliant
• people’s activities are compliant
• the right people do the right activities, the right way, at the right time.
The model captures virtually all rules for the application in one location so that it:
• creates a clear understanding of how the rules interact with one another and an ability to
detect unexpected and unwanted interactions
• allows the flexibility to change the rules at run time, especially those that would typically be
found hard-coded in the database
• stops rules being embedded in the UI or down deep in the code, never to be found – except
when things go wrong.
There are four categories of rules:
• data and relationships,
• workflows and tasks,
• roles and permissions, and,
• events and messages.

Craig Errey Page 9

Data and relationship rules are based on the fundamentals of frequency, uniqueness, value, and
mandatoriness conditions. The higher level rules are definition, derivation and validation, followed by
entity occurrence rules that constrain cardinality, and then relationship rules allowing up to quadruple
tuples. Workflow and task rules include sequence (expressed in the workflow), and tasks triggered by
some expression on data and its result.). Roles and permissions constrain the data and tasks that can
be performed by specific roles. Finally, events and messages include system, user interface and other
application messaging.
The business rules model is compliant with Object Role Modelling (ORM)9, the Unified Modelling
Language (UML)10, and Business Process Model and Notation (BPMN)11, meaning that it can specify
the full range of business rules any organisation would need.

Conceptual user interface design

The fifth and final requirements
model is the conceptual UI
design. It brings the requirements
to life, doing the same job as the
artist’s impression of the plans for
a new building. The artist’s
impression is used to confirm the
building concept with the owner
and other decision makers before
detailed design is carried out.
When the concept design signed
off, the building that’s ultimately
delivered will be an extremely
close match, barring any
unforeseen circumstances given
the extent of architecture and
engineering that went into the
initial designs – something that
doesn’t often happen in IT.
The conceptual UI design usually comprises a number of key workbenches that give people an
overview of their past, present and future work, along with a number of detailed user interfaces for key
workflows. These can be usability tested to confirm performance improvements before continuing into
the detail in Step 3 of CoreX: User interface design.
Detailed user interface design is covered in a separate step because UI design is a rich and complex
activity with many different outputs, especially for large and/or high risk apps. The separation also
allows for people who only want to do UI design and skip requirements modelling. In that situation,
you would still create an initial conceptual UI design, confirm it’s working as expected through
usability testing, and then continue with detailed design.
If you’re confident in the ability of your development team, they can use the conceptual UI design as a
template or pattern for the rest of the application’s UI, creating it as they develop the solution.

9
https://en.wikipedia.org/wiki/Object-role_modeling
10
https://www.omg.org/spec/UML/
11
https://www.omg.org/spec/BPMN/

Craig Errey Page 10

7 Connecting requirements gathering to
requirements models to the UI and to
development
The following diagram shows how the fundamental elements (NAVAs) are extracted from written and
represented in the workflow model, entity model, business rules model and conceptual user interface
design:

In this diagram:
• The noun and adjectives from the written requirements are represented in the entity model
(blue lines). They are then presented in the graphical user interface as tables of data, or
forms showing a single instance of a record (red lines).
• The verbs and adverbs (green lines), paired with nouns and adjectives are represented in the
workflow model. They are presented in GUI as buttons, links and other command widgets.

Craig Errey Page 11

 • The business rules are represented in the business rules model and manifest in the user
interface by constraining who can do which task on which data.

If your preference is to build, the

requirements models also directly
align with the Model–View–
Controller (MVC)12 application
architecture:
• The application Model
generally corresponds to
the entity model.
• The Controller
corresponds to the
combination of the
workflow model and the
business rules model.
• The interaction View
corresponds to the user
interface.

8 Key principles in CoreX

CoreX works, in part, because you need to you think differently about the purpose and nature of
requirements and the business applications selected or developed from them. The following are the
most important techniques and principles from CoreX.

Key principle 1: Define the problem to be solved

before designing the solution
If the application doesn’t solve a problem, then why is it being bought or built? How would you tell that
anything changed? If nothing changes, you’re probably better off not doing anything and diverting the
funds and time elsewhere.
Understanding the problem means knowing what to do more of, less of or differently in the workplace
to achieve an outcome. CoreX treats the application as a means to solve organisational performance
problem within a broader change management program. The design and behaviour of the application
is used to reinforce new ways of working and ensure that change sticks.

Key principle 2: Human-centred design is not about

giving people what they say they want
Human-centred design usually means asking people what they want and then designing a solution
that gives them what they asked for. However, even people who are doing the same job will do things
differently. So who do we ask? Have we asked the person who’s best at the job? Are they doing what
they should be doing?
Job analysis and design is processes that arrives at an independent, agreed statement of what
people should be doing. The approach supports human-centred design by helping people get their
work done, quickly, easily and the right way, because that’s what they really need when they’re at
work.

12
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Craig Errey Page 12

 Key principle 3: Start with the future state, rather
than the current state, to stop legacy thinking
Too often, people spend a lot of time documenting the current state before designing the future state.
This usually means that the future state ends up being a variation of the current state, rather than
being used as an opportunity to rethink everything about how works gets done. The purpose of the
new app should be to make significant improvements – so why not just start there, instead.

Key principle 4: Non-functional requirements must

be converted to functional requirements
Work performance and usability requirements are typically treated as non-functional requirements
even though they’re essential to the application’s success. However, being non-functional, they
generally don’t make their way into the functional requirements that the development team or vendor
is held accountable for delivering – despite being the primary reason the applications are often
commissioned. CoreX coverts these critical and fundamental non-functional success factors into core
functional requirements that can be validated before major decisions are made:
1. Key performance indicators to define the required business and human performance and
the business case
2. Best practice work and activity to help people get their work done quickly, correctly and
consistently embedded in the workflow
3. User experience to make the application fast, relevant and easy through the user interface.

9 Key techniques in CoreX

Key technique 1: Progressive decomposition with

numerical constraints
Progressive decomposition is the most important technique in visual requirements modelling. It
ensures the modelling process starts at a simple, high-level representation because the number of
concepts at each level is numerically constrained to stop people diving into the detail too quickly
This means that Level 1 of the domain, workflow and entity models have, on average, three to eight
concepts. At Level 2, each of those concepts is decomposed to a further three to eight concepts. At
lower levels, the number of concepts can increase, but not excessively.
The benefit is that the simpler higher-level models group concepts logically and consistently so they
can be easily moved across, up and down the levels, as well as new ones added or existing ones
removed, without affecting the overall conceptual integrity of the solution. This affords significantly
greater scalability and flexibility in the future.

Key technique 2: Near total separation of concerns

across the models
Each requirements model does one thing only meaning that all related requirements are grouped and
handled in their respective models. This results in simpler, more understandable and more
comprehensive representations. The separation means there is no need to translate from one model
to another, or have to synchronise overlapping content across different but related models.
The most important effect of the separation is that virtually all business rules are contained within the
business rules model. Conceptually and practically, the entity and workflow models are, for the most

Craig Errey Page 13

part, unconstrained because the business rules are treated as a run-time decision, rather than being
hard-coded into the application. Hard-coded rules, especially in the database, are much harder and
costlier to change after the event.

Key technique 3: Co-design with preparation

Co-design workshops are the preferred method for creating the visual requirements models. Through
the workshops, you can meaningfully involve all relevant people from across the business, such as
the project owner, operational managers, SMEs, BAs, developers and, most importantly, the staff
and/or customers who will use the application. However, you can’t just run the workshop allowing
anything to emerge and be documented as finalised.
Instead, you, with your expertise in business analysis and JAD, need to create the models to around
Level 2 in advance of running the workshops. The purpose is not present them to the group and ask
them to review and sign them off, or even to deliberately influence the group. As the facilitator, you’ll
help the group to create the models from scratch, one after the other. You’ll primarily use (and
enforce) progressive decomposition and numerical constraints to stop the people getting stuck in the
details. The detail does matter, it just comes later in the process.
You’ll start with the domain model, followed by the workflow model, entity model and the UI. As the
workshop facilitator, you’ll take an active role in co-designing each of the models, questioning and
challenging people, rather than just modelling what people say. The problems you’ll stop are:
• a focus on how things are done now, instead of how things could be
• challenges in thinking about how things could be different, at all
• group think because most of the people have the same experience and will fall back on it
• diving into the detail and losing sight of the forest for the trees.

During the workshop, you can use your models to stimulate engagement if the process stalls, or to
use them as a comparison if the group comes up with something different. Because it’s sometimes
hard for people to imagine a different way of doing things when they’ve done it for so long, the
alternative approach can be compared directly with what they modelled. Your model may be adopted,
or a hybrid, or even something altogether different. If the models are substantially the same, and you
didn’t unduly influence the group, then there’s increased confidence that the workshop models are
valid and reliable.
Because co-design is fast, visual and work relevant, people can participate with confidence. They’ll all
have the same shared understanding because they’re all looking at the same visual models rather
than interpreting the written words. That is, one entity is connected to the next in exactly the manner
shown, and not in a different way. Specific tasks are sequenced in the exact order shown, not some
other tasks or order. The UI is laid out exactly as shown, buttons and fields aren’t imagined to be
somewhere else.

Key technique 4: Create the requirements models

in two phases: conceptual then detailed
The progressive decomposition technique has another advantage in addition to controlling complexity.
It allows us to split requirements modelling and UI design into two phases: conceptual design followed
by detailed design.
The first phase, the conceptual design, includes all five requirements models to, generally, Level 2. It
does the same job as the artist’s sketch of a new building. It’s enough to say, ‘Yes, that’s exactly what
want’, and enough to usability test it to confirm that it will work for people and deliver on the business
case in terms of productivity and other performance metrics. Once confirmed, you can investigate the
options of buying or building the app and doing more detailed modelling as needed. If it doesn’t meet
expectations, then you can make other decisions such as creating an alternative design or even
stopping the project.

Craig Errey Page 14

10 Using CoreX

Real digital transformation: connect your

application to change and strategy
Digital transformation doesn’t mean simply automating your existing manual processes. CoreX’s
ability to connect strategy and KPIs with application design and behaviour – combined with its focus
on starting with a clean slate – helps you imagine different futures for your business and your people.
Start with deciding how to best measure the application’s impact. Are you after more productivity? Or
more time? Or better customer service? Or something else? You can measure these and other KPIs
through the requirements models and UI designs.
These are the common situations where CoreX has the greatest impact:
1. Replace one or more legacy systems, without it being just a like-for-like.
2. Automate manual processes, while ensuring they’re the best way to do things.
3. Design and build a new application that hasn’t been done before.
4. Reinvent a business area and underlying technology platform.
5. Create a unified UI that sits across legacy systems.
6. Standardise and improve the user experience across multiple channels.
In CoreX, the role of enterprise applications in change management and transformation is to embed
and sustain new ways of working to support the surrounding initiatives. This is to avoid the situation
where change management occurs everywhere else except with your business applications, making
people go back to the old ways of working because they use those applications everyday.
CoreX’s approach to designing the application means that when you go through change again in the
future, you can more quickly and easily make the corresponding changes to the application.

Buy or build? Actually, you can leave your options

open
With the current general preference for COTS or SaaS solutions, many businesses don’t investigate
the build option due to the belief that it’s always too risky and too expensive. They believe it’s best to
buy because the vendor’s done all the hard work.
However, instead of having a predetermined preference for buying or building, CoreX lets you
investigate both options, knowing that all vendors you ask to quote clearly understand what you need
and that you can now compare and critically evaluate what could have looked like very different
options.
Using CoreX, you’ll create the five requirements models to at least Level 2, paying particular attention
to the conceptual UI design – the user experience required to give people a fast, easy and relevant
environment to work in. This model is most important, particularly when selecting off-the-shelf
solutions to handle the gap that can exist between the promises made and the reality of go-live
because it’s the primary means of expressing your non-functional requirements as functional,
deliverable requirements. The conceptual design takes between four to eight weeks, even for the
most complex enterprise application – a very small investment considering the cost of acquisition and
the risk of both technical and organisational debt if it doesn’t work out as expected.
When you’ve usability tested your conceptual design, you’ll have baseline performance metrics on
how well people can do their work. You can test the vendors’ proposals and make comparisons rather
than take their word for it. You can evaluate the ‘plain vanilla’ version, as well as the cost and impact
of customisations to bring it up to the required performance levels. And you can also compare the
cost of custom build.

Craig Errey Page 15

Whichever solution you choose, you have the confidence that the vendor can deliver what they’ve
promised, because there’s a clear and precise specification of what you require, and they agreed to
deliver to that specification.

Combine the best of Agile and Waterfall to build

enterprise applications
The ideal approach starts with creating the conceptual design for the entire application in the first one
or two sprints. Once completed and tested it to confirm it delivers on the expected performance gains,
use it segment the application into self-contained functional areas based on, for example, the job
KRAs. Then for each segment you’ll do detailed requirements modelling (domain, workflow, entity,
and business rules) followed by detailed user interface design. The conceptual design is the
foundation that ensures consistency over time, especially in the user interface.

11 Who is CoreX for?

CoreX is most relevant for business analysts, business architects and UI designers, but is also useful
for project managers, developers, subject matter experts, and business managers.
Because CoreX is a systematic, predictable process, blending both Waterfall and Agile approaches,
it’s not likely to appeal to purists who believe Agile and iteration is the only way to handle application
build because they think that you can’t know everything up front, and it’s simply impossible to get
them requirements right, anyway, until you build and show people something.
CoreX is for you if you know you could do a better job as a business architect, business analyst or
UI/UX designer if only the business could clearly articulate what they really want. You’ve had enough
of wasting time on the endless adding, removing and rewriting of requirements. And the ongoing
changes launch to try and make it work like the business wanted it to. What you need, instead, is
precise, visual documentation the whole team can agree on and sign off with confidence.
CoreX is also much more. It’s about fundamentally changing the industry by elevating software
engineering to the same standing as every other engineering discipline. And that will lift up every
business, every project and every person.

Craig Errey Page 16