Dronology as a Data Source

Many software engineering research projects rely upon the availability of software engineering data, such as requirements, source code, architectural design etc, for experimentation purposes. However, it can be challenging to acquire extensive data sets outside the Open Source domain.

One of our goals is to openly share Dronology datasets. While we are currently in an incubation stage, we provide a small 'taste' of what we are working towards releasing, including requirements, design, code, test cases, product line information, and safety analysis -- all across multiple versions. Keep an eye on this page for future release announcements!

1st dataset available:

The first dronology dataset consisting of  
Features, Requirements, Design Definitions, Tasks, Code, and trace links.
is released on our datasets page.


All of our requirements are stored and managed in Jira.

While our project follows an agile approach, we specify our requirements using EARS (Easy Requirements Specification Format).

EARS allows us to express systems requirements using a very simple set of keywords.

Source Code

Once released, source code and other artifacts will be available on Github and packaged for experimentation purposes on this website.  Watch this space to learn more!

All of our code is stored in Github (and will be available in the Spring of 2018).

Our core Dronology engine is written in Java with our UI using the Vaadin framework. Our ground control station is developed using Python and leverages DroneKit python to communicate with UAS via MavLink.


Dronology's architecture is designed for flexibility. Future users may wish to deploy Dronology in new settings - or to experiment with changing various aspects such as the collision avoidance system, the types of UAS flown, the monitoring system and so on.

We have therefore adopted an architecture which is designed to accommodate these usage scenarios.

Safety Assets

As Dronology is a safety-critical system, whose failure could cause harm, we also perform a hazard analysis to identify hazards, faults, and safety-related mitigating requirements. 

Furthermore, we are interested in environmental assumptions upon which requirements depend.  Watch this space for more information about Dronology's requirements and related artifacts.

Product Line

While we are not there yet -- we are working towards reverse engineering a Dronology Product line.

Agile Artifacts

We are following an agile development process -- which means epics, user stories (written using EARS), tasks, sprints, developer assignments and so on.  

We made a few modifications to the typical agile process to accommodate the safety-critical nature of the project -- for example, our backlog includes safety stories.