Scoping document - software

Forums › IT Pro and developers › Scoping document - software

SouthernJ

36 posts

Geek

#123271 1-Jul-2013 20:43

So. I need to pick a few brains (please).

I've Googled - to no avail...

Scoping documents (for software) what information should they ideally contain? I'm twixt and between: my legal office background is telling (screaming) at me to make sure I've got an entire library's worth of words in pages and pages of documents but the 'person' in me is saying otherwise...

I'm kinda in the deep end here: all and any suggestions, pointers, etc are greatly appreciated!

TIA

nate

6473 posts

Uber Geek

Retired Mod

Trusted

Lifetime subscriber

#847947 1-Jul-2013 22:15

Our scoping document outlines functionality the client's customers will have, what is in the admin panel, what integrations are included, who will host it, etc etc.

It's pretty much a comprehensive outline of exactly what the system will do. I would suggest the more detail, the better.

(ours also make up a big portion of our legal agreements)

sleemanj

1490 posts

Uber Geek

#847954 1-Jul-2013 22:23

Who are you presenting the document to, and what are they expected to produce for you after reading it.

If you are presenting this document to lay-people (otherwise known as, management), keep it to talking points and buzzwords, general broad outlines, they will glaze over if you go in too deep, they won't read it, or comprehend it, and they will still complain that "it's wrong" when the product is produced exactly according to what you wrote.

If you are presenting this document to somebody who is going to design your new software, the architect if you will, just include the functions you want your software to have. It is their job to take what you say you want and write the specification that describes what you actually need (two separate things).

If you are presenting this to a programming team, then you need to clearly outline what it is you want, exactly, and how it is to work, exactly.

---
James Sleeman
I sell lots of stuff for electronic enthusiasts...

SouthernJ

36 posts

Geek

#848029 2-Jul-2013 07:35

@Nate - thanks!

@Sleemanj - thanks!

Things to think about - both from different perspectives.

Behodar

10504 posts

Uber Geek

Trusted

Lifetime subscriber

#848031 2-Jul-2013 07:45

Our ones also have a section for things that the software won't do (due to time, budget, etc) that the customer may otherwise expect.

SouthernJ

36 posts

Geek

#848045 2-Jul-2013 08:26

Thanks @Behoder - that's a good idea ... nothing worse'n than the 'curse of ass/u/me', eh?

TwoSeven

1623 posts

Uber Geek

Subscriber

#848393 2-Jul-2013 19:02

What kind of project is it for? An internally developed software project for a customer, or one that is going to be developed by an external vendor?

I typically use two types of scope, the first is the Project Scope which defines what activities are included in the project as a whole, the other is the product scope which determines the functional and non-functional deliverables of the final product. The type of project usually determines the weighting of each document - for example time and materials or fixed price.

Also, what project management method is being used? If using PRINCE you'll probably already have a project brief to work from and your scoping process will need to tie in with that. If you are using PMI it may be likely you may only require a Product Scope in which the customer is paying for the deliverables (the stuff in scope). In both cases as mentioned above it is worth while thinking about what may be out of scope.

Another thing to consider is what process are you going to use to manage changes to the scope. For example, if you get scope change that affect the final timescales, is another feature going to be pulled or pushed into a different phase, or will it be ok to move the timescale back. Who needs to be notified and what kind of signoff is required is another consideration for this process.

Finally is your project going to have a risk plan with the appropriate risks mitigated (and will any of these affect the scope if activated?)

As suggested above, it is always worth while knowing the audience one is writing the document for.

Software Engineer
(the practice of real science, engineering and management)
A.I. (Automation rebranded)
Gender Neutral
(a person who believes in equality and who does not believe in/use stereotypes. Examples such as gender, binary, nonbinary, male/female etc.)

...they/their/them...

SouthernJ

36 posts

Geek

#848483 3-Jul-2013 06:30

Thanks for such a detailed answer TwoSeven - appreciated.

Our goal is that the next natural transition after we've delivered the scope is to be assigned the contract to build... that we'll have so wowed and impressed, that they wouldn't even consider going anywhere else. (Isn't that everyone's, lol?)

As we're currently dealing with the owner of the business your suggestion of including 'future alterations' is a good one (thank you) ... no one can know what's in the future, eh?

Thanks for your contribution and input!

GoodSync

GoodSync. Easily back up and sync your files with GoodSync. Simple and secure file backup and synchronisation software will ensure that your files are never lost (affiliate link).

TwoSeven

1623 posts

Uber Geek

Subscriber

#848584 3-Jul-2013 10:00

Believe it or not, one can actually develop a good idea of the future when it comes to software development :)

It comes down to ones understanding of both the vertical market segment and the business domain in which the customer is operating as this leads to a better understanding of the problem that is to be solved.

Generally I have found that it comes down to the quality of the analysis model that one uses. This model is used to foster an understanding of the existing system and turn subject matter experts opinions into tangible fact. Note that analysis model is a method specific term, different methods will do this in different ways.

...they/their/them...