1. Requirements on the parachute system

A vehicle has a parachute system because the mission requires it. In other words: the mission requires a safe return/landing of the vehicle and/or payload. The mission is made clear through the mission statement, a tag line or one-liner for your mission.  From the mission statement, the mission objectives can be derived. Mission objectives are the checkboxes required to be ticked for the mission to be a success. Generally, these are divided into primary, secondary, and tertiary high-level objectives. 

From the mission objectives, one can derive the system requirements. The requirements can be divided into five main categories of constraints which are most important for smaller missions. 

• Functional requirements - What should it do?
• Performance requirements - How well should it do what it has to do?
• Design requirements - How should it look like?
• Operational requirements - How should it operate?
• Constraints - Requirements that cannot be broken no matter what.

To get a good overview of the requirements, it is strongly recommended to sit down with the stakeholders. A stakeholder is anyone that is influenced by the mission in the broadest sense of the word. This can be the payload, the team, a university, but also a launch site. But for a student project, a stakeholder can also be the PR department as the safe retrieval of the hardware might be an eyecatcher for any PR event. Again, think in the broadest sense of the word: a stakeholder is anyone that has influence or is influenced by your mission!

Listen to all of your stakeholders to gather their requirements. One very important stakeholder is the launch site. You need to comply with the launch site requirements if you want to fly. These can be requirements in terms of drift range, maximum parachute deployment conditions, landing velocity requirements etc. When requirements conflict, you should sit down with both parties and discuss the possibilities, when in doubt: go with the strictest requirement. 

When writing requirements one should ensure the requirements are following the following requirements:

• Necessary - The requirement defines an essential capability, characteristic, constraint, and/or quality factor. If it is not included in the set of requirements, a deficiency in capability or characteristic will exist, which cannot be fulfilled by implementing other requirements.
• Unambiguous - The requirement is stated in such a way so that it can be interpreted in only one way.
• Complete - The requirement sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the entity need without needing other information to understand the requirement
• Singular - The requirement should state a single capability, characteristic, constraint, or quality factor.
• Feasible - The requirement can be realized within entity constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk
• Verifiable - The requirement is structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level the requirements exist.
• Correct - The requirement must be an accurate representation of the entity need from which it was transformed.

Parachute subsystem requirements

After the architecture of the mission and the conceptual design of the vehicle is done, the team can dive deeper into the subsystem requirements.  The parachute subsystem is tasked first and foremost with the safe landing of the payload. Therefore the landing velocity and other requirements depend heavily on what the payload requires. It could be that the payload requires more than just a landing velocity, but requires a velocity at a certain altitude for measurements. This can be seen in Mars landers, where the capsule sends data between the blackout phase and the landing. In the case of the sky crane, this requirement is set by the release altitude. In some cases (Huygens), the mission had a limitation on the flight time due to power constraints. This has to be taken into account as well. As with the system requirements, it is important to cover the full scope of the parachute subsystem.

Another source of requirements on the parachute system can be the other engineers working on the mission. One should have a clear overview of the other subsystems' influence on the parachute system and the other way around. These are defined by the interfaces between the parachute subsystem and the other subsystems. Examples of these questions to be asked to the rest of the team can be: What are the maximum forces the parachute can exert on the body? Does the capsule need to be watertight after landing? And maybe even more important, what is the budget in terms of cost, mass, and power of the parachute system? Part of this is also the discussion with the simulation team to determine the flight path and stability of the rocket. The final apogee and velocity at apogee will dictate a significant part of the parachute system's design.

Tips

When writing requirements, one should keep the following in mind:

• Be sure your requirements are complete and give a good representation of the mission.
• Do not state the obvious, this will only clutter the list.
  
• State ranges, not hard numbers where possible.
• When the numbers are not yet known, write the requirement with TBD or "To Be Determined".