Requirements vs Specification

Loading...

From the course by University of Minnesota

Software Development Processes and Methodologies

180 ratings

University of Minnesota

Software Development Processes and Methodologies

180 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

[MUSIC]

Hi, in this video, we're going to differentiate the two ways you document

functionality in a software requirement specification document.

The reason there are two ways to write these statements of what the system will

do is that there are two audiences for that information.

The first audience is the user or the client, depending on whether or

not they're the same person.

In many cases, the user isn't technical.

And so we'd have a very difficult time talking with you about what they want

the software to do.

They don't know the potential of what they can do.

But we still need to provide some sort information that explains

what the system will do, so

that the user is relatively assured that they get at the end what the client

is paid for and it actually does what the user or client wanted them to do.

The second audience is the developing team.

We also need to provide enough detail to allow the people making the solution,

making the code.

Know what the system should and shouldn't do.

Now, this is where things tend to get tricky.

We use natural language, primarily because it allows for

an easy communication protocol with our users.

Know or very little,

technical jargon should hopefully avoid some miscommunications.

But it's often not very precise.

Let me give you an example.

Imagine that you're talking with a street vendor, they're selling you drinks.

You ask what they have.

The merchant says, bottle of water or a cup of tea is a dollar.

You tell the merchant, I'll take both.

The merchant obliges and you put down a dollar, and start to walk away.

Does that sound right to you?

This is what's called an exclusive or.

The or in the case of the language here means one or the other, but not both.

How about this?

I tell you that if you pass all the quizzes or pass all the assignments,

then you pass the class.

You then pass all the quizzes and you pass all the assignments, and

I tell you that you failed the course.

You be a bit upset by that?

This is an exclusive or.

The or in this case means one or the other, or both and

then there's the problem of people saying and when they mean or.

The moral of this story is we need to be very careful of the language we use when

developing these statements.

So let's distinguish them a little bit.

User requirements are exactly what the user wants the solution to do in

the user’s language.

Users do not want to log in though, we want them to.

They want the system to be secured to only allow them to say,

post to Facebook on their behalf.

Logging in is the systems specification.

The required action of the system solution were developing.

System spec is the usually more precise or

constraining statement of how the system will meet the user requirements.

This is still with the solution we'll do not how, but

it's how the system will meet the requirement.

Software design then takes this requirement specification and details that

how, which modules be constructed will it be oriented toward design and development.

How do we make it happen?

This still may not be clear, so let’s take a quick example.

Take this user requirement.

We want to make a boat and sell to the general public.

We talked to some users to find out what they want, so

that we can build what they want so we can make money.

We can tell when a user can put our boat on a rack by themselves,

but how do we constrain and specify our solution to make sure that happens?

Because the generic statement, one person must be able to load the boat on a car

rack doesn't really give our design team anything to go on.

So we specify the solution in such a way that our specification means that we

have met the requirement here.

Now, we have at least a partial list of things we must meet.

And if we meet these things, we have met the user requirement or

at least we think we have.

This is another area of potential mistake.

Making assumptions about whether these specifications will translate about having

met the requirement.

So you need to take care that these and

only these are sufficient to meet the requirement.

So we assume that if the boat's lighter than 100 pounds that it has handles,

that one person can load it onto the car rack.

There is a slight, but important distinction between the requirements and

the specification and it's never quite as easy to distinguish them in reality.

Real world users may very well give you specification level detail.

So not all requirements need a lot of specification level detail to

refine the intent.

But a lot of time, it does need that requirement.

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