=Paper=
{{Paper
|id=Vol-3008/paper4
|storemode=property
|title=Non-Functional Requirements for Quantum Programs
|pdfUrl=https://ceur-ws.org/Vol-3008/paper4.pdf
|volume=Vol-3008
|authors=Lorenzo Saraiva,Edward Hermann Haeusler,Vaston Costa,Marcos Kalinowski
|dblpUrl=https://dblp.org/rec/conf/qce/SaraivaHCK21
}}
==Non-Functional Requirements for Quantum Programs==
https://ceur-ws.org/Vol-3008/paper4.pdf
Non-Functional Requirements for Quantum
Programs
Lorenzo Saraiva1 , Edward Hermann Haeusler1 , Vaston Costa2 and
Marcos Kalinowski1
1
Pontificia Universidade Católica do Rio de Janeiro.
R. Marquês de São Vicente, 225 - Gávea, Rio de Janeiro - RJ, Brazil
2
Universidade Federal de Catalão.
Av. Dr. Lamartine Pinto de Avelar 1120. Catalão - GO, Brazil
Abstract
Quantum computing is moving from a purely theoretical area to an area with practical applications,
allowing considerable performance efficiency improvements. The goal of this paper is to discuss non-
functional requirements for quantum programs. Based on experiences developing quantum software
for real quantum hardware we analyze hardware-related constraints and derive a set of generic non-
functional requirements for this type of program. We identified a set of five performance efficiency and
reliability related non-functional requirements that should considered when implementing a quantum
program for a quantum device. We also discuss available solution options to address the requirements.
There are high level solutions to deal with the hardware-related constraints described in our identified
requirements. While many of the them are specific to quantum programming languages and technolo-
gies, the scientific community is engaging to integrate these kind of solutions into the quantum software
engineering life cycle in an agnostic way regarding quantum programming languages and technologies.
Keywords
Quantum software engineering, Non-functional requirements
1. Introduction
With the developments in the last decade, quantum computing is going from a purely theoretical
area to an area with practical applications, achieving considerable performance efficiency
improvements compared to classical computing. As it becomes more widespread and accessible,
the demand for writing quantum software in a controlled, industrial manner will increase
accordingly [1]. Quantum Software Engineering (QSE) arises as an area that is aiming to bring
the principles and heuristics of software engineering to the quantum computing context.
Classical software development can be divided into phases, and together these phases compose
2nd Quantum Software Engineering and Technology Workshop, Oct 18–22, 2021, Virtual Conference
" lorenzo.saraiva@hotmail.com (L. Saraiva); hermann@inf.puc-rio.br (E. H. Haeusler); vaston@ufcat.edu.br
(V. Costa); kalinowski@inf.puc-rio.br (M. Kalinowski)
~ http://lattes.cnpq.br/1614733376309760 (L. Saraiva);
http://www.inf.puc-rio.br/blog/professor/@edward-hermann-haeusler (E. H. Haeusler);
http://lattes.cnpq.br/5192533875584788 (V. Costa); http://www.inf.puc-rio.br/~kalinowski (M. Kalinowski)
0000-0002-0103-9113 (L. Saraiva); 0000-0002-4999-7476 (E. H. Haeusler); 0000-0002-4488-7518 (V. Costa);
0000-0003-1445-3425 (M. Kalinowski)
© 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
89
what is called the software life cycle[2]. Over the years, many life cycle process models have been
designed, such as waterfall, evolutionary, and spiral [3]. Also, aiming at improving production
speed and stakeholders’ collaboration, agile development approaches have gained popularity
[4].
In the quantum context, there also have been different attempts to create models that accu-
rately describe the development life cycle. Zhao[5] describes a QSE life cycle model that can be
used as a reference. He divides the life cycle of a quantum program into requirement analysis,
design, implementation, testing, and maintenance, and reviews the main articles published on
each of the defined phases. The amount of research dedicated to each life cycle phase varies
greatly: while the implementation and test phases have several academic articles written about
them, there is not a single published article about quantum software requirement analysis yet
[6][5], which was the initial motivation for this research.
In the requirements area, the term Non-Functional Requirement (NFR) has been used to
refer to concerns not related to the software’s functionality. Different authors characterize this
concept in informal and unequal definitions. The definition we use in the context of this paper
is the following: non-functional requirements describe the non-behavioural aspects of a system,
capturing the properties and constraints under which a system must operate [2]. Non-functional
requirements are typically documented textually either quantified or non-quantified [7]. The
quantification depends on the type of non-functional requirement. For instance, performance is
rather documented quantitatively while maintainability is rather documented non-quantitatively
[7].
Quantum algorithms are often described in terms that facilitate proving correctness or
deriving asymptotic complexity estimates, without considering requirements related to the
specific computing device on which to execute them [8]. Still, the fact is that quantum computers
have a series of properties that can be safely ignored if not specified and using simulators,
but have to be accounted for if the plan is to run a quantum program on a real device. These
limitations have their roots mainly in quantum physics interactions and properties beyond the
scope of this article, but their effects and the limitations they create when writing quantum
algorithms are observable and measurable.
2. Quantum Computation Fundamentals
In the realm of quantum computing, we have two ways of constructing (quantum) programs,
which will influence requirements analysis and are therefore briefly described in this section.
Although equivalent to each other, these two ways use slightly different computational models
and manipulate different types of data. These data types are related to pure-state quantum
algorithms and mixed-state quantum algorithms. Both can describe the current states of any
quantum system, and the models can use circuits to represent the computation on the data.
A pure quantum state is represented by a unit vector in a Hilbert space ℋ = ℋ2𝑛 , where ℋ2
describes the Hilbert space of a 2-state particle, also known as a qubit and, ℋ2𝑛 is the n-times
tensor product of this 2-state Hilbert space. Using Dirac’s Bras and Kets notation, the observable
states of ℋ2 are |0⟩ and |1⟩ and a pure state one particle state is |𝛼⟩ = 𝑐0 |0⟩+𝑐1 |1⟩, with 𝑐𝑖 ∈ C
and ||𝑐0 ||2 + ||𝑐1 ||2 = 1, i.e., a linear combination of the states |0⟩ and |1⟩ with probability 1.
90
∑︀ 𝑛−1
A general element of ℋ2𝑛 , i.e., a n-qubits pure state, is 𝛼 = 2𝑖=0 𝑐𝑖 |𝑖⟩. Quantum circuits can
represent any physical quantum system that consist of 𝑛 quantum two-state particles, for some
𝑛, named the canonical way of expressing quantum computing, where the gates are unitary
linear operators. There are sets of universal unitary gates. The Tofolli and Hadamard gates
form a universal set since one can describe any unitary operator by a circuit containing only
occurrences of these gates.
A mixed quantum state is a mixture of pure states. It is represented by {Ψ} = {𝑝𝑖 |Ψ𝑖 ⟩},
where |Ψ𝑖 ⟩ are pure states and the 𝑝𝑖 ’s form a probability distribution. That is, one can represent
the corresponding quantum system in terms of the pure state |Ψ𝑖 ⟩ with probability 𝑝𝑖 . This
representation is not unique. Different mixtures can describe the same physical system. The
use of density matrices has some advantages and, it is equivalent.
Hence, we have Pure-state Quantum Computation (PsQC) and Mixed-state Quantum Compu-
tation (MsQC), and circuits can represent both. Additionally, the former can have a high-level
representation in a Quantum Programming Language. While PsQC is gate based as unitary lin-
ear operators, MsQC is gate base by density matrices. A density matrix can represent any linear
operator in a Hilbert space, which is a great advantage, as there is no need to orthonormalize
density matrices at each step.
The representation of linear operators into density matrices is not injective, but it is surjective.
All density matrix describes the mixture of its eigenvectors, with the probabilities being the
corresponding eigenvalues. Note that diagonal density matrices correspond to probability
distributions over classical states. Hence, density matrices are the linear operators that will
describe quantum computing when dealing with data represented as mixed states.
3. Non-Functional Requirements in Quantum Software
As a first step to discuss NFRs for quantum computing, we analyzed the possibility of adapting an
NFR model for embedded systems. Embedded systems have characteristics related to quantum
computing in the sense that the software is designed specifically for the exact hardware it will
be executed on. The Pecos Model [9] is a component based NFR model for embedded systems.
It is possible to draw parallels between the Pecos Model and hybrid classical-quantum systems,
where a classical environment interacts with a quantum device to perform specific computations
in a black-box manner. This model is composed of components, data ports and connectors. In
a hybrid classical-quantum system, the quantum processor unit and the classical processors
represent the components and the layers in-between represent the connectors. However, after
our analysis, we concluded that adapting the Pecos model to the quantum context would require
significant effort, and that the parallels are not sufficient to justify doing so.
Indeed, in the quantum context, the two ways of constructing quantum programs, PsQC or
MsQC, bring some relevant differences into the requirement analysis. The MsQC model allows
measurements in/at intermediate parts of the quantum circuit. At the same time, the PsQC does
not enable any measurements at any point of the circuit but the terminal nodes. While this
difference affects functional requirements, it seems to be intrinsically linked to a characteristic
of the program in terms of its algorithms design (if in circuit shape or Quantum Programming
Language form), which makes a substantial difference also on non-functional requirements.
91
States superposition and entanglement are the most cited and used features that show
advantages of quantum computation over classical computation. Grover quantum search, for
example, shows up quadratic speed up over classical search. The superposition of states is
mandatory to get Grover speed up over classical computing. The PsQC is the natural choice
for implementing Grover unstructured quantum search. The use of MsQC has to take into
account the entropy of the initial, of the mixed initial state. The literature has reported examples
that depending on the entropy of initial (mixed) state, Grover quantum algorithm performs
as bad as classical unstructured search, see [10] and [11]. They point out to the need of using
entanglement to out-perform classical computation when implementing Grover in MsQC. We
have also to mention the need of entanglement to have more accuracy in the generalization of
Grover algorithm to more than one item existing in the quantum database [11]. Thus, we have
to include hardware’s ability to perform entanglement among the non-functional requirements.
Another difference is that, in classical computation, the programming language is chosen for
an implementation mainly for its adequacy to whatever is being programmed. The most used
languages all have their known strengths and weaknesses, and there is a relative consensus on
which language should be used for what. Abstraction power suitability, efficiency, and many
other pragmatic features of the programming languages are mixed with market directions,
technologies preferences and availability considerations should be taken into account. This is
even a bit fuzzier on quantum computing. The few existing companies still compete for the
spotlight, advertising their own quantum programming language or development technology
as the best choice for the problem you have in hand. This choice is hard, indeed.
Aware of these differences, in this paper, as a first step, we propose a set of NFRs that reflect
quantum computing specific hardware-related constraints. These NFRs were identified based
on experiences implementing quantum algorithms in a set of academic projects. We classify
each NFR according to the ISO 25010 quality model.
The first NFR we cover is relatively simple, but it is worthy of mention since there is usually
not a need for it to be considered in the classical context. The biggest quantum computer known
at the moment of the writing of this article has 72 qubits - reflecting the state-of-the-art. We
can imagine that when quantum processors become integrated into classical computers, the
small number of available qubits will be a real issue when considering the price factor - more
qubits will mean a more expensive device. If someone wants to reach the highest number of
devices in the early stages of quantum spreading, they will have to cater to this limitation by
writing programs that use a number of qubits within that limit. Thus, an essential generic
non-functional requirement that should be considered for the quantum computing context
is: NFR1 - the program should use a maximum of 𝑛 qubits, where 𝑛 is the number of
qubits available in the target quantum device. In terms of its classification in the ISO 25010
quality model, it classifies within the performance efficiency product quality characteristic. More
specifically, being related to its resource utilization subcharacteristic. It is noteworthy that this
requirement is a hard cutoff — if the computer doesn’t have at least the necessary number of
qubits, you will not be able to run the quantum program.
Another aspect of a quantum circuit is its depth. The depth is the maximum length of any
(directed) path from any input wire to any output wire[12]. Quantum devices need to maintain
quantum states stable throughout the whole process of the program execution. If a quantum
circuit is too deep, the device might not be able to maintain the necessary quantum state for
92
a sufficient time frame, thus introducing errors caused by decoherence. Those errors become
an even more significant problem because it’s not trivial to pinpoint how deep a circuit can be
in a specific quantum device. The results might vary even in devices with the same amount
of qubits. Another issue is that even the mere act of detecting errors in quantum programs
is much more complex than on classical ones[13], and so is correcting them. Thus, another
important generic non-functional requirement is: NFR2 - the program should be designed
considering the maximum circuit depth so that the target device can maintain a stable
quantum state for the necessary period to execute the algorithm. If your circuit is too
deep, it will gradually decohere and eventually collapse into a classical state, losing quantum
behaviour. Regarding its classification in the ISO 25010 quality model, it affects the reliability
product quality characteristic, due to potential errors produced by decoherence. Unfortunately
there is currently no subcharacteristic this requirement could mapped against in the ISO 25010.
Nevertheless, it should be related to other non-functional requirements concerning the reliability
fault tolerance subcharacteristic, e.g., specifying the need for related error correction protocols.
When talking about the complexity of a classical algorithm, we use the asymptotic complexity
and big O notation[14]. In quantum algorithms, on the other hand, the complexity measure
usually used is the number of T gates present in the algorithm[15]. This measure has a similar
origin as the circuit depth issues, since T gates are the ones with greater implementation cost.
Therefore, increasing the number of T gates used also increases the overall energy necessary to
keep the quantum state stable, potentially inducing decoherence. Hence, another important
generic requirement is: NFR3 - the program should be designed considering the number
of T gates so that it does not exceed the limit of the target device. This requirements could
also be classified within the reliability product quality characteristic. As for NFR2, ignoring
it will increase the chance of decoherence and, consequently, errors. Thus, fault tolerance
mechanisms should be employed considering such chances.
A problem often overlooked in algorithm design and implementation will arise when dealing
with real quantum devices: not all qubits are connected to each other. Figure 1 depicts the
connectivity map of a series of IBM quantum computers1 . One can note that the number
of connections between qubits can be quite far from the maximum of 𝑛(𝑛 − 1)/2 possible
connections. Since it is only possible to create two qubit gates between qubits that are connected,
this can be quite limiting, especially when working with quantum algorithms that use highly
entangled states with several qubits[16]. Thus, an additional generic non-functional requirement
that arises is: NFR4 - the program should be implemented minimizing the number of
gates between qubits that are not physically connected on the target device.
In the Figure 1, using the Yorktown device as a reference, if the programmer wants to apply
a two qubit gate between qubits 0 and 3, such as a CNOT gate or SWAP gate, it would be
necessary to apply first a SWAP gate between qubit 2 and either 0 or 3, creating a connection
between 0 and 3. While this works in simple cases, this will still be a limiting factor when
writing more complex algorithms. Transpilers [17] can be used to circumvent this problem,
which will transform a generically programmed quantum circuit into an adapted quantum
circuit for the specific device. The drawback is that this is an automated process, and it tends to
create quantum circuits that are bigger than the optimal, which may imply in time behaviour
1
https://www.flickr.com/photos/ibm_research_zurich/albums/72157663611181258/
93
efficiency loss. Hence, this requirement can be related to the ISO 25010 performance efficiency
and reliability characteristics. Not minimizing the number of gates between qubits that are
not physically connected and using transpilers will increase circuit size, increasing resource
utilization and chances of errors due to decoherence.
Figure 1: Qubit connectivity map of IBM quantum computers.
Physically constructing quantum gates can be a daunting task. Because of that, real quantum
devices usually only implement a few quantum gates that compose a universal set. Thus, we
consider the following generic non-functional requirement: NFR5 - the program should be
implemented minimizing the use of gates that are not available in the target quantum
device. In a similar manner as in the qubit connectivity mentioned in NFR4, a transpiler
can be used to transform the original quantum circuit with high-level multi-qubit gates to a
circuit composed exclusively of the available quantum gates, increasing the circuit depth and
possibly creating decoherence. Therefore, this requirement can also be related to the ISO 25010
performance efficiency and reliability characteristics.
4. Discussion on how to address the non-functional
requirements
The restrictions listed are admittedly low-level, as are the NFRs they create. Dealing directly
with them would be the same as accessing individual registers on a classic computer, which is not
something usually done by a classical developer[18]. Even though this could be desirable in an
eventual scenario of extreme need for optimization for a specific and probably limited quantum
94
device, this approach is not practical when considering an average quantum programmer who,
for the most part, is not necessarily developing for any specific device. Naturally, when designing
a quantum algorithm, lowering qubit count, circuit depth, and gate count should always be one
of the objectives. Still, developers are typically used to do that as the general intention, not
considering the specific limits of quantum hardware. And later, when the algorithm is finished,
knowing which quantum device is sufficient or ideal to run the program is not trivial. For
this reason, there is considerable research about high-level approaches to choosing the correct
device, optimizing depth and adapting the circuit.
Quantum computers with qubits numbers in the 50-100 range are already a reality. So, instead
of making quantum algorithms with theoretical speedups but an unrealistically high number of
qubits and circuit depth, some researchers are focusing on these near-term quantum machines,
called Noisy Intermediate-Scale Quantum devices (NISQs). As the name goes, these devices
have a non-negligible amount of noise, relatively short decoherence times, and qubits in the
two digits range. Still, they have a pretty significant advantage: they already exist. For that
reason, close term quantum development will be focused in hybrid quantum-classical software,
where an application sends a specific task to an integrated quantum processor and receives an
output. The life cycle model as described by Zhao[5] is quite abstract and is more fitting to
be used as a guide for research in the area of QSE than as a manual for writing software for
NISQs. Weder et al.[19] proposed a life cycle model with a more practical approach, tackling
the difficulties a programmer face when trying to program quantum software, which includes
dealing with constraints related to our identified NFRs. The model has ten phases, but the ones
that are closely related to the requirements of this article are:
• Quantum Hardware Selection
• Readout-Error Mitigation Preparation
• Compilation and Hardware-dependent Optimization
The authors also introduce the concept of quantum provenance [20] as the relevant data
that should be collected from a quantum computer and further analyzed to effectively select a
suitable quantum computer for the execution of a circuit or to assist in the process of quantum
compilation and optimization.
The Quantum Hardware Selection phase comprises an analysis of the quantum circuit
and further selection of suitable hardware. This expresses well the intention behind this phase,
but the exact way you select the quantum hardware is not defined. Salm et al.[21] have made an
initial draft on how to automate the selection of quantum devices, specifically for current day
NISQs. Given a chosen algorithm and a chosen input range, they describe the steps to generate
a first-order logic statement that will accurately define the requirements to run that algorithm
with that specific input range. The circuit representation of this algorithm is then transpiled for
possible hardware, and from the transpiled circuit, you can gather depth and qubit numbers
and check if the device is a good choice.
Suchara et al. [22] have developed related work but without the emphasis on current quantum
computing, instead of having a more general approach. On the other hand, their framework,
the QuRE toolbox, is a bit more robust. It takes extra factors such as different potential error
correction algorithms to estimate qubit number, gate number, and execution time accurately.
95
These data could theoretically guide the selection of quantum devices and error correction
protocol. Since the focus of QuRE is to quickly compare the properties of large quantum
algorithms [22] that are still beyond our reality, it remains a primarily theoretical framework.
Quantum Volume (QV) is a metric designed to represent the largest random circuit of equal
width and depth that a quantum computer successfully implements [17]. QV is at a higher
abstraction level when compared to the NFRs defined in this paper, since it abstracts some
of those aspects in a single number metric. Another metric, devised by Sete et al. [23], for
classifying quantum computers with a single number is the Total Quantum Factor (TQF). Both
these metrics mainly consider constraints related to the described requirements - number of
qubits, decoherence times and qubit connectivity, combined with other particular aspects (e.g.,
possible parallel operations for QV and longest gate execution time for TQF).
Regarding Readout-Error Mitigation Preparation, a noiseless quantum computer is still
far from our reality. NISQs devices have a non-negligible amount of noise and relatively
short decoherence times [24]. A quantum computer can have different types of errors. One
stems from the fact that gates aren’t always perfectly executed down to the quantum level,
resulting in slight deviations. Several error-correction codes are attacking this issue [25][16].
Still, these techniques are based on redundancy and use extra qubits, called ancilla, so this
increase in qubit number has to be taken into account when applying one. Another type of
error are readout-errors that occur when the measurement is disturbed by some noise. There are
readout-errors protocols to reduce the influence of these errors [19]. During the readout-error
mitigation preparation phase, one has to choose an error mitigation approach, which are based
on the unfolding problem, where the goal is to estimate the algorithm behaviour assuming a
variable could always be measured exactly and then comparing actual execution results with
the estimated ones [26]. Since the chosen error-correction model will have an impact on fidelity
and possibly on the number of qubits used, one may store it as part of quantum provenance
data [19].
Finally, the Compilation and Hardware-dependent Optimization phase is composed
of optimizations based on hardware characteristics and compilation to machine instructions.
This process is built into the different hardware-specific compilers available, but there are
hardware-independent compilers and transpilers. A compiler for a classical language consists of
a sequence of steps used to transform the source code into a suitable representation. Similarly,
quantum compilers are the ones responsible for transforming a program written in a high-level
quantum language, such as Q# or Cirq, into machine instructions that can be executed by a
quantum computer, considering the listed characteristics of the selected hardware.
The first phase of the compilation goes from the high-level representation to a Quantum
Intermediate Representation (QIR) based on the quantum circuit model, which may represent
other forms of quantum computing besides circuit based, such as adiabatic computation[27].
Developing a widely adopted QIR is still being attempted by several researchers[28][29], with
even Microsoft recently releasing their own QIR. Still, the most relevant quantum computing
companies use a specific one for their language, such as OpenQASM[30] for IBM’s Qiskit. The
second phase of the compilation consists of going from the QIR to the low-level language
representing the machine instructions of the chosen hardware, such as QASM. In this step, we
can use any of the hardware-specific compilers like IBM or Rigetti[19] and be limited to their
hardware, or try to use a more generic compiler. Here is where many hardware-dependent
96
optimisations occur, considering the constraints listed in the requirements. Of the non-hardware-
dependent compilers, one that stands out is the |ket⟩[8]. This hardware-independent compiler
focuses on NISQs devices and aims to maximise the overall fidelity of the computation when
executing algorithms that will be affected by noise. The t|ket⟩ achieved two remarkable feats.
The first is the fact that it is both languages agnostic and retargetable. It accepts several different
languages like Qiskit, QSAM, Quil, Quipper, ProjectQ and Cirq, covering a good part of the
widely used quantum programming languages. It also can be deployed on different hardware,
like Rigetti, Honeywell and Google. In a field where there still exists a feeling of "every man for
himself", and competing companies are constantly trying to outdo each other, having a compiler
with these characteristics is an advance towards a unification that will likely be beneficial for
the average quantum programmer. The second feat are the results: t|ket⟩ offers significant
improvement in terms of gate count and circuit depth over other compilers when evaluated on
realistic quantum circuits and real quantum devices [8].
Transpilers and compilers are relatively similar: they take source code and transform it into
a version in a different representation. The main difference is that the compiler converts the
code into a lower-level abstraction while the transpiler converts it into another representation
with the same level of abstraction, be it in the same or a different language. In the quantum
context, transpilation is the process of rewriting a given input circuit to match the topology of
a specific quantum device and/or to optimize the circuit for execution on present-day noisy
quantum systems [31]. Recently, several transpilers have been developed to increase accuracy
on NISQs, and since they’re less work-intensive than developing a compiler, smaller teams can
do valuable research. There is a promising result in a just-in-time transpiler [32], tested on IBM
quantum computers. The qubits on each quantum computer are periodically calibrated and
tested against reference values to check their fidelity levels, and this feedback is open to the
public. The just-in-time transpiler uses this data in real time to remap the circuit and avoid
using low fidelity qubits and had good results, showing that there is room for improvement on
calibrations and that they should be performed as much as possible. This transpiler focused
on optimization. On the other hand, we have works such as the SABRE [33]. The SABRE is an
algorithm designed to tackle the qubit mapping problem in NISQs. This problem is known to
be NP-complete [34], and mathematical solutions can get prohibitively time consuming as the
number of qubits increases. The SABRE combines a series of heuristics to avoid falling into the
drawbacks of previous works and ensure flexibility, scalability, controllability, and high-quality
initial mapping, with results up to exponential speedup on various benchmarks [33].
A promising work that is going in the direction of unifying quantum computing - taking
off the developer the hassle of navigating all these different quantum programming languages,
frameworks and SDKs - is Q|Path⟩. The Q|Path⟩ is an all encompassing platform for quantum
applications life cycle management and development for quality quantum software. From the
creation of the quantum algorithm through its development, testing and implementation, to
its deployment and reuse[35]. It provides a wide array of tools to develop quantum software
and it also supports the execution in actual quantum devices in a transparent way regardless
of the platform where they are executed. The platform aims to abstract the process of dealing
with hardware-related constraints, specific framework issues, quantum data collection and
even connection between different quantum platforms in order to democratize the access to
quantum computing and allow the programmer to fully focus at solving the problem in hand.
97
It does so by providing tools with similar objectives as the ones we presented for the phases
of the quantum life cycle by Weder et al. [19], such as automating the process of choosing the
adequate device do execute a quantum program, collecting relevant data from the execution,
connecting classical and quantum parts to create hybrid programs and managing the hybrid
quantum-classical software production.
5. Conclusion and further considerations
We have reviewed a few hardware-related constraints that exist when executing quantum
programs in real quantum devices, from which we derived a set of NFRs for such programs.
These NFRs are exceedingly low level to be treated directly by a regular programmer.
Indeed, there is ongoing work on high level solutions to deal with hardware-related con-
straints in a more automated manner, aiming near term devices instead of theoretical quantum
computers. These solutions are an integral part of quantum programs development - thinking
about individual connections of qubits shouldn’t be the norm. Therefore, these solutions should
be included in the QSE life cycle, and not only as a footnote in the classical implementation
phase. The model proposed by Weder et al.[19] is a great step in the direction of describing the
process of programming quantum software for NISQs, incorporating the described constraints
in the life cycle, releasing the burden of addressing the low level NFRs from the developer.
Another relevant point to be made is that the current state of quantum computing devel-
opment, with competing companies developing overlapping products with the objective of
becoming the main player is a problem to be addressed, and tends to make things harder for
the average programmer. For that reason, projects such as t|ket⟩ and Q|Path⟩ are extremely
important, with the potential to take a good amount of hassle off the hands of the programmer,
favouring the overall development of quantum algorithms.
References
[1] M. Piattini, G. Peterssen, R. Pérez-Castillo, J. L. Hevia, M. A. Serrano, G. Hernández, I. G. R.
de Guzmán, C. A. Paradela, M. Polo, E. Murina, et al., The talavera manifesto for quantum
software engineering and programming., in: QANSWER, 2020, pp. 1–5.
[2] L. Chung, J. C. S. do Prado Leite, On non-functional requirements in software engineering,
in: Conceptual modeling: Foundations and applications, Springer, 2009, pp. 363–379.
[3] N. M. A. Munassar, A. Govardhan, A comparison between five models of software engi-
neering, IJCSI 7 (2010) 94.
[4] M. Kuhrmann, P. Tell, R. Hebig, J. A.-C. Klunder, J. Munch, O. Linssen, D. Pfahl,
M. Felderer, C. Prause, S. Macdonell, J. Nakatumba-Nabende, D. Raffo, S. Beecham,
E. Tuzun, G. Lopez, N. Paez, D. Fontdevila, S. Licorish, S. Kupper, G. Ruhe, E. Knauss,
O. Ozcan-Top, P. Clarke, F. H. Mc Caffery, M. Genero, A. Vizcaino, M. Piattini, M. Kali-
nowski, T. Conte, R. Prikladnicki, S. Krusche, A. Coskuncay, E. Scott, F. Calefato, S. Pi-
monova, R.-H. Pfeiffer, U. Pagh Schultz, R. Heldal, M. Fazal-Baqaie, C. Anslow, M. Nayebi,
K. Schneider, S. Sauer, D. Winkler, S. Biffl, C. Bastarrica, I. Richardson, What makes
98
agile software development agile, IEEE Transactions on Software Engineering (2021) 1–1.
doi:10.1109/TSE.2021.3099532.
[5] J. Zhao, Quantum software engineering: Landscapes and horizons, arXiv:2007.07047
(2020).
[6] P. E. Z. Junior, V. V. de Camargo, A systematic mapping on quantum software development
in the context of software engineering, arXiv:2106.00926 (2021).
[7] S. Wagner, D. M. Fernández, M. Felderer, A. Vetrò, M. Kalinowski, R. Wieringa, D. Pfahl,
T. Conte, M.-T. Christiansson, D. Greer, C. Lassenius, T. Männistö, M. Nayebi, M. Oivo,
B. Penzenstadler, R. Prikladnicki, G. Ruhe, A. Schekelmann, S. Sen, R. Spínola, A. Tuzcu,
J. L. D. L. Vara, D. Winkler, Status quo in requirements engineering: A theory and
a global family of surveys, ACM Trans. Softw. Eng. Methodol. 28 (2019). URL: https:
//doi.org/10.1145/3306607. doi:10.1145/3306607.
[8] S. Sivarajah, S. Dilkes, A. Cowtan, W. Simmons, A. Edgington, R. Duncan, t| ket>: a
retargetable compiler for nisq devices, Quantum Science and Technology 6 (2020) 014003.
[9] R. Wuyts, S. Ducasse, Non-functional requirements in a component model for embedded
systems, in: International workshop on specification and verification of component-based
systems, OOPSLA, 2001.
[10] S. Bose, L. Rallan, V. Vedral, Communication capacity of quantum computation, Phys. Rev.
Lett. 85 (2000) 5448–5451.
[11] E. Biham, D. Kenigsberg, Grover’s quantum search algorithm for an arbitrary initial mixed
state, Phys. Rev. A 66 (2002) 062301.
[12] A. C.-C. Yao, Quantum circuit complexity, in: Proceedings of 1993 IEEE 34th Annual
Foundations of Computer Science, IEEE, 1993, pp. 352–361.
[13] N. M. Linke, M. Gutierrez, K. A. Landsman, C. Figgatt, S. Debnath, K. R. Brown, C. Monroe,
Fault-tolerant quantum error detection, Science advances 3 (2017) e1701074.
[14] I. Chivers, J. Sleightholme, An introduction to algorithms and the big o notation, in:
Introduction to programming with Fortran, Springer, 2015, pp. 359–364.
[15] A. Paler, I. Polian, K. Nemoto, S. J. Devitt, Fault-tolerant, high-level quantum circuits: form,
compilation and description, Quantum Science and Technology 2 (2017) 025003.
[16] D. A. Lidar, T. A. Brun, Quantum error correction, Cambridge university press, 2013.
[17] A. W. Cross, L. S. Bishop, S. Sheldon, P. D. Nation, J. M. Gambetta, Validating quantum
computers using randomized model circuits, Physical Review A 100 (2019) 032328.
[18] R. Pérez-Castillo, M. A. Serrano, M. Piattini, Software modernization to embrace quantum
technology, Advances in Engineering Software 151 (2021) 102933.
[19] B. Weder, J. Barzen, F. Leymann, M. Salm, D. Vietz, The quantum software lifecycle, in:
Proc. ACM Int. Work. on Arch. and Paradigms for Eng. Quantum Soft., 2020, pp. 2–9.
[20] B. Weder, J. Barzen, F. Leymann, M. Salm, K. Wild, Qprov: A provenance system for
quantum computing, IET Quantum Communication (2021).
[21] M. Salm, J. Barzen, U. Breitenbücher, F. Leymann, B. Weder, K. Wild, The nisq analyzer:
Automating the selection of quantum computers for quantum algorithms, in: Symposium
and Summer School on Service-Oriented Computing, Springer, 2020, pp. 66–85.
[22] M. Suchara, J. Kubiatowicz, A. Faruque, F. T. Chong, C.-Y. Lai, G. Paz, Qure: The quantum
resource estimator toolbox, in: IEEE 31st Int. Conf. on Comp. Design, 2013, pp. 419–426.
[23] E. A. Sete, W. J. Zeng, C. T. Rigetti, A functional architecture for scalable quantum
99
computing, in: 2016 IEEE Int. Conf. on Rebooting Computing (ICRC), 2016, pp. 1–6.
[24] J. Preskill, Quantum computing in the nisq era and beyond, Quantum 2 (2018) 79.
[25] M. D. Reed, L. DiCarlo, S. E. Nigg, L. Sun, L. Frunzio, S. M. Girvin, R. J. Schoelkopf,
Realization of three-qubit quantum error correction with superconducting circuits, Nature
482 (2012) 382–385.
[26] L. Brenner, R. Balasubramanian, C. Burgard, W. Verkerke, G. Cowan, P. Verschuuren,
V. Croft, Comparison of unfolding methods using roofitunfold, International Journal of
Modern Physics A 35 (2020) 2050145.
[27] K. M. Svore, A. V. Aho, A. W. Cross, I. Chuang, I. L. Markov, A layered software architecture
for quantum computing design tools, Computer 39 (2006) 74–83.
[28] D. Ittah, T. Häner, V. Kliuchnikov, T. Hoefler, Enabling dataflow optimization for quantum
programs, arXiv:2101.11030 (2021).
[29] K. Hietala, R. Rand, S.-H. Hung, X. Wu, M. Hicks, Verified optimization in a quantum
intermediate representation, arXiv:1904.06319 (2019).
[30] A. W. Cross, L. S. Bishop, J. A. Smolin, J. M. Gambetta, Open quantum assembly language,
arXiv:1707.03429 (2017).
[31] A. Cross, The IBM q experience and QISKit open-source quantum computing software, in:
APS March Meeting Abstracts, volume 2018, 2018, pp. L58–003.
[32] E. Wilson, S. Singh, F. Mueller, Just-in-time quantum circuit transpilation reduces noise,
in: IEEE ICQCE), 2020, pp. 345–355.
[33] G. Li, Y. Ding, Y. Xie, Tackling the qubit mapping problem for nisq-era quantum devices,
in: Proceedings of the Twenty-Fourth International Conference on Architectural Support
for Programming Languages and Operating Systems, 2019, pp. 1001–1014.
[34] M. Y. Siraichi, V. F. d. Santos, S. Collange, F. M. Q. Pereira, Qubit allocation, in: Proceedings
of the 2018 International Symposium on Code Generation and Optimization, 2018, pp.
113–125.
[35] G. Peterssen, Advantages of agnostic development of quantum algorithms and apps for the
real world with qpath, 2021. URL: https://www.quantumpath.es/2021/02/25/advantages-
of-agnostic-development-of-quantum-algorithms-and-apps-for-the-real-world-with-
qpath/.
100