* Arbabshirani et al. (2017) Arbabshirani, M. R., Plis, S., Sui, J., Calhoun, V. D., 2017. Single subject prediction of brain disorders in neuroimaging: Promises and pitfalls. NeuroImage 145 (Pt B), 137–165.
  * Biswal et al. (1995) Biswal, B., Zerrin Yetkin, F., Haughton, V. M., Hyde, J. S., 1995. Functional connectivity in the motor cortex of resting human brain using echo-planar MRI. Magnetic Resonance in Medicine 34 (4), 537–541.
  * Blankertz et al. (2007) Blankertz, B., Dornhege, G., Krauledat, M., Müller, K.-R., Curio, G., 2007\. The non-invasive Berlin Brain-Computer Interface: Fast acquisition of effective performance in untrained subjects. Neuroimage 37 (2), 539 – 550.
  * Bregler (1997) Bregler, C., 1997. Learning and recognizing human dynamics in video sequences. In: Proc. IEEE Comput. Soc. Conf. Comput. Vis. Pattern Recognit. pp. 568–574.
  * Calhoun et al. (2014) Calhoun, V. D., Miller, R., Pearlson, G., Adali, T., 2014. The chronnectome: time-varying connectivity networks as the next frontier in fMRI data discovery. Neuron 84 (2), 262–274.
  * Camacho et al. (2018) Camacho, M., Perez-Quiros, G., Poncela, P., 2018. Markov-switching dynamic factor models in real time. Int. J. Forecast. 34 (4), 598–611.
  * Cappé et al. (2005) Cappé, O., Moulines, E., Rydén, T., 2005. Inference in hidden Markov models. Springer Series in Statistics. Springer, New York.
  * Carstensen et al. (2020) Carstensen, K., Heinrich, M., Reif, M., Wolters, M. H., 2020. Predicting ordinary and severe recessions with a three-state Markov-switching dynamic factor model: An application to the German business cycle. Int. J. Forecast. 36 (3), 829–850.
  * Carter and Kohn (1996) Carter, C. K., Kohn, R., 1996. Markov chain Monte Carlo in conditionally Gaussian state space models. Biometrika 83 (3), 589–601.
  * Chang and Glover (2010) Chang, C., Glover, G. H., 2010. Time-frequency dynamics of resting-state brain connectivity measured with fMRI. NeuroImage 50 (1), 81–98.
  * Chang and Athans (1978) Chang, C. B., Athans, M., 1978. State estimation for discrete systems with switching parameters. IEEE Trans. Aerosp. Electron. Syst. AES-14 (3), 418–425.
  * Chen et al. (2013) Chen, J. L., Ros, T., Gruzelier, J. H., 2013. Dynamic changes of ICA-derived EEG functional connectivity in the resting state. Hum. Brain Mapp. 34 (4), 852–868.
  * Cosslett and Lee (1985) Cosslett, S. R., Lee, L.-F., 1985. Serial correlation in latent discrete variable models. J. Econom. 27 (1), 79–97.
  * Cox and Hingorani (1996) Cox, I. J., Hingorani, S. L., 1996. An efficient implementation of Reid’s multiple hypothesis tracking algorithm and its evaluation for the purpose of visual tracking. IEEE Trans. Pattern Anal. Mach. Intell. 18 (2), 138–150.
  * Cribben et al. (2013) Cribben, I., Wager, T. D., Lindquist, M. A., 2013. Detecting functional connectivity change points for single-subject fMRI data. Front. Comput. Neurosci. 7, 143.
  * Degras (2020) Degras, D., 2020. Sparse group fused lasso for model segmentation: a hybrid approach. Adv. Data Anal. Classif.
  * Degras (2021) Degras, D., 2021. Scalable feature matching across large data collections.
  * Dempster et al. (1977) Dempster, A. P., Laird, N. M., Rubin, D. B., 1977. Maximum likelihood from incomplete data via the EM algorithm. J. Roy. Statist. Soc. Ser. B 39 (1), 1–38, with discussion.
  * Deng (2004) Deng, L., 2004. Switching dynamic system models for speech articulation and acoustics. In: Johnson, M., Khudanpur, S. P., Ostendorf, M., Rosenfeld, R. (Eds.), Mathematical Foundations of Speech and Language Processing. Springer New York, New York, NY, pp. 115–133.
  * Dennis and Thompson (2014) Dennis, E. L., Thompson, P. M., 2014. Functional brain connectivity using fMRI in aging and Alzheimer’s disease. Neuropsychol. Rev. 24 (1), 49–62.
  * Di and Biswal (2015) Di, X., Biswal, B. B., 2015. Dynamic brain functional connectivity modulated by resting-state networks. Brain Struct. Funct. 220 (1), 37–46.
  * Doucet et al. (2001) Doucet, A., Gordon, N. J., Krishnamurthy, V., 2001. Particle filters for state estimation of jump markov linear systems. IEEE Trans. Signal Processing 49, 613–624.
  * Efron and Tibshirani (1993) Efron, B., Tibshirani, R. J., 1993. An introduction to the bootstrap. Vol. 57 of Monographs on Statistics and Applied Probability. Chapman and Hall, New York.
  * Fiecas and Ombao (2016) Fiecas, M., Ombao, H., 2016. Modeling the evolution of dynamic brain processes during an associative learning experiment. J. Amer. Statist. Assoc. 111 (516), 1440–1453.
  * Fortmann et al. (1983) Fortmann, T., Bar-Shalom, Y., Scheffe, M., 1983. Sonar tracking of multiple targets using joint probabilistic data association. J. Ocean. Eng. 8 (3), 173–184.
  * Fox et al. (2005) Fox, M. D., Snyder, A. Z., Vincent, J. L., Corbetta, M., Van Essen, D. C., Raichle, M. E., 2005. The human brain is intrinsically organized into dynamic, anticorrelated functional networks. Proc. Natl. Acad. Sci. USA 102 (27), 9673–9678.
  * Friston (2011) Friston, K. J., 2011. Functional and effective connectivity: a review. Brain Connect. 1 (1), 13–36.
  * Frühwirth-Schnatter (2006) Frühwirth-Schnatter, S., 2006. Finite mixture and Markov switching models. Springer Series in Statistics. Springer, New York.
  * Ghahramani and Hinton (2000) Ghahramani, Z., Hinton, G. E., 2000. Variational learning for switching state-space models. Neural Comput. 12 (4), 831–864.
  * Goldfeld and Quandt (1973) Goldfeld, S. M., Quandt, R. E., 1973. A Markov model for switching regressions. J. Econom. 1 (1), 3–15.
  * Golub et al. (1979) Golub, G. H., Nash, S., Van Loan, C., 1979. A Hessenberg-Schur method for the problem $AX+XB=C$. IEEE Trans. Automat. Control 24 (6), 909–913.
  * Guerrero et al. (2021) Guerrero, M. B., Huser, R., Ombao, H., 2021. Conex-Connect: Learning patterns in extremal brain connectivity from multi-channel EEG data.
  * Hamilton (1990) Hamilton, J. D., 1990. Analysis of time series subject to changes in regime. J. Econom. 45 (1-2), 39–70.
  * Hamilton (1994) Hamilton, J. D., 1994. Time series analysis. Princeton University Press, Princeton, NJ.
  * Handwerker et al. (2012) Handwerker, D. A., Roopchansingh, V., Gonzalez-Castillo, J., Bandettini, P. A., 2012\. Periodic changes in fMRI connectivity. NeuroImage 63 (3), 1712–1719.
  * Heinsfeld et al. (2018) Heinsfeld, A. S., Franco, A. R., Craddock, R. C., Buchweitz, A., Meneguzzi, F., 2018\. Identification of autism spectrum disorder using deep learning and the ABIDE dataset. NeuroImage: Clinical 17 (Supplement C), 16 – 23.
  * Huang et al. (2017) Huang, Y., Zhang, J., Cui, Y., Yang, G., He, L., Liu, Q., Yin, G., 2017. How different EEG references influence sensor level functional connectivity graphs. Front. Neurosci. 11, 368.
  * Hutchison et al. (2013) Hutchison, R. M., Womelsdorf, T., Allen, E. A., Bandettini, P. A., Calhoun, V. D., Corbetta, M., Della Penna, S., Duyn, J. H., Glover, G. H., Gonzalez-Castillo, J., Handwerker, D. A., Keilholz, S., Kiviniemi, V., Leopold, D. A., de Pasquale, F., Sporns, O., Walter, M., Chang, C., 2013. Dynamic functional connectivity: promise, issues, and interpretations. NeuroImage 80, 360–378.
  * Jalili and Knyazeva (2011) Jalili, M., Knyazeva, M. G., 2011. EEG-based functional networks in schizophrenia. Comput. Biol. Med. 41 (12), 1178–1186.
  * Kang et al. (2011) Kang, J., Wang, L., Yan, C., Wang, J., Liang, X., He, Y., 2011. Characterizing dynamic functional connectivity in the resting brain using variable parameter regression and Kalman filtering approaches. NeuroImage 56 (3), 1222–1234.
  * Karamzadeh et al. (2013) Karamzadeh, N., Medvedev, A., Azari, A., Gandjbakhche, A., Najafizadeh, L., 2013\. Capturing dynamic patterns of task-based functional connectivity with EEG. Neuroimage 66 (Supplement C), 311 – 317.
  * Kim (1994) Kim, C.-J., 1994. Dynamic linear models with Markov-switching. J. Econom. 60 (1-2), 1–22.
  * Kim and Nelson (1999) Kim, C.-J., Nelson, C. R., 1999. State-Space Models with Regime Switching: Classical and Gibbs-Sampling Approaches with Applications. MIT Press.
  * Krolzig (1997) Krolzig, H.-M., 1997. Markov-switching vector autoregressions. Vol. 454 of Lecture Notes in Economics and Mathematical Systems. Springer-Verlag, Berlin.
  * Langrock and Zucchini (2011) Langrock, R., Zucchini, W., 2011. Hidden Markov models with arbitrary state dwell-time distributions. Comput. Statist. Data Anal. 55 (1), 715–724.
  * Lanne et al. (2010) Lanne, M., Lütkepohl, H., Maciejowska, K., 2010. Structural vector autoregressions with Markov switching. Journal of Economic Dynamics and Control 34 (2), 121–131.
  * Lehmann et al. (1998) Lehmann, D., Strik, W., Henggeler, B., Koenig, T., Koukkou, M., 1998. Brain electric microstates and momentary conscious mind states as building blocks of spontaneous thinking: I. Visual imagery and abstract thoughts. Int. J. Psychophys. 29 (1), 1–11.
  * Lindquist et al. (2014) Lindquist, M. A., Xu, Y., Nebel, M. B., Caffo, B. S., 2014. Evaluating dynamic bivariate correlations in resting-state fMRI: A comparison study and a new approach. NeuroImage 101 (Supplement C), 531 – 546.
  * McLachlan and Krishnan (2008) McLachlan, G. J., Krishnan, T., 2008. The EM algorithm and extensions, 2nd Edition. Wiley-Interscience [John Wiley & Sons], Hoboken, NJ.
  * Melnyk et al. (2016) Melnyk, I., Banerjee, A., Matthews, B., Oza, N., 2016. Semi-Markov switching vector autoregressive model-based anomaly detection in aviation systems. In: Proc. 22nd ACM SIGKDD Int. Conf. Knowl. Discov. Data Min. pp. 1065–1074, KDD ’16.
  * Molenaar et al. (2016) Molenaar, P. C., Beltz, A. M., Gates, K. M., Wilson, S. J., 2016. State space modeling of time-varying contemporaneous and lagged relations in connectivity maps. NeuroImage 125, 791–802.
  * Murphy (1998) Murphy, K. P., 1998. Switching Kalman filters. Tech. rep., University of California Berkeley.
  * Olier et al. (2013) Olier, I., Trujillo-Barreto, N. J., El-Deredy, W., 2013. A switching multi-scale dynamical network model of EEG/MEG. NeuroImage 83, 262–287.
  * Ombao et al. (2018) Ombao, H., Fiecas, M., Ting, C.-M., Low, Y. F., 2018. Statistical models for brain signals with properties that evolve across trials. NeuroImage 180, 609–618.
  * Ombao and Pinto (2021) Ombao, H., Pinto, M., 2021. Spectral dependence.
  * Ombao et al. (2005) Ombao, H., von Sachs, R., Guo, W., 2005. SLEX analysis of multivariate nonstationary time series. J. Amer. Statist. Assoc. 100 (470), 519–531.
  * Ombao et al. (2001) Ombao, H. C., Raz, J. A., von Sachs, R., Malow, B. A., 2001. Automatic statistical analysis of bivariate nonstationary time series. J. Amer. Statist. Assoc. 96 (454), 543–560.
  * Park et al. (2014) Park, T., Eckley, I. A., Ombao, H. C., 2014. Estimating time-evolving partial coherence between signals via multivariate locally stationary wavelet processes. IEEE Trans. Sign. Process. 62 (20), 5240–5250.
  * Pascual-Marqui et al. (1995) Pascual-Marqui, R. D., Michel, C. M., Lehmann, D., 1995. Segmentation of brain electrical activity into microstates: model estimation and validation. IEEE Trans. Biomed. Eng. 42 (7), 658–665.
  * Pauley et al. (2020) Pauley, M., Mclean, C., Manton, J. H., 2020. A numerical filtering method for linear state-space models with Markov switching. International Journal of Adaptive Control and Signal Processing 34 (7), 813–838.
  * Prado (2013) Prado, R., 2013. Sequential estimation of mixtures of structured autoregressive models. Comput. Statist. Data Anal. 58, 58–70.
  * Rosti and Gales (2004) Rosti, A.-V. I., Gales, M., 2004. Rao-Blackwellised Gibbs sampling for switching linear dynamical systems. In: Int. Conf. Acoust., Speech, and Signal Proc. (ICASSP). pp. 809–812.
  * Rubia et al. (2014) Rubia, K., Alegria, A., Brinson, H., 2014. Imaging the ADHD brain: disorder-specificity, medication effects and clinical translation. Expert Rev. Neurother. 14 (5), 519–538.
  * Sakkalis (2011) Sakkalis, V., 2011. Review of advanced techniques for the estimation of brain connectivity measured with EEG/MEG. Comput. Biol. Med 41 (12), 1110 – 1117, special Issue on Techniques for Measuring Brain Connectivity.
  * Samdin et al. (2017) Samdin, S. B., Ting, C. M., Ombao, H., Salleh, S. H., 2017. A unified estimation framework for state-related changes in effective brain connectivity. IEEE Trans. Biomed. Eng. 64 (4), 844–858.
  * Shumway and Stoffer (1991) Shumway, R. H., Stoffer, D. S., 1991. Dynamic linear models with switching. J. Amer. Statist. Assoc. 86 (415), 763–769.
  * Siggiridou et al. (2014) Siggiridou, E., Kugiumtzis, D., Kimiskidis, V., 2014. Correlation networks for identifying changes in brain connectivity during epileptiform discharges and transcranial magnetic stimulation. Sensors 14 (7), 12585–12597.
  * Stoffer and Wall (1991) Stoffer, D. S., Wall, K. D., 1991. Bootstrapping state-space models: Gaussian maximum likelihood estimation and the Kalman filter. J. Amer. Statist. Assoc. 86 (416), 1024–1033.
  * Taghia et al. (2017) Taghia, J., Ryali, S., Chen, T., Supekar, K., Cai, W., Menon, V., 2017. Bayesian switching factor analysis for estimating time-varying functional connectivity in fmri. NeuroImage 155, 271–290.
  * Tangermann et al. (2012) Tangermann, M., Müller, K.-R., Aertsen, A., Birbaumer, N., Braun, C., Brunner, C., Leeb, R., Mehring, C., Miller, K., Müller-Putz, G., Nolte, G., Pfurtscheller, G., Preissl, H., Schalk, G., Schlögl, A., Vidaurre, C., Waldert, S., Blankertz, B., 2012. Review of the BCI competition IV. Front. Neurosci. 6, 55.
  * Ting et al. (2018) Ting, C. M., Ombao, H., Samdin, S. B., Salleh, S. H., 2018. Estimating dynamic connectivity states in fMRI using regime-switching factor models. IEEE Trans. Med. Imag. 37 (4), 1011–1023.
  * Tronarp et al. (2018) Tronarp, F., Subramaniyam, N. P., Särkkä, S., Parkkonen, L., 2018. Tracking of dynamic functional connectivity from MEG data with Kalman filtering. In: 2018 40th Annual International Conference of the IEEE Engineering in Medicine and Biology Society (EMBC). pp. 1003–1006.
  * Ueda and Nakano (1998) Ueda, N., Nakano, R., 1998. Deterministic annealing EM algorithm. Neural Netw. 11 (2), 271–282.
  * van Mierlo et al. (2014) van Mierlo, P., Papadopoulou, M., Carrette, E., Boon, P., Vandenberghe, S., Vonck, K., Marinazzo, D., 2014. Functional brain connectivity from EEG in epilepsy: Seizure prediction and epileptogenic focus localization. Prog. Neurobiol. 121 (Supplement C), 19–35.
  * Van Overschee and De Moor (1996) Van Overschee, P., De Moor, B., 1996. Subspace identification for linear systems. Kluwer Academic Publishers, Boston, MA.
  * Vergara et al. (2017) Vergara, V. M., Mayer, A. R., Damaraju, E., Kiehl, K. A., Calhoun, V., 2017. Detection of mild traumatic brain injury by machine learning classification using resting state functional network connectivity and fractional anisotropy. J. Neurotrauma 34 (5), 1045–1053.
  * Vidaurre et al. (2016) Vidaurre, D., Quinn, A. J., Baker, A. P., Dupret, D., Tejero-Cantero, A., Woolrich, M. W., 2016. Spectrally resolved fast transient brain states in electrophysiological data. NeuroImage 126, 81–95.
  * Wang et al. (2018) Wang, Y., Ombao, H., Chung, M. K., 2018. Topological data analysis of single-trial electroencephalographic signals. Ann. Applied Statist. 12 (3), 1506 – 1534.
  * Warren et al. (2014) Warren, D. E., Power, J. D., Bruss, J., Denburg, N. L., Waldron, E. J., Sun, H., Petersen, S. E., Tranel, D., 2014. Network measures predict neuropsychological outcome after brain injury. Proc. Natl. Acad. Sci. U.S.A. 111 (39), 14247–14252.
  * Wu (1983) Wu, C.-F. J., 1983. On the convergence properties of the EM algorithm. Ann. Statist. 11 (1), 95–103.
  * Xu and Lindquist (2015) Xu, Y., Lindquist, M. A., 2015. Dynamic connectivity detection: an algorithm for determining functional connectivity change points in fMRI data. Front. Neurosci. 9, 285.
  * Yang (2000) Yang, M., 02 2000. Some properties of vector autoregressive processes with Markov-switching coefficients. Econom. Theory 16, 23–43.
  * Yang and Chow (2010) Yang, M., Chow, S.-M., 2010. Using state-space model with regime switching to represent the dynamics of facial electromyography (EMG) data. Psychometrika 75 (4), 744–771.
  * Yang et al. (2015) Yang, Y., Qiu, Y., Schouten, A. C., 2015. Dynamic functional brain connectivity for face perception. Front. Hum. Neurosci. 9, 662.
  * Zhang and Hyvärinen (2011) Zhang, K., Hyvärinen, A., 2011. A general linear non-Gaussian state-space model: Identifiability, identification, and applications. In: Hsu, C.-N., Lee, W. S. (Eds.), Proc. Asian Conf. Mach. Learn. Vol. 20 of JMLR Proceedings. pp. 113–128.
  * Zhou and Shumway (2008) Zhou, T., Shumway, R., 2008. One-step approximations for detecting regime changes in the state space model with application to the influenza data. Comput. Statist. Data Anal. 52 (5), 2277–2291.

