Showing posts with label Methodology. Show all posts
Showing posts with label Methodology. Show all posts

Friday, November 16, 2007

Business Requirements: More than a Pretty Face

In the his opinion piece for ComputerWorld, Michael Hugos tries to give us a quick-fix for the complicated world of software development. A couple of good rebuttals of this "CIO at Large" have already appeared on the internet. In particular Bran Selic of the UML task force exposes the lack of Hugos's lack of UML knowledge.
Like Moliere's Monsieur Jourdain, who spoke prose all his life without knowing it, Hugos may be surprised to discover that four of his five diagram types are either valid UML diagrams or can be mapped directly to corresponding UML diagrams, with one important difference: UML diagrams are composed of elements that have a standard semantics associated with them.
"Five Diagrams Beat a Victorian Novel" is a catchy title and we can all relate to a good diagram being easier to absorb than thousands of words. We should encourage meaningful illustratons but there are many parts of our templates that are not amenable to the simple diagram. We need to talk about objectives, risks, non-functional requirements, costs etc. – these are easier to express in words.

Hugos is advocating a warterfall development methodology and not advocating anything new with his 5 diagrams.

The first diagram is a data flow diagram which was developed by Edward Yourdon and then improved by Gane & Sarson in the 1980s. Gane & Sarson added sources and sinks which evolved to be the actors in use-case diagrams and swim-lanes in swim-lane diagrams. The swim-lane diagram is a special case of the UML Activity Diagram. I prefer to see the swim-lane diagrams to the old Yourdon data flow diagram. The old DFDs certainly still have value but I believe the new diagrams are more expressive and better accepted.

The logical data model is good sense and developers have been using these for years. I would hope that any serious business analysis involved a logical data model and that this was based on an enterprise information model.

Hugos writes about a "System Technical Architecture" which is similar to a UML Deployment Diagram. This is not usually the role of the BA and sometimes not even the role of the software developer. The systems architect will often be responsible for what part of the application runs on what hardware and therefore this deployment diagram.

Hugos write about an Object Model which is the equivalent of a UML Class Diagram. It is the role of the programmer or systems analyst to develop these. Again I have no problem with this diagram being included in a solution design.

Storyboarding is a technique that has been around for a while and has been adopted by the XP (extreme programming) agile programming technique. Use cases attempt to portray the same information.

The use of screen mock-ups helps show the user some tangible picture of what the application might look like and is an alternative to prototyping the user interface. There is a good IBM article on this.
There is little question that use cases have a bigger impact on software engineering than storyboards. Use cases are the origin and basis for a well-defined object model that not only manages the functionality and business rules of a system, but also serves more than one HCI [Human Computer Interface]
The Business Analyst(BA) develops requirements for two audiences. It is the BA's call whether to do screen mock-ups or storyboards. If the BA wants to develop these to convey to the user what the solution might look like then this should be commended. However, a BA still needs to develop the use cases for the developers to understand the logic behind the user interface.

I got a difficult email this week. It went something like "I have just found something new. Apparently five diagrams can replace our long business requirement documents. Please investigate and see if we can get rid of RUP". This is what prompted me to prepare this posting. In general I believe diagrams are goodness but we need words to be precise. Hugos would like to regress to a simpler time. UML is a standard and we use well-accepted standards to make our life simpler. We should not be slaves to our methodologies. Develop screen-shots or storyboards or prototypes if they will help the users understand their requirements. We need to remember that the developer will benefit by seeing a use-case in a format that he or she is comfortable with and expresses what happens behind the user interface.

References:

Two responses to the Hugos article:

Letter: UML Shifts Specs to User's Point of View
Bob Jones, October 15, 2007 (Computerworld)
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=304960

Opinion: Five Diagrams Redux
Bran Selic, an IBM distinguished engineer at IBM Canada, is co-chairman of the UML 2 task force in the OMG
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9043002&source=rss_topic73

The IBM article on Storyboarding

Form feeds function: The role of storyboards in requirements elicitation
http://www.ibm.com/developerworks/rational/library/dec05/krebs/index.html