"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 3 Part 3
Loading...
Из курса от партнера UNSW Australia (The University of New South Wales)
Introduction to Systems Engineering
229 оценки
Из урока
Needs and Requirements
Before we look at the various systems engineering activities in more detail in forthcoming modules, in this module we look at what we mean when we refer to the ‘needs’ and ‘requirements’ for a system. We examine the needs and requirements views developed by business management, business operations, and systems designers. We will also consider in this module how we might go about developing a set of requirements—we call that process ‘requirements engineering’. To provide greater detail for this module, we recommend (but do not require) that students refer to pages 43-54 of our textbook "Systems Engineering Practice"--see reading on Course Notes and Text Books.
Познакомьтесь с преподавателями
Dr Mike RyanSenior Lecturer
School of Engineering and IT
Dr Ian FaulconbridgeIndustry Fellow
School of Engineering and IT
Before we leave requirements, it's common to consider two additional aspects of
requirements and requirements engineering.
First, there is certain characteristics we desire from a well formed requirement,
a good requirement we say.
And second, we often upend to the requirement statement one or
more attributes.
And the purpose of doing that is to use those attributes to help us to manage
the requirement statement itself, and the set of those requirement statements.
But let's first look at the characteristics of
a well formed requirement before we come back to consider its attributes.
Desirably, to be useful,
each requirement statement should exhibit all of the following characteristics.
And the first is, to be Necessary.
Now, of course, it seems to be quite obvious statement that
the requirement must be necessary, otherwise we wouldn't have included it.
But it's a good test for us to say, well, is this requirement actually necessary?
It must be necessary if the system has to function in the desired way.
It follows then, the requirement that isn't necessary can't be
traced back to a higher level requirement or indeed be traced back to a higher need.
So I just add that little simple test is this requirement necessary,
allows us to understand whether the requirement really should be there or not.
And that helps us regarding instincts like scope crew.
The next characteristic is Singular.
A requirement can't be a combination of two or more requirements.
Remember we said a requirement is an agreed-to obligation, and for
an obligation to be fair, it has to be singular.
We have to say one thing.
It also helps us then when we're testing it,
et cetera to make sure that we're talking about a single thing.
So, it's very important to make sure that requirements are singular.
They simply apply to a single function, not to a combination of functions, and
that means that the requirement is concise and it's clear.
It follows that the requirement should also be correct.
Again, that it is correct, as axiomatic, we need to know that, but
this is a little test.
We say, is this this requirement correct?
Are we sure it's correct?
Are we all sure it's correct?
To make sure that we don't carry forward requirements that
aren't real requirements or requirements that actually are misleading.
And that brings us to the next characteristic,
requirements should be Unambiguous.
That is, everybody who reads it should all understand the same thing as they've read
that requirement.
Now, that's particularly difficult in languages like English where one
statement can have a large number of meanings and
every word has a considerable number of synonyms.
And so it's very important to make sure that every future reader of this
requirement will understand correctly what the requirement is communicating.
The next characteristic is feasible.
And again, that sounds obvious.
But a little test before we continue on is if we say that, and
we want the system to perform that function, is it actually feasible?
That is, can we do it with existing technologies?
Can we do it with existing skill sets?
Can we do it with the existing manufacturing capabilities?
And so on.
And again, it's just that little test ensures that we don't go
writing requirements that aren't in the end going to be able to be completed or
manufactured or produced.
As well as those,
other characteristics include, well firstly appropriate to level.
That is, that the requirement may even be all of the previous characteristics but
being said at the wrong level.
So we really oughtn't to be talking about sub system functions at the system level
for example, because it's a system level statement and
we're talking about the outside.
The system as a black box, not the inside of the system.
So we need to be very careful then to only say those things that are appropriate to
the level when we're talking about an entity at that level.
The next characteristic is complete.
The requirement itself, now this is not the set of requirements,
this is the individual requirement, needs to be complete.
We say in English, that it shouldn't beg the question,
that there shouldn't be things that are raised by reading it.
You should be able to read the requirement and know exactly what it means.
And that is, it should not need any further explanation.
Then the requirement should conform.
That means that each requirement must conform to a standard formal structure,
probably as described by the organization or perhaps by some external standard.
And that means that when we read it,
because we read it always in the same way, in the same standard format,
it means of course that requirements are therefore less ambiguous as a result.
And last, as we said, not that long ago, requirements need to be verifiable.
That is, we have written a verification statement.
We need to be able to know how it is we propose to prove that the system meets or
possesses this, this property that this requirements requires.
Verification could be by one, or any number of means.
But it's worth a while here before we continue.
It's sort of like being feasible.
If the requirement is feasible, what is the feasible verification method that goes
along with it, because we have to pay for the function.
We also have to pay for the verification method, and so the person who's
writing the system specification has to know what those two things are.
What is it we want and
how it is we propose to know that we've got what we want at the other end.
In addition to requirements characteristics,
we use attributes to support analysis and management.
And so, a requirement could be allocated a number of attributes.
In fact, there could be many such attributes to,
to a requirement sometimes, up to some 300.
Here we only identify a small number which would be the major attributes.
But you get the idea of the sorts of things that an organization might wish to
attach to a requirement to allow that organization to
manage that requirement better over the life of the system.
The first, of course, is the unique identifier.
Words that are general and long lists of words become difficult to manage.
So, each requirement must have a separate unique number to
identify the unique statement.
And of course, you know, requirements database that generally tends to come for
free, as you are allocated a key to the database.
But the point is that, whichever way we manage them, we need a unique identifier.
That number of course is also not terribly useful.
So it helps to add to the number a short title.
And that short title then, in three words, four words long,
simply summarizes the requirement.
It's not as useful as the requirement, obviously, but
it is useful to refer to the requirement by its short title rather than reading out
a number which doesn't seem to make sense or reading the long sentence every time.
Each requirement also needs to have attached to it a priority.
And that's important because later on, we'll talk about the idea of design space.
That is that the designers can trade off weight for range, for burn rate, for
leg room and so on, on a platform like an aircraft.
If we don't understand which is more important to the customer,
then it's very difficult to use that design space to design the system.
So priority is a way which the originator of the requirement communicates to
the designers, and how important each those aspects is to them.
Now, it's not mandatory, but it's also very useful whilst writing
the requirement to attach to the requirement some indication of risk.
It could be a risk level, or
could actually be a risk statement in some, in some, systems.
That is when the writer of the requirement articulates it,
they also have to think a little while about what risk is attached to that, and
that goes back to as we were talking before about
the feasibility of the requirement, and, and also the ability to verify.
If we need to ever in the future discuss the requirement,
we might need to go back to the source.
Now it could be a standard, it could be a regulation.
But it's also commonly of course, an individual or
an organization, or a committee, or a workshop.
Also molicitation process that gave us the requirement.
And so we need to know where it came from in case we need to
go back to discuss perhaps if two requirements conflict, for example.
We might need to go back to reconcile that with the original sources.
Another useful attribute, as we saw before, is a rationale.
Some people would write a rationale statement.
Others might include rationale in the attributes.
I doubt that it matters really either way, but what's important again, as we
said before, that we record the reason for the existence of the requirement.
We also might want to record some history.
Now again, of course, in a relational database the history is tracked
generally by the database so it sort of comes for free.
But we want like to know, when was this requirement raised?
How often has it been changed?
Have we deleted it?
So where are the old requirements that we deleted?
So, history is a really useful thing to help us understand how it's changed in
the future.
We also might like to know, as we saw before, and
we'll talk again later about traceability.
How does this requirement relate to other requirements?
And so those relationships ought to be tracked as well.
Again, it could be in the attributes or it could be part of the relational
database in the modern requirements management system.
And of course as I said before there can be up to some 300 requirements attached,
so lots of other information could be included as an attribute of a requirement.
We can the date of raising, the status, and
is it currently being reviews, has it been accepted, was it rejected, any comments
that are useful to subsequent designers are very useful things to include.
And finally, it's often useful to add a type attribute, so the requirements can be
seated in various logical groupings that are useful in their management.
The type can be of any type really.
Some organizations insist on having a structured series of types,
of labels that can be attached.
Others allow the type field to be open to allow people to add any number of types.
But the value of the type field is to be able to record what sort of
requirement this is.
So it could a, a safety requirement,
a security requirement, a training requirement and so on.
The idea is that we get orders a lot in requirements databases.
So if somebody says to us, so, where are all your safety requirements?
Or, where are all your requirements that relate to standard xyz?
It's very useful to be able to use the type field in a database, to say,
well, let me print out all the safety requirements.
And therefore search and
print based on the type field safety, rather than have to go through and
look and see which of the requirements might relate to safety, for example.
And so there are any number of types and
each organization would use a slightly different system.
But whatever they use, type is a very useful attribute to attach to
a requirement statement as part of a requirement expression.
Finally, in this module,
we make brief reference to what we call the emergent properties of a system.
That is, we have to recognize that when we develop a system,
it will have certain properties that are those possessed by the system as a whole.
And that those properties may not have been obvious in any of the elements, or
the interconnections as we built the system from the component,
all the way up to the subsystem level.
And those properties, therefore, only emerge once all the individual system
elements have been integrated, and hence we call them emergent properties.
Those properties are not obvious by looking at the elements or
the sub systems.
They are only possible when you look at the system as a whole, and
perhaps even only possible when you're looking at the system as a whole as it
interacts with its environment.
That is as it's operating.
There are many examples of emergent properties, and
we don't really have time to deal with them properly here.
We just point them out because firstly, there are lots of,
of, there is maintainability, reliability, usability, security, safety and so on.
All of these things are only obvious when the entire system is put back together.
And secondly, it is possible that there is a property which emerges which is
unexpected, and that's something that we need to be aware of.
Many of these properties we do want and we expect and we design for.
It is of course, possible for there to be an emerging property, which is undesired.
If you want to keep an example in mind on the way through, perhaps the bicycle's one
of the best examples, because if we looked at a bicycle itself and looked at
all the sub-systems, we'd see wheels and frames and handlebars and so on.
But if we stood it up, it would fall over.
In fact, even if you put the rider on it, it falls over.
It's not until the rider is on it, and is pedaling,
moving forward, that the entire functionality of the system is obvious.
And so that property of the system,
which is really what we would call a bicycle, is an emergent property.
It doesn't exist until all of the elements of the system are together,
including the operator, and
that all of those systems are interacting with their environment with gravity and,
and so on, and the wind, until we can see the actual properties of the system.
We're interested in emergent properties because they have to be defined top-down.
They can't be obtained by specifying requirements for
individual elements and then hoping that those properties will emerge as we
combine those elements together.
So for example, if we say the system must be safe,
it's up to the designer to decide how the elements contribute to that safety.
So that when all the elements are together, the entire system is safe.
But it could be true that none of the individual elements themselves are safe,
but the combination is.
And so that emergent properties are very important thing,
it has to be specified top down,
and it has to be controlled by the designer as the system design continues.
Of course, as I said before,
we must also consider the possibility of the completed system exhibiting some
emergent property that hadn't been considered as part of the original design.
And in some cases may be undesirable, in the completed product.
That is, we have to understand that when we are putting subsystems or
elem, system elements together to interact,
that some of those interactions may well be unforeseen.
In this module, we've discussed requirements, the levels at
which they exist, and the relationship between them at each of those levels.
We looked at a number of definitions, and
then finished with an introduction to requirements engineering.
In the next module, we'll look in more detail at how to create, and
how to validate a set of requirements.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