##  Appendix A Derivation of stationary covariance matrices

This appendix details how to obtain the stationary covariance matrices
$\boldsymbol{\Sigma}_{j}^{x}$ in (12), an important calculation which we have
not found elsewhere in the literature. Define the expanded state vector
$\tilde{\mathbf{x}}_{t}=\mathrm{vec}(\mathbf{x}_{t},\ldots,\mathbf{x}_{t-p+1})$
(in models (2)-(3), replace $\mathbf{x}_{t}$ by $\mathbf{x}_{tj}$ in model
(4)). Also define the companion matrix $\widetilde{\mathbf{A}}_{j}$ to the
state transition matrices $\mathbf{A}_{1j},\ldots,\mathbf{A}_{pj}$, and the
expanded state noise covariance matrix $\widetilde{\mathbf{Q}}_{j}$ by

$\widetilde{\mathbf{A}}_{j}=\left(\begin{array}[]{c c c
c}\mathbf{A}_{1j}&\mathbf{A}_{2j}&\cdots&\mathbf{A}_{pj}\\\
\mathbf{I}_{r}&\mathbf{0}_{r\times r}&\cdots&\mathbf{0}_{r\times r}\\\
\mathbf{0}_{r\times r}&\ddots&\ddots&\vdots\\\ \mathbf{0}_{r\times
r}&\mathbf{0}_{r\times r}&\mathbf{I}_{r}&\mathbf{0}_{r\times
r}\end{array}\right),\qquad\widetilde{\mathbf{Q}}_{j}=\left(\begin{array}[]{cc}\mathbf{Q}_{j}&\mathbf{0}_{r\times(p-1)r}\\\
\mathbf{0}_{(p-1)r\times
r}&\mathbf{0}_{(p-1)r\times(p-1)r}\end{array}\right).$

