The problem we address in this paper is the question how to come from initial user wishes to a running system in a straightforward, transparent, modular, and agile manner. In particular, we want to develop a sound underlying theory that grounds engineering approaches that tackle this broad problem (the complete development path for functional requirements, from initial user wishes up to a running system). We develop a theory that crosses the boundaries of several (sub)disciplines, e.g., requirements engineering, machine theory, and (database) systems development.
Section 1 recalls the background notions user story (US), use case (UC) and system sequence diagram (SSD). Section 2 introduces the notion of an information machine (IM): An IM can receive an input and will then produce an output and might change its state. Section 3 depicts a transparent development path for functional requirements, from USs via UCs and SSDs to an IM. Section 4 discusses some aspects of incremental requirements engineering for information systems and then Section 5 treats continuous requirements engineering for information systems.
An information machine is a blueprint, and can have many different implementations, as Section 6 points out. That section also shows the relation with the fundamental ANSI-SPARC three-level architecture, but now extended from databases to information machines in general: USs, UCs and SSDs belong to the external level, an IM belongs to the conceptual level, and implementations of an IM belong to the internal level. We first recall some background notions (but in the words as we want to look at them).
Informally speaking, a user story (US) is a ‘wish’ of a (future) user which the
system should be able to fulfil (see [
Copyright © 2018 for this paper by its authors. Copying permitted for private and academic purposes.
A use case (UC) is a text in natural language that describes the steps of a typical
usage of the system (see [
Initially, use cases can be produced by (future) users of the system, domain experts or (other) staff members, or officials from the organization for which the system has to be built. Initially written use cases might need to be improved (sharpened/enhanced/ detailed/completed) in order to clarify what the system should do exactly (and when). E.g., our sample use case could more clearly distinguish between the two cases whether or not the student was known to the system. A (business) analyst might help to produce sharpened versions of initially written use cases.
A system sequence diagram (SSD) of a use case is a ‘diagram’ that depicts the
interaction between the primary actor (user), the system, and its supporting actors (if
any), including the messages between them (see Chapter 10 of [
User → System: RemoveStudent(<number>); if the student number is known to the system then System → System: remove the student info;
System → User: “Done” else System → User: “Unknown student number” We distinguish 3 types of basic interaction steps (each present in the example above): User → System: Elucidates the inputs the system can expect (input step) System → User: Elucidates the outputs the system should produce (output step) System → System: Elucidates the transitions the system should make (transition step)
For our next development step, we need the notion of an information machine (IM):
An information machine is a 5-tuple (I, O, S, G, T) consisting of:
o a set I (of inputs)
o a set O (of outputs)
o a set S (of states)
o a function G: S x I → O, mapping state-input pairs to the corresponding output
o a function T: S x I → S, mapping state-input pairs to the corresponding next state
The notation f: X → Y used above, indicates that f is a function with X as its domain
and its range being a subset of Y. The notion of information machine is equivalent to
the notion of data machine in [
G is called the output function of the IM and T the transition function of the IM. We could equivalently have chosen for one (combined) function: F: I → (S → S x O) In that case, each input leads to a function assigning a ‘new’ state and an output to an ‘old’ state.
If the system also communicates with supporting actors, say other systems, then we still distinguish three types of basic interaction steps, but with (primary) ‘User’ generalized to ‘Actor’, where an actor can be any other system. Expressed in terms of an information machine: Actor → System: Elucidates the minimally needed set I of inputs of the IM System → Actor: Elucidates the minimally needed set O of outputs and the output function G of the IM System → System: Elucidates the minimally needed set S of states and the transition function T of the IM For instance, our earlier ‘Remove student’ example would lead to inputs of the form RemoveStudent(<number>) and to the outputs “Unknown student number” and ”Done”. Suppose that each state s S contains as a component a student table STUD with an attribute NUMBER, then the condition that a student number n is known to the system translates to n { t(NUMBER) │ t s(STUD) }.
When n { t(NUMBER) │ t s(STUD) } and the input i = RemoveStudent(n), then the output G(s, i) will be “Done” and the student table in the new state T(s, i) will be { t s(STUD) │ t(NUMBER) n}. In the other cases output G(s, i) will be “Unknown student number” and the new state T(s, i) will be s, i.e. stay the same.
Starting from the USs and the UCs via their corresponding SSDs we can define an IM. In a general scheme (where the arrows indicate what is input for what): US1
↓ UC1
↓ SSD1 ↘
US2 . . . . USn ↓ . . . . ↓ UC2 . . . . UCn
↓ . . . . ↓ SSD2 . . . . SSDn ↓ . . . . ↙ Information Machine
User stories: Short texts in natural language, each describing a ‘wish’ of a (future) user which the system should be able to fulfil Use cases: Texts (several sentences) in natural language, each UC describing for one US the steps in a typical usage of the system System sequence diagrams: Diagrams, each depicting for 1 UC the interaction between user, system and its supporting actors, and the messages between them Information Machine: Formal/Conceptual model of the system, including the messages between the system and its environment Information machines in practice are really sophisticated, i.e., supporting a lot of use cases, resulting in very large input sets, output sets, state sets, and with complicated output functions and transition functions. Moreover, in practice such machines are often under continuous development (‘under construction’), just as a city for instance.
Instead of defining and developing such a sophisticated machine in one go (‘big bang’), including ‘all’ functionality that is needed – as might be suggested in Section 3 – since a few decades such machines are often defined and developed incrementally, i.e., starting with a simple, small version and extending/adapting it in several small steps into larger, more sophisticated versions.
Figure 2 indicates how an initial version of an IM might develop into newer versions. Note that, e.g. due to changing requirements, existing US/UC/SSD-triples might be adapted. (The “ + “ in US1+ etc. indicate adaptions of earlier versions.) So, we see the addition of new US/UC/SSD-triples but also the adaption of earlier versions.
UC1 UC2
↓ ↓ SSD1 SSD2 ↘ ↙ IMv1 → ⁞ ⁞ ⁞ ⁞ ⁞ ⁞ ⁞ →
US3
↓ UC3
↓ SSD3
↓ IMv2 ⁞ ⁞ ⁞ ⁞ ⁞ ⁞ ⁞ →
US1+ US3+
↓ ↓ UC1+ UC3+
↓ ↓ SSD1+ SSD3+
↘ ↙ → IMv3 → ⁞ ⁞ ⁞ ⁞ ⁞ ⁞ ⁞ →
US4
↓ UC4
↓ SSD4
↓ IMv4 We now treat incremental development of functional requirements for an information system more generally. Figure 2 can be generalized easily: Via a few USs, UCs and their corresponding SSDs (and the previous version of the IM) one can define an initial (resp. next) version of the IM:
Machines
US … US
↓ … ↓ UC … UC
↓ … ↓ SSD … SSD ↘ … ↙ IMv1 → ⁞ ⁞ ⁞ ⁞ ⁞ ⁞ →
US … US
↓ … ↓ UC … UC
↓ … ↓ SSD … SSD ↘ … ↙
IMv2 → → ⁞ ⁞ ⁞ ⁞ ⁞ ⁞ →
US … US
↓ … ↓ UC … UC
↓ … ↓ SSD … SSD ↘ … ↙
IMv3 →
→
⁞
⁞
⁞
⁞
⁞
⁞
→
…
Now we are heading towards continuous development of functional requirements. We
note that such an incremental development of functional requirements can go on
‘forever’. In a sense, such a development process is cyclic and can even be (almost)
continuous during the lifecycle of an information system. We use the word continuous
here when individual (or ‘discrete’) versions can hardly (or not) be distinguished
anymore. Since we concentrate on development of functional requirements only, we are
not talking about continuous delivery or continuous deployment, for example, but about
continuous requirements engineering; see for instance [
So, all in all, Figure 5 might be more appropriate:
One cycle might contain only a few USs, UCs and their corresponding SSDs, or maybe
even only one US, UC and SSD. Or, maybe even less than one full UC: In a more agile
development process of functional requirements a simple ‘core’ scenario (or ‘main
success scenario’) of a - maybe yet unclear - ‘full’ UC might be delivered first, followed
by ‘fuller’ versions in subsequent cycles (see [
Information machines can be considered as blueprints. An IM can have many different realizations/ implementations. For instance, an information machine can be realized by a human servant (say a clerk), by an ‘SQL servant’ (i.e., a computer with SQL software), or by a ‘Java servant’ (i.e., a computer with Java software): information machine
↙ or ↓ or ↘
human Java SQL
servant servant servant
If we combine Figure 6 with the previous ones then we obtain the fundamental
ANSISPARC three-level architecture, see e.g. [
US . . . . . . . US
↓ . . . . . . . ↓ UC . . . . . . . UC
↓ . . . . . . . ↓ SSD . . . . . . . SSD
↘ . . . . . . . ↙ information machine
↙ or ↓ or ↘ human Java SQL servant servant servant
Relational SQL-based systems, for instance, are very suitable for incremental
development, and since long they are used in this way. For a realization of user stories
by means of an SQL-system for instance, we can use (stored) procedures. E.g., for our
sample user story ‘Remove a student with a given student number’ we can look back at
the corresponding SSD in Section 1 and the details worked out in the last paragraph of
the section on information machines (Section 2). In a naturally way this will lead to the
SQL-procedure below. (Parameter names are preceded by an “@” in SQL.)
We are inclined to call the realization/implementation of an information machine an
information system: According to the literature an information system has a Boundary,
Users, Processors, Storage, Inputs, Outputs and Communication networks (see [
We addressed the question how to come from initial user wishes to a running system in a straightforward, transparent, modular, and agile manner. In particular, we started to develop a sound underlying theory that grounds engineering approaches that tackle this broad problem (the complete development path for functional requirements from initial user wishes up to a running system). The theory we developed crosses the boundaries of several (sub)disciplines, e.g., requirements engineering, machine theory, and (database) systems development. We couldn’t trace such an underlying theory that covers this broad problem completely (the whole development path for functional requirements, from initial user wishes up to a running system).
We placed the notions user story, use case, and system sequence diagram in line, and we linked the SSDs directly to the notion of an information machine: The set of SSDs of an application actually determine the inputs, the outputs, and the output function of the IM. By means of an example we showed how a user story directly leads to a set of inputs for an IM and, when the IM is implemented in SQL for instance, how such an input set in turn directly corresponds to a (stored) procedure. It indicates the modularity of the resulting system when developed in this way.
All in all, we started to develop a theory on Continuous requirements engineering for information systems, grounding some engineering approaches and crossing the boundaries of several (sub)disciplines, e.g., requirements engineering, machine theory, (database) systems development.
After discussing some aspects of incremental requirements engineering for ISs, we treated continuous requirements engineering for ISs. We also pointed out that an IM is a blueprint, and can have completely different implementations. We depicted a straightforward, transparent, and agile development path for functional requirements, from USs via UCs and SSDs to an IM, and then to an actual realization.
We depicted the relation with the fundamental ANSI-SPARC three-level architecture, but extended from databases to information machines in general: USs, UCs and SSDs belong to the external level, an IM belongs to the conceptual level, and implementations of an IM belong to the internal level.
We want to extend our theory with additional, extended, and/or more complicated issues, such as sequences of inputs and corresponding outputs, complete induction for IMs (as a means to prove state properties of IMs), additional guidelines for developing use case texts, UC patterns, more complicated UCs and SSDs, further notions and terminology related to IMs, generalization and formalization of the CRUD-functions, dynamic constraints (i.e., constraints on state transitions), and interacting systems. Acknowledgements. We thank the reviewers for their critical questions, which clearly helped to sharpen the paper.