Hi. In this video,
we're going to take a better look at a real world example of
the WRSPM reference model in action.
So as a refresher, this is the WRSPM model.
What we have is the world assumptions,
the requirements both residing in the environment area of visibility,
the S meaning, specification sitting
within the interface between the environment and our system,
the program and machine itself.
The hardware, has a software and the hardware
that's set within the system level of visibility.
And then using these four variables of EH, EV,
SV, and SH, we look at the control.
So EH are those elements of the environment that are hidden from the system.
EV is the elements of the environment that are visible to the system.
SV is the elements of the system that are visible in the environment.
And SH is the elements of the system hidden from the environment.
Now, this is all relatively abstract.
So to get a better understanding of the difference between
the requirement and the specification,
let's take a real world example of this.
So we have is a patient monitor.
It's something that keeps track of things like heart rate,
pulse, those kinds of things.
The desire for having a patient monitor is that it is
a warning system that notifies a nurse if the patient's heart stops.
It does other things too, but let's focus on this one user desire for the moment.
That's the user's goal.
The real requirement then,
is that when a patient's heart stops,
a nurse is notified.
That's what the user really wants.
They want a system that does that.
If the heart stops, some nurse is notified,
that's really what they want out of a system.
But our system requirement,
what we're going to provide is that when
the sound from a sensor falls below a certain threshold,
an alarm is actuated.
So, when we talk about a sensor, in this case,
what it means is that there's a microphone hooked up to
the patient that measures the heartbeat.
And what we're talking about measuring
the sensor's feedback when it's measuring the volume from that sensor.
And when that sensor falls below a certain threshold,
and what we mean by that is a certain volume over a certain period of time.
Once that fails, we want the alarm to be actuated.
The question, though, is that,
is this satisfying the real requirement,
or will we call it user requirement?
Because remember that the real requirement was that if
the heart stops, the nurse is notified.
That's different than not hearing the sound anymore.
And as anyone who's been in a hospital
and dealt with one of these patient monitors knows,
there's a heck of a lot of false positives.
The sensor falls off, the sensor moves.
The sensor just isn't sensitive enough to pick up the heartbeat.
But those false positives,
especially in a safety critical area like a hospital are generally considered okay.
We'd rather the nurse have to check more often than not.
So, while this system requirement comes close,
it's not quite actually meeting the real requirement.
There's something missing in between what we say we're going to do for our system,
the system requirement or system specification,
and the user requirement,
what the user really wants.
So here's patient monitoring.
The requirements definition.
What we write down is that they want
a warning system that notifies the nurse if a patient's heart stops.
That's what the user wanted.
So that's how we captured what they want.
We then talk about our system design as,
we can make a computer that uses a microphone as a sensor and a buzzer as an actuator.
And using this system design,
we can then talk about this requirement specification. Here's what we're going to do.
If the sound from the sensor, our microphone,
falls below some certain threshold which we'll define based on the user's needs,
this buzzer shall be actuated and it
will work if we take a computer that's been programmed properly.
If we program the computer to buzz
the buzzer when the sound from the sensor falls below the threshold,
we have a warning system that notifies the nurse if the patient heart stops,
sort of, that kind of works.
But we're still missing some key elements.
And these are the W from the WRSPM model,
It's the World assumptions.
This works because there will always be a nurse close enough to hear the buzzer.
We didn't say anything about the nurse hearing the buzzer,
that's a World assumption.
We are making a business rule assumption that there is
a business rule that a nurse will be at
the nurses station because that's where the buzzer is.
So if the buzzer goes off and there's a nurse there,
which the business rules require,
then they should hear the buzzer.
Now, we also start talking about, well,
what about nurses who are deaf? They can't hear the buzzer.
So now we have to talk about actuating our actuator,
maybe a buzzer is not sufficient.
Maybe we need a buzzer and a light.
Maybe we need a buzzer, a light,
and something that actually physically shakes the desk, something like that.
So it's not only necessary that a nurse be close enough to hear a buzzer,
it's that a nurse is close enough to recognize our alarm once we've actuated it.
In addition, we also have a World assumption that if
the sound from the heart falls below that threshold,
that means the heart has or is about to stop.
Now, this is a pretty light definition because just because that's happened,
the sound falling below the threshold,
doesn't necessarily mean the heart has or is about to stop.
That's not necessarily true.
However, we accept that to be true because
the only other reason for it to fall below
the threshold means that the sensor isn't in the right spot,
or it's falling off, or for some other reason,
we definitely also want the nurse to go and check.
Those are world assumptions that we haven't properly modeled yet.
We will talk about our definitions back
here of our requirements definition and requirements specification.
The WRSPM model helps identify the elements involved in solving the problems.
You have to be very careful about the World assumptions.
The requirements are met when these things are true.
The Specifications meet those requirements when and only when these things are true.
What you want to be able to do from a formal standpoint is that,
if W and S,
the World assumptions and the Specifications imply the requirements are
met and the machine and the program imply that the specification has been met,
then and only then your solution is right,
and where most of the problems like,
is in that definition.
It's that W and S imply are,
we have to make a lot of assumptions about the world and
make a lot of other things that are out of our control most of the time,
to make sure that that's true.
The same goes for M and P,
the Machine in the Program.
Just because we have our Specification,
doesn't mean that we've programmed it properly,
doesn't mean that we've tested it properly,
doesn't mean that the machine won't fail sometimes.
Those are all things that we have to assume when they imply S. So it makes
this WRSPM model very important to make sure that
you're actually investigating all the assumptions,
to make sure that these two equations end up being met.rr