We assume here that the eigenvalues of $\widetilde{\mathbf{A}}_{j}$ are less
than 1 in modulus, which guarantees that the state process
$(\tilde{\mathbf{x}}_{t})$ is asymptotically stationary. The stationarity
equation for
$\boldsymbol{\Sigma}_{j}^{\tilde{x}}=\lim_{t\to\infty}V(\tilde{\mathbf{x}}_{t}|S_{1}=\cdots=S_{t}=j)$
expresses as

$\boldsymbol{\Sigma}_{j}^{\tilde{x}}=\widetilde{\mathbf{A}}_{j}\boldsymbol{\Sigma}_{j}^{\tilde{x}}\widetilde{\mathbf{A}}_{j}^{\prime}+\widetilde{\mathbf{Q}}_{j}$
(17)

and $\boldsymbol{\Sigma}_{j}^{x}$ equals any of the $p$ diagonal blocks of
$\boldsymbol{\Sigma}_{j}^{\tilde{x}}$ of size $r\times r$.

If $\widetilde{\mathbf{A}}_{j}$ is of full rank, this equation can be
transformed into the Sylvester equation

$\widetilde{\mathbf{A}}_{j}^{-1}\boldsymbol{\Sigma}_{j}^{\tilde{x}}-\boldsymbol{\Sigma}_{j}^{\tilde{x}}\widetilde{\mathbf{A}}_{j}^{\prime}=\widetilde{\mathbf{A}}_{j}^{-1}\widetilde{\mathbf{Q}}_{j}$
(18)

and solved with standard methods (e.g., Golub et al., 1979).

On the other hand, if $\widetilde{\mathbf{A}}_{j}$ is not of full rank, (17)
can be vectorized as

$\mathbf{v}_{j}=(\widetilde{\mathbf{A}}_{j}\otimes\widetilde{\mathbf{A}}_{j})\mathbf{v}_{j}+\mathbf{q}_{j}$

where $\mathbf{v}_{j}=\mathrm{vec}(\boldsymbol{\Sigma}_{j}^{\tilde{x}})$,
$\mathbf{q}_{j}=\mathrm{vec}(\mathbf{Q}_{j})$, and $\otimes$ denotes Kronecker
product. Noting that $\mathbf{v}_{j}$ contains only $r(r+1)/2+(p-1)r^{2}$
unique elements, there exists a matrix $\mathbf{M}$ filled with zeros except
for a single value one in each row such that
$\mathbf{v}_{j}=\mathbf{M}\tilde{\mathbf{v}}_{j}$. Problem (17) can then be
solved as the linear system

$(\mathbf{I}_{(pr)^{2}}-\widetilde{\mathbf{A}}_{j}\otimes\widetilde{\mathbf{A}}_{j})\mathbf{M}\tilde{\mathbf{v}}_{j}=\mathbf{q}_{j}.$
(19)

##  Appendix B Example code for the toolbox switch-ssm

The statistical methods of this paper are implemented in a MATLAB toolbox
available at https://github.com/ddegras/switch-ssm. Here we demonstrate the
toolbox switch-ssm with a small example using continuous EEG data recorded
from an open/closed eyes experiment. The data and their description can be
found at https://archive.ics.uci.edu/ml/datasets/EEG+Eye+State. The data are
also included in the toolbox after artifact removal and standardization. The
code below is a simplified edited version of the file _eeg_example.mat_ in the
toolbox.

    % Load the EEG eye state data
    load(’eeg_eye_state.mat’)

    % Visualize the EEG signals
    visualize_mts(eeg,channel)

    % Fit a standard (non-switching) VAR model
    M = 1; p = 6; S = ones(1,T) % set all regimes S(t) = 1
    pars0 = fast_var(eeg,M,p,S);

    % Subtract the common stationary component from the data
    e = eeg; e(:,1:p) = e(:,1:p) - pars1.mu;
    for l = 1:p
        e(:,p+1:T) = e(:,p+1:T) - pars0.A(:,:,l) * eeg(:,p+1-l:T-l);
    end

    % Fit a switching VAR to the residuals
    M = 6; % number of regimes
    [~,Ms,~,Shat,pars,LL] = switch_var(e,M,p);

    % Extract regime-specific stationary quantities
    [ACF,COH,COV,VAR] = get_covariance(pars);

    % Calculate 100 bootstrap replicates of the MLE
    B = 100; parallel = true;
    [parsboot,LLboot] = bootstrap_var(pars,T,B,[],[],[],[],[],parallel);

     % Match bootstrap estimates to MLE based on matrix A
    parsboot = bootstrap_match(parsboot,pars,’A’);

    % Build bootstrap confidence intervals for the model parameters
    ci = bootstrap_ci(parsboot,0.95,’normal’);

In this example, rather than directly fitting a switching SSM to the data, we
first estimate a single VAR model with the function `fast_var` and then fit a
switching SSM to the residuals with the function `switch_var`. The reason for
this approach is that if a switching SSM is directly fitted to the data, the
parameter estimates are all nearly equal across regimes and identical to the
common SSM component. In contrast, removing the common SSM component first
reveals interesting and diverse FC regimes in the residuals. The model orders
$M=6$ and $p=6$ are reasonable choices obtained after fitting and examining a
range of models. The regime-specific stationary covariance, variances, and
autocorrelation and coherence structures are computed via `get_covariance`.
After that, $B=100$ bootstraps of the MLE are calculated in parallel with
`bootstrap_var` and matched to the MLE by regime based on the matrices
$\widehat{\mathbf{A}}_{1},\ldots,\widehat{\mathbf{A}}_{M}$. This step is
accomplished with `bootstrap_match`. (The matrices $\widehat{\mathbf{A}}_{j}$
are used here for matching and not, say, the noise variance matrices
$\widehat{\mathbf{Q}}_{1},\ldots,\widehat{\mathbf{Q}}_{M}$ which are nearly
equal to each other. The matching could also be based on stationary covariance
matrices as in Section 5.1.) Finally, normal bootstrap confidence intervals
are built for all model parameters and stationary quantities at the level 95%
with `bootstrap_ci`.


COMMISSIONS 27 AND 42 OF THE IAU

INFORMATION BULLETIN ON VARIABLE STARS

Number 0000

Konkoly Observatory Budapest 16 September 2011 HU ISSN 0374 – 0676

V1162 ORION: UPDATED AMPLITUDE AND PERIOD VARIATION

KHOKHUNTOD, PONGSAK1,2; ZHOU, AI-YING3∗; BOONYARAK, CHAYAN1; JIANG, SHI-
YANG1,3

1 Department of Physics, Faculty of Science, Naresuan University, Phitsanulok
65000, Thailand

2 Department of Astronomy, Beijing Normal University, China

3 National Astronomical Observatory of China, Chinese Academy of Sciences,
Datun Road 20A, Beijing, 100086, China; *Correspondent author, E-mail:
<EMAIL_ADDRESS>

V1162 Orion is an intermediate-amplitude $\delta$ Scuti type variable. Its
variability was first discovered by Lampens (1985), who derived a period of
0.078686(2) days with a full amplitude of about 0.18 mag in $V$ band. Hintz et
al. (1998) observed this star and found its amplitude in $V$ had dropped to
about 0.10 mag. Arentoft & Sterken (2000) and Arentoft et al. (2001a, 2001b)
got the same amplitude of $\sim$0.10 mag in $V$.

We had observed this star from 2007 January to 2010 February using several
telescopes at Naresuan University, Thailand and at Yunnan Observatory and the
Xinglong Station of National Astronomical Observatories, China (NAOC). We
determined a sum of 39 new times of maximum light (refers to Table 1),
following the method described by Zhou & Liu (2003). Errors involved in the
maximum determination are around 0.00045 d or less. In this note, we present a
two-night sample of the newly observed light curves along with an updated
$O-C$ diagram. Figure 1 shows the light curve of V1162 Ori on 2010 November 24
and 25 from the 60-cm telescope of NAOC. We can see clearly that the peak-to-
peak full amplitude in $V$ recovered to about 0.18 mag. This conforms with the
amplitude variability declared in the literature. The differential photometric
light curve data are available upon request from the authors.

Figure 1: The light curves of V1162 Ori obtained on 2010 Nov. 24 and 25.

We have noted that Arentoft et al. (2001a) presented the results of multisite
observations contributed by 18 telescopes from 15 observatories around the
global. They measured 253 light extrema (145 maxima and 108 minima) during the
observing season from 1999 October to 2000 May. They got an overall tendency
of period decreasing with a very high rate of $\frac{{\rm d}P}{{\rm
d}t}$=$-5\times 10^{-9}$ s s-1 (equivalent to $\frac{1}{P}\frac{{\rm d}P}{{\rm
d}t}=-2.4\times 10^{-5}$ yr-1). Moreover, the $(O-C)$ residuals seemed to
follow a cyclic variation with a period of 285$\pm$3 d, which is on a time-
scale similar to that of the amplitude variations (282$\pm$6 d). In addition,
we found 40 maxima in Wils et al. (2010, 2011), we draw here a $(O-C)$ diagram
based on a total of 385 times of maximum light.

