General feedback:

• Very good progress in general, on track for now, we will keep refining the requirements in
the coming weeks as we refine the mission concept and we go to system architecture.

• Most groups understood the requirement classification and provided the key requirements
for each section. Some still need to think about what are the differences between each type
of requirement (refer to definitions/examples). It’s up to you to make choices in your mission
concept/architecture to design more precisely your mission and imposed constraints on the
system, helping you to identify requirements then.

• Example: spacecraft = lander or orbiter + lander ? How much autonomy for rover?
For sure we can discuss together these choices.

• Focus on selecting what are the most important requirements

→ Focus on the requirement function rather than on its performance level

• Given your preliminary mission concept/architecture and mission

requirements (slides Requirement Workshop), try to identify what each
phase or input there involves in terms of requirement?
What is essential to be done during each phase of the mission?

• Precise values are not the most important things, you can use To Be Defined (TBD) and
possibly refine in the coming weeks thanks to:

• Refining your mission architecture and CONOPS (you will know more about how you
mission operates and then you can identify from reference missions / discussing with
us, which performance level (numbers) you can allocate.

• An advice to find relevant requirement is :

• To consider for each subsystem (e.g communication):

• Which functions are required from it? (e.g communicate in X-band with a
TBD data rate for uplink and TBD data rate for downlink ((functional
requirement))

• Which performance level? (The data link quantity for example, you can
assume TBD at this stage or look at existing missions (Chandrayaan,
Beresheet, SMART-1, Chang’e…)

• Which verification method/criteria? (You select from the types of methods

(given) and can refine with given documents (Typical Tests) and by searching
in references/internet)
(e.g Antenna tests, Electromagnetic Compatibility test, radio frequency
testing)

• To think in detail of the mission concept of operations and the phases in detail:

• Think of what can happen, what do we need to do in this given phase, how
would we do it in reality? By identifying key functions and potential
 problems to solve, this will give you new requirements (especially
operational requirements)

• Constraints are not requirements, but they help identifying/organizing them

• Difference programmatic / mission requirements:

• Programmatic requirements are not technical requirements, not present in the ECSS
standard that we saw but sometimes used by some missions… But we can consider
to include what they cover (cost, launcher, schedule, TRL, partner choice, etc…)
under mission requirement too.
> More details in dedicated slide later

Specific feedback:
• Difference between functional/operational.

• Functional : related to what the system/lander has to DO during all its lifetime, which
breaks down into what each subsystem must do, to ensure that we can realize the
mission goals/requirements.

• Operational: how to operate the system? What is required to control, command,

communicate with the system, ensure it can properly work in each phase and in
different situations? It deals with operational modes (eg. Nominal, science, safe
modes…), the interaction with the environment (ground segment, collaboration
between elements such as lander/rover (not interface)) and potential events to deal
with.

• Examples: system shall communicate via X-band and a data rate of TBD with ground
stations = functional.
Communication windows of TBD hours/day, controlled/remote operations, etc. =
operational

• Power:

• Power generation level

• Storage capacity (Batteries performance)

• Duty cycle (already precise)

• Backup options or power requirements in some modes? (ensure that we generate

TBD enough power in safe mode for key systems, etc..)

• Environment:

• Identify environmental conditions in which the system shall operate (temperature,

vaccuum, dust, radiation, heat, electromagnetism, vibrations…)

• Interface / Operational difference:

• Interface req: Data relay to be done between ground segment & lander, using
telemetry / radio-frequency.. OR Telemetry / Telecommands to rover
are communicated via Lander by Wi-Fi between them.
 • Operation: Communication windows between ground stations and lander shall be at
least TBD hours a day.

• Landing-related requirements:

• [Mission] Landing site selection : criteria of slope, temperature, no boulders bigger

than TBD, …

• [Mission / Operation]: Orbital sensing to be performed before to determine the

precise location of the landing site (we already have 30km resolution maps for water,
but we can imagine that as we get closer, e.g parking orbit or descent, we refine the
target site location.

• [Functional] GNC: landing accuracy to be within 100m (TBC)

• [Operational] Autonomous landing by on-board computer?

• [Functional] Hoverring phase (staying just above the surface) to be estimated to 2

minutes (TBC) to be able to find a good landing location (impact on propulsion
subsystem)

• [Functional] Structure: landing legs shall stand a shock acceleration of TBD

• Lander heatshield → no need on the moon (vacuum, ultra-thin atmosphere)

• Spacecraft shall generate power with solar arrays → this is expressing a solution, not a
required function (generate power) with a level of performance (TBD Watts). If the design is
already chosen for solar arrays, then I’d refine by « The solar arrays shall provide TDB
power ».

• Rover shall be able to come back to lander: it’s functional (even can be seen as payload
requirement as rover =payload). Rover shall come back to lander every 4h during its science
operations (=Operational requirement). Rover shall be connected to lander with a cable,
providing power/data/safety… → interface req. (not a very probable one for rover
operations but could be when rover comes back).

• Rover shall be able to drive autonomously through pre-programmed traverses of 200m

(TBC), avoid obstacles of height more than 30cm (TBC) and perform sensing observations
every 10m (TBC). Mix of functional/operational here.

• Rover can be seen as a payload

About programmatic / mission requirements:

❑ You have Technical and Non-Technical requirements. The programmatic requirements are
non-technical ones (e.g cost, schedule, political, TRL, constraints...) and were not presented
in the workshop as we focused on the technical ones according to ECSS standards (cf canvas
documentation).
❑ Indeed, they are quite close to Mission Requirements (which are more related to
functions/tasks to be performed within mission scenarios, what is required to reach the
mission objectives, cf slides 22-25 lect 2). As there are different terms used by different
actors/countries (no international standard), it's quite difficult to distinguish them (in a way
programmatics can be included under mission requirements).

❑ In my opinion, it is better to merge programmatic requirements into mission requirement

(if you split make sure that the programmatic are not technical and the distinction is clear).

❑ Otherwise, a way to help to split them I believe is to think of if it's technical and linked to the
mission objectives (what needs to be done for the mission to succeed) VS not technical and
rather about HOW to implement the mission (programmatics, e.g cost, schedule,
international collaboration, etc.)