"Introduction to Systems Engineering" uses a structured yet flexible approach to provide a holistic, solid foundation to the successful development of complicated systems. The course takes you step by step through the system life cycle, from design to development, production and management. You will learn how the different components of a system interrelate, and how each contributes to a project’s goals and success. The discipline’s terminology, which can so often confuse the newcomer, is presented in an easily digestible form. Weekly video lectures introduce and synthesise key concepts, which are then reinforced with quizzes and practical exercises to help you measure your learning. This course welcomes anyone who wants to find out how complex systems can be developed and implemented successfully. It is relevant to anyone in project management, engineering, QA, logistic support, operations, management, maintenance and other work areas. No specific background is required, and we welcome learners with all levels of interest and experience.
Module 5 Part 2
Loading...
Del curso dictado por UNSW Australia (The University of New South Wales)
Introduction to Systems Engineering
220 calificaciones
UNSW Australia (The University of New South Wales)
220 calificaciones
De la lección
Conceptual Design
In this module we examine Conceptual Design, during which we investigate how business needs and requirements and stakeholder needs and requirements are translated into a system-level understanding of the requirements of our system. This understanding will tell us what the system needs to do, how well it needs to perform, and what other systems it needs to interact with in order to meet the stakeholder and business needs and requirements. We then look at the concept of system level synthesis where we make some high-level design decisions before reviewing our work in preparation of the core design effort normally associated with preliminary and detailed design. To provide greater detail for this module, we recommend (but do not require) that students refer to pages 81-130 of our textbook "Systems Engineering Practice"--see reading on Course Notes and Text Books.
Conoce a los instructores
Dr Mike RyanSenior Lecturer
School of Engineering and IT
Dr Ian FaulconbridgeIndustry Fellow
School of Engineering and IT
It's now time to translate the business needs into more formal
business requirements.
Whilst undertaking this process, stakeholders are also required to look at
the feasible alternatives associated with closing our capability gap.
Feasibility assessment will allow stakeholders to concentrate their
efforts on defining business requirements around the most feasible solution space.
Note that they're not choosing or defining the solution at this stage, but
merely assessing the most likely solution option when looking at their requirements.
This avoids wasted effort and also focusses the business
requirements making them more useful in the following stages.
For example, earlier I mentioned an example of a military capability gap,
associated with monitoring national borders.
The likely options for doing this, that is the possible solutions basis, may include
satellite surveillance, surveillance from uninhabited aerial vehicles,
surveillance from conventional aircraft, or surveillance from warships.
These may all be technically feasible but the business needs and
constraints are likely to rule some of those options out.
For example, we may not have the money or
time to establish a satellite based system.
We may not have the human resources or
desire to establish a warship capability, the feasible options,
therefore, might either be conventional or uninhabited aircraft.
The stakeholders responsible for extracting business requirements should
therefore concentrate on the feasible-solution spaces only.
These business requirements will be more formally stated than needs, and
will eventually guide the development of engineering requirements for our system.
Whilst the business needs paint a picture of the problem and the desired solution.
The resultant business requirements are a further decomposition of the needs, so
that we can understand exactly what the business requires from
the ultimate solution when it's deployed.
We'll capture these requirements in a structured or organized artifact,
that we're going to call the business requirement specification or
simply the BRS.
Once the business requirements are established in the context of the business
needs, the stakeholders can document and record all of that information.
We're going to propose recording all of this information in the form of
an artifact that we call the business needs and requirements,
which consists of a preliminary lifecycle concept document, or a PLCD.
And a business requirement specification or a BRS.
Once produced and updated, we'll conduct some form of requirements review with our
key stakeholders and the organizational decision-makers, in order to review and
agree to the PLCD and the BRS.
That will then allow us to pass this information onto the groups of
more operationally focused stakeholders for them to refine and
further develop our requirements.
We have endorsed business needs and requirements from the previous work,
this shows that management are confident that there is a need existing for a new or
improved system.
And that they understand those needs sufficiently to move on with the process.
We have a preliminary life cycle concept document that describes all of
the life cycle concepts, including concepts for
acquisition, operations, support and disposal.
And we have a business requirement specification that defines the agreed
business requirements for the system.
We now look to build on this work by using selected groups of
more operationally focused stakeholders.
These stakeholders are more on the coal face so to speak, and are able to look
over the business needs and requirements and give them a more refined feel.
To acknowledge the refinement process,
we're going to call the resulting work the stakeholder needs and requirements.
In performing this work, the operational stakeholders will look over all of
the previous work, including the mission, goals, and
objectives, the scenarios, and the life cycle concepts.
They may develop more refined scenarios that are sometimes called vignettes,
to capture a more detailed and operational nuance.
They will also refine the validation criteria in order to communicate how
stakeholders could be convinced that their expectations have been met.
We will refine the preliminary life cycle
concept document into the initial life cycle concept document, or
simply the LCD, and we'll refine further the business requirement
specification in to stakeholder requirements pick or simply a STRS.
In some cases the refinement might be minor but
in other cases the LCD and the STRS may represent quite substantial developments.
Regardless, we will finalize their effort by reviewing both the LCD and
the STRS via another requirements review.
Armed with the endorsed life cycle concepts in the LCD and
the endorsed stakeholder requirements in the STRS, we're now in
a position to embark on a major systems engineering task within conceptual design.
This task is generally dominated by a system-level analysis.
As an introduction to this process,
I need to warn you that performing a solid requirements analysis, and
writing effective system level requirements, is a very tough job.
It's a job for a team of people, because more heads are better than one.
It's also a job for experienced people, because practice makes perfect.
Although, you're going to find perfection very difficult to come by
in the requirements analysis space.
And, it's also a job that requires iterations, reviews, and re-working.
We're aiming to describe what the system has to be able to do
in order to satisfy the stakeholder requirements in the STRS.
We try to avoid specifying how the system should be designed at this stage.
If we start specifying the design at this stage,
we risk overlooking innovative ways of solving the problem.
We also risk taking responsibility for a design that simply doesn't work.
We should specify what we want the system to do and leave the design to the experts
we engage to perform the preliminary and detailed design later in the process.
We'll record the system level requirements in an artifact that we're going to
call the system requirements specification, or the SyRS.
As we're drafting this artifact, we establish and maintain traceability from
our system requirements back to the stakeholder requirements just to
ensure that everything we specific has a reason for being there.
We also trace from the stakeholder requirements forward to
the system-level requirements,
to ensure that we've addressed all of the stakeholder requirements.
Traceability by forwards and backwards between different levels of
requirements is a cornerstone of requirements engineering.
In this case, it's traceability between stakeholder and
system level requirements that's of interest to us.
Later, the traceability of interest will be between system level requirements and
lower level design requirements of our solution.
A useful starting point for our requirements definition effort is to
establish a requirements framework, or a requirements breakdown structure.
We've probably already established a requirements breakdown structure in
the previous process, where we were looking at stakeholder requirements.
If it's already established, we can review, refine, and reuse that structure.
If it hasn't already been established, then now is the time to get one in place.
An example of a requirements breakdown structure, or
what we call an RBS, for a burglar alarm is illustrated.
The structure helps us when we're performing requirements work
because it allows teams of people to be working on the task at
the same time without duplicating the effort.
For example, we could have one team or one person looking at our
detection requirements, under heading two, whilst another team or
person is looking at reporting requirements, under heading four.
The RBS provides a common framework against which different teams of
people can have discussions.
And it will provide a common framework against which our requirements can
be allocated when the time comes.
This will allow similar requirements to be grouped and allocated to single
sections within the framework, assisting in correcting conflicting requirements.
It also helps us guard against duplication or omission of our requirements.
We then start performing our system level requirements analysis.
We're looking to answer some pretty fundamental questions about our system.
What does the system need to be able to do?
This is where our functional requirements help.
Functional requirements define what the system needs to be able to do.
How well does the system need to be able to perform those functions?
Performance requirements associated with our function requirements
define performance levels.
What other characteristics are required of our system?
These are typically emerging properties or
non-functional requirements associated with our system, these might include
factors like reliability, usability or maintainability just as examples.
What other systems are involved with our system?
We may need to define external interface requirements.
Probably specialized examples of functional requirements
associated with our system.
And under what conditions is our system expected to operate?
We also need to be able to define how we're going to verify our
system performance against those requirements.
It's important to note that verification is a term in systems engineering,
meaning to confirm system performance against specified requirements.
Recall that we've used another term, validation, in previous discussions,
to mean confirmation that our stakeholders are being satisfied.
Often you'll find that people use those two terms interchangeably,
which is not correct.
Also, people often combine the terms to describe the process as being V and V.
Unless that acronym V and
V is used very carefully, it may also be used incorrectly.
If we are talking about confirming a system against its specified requirements,
we're talking about verification.
Establishing verification requirements at the same time as writing functional or
nonfunctional requirement statements,
is considered to be good requirements writing practice.
It forces the author of the requirement to ask, how would I confirm this requirement?
It often highlights problems with the requirement statement and
forces the author to revise the statement in order to make if more verifiable,
this is a very worthwhile exercise.
While we're writing our requirements, it's also recommended to allow authors to
record rationale or notes associated with each requirement.
This allows the author to explain the background to the requirement for
future reference.
Traceability can provide some rationale for the requirement, but
it might not be enough to explain why the requirement exists.
Rationale may protect requirements from being changed in future,
without due consideration as the why the requirement was there in the first place.
I'll give you an example of where I have benefitted in the past from
recording rationale.
I remember being responsible for
writing requirements for a large project a number of years ago.
One day, about five years after finishing my job,
I received a phone call from someone who was still on the project.
And I asked why I had to sign a specific performance level,
against a specific requirement.
The caller said that I'd recorded a rationale pointing to a meeting that I'd
had with air traffic controllers,
relating to controlling air craft that were flying in tight formation.
Once the guy reminded me of the rationale, i.e, the meeting.
I was able to remember and explain exactly why that requirement was written the way
it was and who the caller should refer to for further information.
In the absence of that rationale, I think I would have struggled to recall why
the requirement was written that way, and it's possible that, that requirement would
be been changed with possible adverse consequences on the relevant stakeholders.
In this case, on the air traffic controllers,
who were going to have to try to control aircraft flying in tight formation.
Once the requirements have been written,
they are re-read, analyzed against the parent stakeholder requirements,
to ensure that they are of adequate depth and detail, and then we move on.
Further detail or breakdown occurs if required.
The requirements are then allocated to one of the locations within
the requirements breakdown structure.
We look at the requirements breakdown structure and
work out where, within that structure, the requirement best fits.
If it turns out that the requirement could reside in more than one
location within the structure, that's okay.
We make a decision, record it once, and then refer to it from the other locations.
Duplicating and repeating requirements in the same document is considered bad
practice and will result in potential conflict and
confusion in the future, especially if the requirements change.
We now have our requirements in a structured form that we're going to
call a system requirements specification, or an SyRS.
This may be a physical document, but it may also be a spreadsheet or
it might be in some other form like a structured or populated database.
It could even be in the form of a model of the desired system,
that's able to illustrate the system requirements via simulation.
There are plenty of reference sources out there to explain what structure and
content should be used for this level of specification.
It's form is not as important as it's existence.
It's only a draft at the moment because we're likely to categorize our
requirements as mandatory, important or desirable.
For example we might have a functional requirement associated with
detection range for our burglar alarm made we might have three levels of performance.
We might say that the alarm needs to be able to detect an 80 kilo human,
under certain environmental conditions from ten meters mandatory,
12 meters important, and 15 meters desirable.
This allows us some flexibility in expressing our requirements and
it also allows us to assess the value of different solutions when we look at
possible solutions in the next stage.
Whilst this concept helps us at the moment,
we will not leave those levels in the final specification.
We will end up replacing those levels with an agreed level that
the selected solution claims to be able to achieve.
We've been doing a lot of work in order to develop and
document the system level requirements.
As discussed earlier, it seems like common sense that we would review our
work before proceeding and this is certainly the case with our requirements.
Unimaginatively, we are going to call these reviews system requirement
reviews or SRR's.
Sometimes if we're dealing with a straightforward situation,
we might only conduct a single SRR for
our system, but, in all likelihood a single review just might be sufficient.
We'll probably conduct a series of reviews in a work-review-rework cycle,
until we're happy with our set of requirements.
This idea of a series of reviews leading to a complete and
agreed set of requirements, is illustrated in your slide.
Either way, once we've completed our SRR process,
we're ready to move on to system level synthesis.
The draft system requirements spec is sent out to potential solution providers.
These might be external organizations or they might be in house solution providers.
These providers will review the specification and
try to match it to what they can provide in the form of a solution.
They also note any differences between their potential offer, and
the draft system requirement spec.
Differences might be discrepancies or non-compliances, or
there might be additional functions, or
enhanced performance levels that the proposed solution can offer.
In most cases, solution providers will propose a revision of the draft
system requirement spec to make it better aligned with their proposed solution,.
Potential solution providers also advice the acquirer of the cost and
schedule associated with their solution,
along with the proposed revision to the system requirements spec.
The acquirer will consider all of these offers from different
suppliers before making a decision about which way theyâre going to proceed.
It's normal to conduct a period of negotiation and offer definition with
the preferred supplier, so that both the acquirer and supplier are very
clear about what is required and what is being offered including how the system is
going to be verified by the customer prior to acceptance.
The system requirement spec will be a very important part of these discussions, and
by the end of the discussions that specification needs to be refined and
agreed and needs unambiguously define the what, how, well, and so
on of the proposed solution.
Once we have a solid understanding of our requirements via
the system requirements pick, and we've selected and
negotiated a preferred solution via system level synthesis, we conduct a system level
design review to confirm that we are ready to move on to preliminary design.
Not surprisingly, we're going to call this review a system design review, or SDR.
During SDR, we will investigate the proposed solution, and
the refined system requirement specification.
Within the refined system requirement specification we're going to have
a look at the traceability back to the stakeholder requirement spec, and
the planning that's being put in place to execute and manage the technical program.
Like all of our design reviews,
we need to run the system design review like a professional technical meeting.
This means that we need to establish an agenda,
nominate a chair person anda secretary, take minutes,
take action items and then follow up on those action items, after the meeting.
Once complete to the satisfaction of the acquirer,
we're ready to move on to the next stage of the system's engineering process.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2018 Coursera Inc. Todos los derechos reservados.
