WRSPM Model: Real-world Example

Loading...

From the course by University of Minnesota

Software Development Processes and Methodologies

181 ratings

University of Minnesota

Software Development Processes and Methodologies

181 ratings

Course 1 of 4 in the Specialization Software Development Lifecycle

Software is quickly becoming integral part of human life as we see more and more automation and technical advancements. Just like we expect car to work all the time and can't afford to break or reboot unexpectedly, software industry needs to continue to learn better way to build software if it were to become integral part of human life. In this course, you will get an overview of how software teams work? What processes they use? What are some of the industry standard methodologies? What are pros and cons of each? You will learn enough to have meaningful conversation around software development processes. After completing this course, a learner will be able to 1) Apply core software engineering practices at conceptual level for a given problem. 2) Compare and contrast traditional, agile, and lean development methodologies at high level. These include Waterfall, Rational Unified Process, V model, Incremental, Spiral models and overview of agile mindset 3) Propose a methodology best suited for a given situation

From the lesson

Software development processes : Part 1

In this module and next one, we will learn about various software development processes at a high level to understand what is involved in each of these processes. In this module, we will cover Requirements and Architecture.

Why do we need requirements?4:37

Requirements vs Specification4:14

Non-functional Requirements3:19

WRSPM Model: Real-world Example7:29

Meet the Instructors

Praveen Mittal
Adjunct Professor
College of Science and Engineering
Kevin Wendt
Teaching Specialist
Department of Computer Science and Engineering

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

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play