Documenting Scope: Concept vs. Solution

As many of you can attest to scope can be painful and usually not in a good way. The process of defining the project scope can be challenging for me becauase I like to see and end result in my head so I can write the scope. My excercise of doodling on paper is exteremely helpful for writing the functional requirements of the scope document. But I do not have that same luxury this time.

One of the most difficult things that I find in writing scope documents is the constant struggle in my head of highlighting the functional needs to meet the solution I see in my head. As I have mentioned previously there are plenty of changes to the solution in my head, but it is easier for me to understand how the final product will operate in order to capture the requirements for making the vision a reality.

In my current role we do not solution any functional requirements in the scope document itself. We are to provide a high level concept that the development teams can find an appropriate solution. The following example is an exaggeration, but still reflects the point I’m trying to make. If I know that I want to have a flash file that can display videos I would need to write it like this: Page will need to allow for Flash component capable of video and other media types supported by Flash.

That sounds redundant doesn’t it? The reason for being specific is that if I do not allow for the other media types then the door is open to ONLY support flash video. In this case we could potentially have a space on the page that will only display “.flv”. The content management system might also be coded to accept only “.flv”. As soon as you paint yourself into a corner the stakeholders will comeback to you and ask for “.swf”.

To get around this I usually end up with more “solution” than “concept” in my scope document on the first draft. I then go back through and pull the details where it is unnecessary and rephrase the wording. This is how it works for me. Let’s hope I can nail down my scope before the deadline next week!


2 thoughts on “Documenting Scope: Concept vs. Solution

  1. Isn’t your example requirement slipping from the WHAT to the HOW? I would have written it as “The page will display video of various formats.” This way I know I’d end up with an architecture that provided an adapter for the various video codecs. I would then specify flash in the non-functional requirements (HOW WELL). If the application doesn’t meet the non functional requirements, it doesn’t ship. You would need to test for the adapter being there, otherwise, it might just get ignored and left for later refactoring.

    I recently read in another blog that you can use a persona to be the source for architectural features. I like that, because in specifying my marketure, or technical architecture that facilitiates marketing, personas would work. Marketure is not something that developers are aware of.

  2. David,
    I should clarify that our current document structure does not separate functional and non-functional specs. We just have ‘function specifications”. So we do end up with more specifics in our docs than you would find in a functional vs. non-functional doc. Previous experience with this particular format leads to open interpretation of the team member(s) responsible for creating the functionality.

    Interesting you bring up personas in the definition of scope. I’m going to have to do some further research on that one. Thanks for bringing it up.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s