Archive for November, 2009

Seminar on Agile Methodologies hosted by IBM

Tuesday, November 24th, 2009

Yesterday i attended a seminar on Agile Methodologies. The event was organized by RUG – Rational User Group and hosted by IBM.

The event was quite informative esepcially meeting with leading thinkers of Agile Methodologies and getting to know their ideas.

I would definitely like to mention about one of the speakers; Clarke Ching – Chairman of Agility in Scotland. He is doing really great work as an Agile Consultant. In his presentation, yesterday, he intelligently proved that Agility is not a new idea or technique being used but it emerged as back as in 1700. He proved it using the examples of James Watt (inventor of Steam Engine) and Abe Lincoln (American President).

Clarke Ching has written a book “Rocks into Gold” on Agile. I was honoured when he gifted me his own book. The book is also available to read online.

Also, it was good to know that Agile is currently making progress and being used by many companies throughout the world. Scott Ambler – Chief Mehtodologist/Agile proved Agile progress with statistics.

I would definitely write more blogs on Agility and would share my experiences as well.

Happy Agility!

Difference between Business Requirements and Functional Specifications

Tuesday, November 17th, 2009

I am currently writing templates for Business Requirements and Functional Sprecification documents. And trying to keep a boundary line in between both of them.

I am working mainly on Software products so the below detail is as per my exposure with IT systems.

The way i see Business Requiremenst and Functional Specifications is as:

Business Requirements (inc. Business Use Cases) are a high level list of the requirements gathered during planning stage, tend to propose a solution and meant for Business stakeholders.

Functional Specifications or Solution Requirements are further details of the Business Requirements meant for the understanding of Developers and other Technical stakeholders.

Business Process overview diagramas are part of the Business Requirements and Detailed diagrams like activity diagrams and detailed process flow diagrams are part of the Functional Specifications.

Detailed or well dressed use cases are also part of the Functional Specification though high level Use Cases can be imposed into Business Requirements.

The above is a very high level difference betweeen Business Requirements and Functional Specifications.

What are the characteristics of a good requirement?

Tuesday, November 17th, 2009

Today i was reading an article on charactristics of good requirements and thought to share it with you.

While different organizations and authors may describe a slightly modified list, the following characteristics are generally accepted as those defining a good requirement.

Cohesive: The requirement defines a single aspect of the desired business process or system.

Complete: The individual requirement is not missing necessary or relevant information. Additionally, the entire set of requirements should cover all relevant requirements.

Consistent: The requirement does not contradict another requirement.

Modifiable: Like requirements should be grouped together to allow similar requirements to be modified together in order to maintain consistency.

Correct: The requirement meets the actual business or system need. An incorrect requirement can still be implemented resulting in a business process or system that does not meet the business needs.

Observable: The requirement defines an aspect of the system that can be noticed or observed by a user. This is often referred to as “Implementation Agnostic” as the requirement should not specify aspects of system architecture, physical design or implementation decisions. These aspects of a system should be defined separately as constraints.

Feasible: The requirement can be implemented within the constraints of the project including the agreed upon system architecture or other physical design or implementation decisions.