Skip to main content

A small hint

In writing requirements, synonyms do not exist.

An example is "tree" and "plant". 

The two words seem similar, but they have different meanings.

Tree:   "a usually tall plant that has a thick, wooden stem and many large branches"

Plant:   "organism belonging to the vegetable kingdom"


Please note also that tree can mean"a drawing that connects things with lines to show how they are related to each other", while plant suggests a "factory and its buildings and equipment".

Comments

Popular posts from this blog

A good book by Jim Arlow

Currently reading Jim Arlow's " Secrets of Analysis: Generative OOA with NLP, Literate Modeling and M++ ". I found it extremely interesting, first because it has a lot of extremely interesting hints and tips and emphasizes the importance of communication Second, it introduces a simple but useful meta-language, called M++, that allows to recover information from deleted, distorted and generalized communications. It is an extension of the work on language patterns by Bandler and Grinder. M++ could gives you a set of simple, powerful communication strategies that you can apply straight away in your job. M++ (and the original Meta Model) specifies how you can use language to clarify language. It deabstracts to uncover distorted, deleted and generalized information.

Suppliers, suppliers, suppliers

Some managers don't find the time to evaluate new suppliers, not even 10 minutes on the phone. Then they complain for weeks  that they are stuck in a project that does not take off in 2 years. Because of the supplier....

Vague requirements

An old school tip on vague requirements. A lot of words and sentences that we write in our requirements documents are often too vague . And these kind of unclear requirements have a big chance to cause problems at the end of your work. Blurred Something like: the system must be scalable , the system must be user friendly , the system must be quick . A good way to at least improve these three requirements could be something like this: 1. The system must be scalable up to 1.000 concurrent users without upgrading our servers, 2. The system must be usable by an average 50 years old accountant that only knows Word and some Excel, 3. The system must have any functinality ready on the screen  in 1" when all concurrent users are using the system. So, by just exploring a bit more with the stakeholders, you can reduce ambiguity a lot. It's not too difficult and you can have a huge improvement in the end product or service.