Agility in Information Systems Engineering should not be limited to the software design & implementation phase. Agility should already start early during requirements analysis and customer validation. The objective of this position paper is to sketch how to integrate requirements engineering with agile software development, a.k.a. Agile RE. We sketch our approach to support the agility-oriented development of the functional requirements for an information system and to describe our ongoing research on the Agil-ISE topic. Our main message: Align and improve the development path, not only the individual development steps.
textual ⟶ graphical ⟶ ⟶ ⤐ ↴
During validation it might turn out that the result wasn’t okay yet. In that case, we have to go back, most likely to the MSS or the ASs (as indicated in Figure 6). So, our development approach is iterative, i.e., improving ‘the same piece’ through successive refinements/adaptions. A ‘piece’ could be only one functional requirement / use case, or even only one scenario within a use case.
The results of a Requirements Analysis phase for a system essentially consist of a description of the dynamics, describing the relevant processes (i.e., what the system must be able to do), and a description of the statics, describing the relevant data structures (i.e., what the system must know). We specify the dynamics in the form of textual System Sequence Descriptions (tSSDs). The statics are often given in the form of a Conceptual Data Model. Together, the statics and the dynamics constitute a complete conceptual ‘blue print’ of the system to be developed, as summarized in Table 1:
• a syntax for our textual SSDs [1] • a formal, declarative semantics for those textual SSDs [2] • a mapping of those textual SSDs to Natural Language [3] • a mapping of those textual SSDs to graphical SSDs [3]
The mappings of a textual SSD to Natural Language and to a graphical SSD can be used to validate the textual SSD (resulting from a Requirements Analysis phase) with the user community.
• a mapping of conceptual data models to Natural Language [4] • a mapping of conceptual data models to SQL [5]
The mapping of a Conceptual Data Model to Natural Language can be used to validate the Conceptual Data Model (resulting from Requirements Analysis) with the user community. The mapping to SQL gives (a first version of) an implementation design.
Figure 3 positions and links our ‘development products’ schematically (with existing components in white and our ‘development products’ in yellow):
textual SSDs
It is worthwhile to sketch a complete example of a development path for a concrete functional requirement, showing the artefacts produced along the development path. Figure 4 contains such an example.
eUW pUW US MSS AS* UC tSSD SW-procedure(s)
Register a student Register a student with a given name, address, country, birth date, … As an administrator, I want to Register a student [ because ….. ] 1. The user asks the system to <pUW> (Register a student with …) 2. The system fulfils <pUW> (Register a student with …) 3. The system sends result to the user (e.g., registered data including the generated student nr.) AS1: If (s)he is a foreigner then … AS2: If (s)he was a student before then … AS3: … ⁞ MSS + AS1 + AS2 + AS3 + … (But what if the foreigner was a student before?)
User System: <pUW> ; if student is a foreigner then ….. (even if the foreigner was a student before, as the customer told us) else if (s)he was not a student before then System System: generate new student number ;
System System: fulfil <pUW, with new student number> else …..
end end ;
System User: result (e.g., registered data including generated student number) E.g., a stored procedure in SQL @output is declared as a return parameter here (Let’s suppose that student number is declared as an AUTO-INCREMENT primary key field) CREATE PROCEDURE RegisterStudent @n VARCHAR(50), @a VARCHAR, @c VARCHAR(20), @bd DATE, ...., @output VARCHAR OUTPUT AS BEGIN
IF @c <> ‘NL’ THEN .....
ELSE IF .....
THEN BEGIN INSERT INTO Student(name, address, country, ...)
VALUES(@n, @a, @c, @bd, ...)
SELECT @output = ‘Done. New student nr. is ’+ < . . . > END
END
ELSE .....
Figure 4 also illustrates the traceability virtues of our aligned approach: The original user wish (Register a student) forms a ‘trace’ all the way from that user wish down to the software procedure (RegisterStudent). Since textual SSDs can also be named in our syntax, the textual SSD produced during the development could be named RegisterStudent as well. All in all, the traces arise during and as part of the development, not produced as a (ceremonial) duty afterwards, as is typically the case [6].
In Figure 5 we show the graphical SSD generated from our textual SSD and the generated NL-text next to it, but both with all scenarios integrated now. For the generation of the graphical SSD we used the drawing generation tool Plantuml (see https://plantuml.com/sequence-diagram, and our appendix for the code). For a complex example we refer to [7].
The User asks the System to <pUW>.
If student is a foreigner then ….. else if (s)he was not a student before then the System does generate new student number.
The System does fulfil <pUW> else …..
end end.
The System sends result to User
Now we are ready to sketch an agile method for information systems engineering (Agil-ISE).
When a new user wish pops up, then you can ‘walk the line’ we sketched, i.e., follow the aligned development path, completely from initial user wish all down to implementation (say, in Java or SQL).
eUW pUW US US
for the development of a functional requirement
tSSD Convert it to a textual SSD
gSSD Generate the corresponding graphical SSD (if desirable)
tSSD Convert it to a (local) textual SSD MSS ⊕ AS* Integrate it into the already existing textual SSD
gSSD Generate the corresponding graphical SSD (if desirable)
Until now we discussed the development of an individual functional requirement (FR). Developing several FRs can be done incrementally, i.e., developing (and delivering) the system ‘piece by piece’. And if there are several development teams to develop the FRs, an individual FR should preferably be handled within one team. Figure 6 illustrates these aspects. This way of working makes the approach well scalable.
Team 1
Currently we are working on a mapping of those textual SSDs to SQL (see the dotted downward arrow in Figure 2). Our planned future research is to elevate our theory to meta-level in order to be able to generate all this from a central repository (so, automation in agile ISE).
E.O. de Brock: From Business Modeling to Software Design. In B. Shishkov (ed.): Proceedings
E.O. de Brock: Declarative Semantics of Actions and Instructions. In B. Shishkov (ed.):
Proceedings BMSD (Business Modeling and Software Design), LNBIP 391, pp. 297–308 (2020)
E.O. de Brock: On System Sequence Descriptions. In M. Sabetzadeh et al (eds.): Jo
rnote over User, System #white: ….. else else group if [(s)he was not a student before]
System -> System: generate new student number
System -> System: fulfil <pUW> else else
rnote over User, System #white: …..
end end System -> User: result