Systems Engineering M.Eng. Project Guidelines
A Systems Engineering (SE) project must take a holistic, systems view of the problem to solve and apply the SE process to create a solution to propose and implement. The project must include:
- A statement of both overall and detailed goals and requirements for the system, or subsystems, based on the overall project or stakeholder needs, together with measurable criteria for success;
- An identification of different possible approaches for meeting those requirements,
- A chosen or recommended choice of approach based on tradeoff analysis among the possible plans,
- An identification of critical interfaces between development subsystems (or development teams),
- A plan and schedule for development, integration, and test, along with a schedule of review points, and then
- A process for tracking and managing the schedule.
These will need to be done iteratively as the project progresses. Goals and requirements may have to be refined, approaches may have to be changed, etc. as the process moves forward.
Final Report Requirements
Your final written project report must document your application of the SE process, as well as the resultant solution to propose and implement. Your report must present in detail your considerations of the following basic parts of an SE process:
- An analysis of the context of the presented problem.
This means not just what is presented to the student as a problem to be worked on but an understanding of why it is a problem or needed improvement and what the context that it will exist in is. Context refers to all the surrounding factors in the world that are involved in this problem and are more or less fixed and not accessible for change by the systems solution to be determined. An example would be the climate in a particular area for a study of building heating or cooling. Another example would be the availability of some resource such as more than a certain amount of money or water or expertise to be used by the proposed systems solution.
- Well defined requirements that are agreed-upon to define a satisfactory solution to the problem.
This means that all the metrics and conditions that need to be achieved in order to have people agree that the proposed solution to the problem indeed solves the problem in an acceptable way. Each requirement must be stated in a “shall” statement and must be verifiable. Verifiable means there exists some way of determining whether the requirement has been met. In some cases that may mean a numerical value for some factor. In other cases, it might mean that a certain percentage of a certain category of people polled agree that the solution is satisfactory.
- Determination of some possible functional definitions of a solution.
This means that a number of alternative ways that the system might behave to meet those requirements that are delineated. This might mean that a new way of approaching the problem will be used, or more of a certain resource or process will be used, or that the need for resources will be reduced due to some kind of increased efficiency, or that some resources might be applied in a different way than previously thought about, etc.
- Determination of some possible structural ways of realizing the functions that are being proposed as alternatives.
This means identifying all alternative actual hardware, software, or procedural realization of the proposed functions. For example, whether to use a robot, hard automation, or people to do a certain task, including necessary equipment and supplies etc. and always considering lifecycle costs, performance, and other measures relating to the requirements.
- Analysis and optimization.
This means choosing among the alternatives identified above, optimizing the system with respect to requirements, costs, and lifecycle performance, addressing the associated risks, etc.
- Planning and carrying out implementation, testing, and development.
This means laying out the plans for the actual implementation and application of the chosen solutions to the problem and, of course, solving further problems that may arise and then cycling back to iterate on all the other parts of the SE process outlined above.
"Robocup, The Formula SAE Car... These may sound like mere student projects. But we pit our best designs, our best thinking, against other universities around the world. It's competition on a global level - an invaluable way to learn. And we perform."
Albert R. George, J.F. Carr Professor of Mechanical & Aerospace Engineering