Comments on: Documenting Scope: Concept vs. Solution http://websiteproducts.wordpress.com/2008/11/08/documenting-scope-concept-vs-solution/ Managing features and functionality accessible via the Internet. Sat, 31 Oct 2009 00:23:16 +0000 http://wordpress.com/ hourly 1 By: Brooks G. http://websiteproducts.wordpress.com/2008/11/08/documenting-scope-concept-vs-solution/#comment-16 Brooks G. Thu, 13 Nov 2008 19:51:34 +0000 http://websiteproducts.wordpress.com/?p=45#comment-16 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. 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.

]]> By: David Locke http://websiteproducts.wordpress.com/2008/11/08/documenting-scope-concept-vs-solution/#comment-15 David Locke Thu, 13 Nov 2008 19:17:46 +0000 http://websiteproducts.wordpress.com/?p=45#comment-15 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. 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.

]]>