Table 1: The new times of maximum light of V1162 Ori obtained in 2007–2011. No. | HJD(max) | No. | HJD(max) | No. | HJD(max)
---|---|---|---|---|---
1 | 2454130.0693 | 14 | 2454178.0626 | 27 | 2455525.13603
2 | 2454131.0901 | 15 | 2454181.0580 | 28 | 2455525.21233
3 | 2454131.1701 | 16 | 2454184.0422 | 29 | 2455525.29404
4 | 2454132.1171 | 17 | 2454847.0331 | 30 | 2455526.15567
5 | 2454132.1882 | 18 | 2454847.1111 | 31 | 2455526.23844
6 | 2454133.0578 | 19 | 2454847.1889 | 32 | 2455526.31468
7 | 2454133.1367 | 20 | 2454871.1100 | 33 | 2455565.10686
8 | 2454133.2158 | 21 | 2454871.1910 | 34 | 2455565.18583
9 | 2454137.0715 | 22 | 2455249.1147 | 35 | 2455565.26503
10 | 2454137.1467 | 23 | 2455250.0539 | 36 | 2455602.08888
11 | 2454161.0694 | 24 | 2455250.1342 | 37 | 2455602.16764
12 | 2454164.0582 | 25 | 2455524.19384 | 38 | 2455610.03529
13 | 2454176.0189 | 26 | 2455524.26824 | 39 | 2455610.11388

To calculate $(O-C)$ residuals and their corresponding cycles (denoted by E
below) elapsed since an initial maximum epoch, we have defined a new ephemeris

$T_{\rm max}={\rm HJD}\,2451890.3708+0.0786869\times E.$ (1)

according to Arentoft & Sterken (2002). The cycle counts are usually the
results rounded off by rounding a numerical value to the nearest integer. For
those cases when a value is exactly half-way between two integers, it is
always rounded up following the so-called ‘round half up’ tie-breaking rule.
For example, the values (66.51, 23.5, –23.5, 15.49, –18.38, –18.67), get
rounded to (67, 24, –23, 15, –18, –19), respectively. This rounding policy
results in $(O-C)$ residuals within half a period, i.e. $|O-C|\leq 0.0393$
days. The resultant $O-C$ diagram was drawn in Fig. 2, which cannot be fitted
by either a single linear line or a simple parabolic curve. Part of the 385
maxima and $(O-C)$ data are shown in Table 2. The full list is available upon
request from the authors.

Figure 2:  The $O-C$ diagram of V1162 Ori: the forced parabolic fitting curve is not justified. The new maxima in Table 1 are drawn in squares. Table 2: List of 385 light maxima of V1162 Ori and their $(O-C)$ residuals computed by Eq.(1). The reference ’L’ refers to Lampens(1985), ’A’ refers to Arentoft et al.(2000,2001a,2001b,2002), ’H’ stands for Hintz et al.(1998), ’P’ for Poretti et al.(1990), ’W’ for Wils et al.(2010,2011), while ’J’ for this work. No. | Maximum | Fractional Cycles | Cycles | $(O-C)$ | Ref.
---|---|---|---|---|---
1 | 2445347.02750 | –83156.70 | –83157 | 0.023243 | L
2 | 2447110.78000 | –60741.88 | –60742 | 0.008880 | P
3 | 2447110.85550 | –60740.92 | –60741 | 0.005693 | P
$\cdots\cdots$ |  |  |  |  |
247 | 2451890.37080 | 0.00 | 0 | 0.000000 | A
248 | 2451890.45000 | 1.00 | 1 | 0.000513 | A
$\cdots\cdots$ |  |  |  |  |
346 | 2455293.33020 | 43246.83 | 43247 | –0.012964 | W
347 | 2454130.06930 | 28463.42 | 28463 | 0.033265 | J
$\cdots\cdots$ |  |  |  |  |
384 | 2455610.03529 | 47271.71 | 47272 | –0.022647 | J
385 | 2455610.11388 | 47272.71 | 47273 | –0.022744 | J

References:

Arentoft, T., Sterken, C., 2000, A&A, 354, 589

Arentoft, T., et al., 2001a, A&A, 374, 1056

Arentoft, T., et al., 2001b, A&A, 378, L33

Arentoft, T., Sterken, C., 2002, ASP Conf. Ser., 256, 79, in Observational
Aspects of Pulsating B- & A Stars.,

Hintz, E. G., Joner, M. D., Kim, C., 1998, PASP, 110, 689

Lampens, P., 1985, IBVS, 2794

Wils, P., Hambsch, F. J., Lampens, P., et al., 2010, IBVS, 5928

Wils, P., Hambsch, F. J., Robertson, C. W., et al., 2011, IBVS, 5977

Zhou, A.-Y., Liu, Z.-L., 2003, AJ, 126, 2462


# Applying Model-based Requirements Engineering in Three Large European
Collaborative Projects: An Experience Report ††thanks: This work has received
funding from the ECSEL Joint Undertaking under grant agreements No. 737494
(MegaM@Rt2 project) and No. 101007350 (AIDOaRt project), from ITEA3 (REVaMP2
project No. 15010) and from H2020 under grant agreements No. 732064 (DataBio
project) and No. 957212 (VeriDevOps project).

Andrey Sadovykh  Innopolis University \- SOFTEAM
Innopolis, Russia - Paris, France
<EMAIL_ADDRESS>
<EMAIL_ADDRESS>Dragos Truscan  Åbo Akademi University
Turku,Finland
<EMAIL_ADDRESS>Hugo Bruneliere  IMT Atlantique, LS2N (UMR CNRS 6004)
Nantes, France
<EMAIL_ADDRESS>
###### Abstract

In this paper, we report on our 5-year’s practical experience of designing,
developing and then deploying a Model-based Requirements Engineering (MBRE)
approach and language in the context of three different large European
collaborative projects providing complex software solutions. Based on data
collected both during projects execution and via a survey realized afterwards,
we intend to show that such an approach can bring interesting benefits in
terms of scalability (e.g. large number of handled requirements),
heterogeneity (e.g. partners with different types of RE background),
traceability (e.g. from the requirements to the software components),
automation (e.g. requirement documentation generation), usefulness or
usability. To illustrate our contribution, we exemplify the application of our
MBRE approach and language with concrete elements coming from one of these
European research projects. We also discuss further the general benefits and
current limitations of using this MBRE approach and corresponding language.

###### Index Terms:

Requirements Engineering, Model-based Engineering, Collaborative Projects,
Experience Report, Scalability, Heterogeneity, Traceability, Automation

##  I Introduction

In many countries, funded collaborative projects involving academic partners
and industrial ones, either SMEs or large enterprises, are a preferential way
of implementing ambitious Research and Innovation Actions (RIAs) [1, 2]. Such
projects are also frequently used in order to foster international
collaborations and to develop corresponding long-term partnerships between
organizations from various countries. This is notably the case in Europe,
where the European Commission has several active funding bodies proposing
various kinds of funding programmes targeting different societal, economical
and scientific grand challenges [3].

In the context of such collaborative projects in the Software and Systems
Engineering area, possibly important in terms of the number and variety of
involved partners and countries, the main expected results are generally large
and complex integrated frameworks or tool sets. In order to allow for their
actual design, development and deployment, it is thus fundamental to be able
to support and manage as efficiently as possible the corresponding
Requirements Engineering (RE) processes [4], from the initial identification
of the industrial needs to their actual realization within the final
innovative solutions.

As it can be observed in the literature, the state-of-art in RE is already
rich in terms of approaches and corresponding technical solutions [5]. Among
other paradigms, some of these approaches rely on model-based concepts [6].
This notably reflects the fact that model-based principles and techniques have
become more popular in industry over the last two decades, as they can provide
relevant abstraction, genericity or reusability capabilities (for example)
[7].

In this paper, we report on our practical experience of proposing and applying
a Model-based Requirements Engineering (MBRE) approach and language during 5
years in the context of three different large European collaborative projects,
each one of them providing as a result various complex software solutions
(e.g. frameworks, integrated tool sets, etc.). The approach was mainly
developed by the SOFTEAM company and applied in 3 different research projects
in which SOFTEAM participated in the technical coordination activities. With
this reporting and data analysis work, we notably intend to show that such a
MBRE approach can bring interesting benefits in terms of scalability (e.g.
large number of handled requirements), heterogeneity (e.g. partners with
different profiles and types of RE background), traceability (e.g. from the
initial requirements to the software components), automation (e.g. requirement
documentation generation), as well as general usefulness or usability.

The remainder of the paper is structured as follows. Section II introduces the
general context and background of this experience report. Then, Section III
highlights relevant related work while Section IV describes the MBRE approach
we proposed in order to support RE processes in collaborative projects.
Section V evaluates this approach and its practical application in the context
of three different large European collaborative projects. Finally, Section VI
discusses the main lessons learned from this experience while Section VII
concludes the paper.

##  II Context and Background

European collaborative projects are one of the main sources of innovation in
Europe [2]. There are several funding bodies such as ECSEL, Horizon 2020,
ITEA, etc. coming with different types of funding programmes. The funded
projects all have in common that a number of organizations (academic or
industrial) from several European countries participate in a collaborative
research effort. The average number of partners in such projects varies
according to the funding framework. For example, this goes from 4.69 in
Horizon 2020 [8] to 30 and 40 for Research and Innovation Actions and
Innovation Actions ECSEL projects respectively [9]. However, it is not unusual
that ECSEL projects exceed 100 organizations [10].

A key element of such European research projects is the complementarity of the
project’s participants. These participants can come from different application
domains (e.g. railway, avionics, telecom, manufacturing), have different
company sizes (e.g. from small and medium enterprises to large industrial
groups) and levels of maturity related to the project’s challenges, or come
with different kinds of research background. They have to work together to
achieve a set of shared R&D goals, usually validated via several case studies
that serve as a common platform for experimenting on newly designed and
developed technologies. The overall objective is to provide evidence to the
European Commission of the benefits and drawbacks, both scientific and
economical, that the innovative technologies developed in the context of the
project can offer.

However, the diversity and number of partners can also imply project
management challenges related to 1) the elicitation of the needs from the
industrial case study providers and 2) the identification of not only the
concrete solutions to be provided during the project (lasting typically three
years), but also of a roadmap for the development of the final technical
solution. These challenges are amplified by the number of partners in the
project and by the diversity of their (scientific and technical) backgrounds
and of their application domains. When challenges are not addressed properly,
they can negatively influence the outcomes of the project [11].

