Pragmatic programming thoughts

I was discussing an interesting concept with my friend today. When it comes to the implementation of software , we discuss principles like cohesion , coupling and so on.  My friend interestingly extrapolated the concept to the other departments of the software development life cycle.

An example could be the principle of reuse. We have stated it so many times when we talk about good design.  What if we could apply to preparing requirement document? The result pretty much intrigued me. It has not convinced me yet!

The result was keeping functionality description separate from UI specification and not tie one to the other. This could mean for the same requirements ,multiple UI’s could be developed.  This could also mean that when the software architect is designing the software , his thoughts are less influenced by the flow/process (generally the UI) of the application.

Another interesting thing could be that this might lead to the creation of patterns for certain requirements. Let’s say you are writing an requirement of uploading media to multiple sites. The solution that ultimately ends up as a requirement can be reused as a module in another application.

However there are some ‘practical’ drawbacks with this method. Having 2 documents to refer to is not a happy scenario to have.  I guess it is also quite difficult for the requirement definition team to envisage functionality and UI separately.  Most of them think visually.

Well I am not sure how well will this work.  But it is a idea worth giving some thought.