 Subunit 3.3, phase A. So let's talk a little bit about what happens during phase A. At this point, you've got some kind of baseline system requirements that you're developing. And in phase A, you're going to really try to work on taking those high-level objectives that the stakeholders define and trying to make these requirements from them. And so we'll talk a lot more about requirements in the other units. What you're trying to do here is take these objectives and break them down into lower and lower levels of detail so that in the end you could provide specific information for, let's say, the person who's going to go off and buy the propulsion tank or the person who's going to go off and buy the battery for the spacecraft. They need very specific direction. The direction is going to be documented in requirements on what the specifications are for that battery. How much energy does it need to hold? How much energy does it need to be able to send out to the spacecraft during the time when the spacecraft is going through its eclipse period where it needs to have the battery providing energy to all the systems? And so all of those requirements at the very low level need to come from all the way back to these objectives that the stakeholders have defined for how this mission needs to successfully operate and what it needs to be able to do, science collection or whatever the objectives are for that mission. So what you're doing here is at the phase A level, you're making sure that the high level objectives are starting to be decomposed into lower levels of requirements, we're now calling them requirements, lower levels of requirements that will allow the system developers to provide more specificity and more detail to all the components of the spacecraft on what they need to do to meet the high level objectives. So specific activities in phase A include developing top level requirements and top level. So we're going to use that term to refer to the first level of requirements that are under the system objectives, under being as in more defined. So stakeholder objectives are at the higher level. They say, let's say for a Mars mission, objectives might include looking for water on Mars, objectives might include studying the atmosphere of Mars to understand its composition. So that's the kind of stakeholder objectives that we might have for a NASA mission. So now the engineering staff has to say, well, gee, what kind of requirements would I have to levy on the system to be able to look for water or to analyze the atmosphere? And so again, we'll get into more detail, but now you're going to get into lower and lower and lower levels of specificity on how the system needs to work to be able to accomplish those high level objectives. And so top level will be the first level of requirements that you define. And now you're going to go lower and lower. And so we're going to call the next, you see in the next bullet, you've got to flow these top level requirements down a few more levels of detail in phase A. And we're going to call those a high level set of requirements. And so you're going to flow them down maybe two more levels of detail and you're going to provide more specificity along the way, right? And you're going to try to figure out what are your driving system requirements? What are the requirements that are going to really cause your designers to have to stretch to meet them, right? What are the requirements that are going to really cause maybe a new technology to have to be used or some, you know, new technique on how you design a satellite? So you want to understand for your specific system, what are your driving requirements that are going to really be the key ones for making sure that the objectives can be met and that are the ones that are going to really push the designers to, you know, to make sure this design is compatible with these objectives. You're going to also define all your primary internal and external system interfaces at this point. Remember, as you decompose any problem into smaller and smaller pieces, there become many more pieces. They all have to interface with each other. And so both within the satellite itself, the power system needs to connect to the propulsion system or to the computer system. Everything needs to connect together. So you need to have to find those interfaces because in the end, there'll be many teams off working on their individual part of the spacecraft. And when they're doing that, you want to make sure that they understand exactly what the interface will be between them and all the other parts so that when everything comes together, everything can work properly to meet those high-level objectives. You also want to understand external interfaces because the satellite doesn't live by itself in its own world as a system. It has to interface to a rocket at launch, a launch vehicle. It's going to have to have certain capabilities to interface to the launch vehicle. When it's on orbit, it's going to have to communicate back to an antenna on Earth and has to be able to interface to that antenna, which is usually used by many missions. So it's an antenna that's already there. It's its own system. So you have to have an interface to that system. So all those kind of high-level system interfaces need to be defined here in phase A. You're also going to perform some key trade studies to evaluate design attributes and alternate design attributes. And we'll talk more about trade studies in another unit. But trade studies being you're going to trade off some alternative ideas. So maybe in the world of propulsion, there are two or three different types of propulsion systems that might be able to meet most of the requirements, high-level requirements for your system. And you might look at them and say, well, gee, which one do I think is maybe the best one? So I'm going to trade them against each other. Which one costs the most? Which one can perform the best in meeting my high-level requirements? Which one uses the most power, electrical power? So I'm going to be doing these studies to look at all these kind of high-level what kind of decisions do I want to make. And you'll be continuing to do trade studies throughout the lifecycle. But in phase A, you're kind of initiating that process to try to refine your system. You're also going to establish an initial system baseline. You're going to identify any key technologies that will require investment during phase A and B to make sure they're ready to be used in the system implementation. You're going to refine your lifecycle cost estimates to make sure your stakeholders understand how much it's going to cost to your best estimate of how much it's going to cost to complete the entire lifecycle and get through the development of the system. And you're going to put in place all of your management tools here in phase A to make sure that along the way, through the rest of the lifecycle, you've got a clear way, clear set of processes and tools to manage all your resources. And resources could be anything from money and schedule. Those are resources and development, as well as things like power and mass, where you only have a certain amount of them to give away to all your development team. And so you have to manage those resources, well, those technical resources. You're going to have to have management processes in place to manage all the risks or things that concern the team that have to be dealt with throughout the lifecycle, as well as all your system engineering processes to make sure that the team gels as a team and understands roles and responsibilities between team members and kind of how you're going to work through the process in a system engineering sense as well. You'll see the example here of the Morris 2020 rover. And so this is a rover that's currently in phase A being designed by the Jet Propulsion Lab out in California. And so this is what you see in this picture is, although a concept, an early concept, again, they're not building it yet, phase A is really the early part of the development cycle. But now in this part of the cycle, they're trying to neck down to one concept. So instead of in the previous example where we had many, many different concepts that could meet the objectives, they're using now one baseline concept in phase A to try to flush out a little bit more details. Maybe there are more than one concept, sometimes there are, but you are trying to move towards a single design as opposed to many different concepts that can meet requirements. So for Morris 2020 rover, it was easy to move to phase A because there are some high-level requirements. They want to keep the budget within, it sounds like a lot, but $1.5 billion. And at $1.5 billion, the only way to do a rover on Mars that's the size of an SUV is to reuse a lot of technology and equipment from the past. And so in this example, you're looking at a rover that will be basically designed around the Curiosity spare parts and the Curiosity technologies. The scientific instruments on board will be modified, changed, and there will be different instruments on board, but the basic shape and the whole system that's going to be used to land it on the surface and rover around will use a lot of heritage from the Curiosity rover. And so that's how they're going to try to keep the cost down, but that also means that in phase A, there are less trade studies to do, there are less analysis to do, because a lot of this is a given. You know what this rover is going to look like. So in phase A, that's the kind of studies you're doing is to try to bring it down to one concept, trying to mature it a little bit and see where there might be some flaws in its ability to meet the objectives, so that's the kind of maturity. So the primary technical reviews in phase A include both a system requirements review and a mission design review. So the system requirements review is where you're going to bring the external technical team in again, and they're going to look at things like have your top-level requirements been clearly defined and do they fit in with your high-level stakeholder-defined system objectives? And so the goal here is you're looking at, you know, did I do the flow down correctly if I looked at these top-level requirements, yeah, do they seem like they're the right ones to meet these system objectives? And then the next bullet is, you know, if I define the top-level requirements right, did I take that down to the next couple levels of detail and form a good set of high-level requirements that look complete to be able to again meet the high-level system objectives? Now the team will also be looking to see if all the internal and external system interfaces have been clearly defined. And that all the risks for the development of this system have been clearly identified and there's a plan for addressing those risks. And that things like a system engineering management plan, how am I going to manage this project from a system engineering standpoint and all of your other processes and tools for management have all been put in place and are ready to go. And that there's an initial plan for verifying and validating the system and we'll talk more about verification and validation in another unit but suffice it to say that as you're defining requirements for a system, sooner or later when you build the system, you're going to want to verify that that system as built can meet the requirements and a requirement might be a performance capability. A thruster needs to be able to provide a certain amount of thrust. Early on when you're developing requirements you may have defined how much thrust later on when you actually purchase a thruster and you might say well gee, let me test it on the ground make sure it can produce the amount of thrust that's required and you might also say well gee the thruster can only weigh a certain amount because overall the whole system can only weigh a certain amount so the thruster has been given an allocation of that and the thruster itself can only have a certain amount of mass so you might put it on a scale and say well how much is that thruster and verify that the requirement I set for how heavy it could be can be met by the thruster that I actually went ahead and purchased and so this plans for verifying and validating and validating here is another term that we'll talk more about and validating is making sure that as you put the system together it performs as a system and meets those high level objectives that you set out for it so verification being very specifically requirement by requirement should, validation being when I put it all together does it perform and meet the high level objectives that were set out for it by the stakeholders and so those plans are developed early on you know you think about that when you are starting to define requirements and objectives you also have to start to think about how in the end when I actually build this thing later on at the end of the life cycle how will I make sure that it's going to perform the way I want it to will I do that through testing in a computer how will I actually do that verification I have to think that through now because I might need to build special tools to be able to do that verification special equipment so I need to know that so that I can make those investments throughout the life cycle I'm also going to look and see that the plans for technology development have matured and then I understand all the technologies that need to be developed and completed before the end of phase B and the system requirements review will also look at the results of any actions that have been assigned to the team back at the mission concept review and so the goal here is that at each one of these technical reviews the technical review team is going to assign some actions to the designers and say you know we thought your system is pretty mature we think you're ready to go to the next level but you know there are some areas of concern we don't think you've thought enough about X Y or Z and we want the team to go back and do a little bit more work on that improve to us that you've completed that so at the next review you're going to want to make sure that all the actions have been closed out the second technical review that happens during phase A is the mission design review so during the mission design review this is again after the system requirements review on the life cycle and at this point the technical review team will be back and they will now be assessing things like your baseline concept baseline concept being your current design instead of requirements and all the things that define the system at this very early part of the life cycle everything you've put together to define what the system is and how it will operate and they're going to look at that baseline concept to ensure that it's reasonable, feasible it's complete it's responsive to the high level requirements that you set out for it and it's consistent with the available resources resources being anything from technical resources like mass and power to programmatic resources like cost and schedule so they want to know that as you're maturing this baseline concept and adding more detail to it that it still looks like it can be executed and that it will meet the high level objectives and be able to be done within the programmatic resources available so they'll also be looking to see that your system level design approach and your operational concept are maturing so that they are consistent with the high level requirements so there's two things going on you're developing requirements what will the system need to do how will it need to perform that's what's being defined by requirements but you're also starting to work more and more on this concept kind of an early stage of a design what is this system going to look like and so you're going to look at in this review both the requirements make sure that they're maturing properly but that was done mainly in the system so you get this design that you're starting to come together with to make sure that it's maturing and could meet the requirements that are being laid out for it you're also looking at any risks that have been identified along the way that the team is worried about things that again may preclude us as a team from being able to finish the system development on time on schedule and meeting its technical objectives and so the review team is going to want to know that you clearly understand the risks and by understanding risks you also have a plan for how you're going to deal with those risks what kind of mitigation strategy or what kind of steps are you going to take to make sure that that risk doesn't end up causing you problems in the life cycle you're also going to be looking at the technology maturation effort you're a little deeper into phase A at this point so the review team wants to know is everything on track is your technology plan executing as planned and are you ready to go so that by the end of phase B you can be matured to where they can be ready for flight and ready for implementation and then you're also going to look back at the system requirements review and say okay were there any actions assigned by the technical review team back at system requirements review that needed to be closed out and what's the status of all those actions you want to know that they've all been completed there are no additional resources for this subunit feel free to skip ahead to the next video