Therefore, appropriate RE practices become a necessity for maximizing benefits
for a larger number of partners in order to achieve good technical results in
such projects. Those RE practices span over all areas of the RE process such
as requirements elicitation, specification, validation and management [4]. The
approach proposed in this paper applies model-based principles and techniques
in order to support and improve the RE process in the context of possibly
large and diverse collaborative projects. With our approach, we intended to
provide better scalability, improved support for heterogeneous types of
partners, as well as more complete tool support and automation for managing
the requirements of the developed solutions.

In practice, the proposed approach was designed, developed, matured and
actually applied in three large European projects covering a period of 5 years
(cf. Section V-A for more details and data on these different projects):

  * •

H2020 DataBio 2017-2019 - Data-Driven Bioeconomy [12]
(https://www.databio.eu/),

  * •

ITEA3 REVaMP2 2016-2019 - Round-trip Engineering and Variability Management
Platform and Process [13] (http://www.revamp2-project.eu/),

  * •

ECSEL MegaM@Rt2 2017-2020 MegaModeling at RunTime [14]
(https://megamart2-ecsel.eu/).

In this paper, we specifically focus on the three above-mentioned projects as
the most recent ones from our side. However, we have already faced the similar
challenge to coordinate RE processes and tool framework developments in more
than 15 similar European collaborative research projects.

##  III Related Work

Requirements Engineering (RE) is the process of identifying, describing, using
and maintaining requirements within engineering processes [4, 15]. There is a
general consensus on the main steps of RE processes [16, 17]: 1) requirements
elicitation, 2) requirements analysis, 3) requirements specification and 4)
requirements validation. Requirement management is a transverse activity
covering all these steps and ensuring their smooth running. Even if
requirements have been used for a long time in different disciplines, the RE
advent mostly coincides with the software expansion in the 90’s [18]. This
resulted in the progressive growth of an active research community working on
various related challenges [19, 5].

By nature, RE always implies a modeling-related activity [20]. Thus, model-
based principles and techniques have already been applied in the past to
address different kinds of RE activities [6]. Notably, this resulted in
acknowledged contributions such as goal modeling languages for instance [21,
22] or in the quite recently proposed ReqIF requirement modeling standard
[23]. Besides, RE has also been sometimes applied in the context of model-
based development processes [24]. However, up to our current knowledge, few
model-based approaches have been proposed to cover complete RE processes in
the general case. For example, an existing solution relies on a generic
modeling framework to represent (and simulate) requirements independently from
the context [25]. Another one is based on a core requirements metamodel to be
customized in order to support various kinds of RE processes [26]. In
addition, we can also mention transformation-based approaches from goals or
requirements models to design models, such as the KAOS method [27].

Closer to the context and background of our work, a few model-based approaches
have already been proposed and used inside collaborative research projects to
handle, at least partially, corresponding RE processes. However, either they
have been deployed only in the context of a single project [28] or they were
mostly focusing on some particular RE aspects such as requirements
visualization [29], for instance. In this paper, we rather intend to propose
and use a model-based RE approach that is potentially covering more complete
RE processes, including important features such as requirements traceability
and automated documentation generation. We intend to make such a support
practically available in the context of different large collaborative projects
involving both heterogeneous and numerous partners.

From a more industrial perspective, and in order to foster genericity,
reusability and interoperability, the proposed MBRE approach and language are
rooted in well-known and acknowledged software and system modeling standards:
UML [30] and SysML [31]. Moreover, they are also partially inspired by the
European Space Agency standard terminology and structure for RE documents
[32].

##  IV Proposed Approach

As a solution to the problem of covering complete RE processes in the context
of large collaborative projects involving many different kinds of partners, we
propose a MBRE approach accompanied by a dedicated modeling language and the
corresponding tool support. We give an overview of this approach in Section
IV-A and we describe the corresponding RE language we designed in Section
IV-B. In Section IV-C, we also provide more details on how these approach and
language have been concretely implemented and supported in the Modelio tool.

###  IV-A Overview of our Conceptual Approach

Our MBRE approach is natively defined to take into account the typical
participant roles in collaborative research projects: Case Study Providers
have a practical problem, e.g. in terms of development processes, product
quality or features, for which they are looking for innovative solutions;
Research Partners develop new research methods and prototypes and Technology
Providers offer technological solutions, in collaboration with the research
partners, that can be deployed and evaluated against the industrial case
studies. It is the task of the technical coordination team to both ensure a
smooth collaboration between the involved parties and make sure that the
project’s objectives are achieved.

Figure 1: A conceptual approach for MBRE.

As illustrated in Figure 1, our approach proposes that the technological
solutions in such collaborative research projects are provided in the form of
a generic framework. The requirements of the framework are elicited from the
requirements of the industrial case studies in the project. The framework
aggregates Tool Components which are specific to different application domains
and applicable to one or several case studies. Each tool component is
developed by different project participants based on Tool Component
Requirements, also sometimes called “Tool Purposes”, which satisfy the
framework requirements. Each tool component will have a specific architecture
including the interfaces available for being interconnected with other tools.
This notably allows for different tool chains to be easily created for
specific case studies. Each tool component is developed throughout the project
with different priorities and becomes available at different milestones
according to the Tool Component Roadmap.

Based on the individual tool component architectures and roadmaps, the
technical coordination team can design the Framework Architecture and the
Framework Development Roadmap. Such a roadmap will allow the case study
provider to know when different technologies will be available for evaluation,
and consequently to create Case Study Requirements Validation Roadmaps. When
different Tool Component Implementations become available at different
milestones of the project, they are integrated in the framework and evaluated
against the case studies in the Case Study Requirements Validation and
Solution Evaluation process.

The above process is applied continuously during the implementation of the
project. However, several challenges have to be addressed for ensuring a
smooth process.

The first challenge that we address is the elicitation of the framework
requirements that support the needs of the industrial case study providers
(i.e., the case study requirements). This step is not trivial since it
requires the collaboration of all the partners in the project, each one coming
from different application domains and having different technical backgrounds.
Having a centralized and clear mapping between case study requirements on one
hand, and the framework and tool components requirements on the other hand,
also allows the technical coordination team to track the progress of the
project, to spot further needs for technical solutions and to mitigate the
risks of the project.

The second challenge that we address is to create a roadmap for the
development of the framework by collecting development plans for individual
tool components. This will allow all partners in the project to be aware of
when different features of the framework will be implemented. This will also
allow case study providers to know when these tools can be evaluated against
their own case studies. In addition, having such a roadmap allows the
technical coordination team to better plan and produce different deliverables,
demonstrations and thematic events in the project.

###  IV-B A Dedicated Modeling Language for RE

In order to realize the proposed conceptual approach, and to represent and
share appropriately the requirement data during the full RE process, we worked
on a dedicated modeling language for MBRE. The reason for developing a
dedicated language, rather than directly using an already existing one, is
that the commonly used modeling languages (i.e. general-purpose ones such as
UML) are very wide in terms of scope. Thus, users tend to have multiple and
different ways to specify requirements and corresponding design decisions when
using them. This is actually an issue in our context of large collaborative
projects involving partners with different backgrounds and experiences.

As a solution, we decided to design and build our modeling language by
following a bottom-up approach: We started by analyzing what were the
documents (i.e. deliverables) generally needed in terms of both requirements
and architecture in the context of large collaborative projects. To this end,
we notably studied standard representation formats such as ESA ESS [32] as
well as standard modeling languages such as UML [30]. Then, inspired by such
standards, we designed a generic modeling language that would help in
supporting and simplifying the automated generation of these
documents/deliverables. The different aspects of the resulting modeling
language are presented in what follows.

####  IV-B1 Abstract Syntax

The main concepts of our dedicated modeling language for RE are depicted in
Figure 2.

Figure 2: Metamodel describing the abstract syntax of our RE modeling
language.

At the Requirements level, the base element is the Requirements Container that
is used to logically group sets of related requirements (e.g. requirements
attached to a same tool). Each Requirement is represented by various
properties such as an identifier, a definition, a criticality level, a
corresponding release, a status and additional comments if any. The
criticality level indicates the priority for the requirement’s implementation
(i.e. low, medium or high). The release indicates the milestone at which the
requirement is planned to be satisfied (i.e. baseline, initial, intermediate
of final). The status indicates the state of fulfillment of the concerned
requirement (i.e. planned, in progress, done, postponed or cancelled). The
comments provide additional information on the concerned requirement. A given
requirement can be connected to another requirement it depends on via a trace
dependency link. For example, a Tool Requirement (also called Tool Purpose)
can be linked to a corresponding Framework Requirement, and this Framework
Requirement to a corresponding Case Study Requirement. Moreover, any
architectural element realizing a given Requirement can be mapped to it via a
satisfy dependency link.

At the Architecture level, the base element is the Package that is used to
logically group sets of related Framework or Tool Components, common
interfaces of platform nodes. Each Component depicts a tool or its constituent
part. A given component can be composed of different sub-components to
represent its various constituent parts. An Interface described a required
functional service (e.g. XMI import/export). It can be connected to a
component via an interface realization link to indicate a provided service,
e.g. the tool component’s output, or via an use dependency link to indicate a
consumed service, e.g. the tool component’s input. A Node represents a
deployment platform (e.g. Eclipse RCP, a Java virtual machine, etc.). A given
component can be connected to different nodes, i.e. its deployment platforms.

####  IV-B2 Concrete Syntax

Attached to the abstract syntax of our language as introduced just before,
various kinds of concrete notations could be envisioned, either graphical,
textual or combining both. Based on our own experiences, and notably the
industrial experience of SOFTEAM when using Modelio-based solutions for their
customers’ projects, we decided to consider a combination of tabular views and
UML/SysML-like diagrams as the syntax for our RE language.

In terms of diagrams, a SysML Requirements diagram is used to graphically map
the different tool components to their respective tool requirements/purposes
and then to their corresponding case study requirements. A UML Class diagram
is used to both describe a component and their constituent parts and describe
its required and provided interfaces. It is also used to map individual tool
components to conceptual frameworks components. Finally, a UML Deployment
diagram is used to represent the nodes showing the deployment constraints of
the different tool components.

As far as tabular views are concerned, they are mostly used in order to easily
enter and then properly display various properties of possibly very large sets
of requirements.

Figure 3: Example view of the concrete syntax of our RE modeling language, as
implemented in the Modelio tool.

