Continuous development, including continuous RE, requires more intensive, better organized, and better supported involvement of, and interaction with, business stakeholders than ever before. We should move from looking at (business) stakeholder involvement as an occasional activity in a design/development project to a regular activity very much embedded in and integrated with the daily, core business work of end-users and other stakeholders. There are similarities between 'requirements governance' and innovative, community-oriented approaches to 'data governance'. Building on work in collaborative conceptual modelling over the last decade, a perspective is presented in which the creation and maintenance of development artefacts (including requirements documents) is mirrored in a goal-oriented, continuous 'conversation about applications' (or rather, a set of interlinked sub-conversations) between various stakeholders. Gamification of this systematic interaction may add to making it more engaging and more lively. Organization and support of these conversations can add to lowering the threshold for business stakeholders to get on board and stay on board the continuous development cycle.
asking them for feedback on designs and prototypes, in various project phases.
This perspective is beginning to conflict with more radical views that now emerge concerning continuous development. With ‘more radical’ I mean the vision that in principle, it should be possible to intensively and frequently and indeed continuously adapt running systems based on requests and other input from many sources: diverse kinds of stakeholder feedback (bug reports, irritations, complaints, suggestions, but also fresh ideas, and even positive experiences) as well as more classical sources (requirements interviews and workshops, business modeling, co-design) or more indirect information sources (monitoring of system use and user behavior, measured impact on the organization or on other systems; etc.).
I focus here on direct interaction between on the one hand, people in ‘continuous development teams’, i.e. IT stakeholders, and business stakeholders on the other. Such interaction can take many forms, and indeed we should look beyond highly useful but limited traditional forms of communication like requirements sessions and interviews, or one-way, formal change requests. In particular, the vision is to make interaction with stakeholders much more part of their everyday routine; to embed it into daily ‘core business’ work and in the regular use of and communication about applications as part of that. So what we refer to here is direct, purposeful communication, in whatever form, about work/business supporting systems. Very useful information can of course also be acquired through monitoring (automated or not) of users and of running software, but this is not our focus here.
When we speak about ‘interaction with business stakeholders’, the assumption is that this is somehow an organized, or at least explicitly recognized and supported, activity. Since it at least involves collaboration between IT stakeholders and business stakeholders, but very likely also collaboration among business stakeholders (possibly of various backgrounds) and collaboration among IT stakeholders (also of various backgrounds), it seems quite reasonable to characterize all this activity as inherently collaborative.
There is a parallel here with a field closely related to requirements engineering: business modelling in many shapes and forms. Relevant directions include Enterprise Modelling, Conceptual Modelling, Business Analysis, Functional Maintenance, Articulation of Work, and so on. Model-oriented approaches in particular have since long taken the perspective that: Describing the business should preferably be done by the experts, i.e. the business itself, or at least conscientiously build on information directly derived from and checked by the business; Business descriptions can be created for various reasons, including knowledge management, process improvement, LEAN change management, risk assessment, and of course also: requirements engineering; It is not realistic to assume that business modelers, if they are indeed ‘from the business’, can simply use conceptualizations, languages, techniques and tools from IT practice and culture. Unfortunately, IT-oriented people often underestimate how different the perspectives, concerns, ‘mental models’, competences, goals and motivations of business people are from their own. An important difference, however, between business modelling and straight-up RE is that RE more emphatically focuses not on the business as such, but on applications, systems and software, and what the business stakeholders expect and demand of it. In this respect, it is useful to distinguish, at least reflectively if not in practice, between ‘communication about work/organisation’ and ‘communication about applications/systems’. In RE, the two modes of communication are in fact often combined, and business stakeholders are quite capable of both – but on their own terms, and in their own terms. Co-workers and colleagues talk a lot about their work/organisation and how to improve it, and they also talk a lot about the systems they work with. The question is how we can harness this ‘grassroots’, daily communication to gather input for continuous development.
On the other hand, system development, continuous or not, calls
for information that is structured in a way that makes it directly useful
for developers. This is what underlies the creation, over the lasts
decades, of many types of representation, models, and documentation (and
related procedures and practices) like Use Cases, the UML, BPMN,
business rules, scenarios, storyboards, persona’s, domain models, and
so on. So the trick is to somehow get from ‘grass roots’ communication
about work and about applications to effective, well-structured and
goal-oriented information at the right level of abstraction to be useful
for developers (or even as direct input for generative machinery).
A similar vision has indeed recently been voiced in the European
enterprise engineering community [
Over the last fifteen years, as part of a worldwide (though largely uncoordinated) effort to address some of those challenges, I have focused not so much on the many types of representation that exist (and are sometimes even used) in enterprise modelling and requirements engineering, but on understanding and support of the act of creating such representations: the interactive, dialogue-like processes in which people collaboratively ‘generate’ or ‘author’ such descriptions (that indeed can be seen as texts). In the second part of this keynote, I will briefly outline this perspective, in the hope (and belief) that it is relevant to the future of continuous development and continuous requirements engineering. 2
The core of the ‘dialogue perspective on business modelling /
requirements engineering’ is that every piece of documentation
(representation) leading to the creation of a computational (or other) system is
the result of a conceptualization-and-formulation oriented,
collaborative dialogue between stakeholders. The resulting documentation
may be a set of formally required documents that are explicit project
deliverables, but in principle they also include highly informal,
undocumented doodles and coffee table conversations. This also, at the other
end of the spectrum, includes programming code, which is a highly
specialized form of text. Documentation and design/development
representations do after all not appear out of thin air: they are the explicitly
formulated, structured outcomes of people thinking, talking, and
writing down their shared thoughts and creations.
Indeed, it seems that in the age of ‘agile development’, elaborate
documentation (including requirements) as once advocated is now pretty
much ‘out of grace’ [
Such conversations generally share some properties concerning
their nature, purpose and outcome:
They work towards clear, unambiguous conceptualizations
that can be used as input for engineering-style design and
construction
In their gradual structuring, they make increasing use of
concepts (terms, relations; notations) supporting specific
perspectives of engineering activity (e.g. functional decomposition,
process flow, entities and relationships, logic, machine states,
etc.)
They often include the classic ‘divergence – convergence’
pattern known from collaboration engineering [
My work has mostly been in ‘collaborative modelling’, and therefore is mostly based on ‘collaborative dialogues aiming to create a representation in view of some meta-model’. We could say the approach is that of ‘meta-model driven, guided conversations’. This is certainly not the only possible direction, but I will stick with it for now.
The current line of research started out as an attempt [
A good review of the work mentioned as part of a larger
perspective on ‘elicitation of descriptions of work processes’ can be found in
[
Let us return to the outset of this keynote: continuous development, continuous requirements engineering, and stakeholder involvement in a collaborative setting. The fundamental stance that every representation created or used in a development activity is mirrored in a conversation that leads to it, and that a resulting representation –text– may also be input for further conversations, seems a realistic enough position to take. Contrarily, the much more limited idea of purposeful guiding and supporting of ‘conversations for modelling’ (or in the current context: ‘conversations for requirements engineering’) is still merely an explorative direction that may or may not lead to actual practical application. It is the perspective and framework for understanding that I consider the main contribution to the literature, though I keep aspiring to realizing the more practice-oriented ‘guided dialogue’ approach at a practical level.
In section 1, we mentioned the challenge of organizing, and perhaps supporting, and maybe even guiding, the many different types of conversation that can be observed or imagined in practice. To include all of these conversations in an explicit and even governed organizational effort seems highly over-ambitious and unrealistic, if even useful. However, when restricted to a subset of conversations that have clear goals, settings, participants and resulting artefacts (representations, documents), it may yet be interesting and useful to employ the dialogue game approach. I particular, on-line supported and communicated versions of such conversations may be recorded, stored and even monitored or analyzed as an asset complementary to the requirements and design documents they result in and/or are about. Even in informal, volatile contexts like SCRUM/Agile standup conversations, dialogue games in some form could be used to keep the eyes on the ball and help SCRUM masters keep chaos and loss of information at bay.
As voiced in Steven Alters keynote to PoEM 2017 (unfortunately
unpublished), which was a response to [