# Software Development Process Considerations in GNSS-Denied Navigation Project for Drones
## 3 Software Development Process Given for Consideration in This Paper
#### 3.2.1 Preparation Activity  
Software requirements taken as input to the process were already prepared and somehow stable (at least 75% of the expected number) before the software development process activities began. That gave a better view of the development scope and allowed us to plan the tasks and support ensuring product completeness by providing traceability (task to requirements and vice versa). Software requirements were then transformed into \"issues\" (Issue definition may be found in [9; 35]), which represented tasks to be completed. The term \"issue\" corresponds to the term used in a tool chosen to support the example process and will be explained later. Functional requirements defined in [15; 18; 29; 37] were first represented by issues whose names corresponded to the name of a function represented by such requirement and were given a special label, marking the issue as a function like \"function 1, function 2, function n\". Labels were also a consequence of a chosen tool, with each issue having a requirement, as a parent gives a special link to the issue representing a function to ease the tracking of function development progress. In fact, in software development, we provide  
Figure 2: The software development process implemented in the project. functions, but performance requirements, as highlighted in [15], are a special kind of quality requirement that corresponds to the quality of these functions that deal with values like time, volume, frequency, etc. The number of functions we need to implement in software depends on how many functional requirements we have allocated to the software. The non-functional requirements [15] tell us about the quality and degree of complexity of implementing such functions, as pointed out in [38]. Non-functional requirements like quality requirements [29] may have their source, for example, in specialty engineering areas [15] like safety engineering, reliability engineering, etc., or in quality models and quality characteristics related to those models like those defined in [16] or [34]. ECSS-Q-ST-80C [16] clearly defines a \"quality model\" as a set of characteristics and relationships between them. A quality model is used as a basis for specifying quality requirements and evaluating quality. Key software quality characteristics identified for software developed during the example project were based on ISO/IEC 25010 [34] and were mainly as follows:  
* Functional completeness and correctness (from the functional suitability group);
* Time behaviour and resource utilisation (from the performance efficiency group);
* Analysability, modifiability and testability (from the maintainability group). Each characteristic should be understood in terms of a product under development and its context (for context definition see [29]) or intended future use. It should be transformed into requirements and then reflected in the system/software design. It is a common practice to use some pre-defined patterns that support different characteristics related to software architecture, as mentioned in [7]. **The process described in this paper goes further. It was designed to ensure these characteristics are reflected in the final product. **  
This was a useful consequence of the three valuable scrum pillars mentioned in [30]. The process supported achieving these characteristics by providing means of facilitating transparency and inspection. Adaptation was achieved by self-concluding the results. It mainly took place in the retrospective activity (described further).