Figure 3 illustrates this concrete syntax, as currently implemented in the
Modelio tool (cf. Section IV-C), on an example RE model from the MegaM@Rt2
project. In this particular example, we can see in the tabular view a set of
tool requirements/purposes for the Modelio tool itself. These tool
requirements are grouped in a same requirements container named “Modelio
(SOFT)” (cf. left panel). On the related diagram (cf. bottom view), we can see
how a given Modelio tool requirement “MODELIO-030” is traced to some framework
requirements “SYS-020201”, etc. and then, by transitivity, to some case study
requirements “NOK-02”, etc. We can also see that a given tool component
“Modelio (SOFT)” satisfies a corresponding tool requirement “MODELIO-030”.

####  IV-B3 Semantics

As partially extending UML core concepts, the semantics of our RE language is
directly connected to the semantics of UML. For instance, we consider the
concepts of Package, Component, Interface, Node and various types of links as
having the same meaning that prescribed by UML. However, in order to make the
models universally understandable and reusable by other persons relying on our
RE language, we limited their usage to the strict definitions provided in
Section IV-B1. As introduced earlier, one of the main objectives of our RE
language is to allow for the automated generation of corresponding
requirements, architecture and roadmap documents. Thus, RE models expressed in
our language are meant to be interpreted by (i.e. taken as inputs of) specific
document generators. As a consequence, part of the semantics of our RE
language is also embedded in the source code of these document generators. For
example, a Package would often correspond to a first-level chapter in the
specifications. A Common Interface is a section of the Software Requirements
Specification (SRS) where we list the information that is very helpful for
integration. Besides, each Tool Component section will have exactly four
subsections based on the used diagrams (cf. Section IV-B2): The SysML
Requirements diagram is the main source to extract information about the
features (existing or planned) or a component, the UML Class diagram maps to
the corresponding section giving more information on provided and required
services, etc. Basically, the document generator would navigate the whole
model from its root and, when getting to an element with a corresponding type
e.g. a Package providing Common Interfaces, it will collect the corresponding
data from the model and then integrate them into paragraphs, tables, matrices
and figures of the generated document, cf. a deliverable generated in
MegaM@Rt2 for example[33].

###  IV-C A Modelio-based Implementation of the RE Approach and Language

The complete MBRE approach and language presented in this paper have been
implemented in the Modelio tool [34] developed by SOFTEAM. In the DataBio
project, we first experimented with extending/refining ArchiMate as the high-
level representation for architecture. However, due to the constraints imposed
by the ArchiMate metamodel, collaborative modeling was quite tedious in
Modelio. For example, the locking of a single element was leading to the
locking of a large portion of the model, possibly impacting other users.
Moreover, ArchiMate is quite new and much less adopted in the industry. This
would have resulted in a steeper learning curve, such a limitation being
partially reflected in the survey data presented in Section V-B. These are the
reasons why, in the subsequent REVAMP and MegaM@Rt2 projects, we rather opted
for extending/refining UML as 1) allowing atomic editing of components and 2)
being already widely known in the industry.

Figure 4: Structure of the RE model in Modelio: The practical example of the
MegaM@Rt2 project.

The main elements of a RE model in Modelio are shown in Figure 4, with respect
to the MegaM@Rt2 project as a practical example. Conforming to our RE language
as described in IV-B, the overall structure of the RE model includes both the
Requirements and Architecture levels. For the Requirements level, we directly
benefited from Modelio Analyst features such as Requirements Containers,
Tabular, Diagram view, Traceability matrices and Import from Excel. Modelio
also allowed us to specialize the Requirements properties (that correspond to
the columns in the tabular view) in order to implement our approach and
language. For the Architecture level, we relied on the standard implementation
of UML as currently available in Modelio. We refined this UML implementation
in order to limit the use of UML to the concepts considered in our RE
language. Moreover, in order to facilitate the initial use of the RE language,
we also built-in a specific template for tool components and made it available
directly from the Modelio workbench. This way, the users of our RE language in
Modelio can benefit from clear guidelines on what is expected from them when
elaborating on their Requirements model.

The Modelio Document Publisher was also a major feature that helped us to
construct our MS Word document generator. Indeed, Modelio provides a
simplified document template editor with graphical interface that has pre-
build functionalities for navigating the model, filtering model elements,
extracting textual notes and diagrams, as well as building sections,
paragraphs, tables and matrices. These features were particularly useful,
since they allowed us to generate important parts of our documents. This is
notably the case for roadmaps, where we created tables displaying mappings
between case study requirements and tool requirements indicating planned
delivery dates. Based on such roadmaps, the case study providers could
anticipate and organize both the building of their tool chains and their
validation activities. Moreover, the traceability information contained in the
RE model was extremely important in order to identify the case study
requirements that are not addressed by any of the tool components. This way,
we were able to conduct gap analysis from our RE model in order to better plan
corrective actions.

In addition to the base implementation of our MBRE approach and corresponding
language, our Modelio-based implementation also provides additional features
which are particularly relevant in the context of RE processes within large
collaborative projects. For example, it is possible to relate and trace our RE
models to elements coming from other kinds of models in Modelio (Enterprise
Architecture models expressed in ArchiMate [35], business models in BPMN [36],
system models in SysML [31], etc.). It is also possible to import requirements
from external tools (e.g. Microsoft Excel) and to integrate them in our RE
model. Moreover, complementary to the already provided document generators,
new generation capabilities can potentially be added to target other kinds of
text-, diagram-, table- and matrix-based representations for the RE
information Finally, our Modelio-based implementation directly benefits from
the collaborative features provided by the Modelio environment: support for
locking / unlocking model elements, commit and update, user, configuration or
version management, etc.

##  V Evaluation

In order to evaluate our MBRE approach and language, we collected various
kinds of data associated with the three large collaborative projects
considered in the present experience report. We describe quantitative and
qualitative data resulting from both the projects’ execution, in Section V-A,
and a survey realized after the end of these projects, in Section V-B. In
Section V-C, the collected data is then used to assess the relevance of our RE
approach and language according to main targeted properties.

###  V-A General Data on Projects

The proposed MBRE approach and language have been designed, developed and then
deployed in the context of three large collaborative projects, financially
supported by the European Commission under different R&D funding programs.

The first project is named DataBio, standing for Data-Driven Bioeconomy
(Horizon 2020). It lasted 3 years from 2017 to 2019 and involved 48 partners
from 17 countries, for a total budget of € 15M. 27 industrial pilots / use
cases in the agriculture, forestry and fishery areas have been considered
during the DataBio project.

The second project is named REVaMP2, standing for Round-trip Engineering and
Variability Management Platform and Process (EUREKA ITEA3). It lasted 3 and a
half years from 2016 to 2019 and involved 27 partners from 5 countries, for a
total budget of € 22M. Seven industrial use cases in the cyber-physical
systems, electronic systems or tourism areas have been considered during the
REVaMP2 project.

The third and last project is named MegaM@Rt2 [14], standing for MegaModeling
at RunTime - An scalable model-based framework for continuous development and
runtime validation of complex systems (ECSEL). It lasted 3 years from 2017 to
2020 and involved 27 partners from 6 countries, for a total budget of € 16.7M.
9 industrial use cases in the aeronautics, warehousing, automotive,
construction, transportation or telecommunication areas have been considered
during the MegaM@Rt2 project.

Complementary to these global projects figures, we provide in Table I
additional data displaying the level of activity in terms of RE, as registered
during these three projects.

TABLE I: Key figures related to the DataBio, REVaMP2 and MegaM@Rt2 projects in terms of RE activity.  | DataBio | REVaMP2 | MegaM@Rt2
---|---|---|---
No. of registered | 55 | 43 | 56
users in the Requirements |  |  |
model repository |  |  |
Number of contributors | 31 | 24 | 27
to the Requirements model |  |  |
No. of commits to | 958 | 534 | 1322
the Requirements model |  |  |
No. of , | 211 | 535 | 458
handled requirements |  |  |
in the Requirements model |  |  |
Total no. of model elements | =5052 | =2751 | =3902
(Requirements level | 181 | 535 | 458
\+ Architecture level) | 4871 | 2216 | 3444
in the Requirements models |  |  |
Size of the generated | 61 | 109 | 125
SRS document from the |  |  |
Requirements model |  |  |
(no. pages) |  |  |

The data show that the number of individuals involved in the RE process,
whether they are just registered users having a “read-only” profile or
actually active contributors having a read-and-write profile, was relatively
important and globally similar in the three projects.

In terms of RE activities, as illustrated in our case by the number of commits
on the Requirements model, we however observed a disparity between the three
projects even though it stays globally important in all of them. This can be
explained by the slightly different size of the three projects e.g. in terms
of number of partners or use cases. This can also be partly explained by the
nature of the single commits: A given user can frequently do small single
commits to the Requirements model while another can rather commit a large
number of updates as a single commit.

In terms of the Requirements models themselves, the data highlight the
globally high number of handled requirements and related elements in the
context of the three projects. We can observe differences between the projects
but, as stated before, this can be explained by the specificity of each
particular project e.g. the number of partners and the use cases to be
covered. These differences are also directly reflected and visible in the
number/size of the various project’s documents or deliverables generated from
the Requirements models in the three projects. We also want to note that the
initial use of ArchiMate in the DataBio project, as previously mentioned in
Section IV-C, does not have a significant influence since the number of
concepts considered for modeling the architecture is exactly the same than in
UML. The slightly bigger numbers can be rather explained by the greater size
of the DataBio project in terms of involved partners and tools.

###  V-B Survey for Projects’ Participants

In order to be able to evaluate our MBRE approach and language according to
more data, we have also run a complementary survey among the members of the
MegaM@Rt2, REVAMP and DataBio projects. The key research hypothesis we want to
validate is whether our approach is relevant and helpful in the context of
large collaborative research projects. We started with three quantitative
assessment questions:

  * •

Q1: In your opinion, did you find this graphical model-based approach useful
in different activities of Requirements Engineering? Followed by the list of
main RE activities.

  * •

Q2: In your opinion, do you see the modeling approach as an improvement
compared to other non-modelling (e.g. text-only or table-based) regarding the
following aspects? Followed by the list of characteristics that the
requirements have to follow, such as correctness and traceability [37].

  * •

Q3: In your opinion, did you find the following Modelio tool features useful
in different Requirements Engineering activities? We listed all presumably key
features of Modelio that could be considered helpful.

