Featured article
How NEXUS connects perception, memory and forecasting across robots in a distributed reasoning process, from assessing a situation to coordinated action.
From the customer's task to verifiable requirements
In this article
The technical specification for UAV software begins with the customer’s task: what data the system should receive, what to do with it, and what result to transfer to a person or another system. The list of technologies and the desire to “add autonomy” do not in themselves determine the scope of development.
For the first discussion, you don’t need a document of dozens of pages. It is enough to describe the working scenario, existing equipment, limitations and how to verify the result. Below is the structure of the brief, which helps separate the required features from the assumptions.
1. Describe the task and scope of the project
Record who is using the system and what actions need to be made easier or more repeatable. For example: the operator needs to upload equipment logs into a single format, compare sensor data with measurement time, or receive notification of an incomplete set of materials after an examination.
- How does the process work now and where does the difficulty arise?
- What should change after implementation?
- What actions are left to a person?
- What functions are not included in the first stage?
Separate mandatory requirements and wishes. If the result depends on an unavailable interface or an unknown hardware property, mark it as a review question rather than a ready-made possibility.
2. Gather information about the platform
Specify the vehicle, flight controller, onboard computer, payload and ground software that will be used. Attach available documentation for the interfaces and a list of software versions. For an existing system, a wiring diagram indicating the boundaries of the component being developed is useful.
Separately indicate what equipment is available for bench testing and who can provide access to it. A protocol name match does not confirm compatibility; information about supported messages, commands, and implementation limitations is required.
3. Define Inputs and Outputs
| What to describe | What to include in the brief |
|---|---|
| Source | What device or application is transmitting data; Is there an example recording available? |
| Contents | Fields, units, timestamps, and data quality attributes. |
| Exchange | Documented interface, transmission direction and communication restrictions. |
| Result | File format, API message, operator screen, or log entry. |
| Storage | Where materials are stored, to whom they are available and how they are transferred to the customer. |
Submit only examples that are permitted for disclosure. Accesses, personal information and proprietary materials should not be included in the public brief.
4. Agree in advance how to check the result
Every mandatory requirement must have an observable outcome. The wording “convenient export” can be replaced with a verifiable one: the operator selects a record, receives a file in the agreed format and sees a message if the required data is missing.
- Describe a typical work scenario and the input data for it.
- Specify behavior when a record is incomplete, hardware is unavailable, or there is an input error.
- Determine what checks are performed on the data record, on the bench, and as part of the system.
- Agree on who accepts the result and what materials support the verification.
Requirements for latency, accuracy and stability are specified for a specific task and environment. They cannot be transferred from another platform's ad description without verification.
5. Define the handover deliverables
List expected software components, instructions, configurations, and test results. The volume of transferred source code, rights of use, access to third-party components and further support are agreed upon separately.
If only one integration module is needed, it is not necessary to include a redesign of the entire system in the project. The boundaries between the new component, existing software and hardware should be defined before estimating the work.
A brief for the initial discussion
- Task and expected result.
- System user and work scenario.
- Platform, hardware and software versions.
- Interface documentation and permitted data examples.
- Limitations and open technical issues.
- Acceptance criteria and available testing equipment.
- The composition of the program and wishes for support.
This brief can be used for discussion of software development for UAVs and UAS. If the configuration is not yet defined, start with system integration boundaries: this will help not to mix software development with the selection and replacement of equipment.
.svg){kind=icon}
