Why you would need a modeling tool to do the requirements job

People often ask me why you would need a modeling tool to do the requirements job.

They often argue that requirements is mostly text, so using a wordprocessor would do the job. And indeed, when you look at a RUP Vision document, or examine RUP Use Case specifications, 98% of the content is text. Requirements are often written in the form of "The System shall …", and writing those statements certainly has a place when you need formal requirements, but they are difficult to express user requirements effectively.

Sometimes some pictures are added, but pictures can easily be constructed using a drawing tool like Powerpoint or Visio.

The pictures you see in requirements documents indeed most of the time look rather simple, but in my humble opinion simple pictures are the most difficult ones to come to. Often they are a sign that the analyst really understood the domain and found a way to organize the requirements in simple pictures to make them understandable.

Sometimes I see intrigueing pictures made by collegue analist who made it their personal goal to include as much includes and extends in their Use-Case diagrams as they could possibly think of. Personally, I don't like those diagrams, as they are difficult to explain and often obscure the true requirements of the system.to be built.

In Why Do We Model Software Requirements? at Requirements Defined, three reasons for modeling are listed:

• Requirements Models Allow Us to Organize Our Data in Multiple Ways.
• Models Help Us to See Things That Might Be Missing.
• Models Create a Visual Representation of What’s Expected.

Models are not just fancy drawings, they are an effective and powerful tool.

Especially when you create models in collaborative workshops together with your business stakeholders, models are a quick way to articulate requirements, reveal missing and conflicting requirements and pinpoint the real needs of your stakeholders. A nice example of such a model is the context diagram from Ellen Gottesdiener's article.

Another good example is a Use-Case model created in a Use-Case modeling workshop. A good introduction to this technique can be found in chapter 5 of Use Case Modeling book by Kurt Bittner and Ian Spence.

The nice thing about using a modeling tool, is that it allows you to look at the requirements from different viewpoints. You can reorganize and restructure the model created with your stakeholders, adding detail where necessary, while keeping the relation with the original model.

While looking at the requirements from different viewpoints, missing things are easily identified, resulting in better requirements.