In addition to these quantitative assessment questions, we proposed to answer
three qualitative assessment questions:

  * •

Q4: In your opinion, what was the most challenging aspect of the Modelio-based
approach?

  * •

Q5: In your opinion, what was the most challenging aspect of the Modelio-based
approach?

  * •

Q6: In your opinion, which additional Modelio tool features would have been
useful for Requirements Engineering in the project?

The potential respondents were all project partners who had an account in the
shared model repository and presumably had access to the modelling. We
excluded the authors from the survey in order to avoid the subjectivity bias,
even though they were primary beneficiaries of the approach as responsible for
architecture definition in the MegaM@Rt2 project.

In total, we had 154 individual contact persons: 55 for DataBio, 43 for REVAMP
and 56 for MegaM@Rt2. We received 15 complete answers, including 1 person not
involved in RE activities. We explain this level of participation by a couple
of factors: (1) Few of these contact persons were active contributors to the
RE process in these projects, most of them were “readers” or contributed very
few elements; (2) It has been at least 1 year since the projects terminated
and at least 2 year since the end of the corresponding RE work. While this
amount of data cannot be considered statistically representative, we believe
the received feedback still provides interesting and relevant complementary
insights.

Overall, 76.95% of respondents would agree or strongly agree that our model-
based RE approach implemented in Modelio was useful. For Q1, 90% would agree
that graphical model-based approaches are useful for RE. For Q2, 65% would
agree the modeling approach is better for RE. For Q3, 79.59% would agree that
Modelio was useful for RE.

In Q1, all respondents (100%) agree that model-based approaches are useful in
Requirements analysis and negotiation. However, only 80% find that model-based
approaches are useful in Requirements validation.

In Q2, the highest agreement (86.67%) concerns the advantages of a model-based
approach regarding Traceability – can be linked to system requirements,
designs, code, and tests. The lowest agreement (53.33%) concerns the benefits
of model-based versus non-model-based approaches for dealing with Correctness
– accurately states a customer or external need and Clearness – has only one
possible meaning.

In Q3, all respondents (100%) would find Changing/adding dependencies useful
in the implementation of our approach. The lowest agreement (57.14%) concerns
the usefulness of Roadmapping (e.g. setting up expected delivery dates and
completion stage for designed components). However, this feature was
introduced in the Mega@Rt project only, where 80% (4/5) of the respondents
would find it useful.

Moreover, we asked additional questions on the appropriateness of our
approach. This notably resulted in the following assessments:

  * •

85.71% would find the approach appropriate for the given size and scope of the
project.

  * •

92.86% would find the tool support useful for guiding the RE process and
enforcing project conventions.

  * •

71.43% would find the approach easy to learn.

  * •

78.57% would find the approach easy to apply.

  * •

78.57% would apply a similar approach in future.

Finally, we also received some open qualitative feedback. Respondents
generally mentioned the difficulty to convince stakeholders to apply the
approach as well as difficulties in terms of model synchronization during
collaborative editing. More positively, respondents also mention their
appreciation in terms of the standardization of the RE process provided by our
approach, the improved traceability support or the fast and clean
documentation generation.

For the sake of completeness and transparency, the summary of the survey
results is publicly available [38] as well as the fully detailed answers from
the participants [39].

###  V-C Overall Assessment of our MBRE Approach and Language

Based on all the collected data presented in Section V-A and Section V-B), we
can provide a first assessment of the relevance of our MBRE approach and
language according to the main properties introduced in Section I:

  * •

Scalability \- The consolidated data extracted from the Requirements model
repository in the three projects clearly shows that we have been able to
support a significant number of users, including regularly active ones, as
well as to handle a relatively large number of requirements and related model
elements. Moreover, the final success of the three projects in terms of
deliveries (i.e. documents, tools, demonstrators) and the results of the
survey also demonstrate the general scalability of our MBRE approach and
language, at least for projects going up to the size of the three mentioned
ones.

  * •

Heterogeneity \- The varied characteristics of the three projects (e.g.
different partners providing different kinds of tools and technologies,
various use cases covering several application domains) show that we have been
able to handle a certain level of heterogeneity. Based on our experience in
these three projects, and the participants’ feedback we collected via the
survey, we can also argue that our MBRE approach and language can be applied
similarly in any large collaborating project whose main purpose is to produce
integrated software solutions.

  * •

Traceability \- Looking at the results of the projects participants survey
notably, we can state that traceability and the capability to guide and
enforce full RE processes from the beginning to the end of collaborative
projects has been one of the most acknowledged features of our MBRE approach
and language. Even though improvements and/or extensions are still possible,
e.g. tooling support for traceability down to the source code, the feedback
received up to now already highlights a correct support for traceability.

  * •

Automation \- The quantitative data collected at the end of the three projects
show that we have been able to automatically generate documents of significant
sizes from the corresponding Requirements models. These were quite complete
requirements, architecture or roadmap documents whose content could be then
reused directly to produce the official projects deliverables. The achieved
level of automation, though not total, was already quite appreciated by the
projects’ participants.

  * •

Usefulness and Usability \- The fact that our MBRE approach and language have
been successfully used in practice in the context of three different
collaborative projects already shows a certain level of usability. The
qualitative data collected from the participants’ survey also confirm that the
users globally found our approach useful during these three collaborative
projects. Furthermore, they appreciated in particular the fact that the
approach was easily applicable in their respective contexts, i.e. both easy to
learn and to apply.

##  VI Discussion

In what follows, we discuss further the contributions proposed in this paper
as well as our own experience in their contexts. We notably present general
lessons learned from the three collaborative projects in Section VI-A. We also
describe in Section VI-B a few threats to validity we have identified
concerning the current evaluation of our MBRE approach and language. Finally,
we introduce in Section VI-C some open challenges concerning both our approach
and its applications in other contexts in the future.

###  VI-A Lessons Learned

From our global experience of designing and then applying our MBRE approach
and language in the context of three different large collaborative European
projects, we have been able to extract some general lessons learned we hope to
be useful to the RE community as well as more globally to the whole Software
Engineering community:

  * •

Project management \- The received feedback shows that our MBRE approach and
language is mostly beneficial from a project management perspective: One of
the most valuable user features appeared to be the automation capability.
Notably, the possibility to perform more easily gap analysis and obtain a
corresponding roadmap, or the possibility to generate long documents directly
from the Requirements model, were highly appreciated.

  * •

Software architecture \- Moreover, the proposed approach and language also
appeared to be relevant from a software architecture perspective. Notably, the
mostly appreciated features were related to the support for collaborative
work, integration with a model repository, etc. The combination of well-known
diagrams coming from UML and SysML with tabular views was also perceived as a
good way to facilitate the use of our solution, especially for partners
already having experiences in modeling or related activities.

  * •

Learning curve \- Some participants in our projects had a somehow limited
previous experience in modeling, both conceptually and technically. This
resulted in difficulties for them to catch up with some of the concepts
proposed by our RE language. In this same vein, it also appears that the
guidelines initially provided, both on the approach/language and on the
Modelio tooling itself, were not sufficiently detailed in order to allow for a
first usage. Fortunately, this was quickly fixed by the Modelio team thanks to
the organization of online hands-on sessions for example. The participants
were then more easily able to go on with their RE activities in the context of
their respective projects.

###  VI-B Threats to Validity

In this paper, we evaluated the proposed MBRE approach and language according
to different kinds of data we were able to collect both during and after the
end of the three European collaborative projects mentioned earlier.

The main threat to validity probably concerned the amount of data we have been
able to gather. Our MBRE approach and language have been deployed in ”only”
three different projects from which we have extracted mostly quantitative
data. However, the fact that these were large projects that run over 5 years
in total already provides a certain level of confidence about the quality and
relevance of the collected data. Moreover, we complemented this quantitative
data with extra data (quantitative but also qualitative this time) we obtained
as a result of a survey largely distributed among the three projects
participants. Obviously, it would have been more significant to get more
answers to the survey. However, we believe the collected feedback coming from
15 different participants is already interesting in order to improve our
global appreciation of the proposed solution.

###  VI-C Next Steps and Challenges

The very next step of our work will consist in improving our experience with
the proposed MBRE approach and language by applying in the context of another
large collaborative project. This will actually be the case as we are now
starting RE activities in the context of two new European projects -
VeriDevOps (H2020) [40] and AIDOaRt (H2020 ECSEL) that will run 3 more years
and involve more than 40 partners, both industrial and academic ones, coming
from 7 different countries. As also strongly involved in these new projects,
we (the authors) have already planned to work on deploying again our MBRE
approach and language. This way, we hope to be able to 1) collect more
relevant feedback from our partners and 2) upgrade our solution accordingly.
For instance, similarly to what we did in the MegaM@Rt2 project, we plan to
experiment further on the use of our MBRE approach and language in the context
of hackathons mixing both business and technical people [41].

Moreover, as a result of the work and overall experience reported in this
paper, we also identified some challenges we believe to be worth investigating
as far as MBRE or more generally RE is concerned:

  * •

From requirements to source code \- Our requirements models contain
information concerning mostly the needs and architectural decisions at the
project level. While this is already useful for coordinating the common global
effort towards the realization of the target solution, it remains relatively
far from being full model-driven development where implementation and
verification artifacts can be produced from the models. Thus, more efforts
still have to be made in order to better mind this gap between the
architecture and development levels in our MBRE solution and also possibly in
others.

  * •

User training and support \- In our RE language, we deliberately restricted
the UML usage to a limited number of concepts. We also provided tooling
support, user guidelines and online workshops to make the life of the various
projects’ partners easier. Nevertheless, the partners appeared to still need
constant support with the tooling and the approach. Thus, we strongly believe
that the usability and learning curve of RE solutions are key elements to
consider and improve accordingly in order to allow for their large industrial
dissemination.

  * •

Collaborative and online work \- One of the most reported issues concerned
restrictions in the collaborative editing capabilities provided by our MBRE
solution as relying on a Subversion-based lock - edit - commit - release
operation mode. The fact is that, nowadays, users generally tend to prefer
online editing collaboration modes e.g. via their favorite Web browser.
However, we have seen limited support for that so far in existing modelling
tools or even in popular IDEs. Such a support for online collaboration at the
requirements level is probably a path to be explored more deeply in the future
as far as RE solutions are concerned.

  * •

