1 Introduction
This guide describes the Systems Engineering Mini-project that forms part of the assessment for
EG7312 Systems Engineering. This guide contains the background and administrative information
you need to complete the project, but you will need to research components and make appropriate
assumptions in the absence of perfect data, because this is what Systems Engineers do!
The mini-project is to produce systems engineering documentation and a systems architecture for
a simple system, then plan how the system will be verified. The system selected may be changed
each year the module is run. The brief for the current year is given in section 3 below.
The aim of the project is not to produce a detailed engineering design or to undertake a full systems
engineering activity but for you to demonstrate the application of a systems engineering approach
and the selection and use of appropriate systems engineering tools. The project is deliberately open-
ended so there is no single ‘right’ answer.
2 Coursework briefing
2.1 Fit with overall assessment for the module
Group of five or six students can be formed to complete this coursework. The coursework is
designed to assess learning outcomes of the module that cannot be assessed via a conventional
examination. These include writing systems engineering documentation and more advanced
application of some of the systems engineering tools. Overall, it gives you the opportunity to
demonstrate knowledge of key systems engineering principles and techniques and how to apply
them. You do not have to use every tool or technique we have covered in the module; you do need
to pick the most appropriate of these.
The coursework is worth 50% of the marks for the module and is marked out of 100 points. Marks
are awarded for two main elements of the report – an updated Requirement Specification and a
System Architecture & Verification Plan. These are described below.
The coursework report shall be submitted via the Blackboard module site in PDF format. The
Blackboard assessment page gives a ‘rubric’ for that describes the marking criteria that will be
applied.
2.2 Initial Report- Requirement Specification
You are required to write a Requirement Specification for the system. The requirement specification
shall:
start with a statement of the system objective,
use the requirement specification template as provided and used in the taught sessions,
follow the advice given in:
o the taught sessions,
o the formative feedback on the class activity and
o other background reading.
It shall include a brief justification for each requirement in accordance with current good
practice and,
It shall have a MAXIMUM of 15 requirements.
The limit on the number of requirements is there to encourage a focus on the most important
requirements for the system.
Students must submit this initial part of the report by November 17th , submitted via Blackboard.
This part will not be marked, however general feedback will be provided. This feedback must be
used while preparing the final report that must contain the updated requirement specifications.
A session will be organized to provide general feedback for the prepared requirement specification
before system architecture and verification activity can be started.
2.3 Final Report- Updated Requirement Specification, System Architecture and Verification
You are required to develop the overall architecture of a system that would meet the requirement
specification discussed initially in the report. The system architecture report shall:
describe the updated system objective and requirement specification
describe the approach taken to developing the architecture, including any systems
engineering methods used,
include a schematic diagram of the system architecture selected, including sub-systems and
elements and interfaces
report the results of any analysis performed to confirm the feasibility or performance of the
system architecture against key requirements and provide a risk analysis and mitigation plan
for the feasibility of operation of this system
describe a verification plan to determine whether the system has quality, including both
qualification and acceptance activities.
include a discussion of how the general feedback on the requirements specification has been
taken into account or problems with the original requirements have been identified and
fixed.
