To emphasize the challenges that we face,
please consider this example and think about it for a couple of minutes.
Consider the case of somebody coming to you and saying,
"I work in immunology and I want a website that will search
a database and report severe outbreaks of the disease that I searched for.
My bosses hired you to construct the site.
Good luck."
So I want you to think about how you would develop a set of requirements to describe
what you're going to do based on just this bit of information.
First, who would you talk to? What information do you need to learn?
Just from this description,
what kinds of questions do you need to ask?
Please take a minute and think about this.
When you looked at this issue,
when you looked at this potential project,
all of you likely came up with very different things.
One of the first questions to ask from that description was, what's severe?
What defines a severe outbreak?
Severe could be regional,
a regional outbreak, it could be international.
What are we looking at?
By the way, as a customer,
I also forgot to tell you that,
there's already a database out there that you could be using, sort of.
You need to clarify what that database is and how you can use it.
And if you can use it.
Another thing I forgot to mention as a customer is that,
my intern shouldn't be allowed to use the database.
People need to log in with proper qualifications.
Follow up question.
What are proper qualifications?
Within software requirements, you are constantly asking the question, why?
Why are we doing this?
Why are we doing this?
Why are we doing this?
You feel like a five-year-old asking why the sky is blue and continually asking.
Many times it becomes our job to discover the requirements.
For example, if I said,
"Please find me a rock."
You might ask, "What size of rock?
Do you want a gemstone or a rock?"
"Wait, you actually won, Dwayne Johnson."
He's the rock of TV and movie fame.
So you have many questions to ask that.
As another example, I could ask you as my requirements engineer to build me a house.
Size, levels, location, mobility,
the list goes on and on.
Software is very tricky and customers
often lose the sense of responsibility over the product.
And is up to you to figure that out.
Customers will look at it and say,
"You handle the computer stuff."
It's your job to figure out how to convert the customer's stuff to the computer stuff.
So now we're going to get into how we can do that effectively and efficiently.