Every software
project needs a really good specification if
its gonna succeed but it
takes a lot of practice to
able to write those specifications it is
not easy. So today we
are gonna look at a very simple
approach that anybody can use
to write  solid specifications to get their project done right.
Hey everybody, I'm Dave
Hecker and today we are talking about how
to write specifications for your outsource software project.
Let's first look at what the
high level objective is of the specification.
All you really want to do
is communicate what you need to the developing team.
It doesn't really matter how
you do it, or the format
or what it looks like, or how you deliver it
as long as you communicate it well, that's what we're going for.
It's not easy to do
but there is kind of a
simple mentality that you can
take that's going to help a lot.
First you wanna keep in
time that you should
always put in as much detail
as possible, you can't have
too much detail. Repeating yourself a
few times or putting into
unnecessary detail waste a
little tiny bit of space on usually a virtual document.
Forgetting something is a
big expensive mess, so don't
hold back try to get as much as you can.
Also imagine that the reader,
your developer, is coming with zero knowledge.
Explain everything no mater
how rudimentary or obvious
it seems get it down on paper.
Imagine they have nothing coming
in that's going to
help a lot, and they have to learn everything from scratch.
Use lots and lots and lots of words.
Don't go short.
Don't try to be concise.
Really go for it.
Just keep talking or talking or whatever it is you do.
So keeping those things in mind
we're going to walk through an example
and I'm going to show you how easy it can be.
This is sort of a brainstorming exercise.
People think that when you write
a requirement to know
exactly what's going on in your application.
You've got everything in your head and you're just writing it down but it doesn't really work like that.
Writing requirements is a brainstorming
process in this example
we're going to use a real
example which is a site
that tracks peoples weight loss.
So, when this client
comes to the service provider they
say I've got this great idea
for the weight loss site and here are the requirements.
And let's say one of the requirements says something like this.
User's can see metrics about
their workout. Sounds good.
The client is probably thinking
there's going to be all kind of
metrics, they can see
how their workout are going, how
much weight they're losing, how much
muscle their getting whatever it is.
The developer, that doesn't mean
anything, they're going to say
what metrics are you talking about?
I need more information.
So already we can just add words.
That's the main part of the exercise.
It's just add stuff. Let's see
if we can add just anything to that requirement.
How about instead of user
can see metrics about their work
out, logged-in user
you can see metrics about their work
out. Not very useful but
we did add something into
its true The idea of
the exercise is just to add
stuff for brainstorming. So its
OK that it is not really meaty.
Lets try it again. We can
look at that and think well What kind of metrics are there?
There could be lots of them.
Let's try one.
Logged-in user can see
a progress chart showing their weight loss.
Now, this is getting good.
Now we've got a specific metric in mind.
We know the user is logged-
in and we're starting to develop a real requirement.
Let's try to add one more thing.
Logged-in user can see the
progress chart showing their weight loss period.
The chart will show the
users weight loss by day,
week for a month.
Now this is kind of getting interesting.
Now at least we're drilling down on one feature.
It's okay to repeat yourself, like
we say logged-in every
time, it seems obvious right, but
don't worry about that because we
want the developer to be crystal, crystal clear.
We don't mind repeating our words.
Okay, we're brainstorming that right now.
We're going to brainstorm in
a totally different way We're gonna tell a user story.
These are sometimes called use cases,
sometimes called user stories, but it doesn't really matter.
The idea is to get away
from a requirement that says the
user can do this and
try something where it says,
this user enters the site
and here's what they do and it's sort of a narrative.
So let's try the same requirement as
the user story. Lets try
like this. A user wanted
to see their weight loss so they
logged in to this site and
they viewed a chart showing their
progress. That's kind of
the same requirement but its just said in a different way.
The reason it's so valuable is because
now we're still brainstorming and we're going to think of a lot more stuff as we go.
Let's try it again, we'll add
a little more brainstorming and we're adding stuff all the time.
A user wanted to see their
weight loss so they logged
into the site, clicked on My
Progress and saw a chart showing their
weight loss. This is even
better. Now we came up with
something new. The developer didn't
knew that there was a area
called My Progress. So
through this brainstorming process we started
to go up navigation and it's getting more and more useful to the developer.
Let's try it again.
A user wanted to see
their weight loss so they
logged into the site, clicked
on My Progress and saw a chart showing their weight loss.
Their weight had gone up that
week and because they were gaining
weight the chart was displayed in red.
Now that might be something you just
thought of while you were
brainstorming that use case but
it doesn't matter. If you
wanna capture it down, if
its something you wanna do it write
it down. You don't need
to go from beginning to end
and write down every single piece of the application in one go.
It never works like that.
Consider it a brainstorming exercise
and just jump around all over
the place and when something comes to you just add it in.
Just start typing, typing and
typing and you'll drill down on
each requirement just like we did on that one.
After you add that one
requirement go back to the
use case and read that and
then go back and forth and if you think of something else jump to another requirement.
It doesn't matter.
Just alternate, keep moving.
So, to sum it up
alternate between requirements and user stories.
You want to be brainstorming.
You want to keep adding stuff.
You can never have too many words.
Repeating yourself is okay
and imagine that the
reader of the document was starting with zero knowledge.
They're coming in totally cold.
So that's it for today.
For more outsourcing advice,
be sure to visit us a sourceseek.com
and be sure to subscribe to our channel for weekly tips.
We also want to hear from
you . So please leave your
comments and questions below. We are gonna answer
every comment and question that comes in.
We'll see you soon.