Automation and production \- There are still open challenges related to the
support for automation in RE processes and more generally in Software
Engineering processes. For instance, we could have considered to build-in some
more automated support for document generation or even code generation.
However, it is always a matter of cost/benefit balance since development
resources can be limited in collaborative R&D projects. Thus, our MBRE
solution is still not in full production stage e.g. it requires some level of
customization for each new project, and it will need more work to be made
available as an actual product in the future.

##  VII Conclusion

In this paper, we reported on our practical experience of proposing and
deploying a Model-based Requirements Engineering approach and language during
5 years in the context of three different large European collaborative
projects providing complex software solutions. Our MBRE approach and language
mostly focused on supporting three complementary aspects: 1) requirements are
described appropriately at different abstraction layers (case study,
framework, tool), 2) requirements can be better interconnected and traced
during the RE process and 3) requirements can be used to (semi-)automatically
perform gap analysis, roadmap and corresponding document generation.

Based on this global experience and the collected data, we showed that our
MBRE approach and language can bring interesting benefits in terms of
scalability, heterogeneity, traceability, automation, general usefulness or
usability. We also discussed the added-value of our solution from a project
management and architecture perspective while identifying some limitations we
faced, in terms of RE solution learning curve for instance, and that we
already managed to partially overcome. As a conclusion, we have concrete plans
to continue working on extending and applying our MBRE approach and language
in the context of other large collaborative projects we will be involved in
the near future.

## References

  * [1] Richard Van Noorden and Declan Butler.  Science in europe: by the numbers.  Nature, 569, May 2019.
  * [2] European Commission-DG CONNECT.  Digital economy and society index (DESI) 2020 - the EU ICT sector and its R&D performance.  Online at https://ec.europa.eu/newsroom/dae/document.cfm?doc_id=72352.  Accessed: 2021-04-07.
  * [3] European Commission.  EU research programmes.  https://ec.europa.eu/info/funding-tenders/funding-opportunities/funding-programmes/overview-funding-programmes_en.  Accessed: 2021-04-07.
  * [4] IEEE/ISO/IEC.  International standard - systems and software engineering – life cycle processes – requirements engineering.  Technical Report 29148-2018, IEEE Standards Association, 2018.
  * [5] Betty H. C. Cheng and Joanne M. Atlee.  Research directions in requirements engineering.  In 2007 Future of Software Engineering, FOSE ’07, page 285–303, USA, 2007. IEEE Computer Society.
  * [6] S. Assar.  Model driven requirements engineering: Mapping the field and beyond.  In 2014 IEEE 4th International Model-Driven Requirements Engineering Workshop (MoDRE), pages 1–6, 2014.
  * [7] Marco Brambilla, Jordi Cabot, and Manuel Wimmer.  Model-Driven software engineering in practice.  Synthesis Lectures on Software Engineering, 1(1):1–182, 2012.
  * [8] Accelopment.  Lessons learnt from horizon 2020 for its final 2 years.  https://accelopment.com/blog/lessons-learnt-from-horizon-2020-for-its-final-2-years/, February 2019.  Accessed: 2021-04-07.
  * [9] Ecsel joint undertaking work plan 2020.  https://www.ecsel.eu/calls-2020-wp2020.
  * [10] ECSEL-JU.  Productive4.0 project.  https://www.ecsel.eu/projects/productive40.  Accessed: 2021-04-07.
  * [11] Daniel Nepelski and Giuseppe Piroli.  Organizational diversity and innovation potential of EU-funded research projects.  J. Technol. Transf., 43(3):615–639, June 2018.
  * [12] Andrey Sadovykh, Alessandra Bagnato, Arne J. Berre, and Stale Walderhaug.  Archimate as a specification language for big data applications - databio example.  In Jean-Michel Bruel, Manuel Mazzara, and Bertrand Meyer, editors, Software Engineering Aspects of Continuous Development and New Paradigms of Software Production and Deployment, pages 191–199, Cham, 2020. Springer International Publishing.
  * [13] Andrey Sadovykh, Tewfik Ziadi, Alessandra Bagnato, Thorsten Berger, Jan-Philipp Steghöfer, Jacques Robin, Raul Mazo, and Elena Gallego.  Revamp2 project: Towards round-trip engineering of software product lines - approach, intermediate results and challenges.  In Manuel Mazzara, Jean-Michel Bruel, Bertrand Meyer, and Alexander Petrenko, editors, Software Technology: Methods and Tools, pages 406–417, Cham, 2019. Springer International Publishing.
  * [14] Wasif Afzal, Hugo Bruneliere, Davide Di Ruscio, Andrey Sadovykh, Silvia Mazzini, Eric Cariou, Dragos Truscan, Jordi Cabot, Abel Gómez, Jesús Gorroñogoitia, Luigi Pomante, and Pavel Smrz.  The MegaM@Rt2 ECSEL project: MegaModelling at runtime – scalable model-based framework for continuous development and runtime validation of complex systems.  Microprocessors and Microsystems, 61:86–95, 2018.
  * [15] Jeremy Dick, Elizabeth Hull, and Ken Jackson.  Requirements Engineering.  Springer, Berlin, Germany, 2017.
  * [16] Klaus Pohl.  Requirements Engineering - Fundamentals, Principles, and Techniques.  Springer-Verlag Berlin Heidelberg, 2010.
  * [17] Axel Van Lamsweerde.  Requirements Engineering: From System Goals to UML Models to Software, volume 10.  John Wiley & Sons, Hoboken, NJ, U.S.A., 2009.
  * [18] Gerald Kotonya and Ian Sommerville.  Requirements Engineering: Processes and Techniques.  John Wiley & Sons, Hoboken, NJ, U.S.A., 1998.
  * [19] Bashar Nuseibeh and Steve Easterbrook.  Requirements Engineering: a Roadmap.  In ICSE 2000, pages 35–46, New York, NY, USA, 2000. ACM.
  * [20] Axel van Lamsweerde.  Requirements engineering in the year 00, 2000.
  * [21] Eric SK Yu.  Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering.  In ISRE 1997, pages 226–235, Washington, DC, U.S.A., 1997. IEEE Computer Society.
  * [22] Axel Van Lamsweerde.  Goal-Oriented Requirements Engineering: A Guided Tour.  In ISRE 2001, pages 249–262, Washington, DC, U.S.A., 2001. IEEE Computer Society.
  * [23] Object Management Group (OMG).  Requirements Interchange Format (ReqIF), 2020.
  * [24] Grzegorz Loniewski, Emilio Insfran, and Silvia Abrahão.  A systematic review of the use of requirements engineering techniques in model-driven development.  In Dorina C. Petriu, Nicolas Rouquette, and Øystein Haugen, editors, Model Driven Engineering Languages and Systems, pages 213–227, Berlin, Heidelberg, 2010. Springer Berlin Heidelberg.
  * [25] B. Baudry, C. Nebut, and Y. L. Traon.  Model-driven engineering for requirements analysis.  In 11th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2007), pages 459–459, 2007.
  * [26] Arda Goknil, Ivan Kurtev, and Klaas van den Berg.  A metamodeling approach for reasoning about requirements.  In Ina Schieferdecker and Alan Hartman, editors, Model Driven Architecture – Foundations and Applications, pages 310–325, Berlin, Heidelberg, 2008. Springer Berlin Heidelberg.
  * [27] Emmanuel Letier, Jeff Kramer, Jeff Magee, and Sebastian Uchitel.  Deriving event-based transition systems from goal-oriented requirements models.  Automated Software Engineering, 15(2):175–206, 2008.
  * [28] Stefan Karg, Alexander Raschke, Matthias Tichy, and Grischa Liebel.  Model-driven software engineering in the openETCS project.  In Proceedings of the ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems, 2016.
  * [29] H Solheim, F Lillehagen, S A Petersen, H Jorgensen, and M Anastasiou.  Model-driven visual requirements engineering.  In 13th IEEE International Conference on Requirements Engineering (RE’05), 2005.
  * [30] OMG Unified Modeling Language.  https://www.uml.org/.
  * [31] OMG Systems Modeling Language (SysML).  https://www.omgsysml.org/.
  * [32] European Cooperation for Space Standardization.  Space engineering software.  Technical Report ECSS-E-ST-40C, ECSS Secretariat ESA-ESTEC Requirements & Standards Division, Noordwijk, The Netherlands, March 2009.
  * [33] MegaM@Rt2 project.  Deliverable d2.2 MegaM@Rt2 design tool set specification.  https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5b8e1feb7&appId=PPGMS.  Accessed: 2021-04-07.
  * [34] Modelio: A Collaborative Business or Software Modeling Platform.  https://www.modeliosoft.com/en/.
  * [35] The ArchiMate Enterprise Architecture Modeling Language.  https://www.opengroup.org/archimate-forum/archimate-overview.
  * [36] OMG.  Business Process Model and Notation (BPMN).  https://www.omg.org/bpmn/.
  * [37] Karl Wiegers and Joy Beatty.  Software Requirements.  Pearson Education, August 2013.
  * [38] Survey on Model-based Requirements Engineering in Research Projects – Summary.  https://docs.google.com/forms/d/e/1FAIpQLSeYWv8quqq_pkTrKEP2XKd4iVGrxHt50_VjLiwAJIVq4X-4TQ/viewanalytics.  Accessed: 2021-04-07.
  * [39] Survey on Model-based Requirements Engineering in Research Projects – Detailed Answers.  https://drive.google.com/file/d/1LljYrzMiIzgyHEP6KNGh6RrMuTsi-QKh/edit.  Accessed: 2021-04-07.
  * [40] Andrey Sadovykh, Gunnar Widforss, Dragos Truscan, Eduard Paul Enoiu, Wissam Mallouli, Rosa Iglesias, Alessandra Bagnto, and Olga Hendel.  Veridevops: Automated protection and prevention to meet security requirements in devops.  In Design, Automation and Test in Europe Conference (DATE’20), 2020\.
  * [41] A Sadovykh, D Truscan, P Pierini, G Widforss, A Ashraf, H Bruneliere, P Smrz, A Bagnato, W Afzal, and A E Hortelano.  On the use of hackathons to enhance collaboration in large collaborative projects : - a preliminary case study of the MegaM@Rt2 EU project -.  In 2019 Design, Automation Test in Europe Conference Exhibition (DATE), pages 498–503, March 2019.