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".
Labels:

Comments

Post a Comment

Popular posts from this blog

Practical advices by Karl Wiegers

I am reading the beautiful book "More About Software Requirements: Thorny Issues and Practical Advice" by Karl E. Wiegers. I'd like to share with you two of the most important points of his "10 cosmic truth",  that to me are #6 and #9. #6 The requirements might be vague, but the product will be specific. I would say this is the usual point of "Natura abhorret a vacuo", that is here... each gap n requirements will be filled by some bad feature. #9 The customer is not always right, but the customer always has a point. Never underrate your key users
Post a Comment
More »

2. The four causes

Aristotle's was often thinking which were the four causes of... anything: the material, formal, efficient, and final cause. To my own risk, I'll try to apply these causes, to the very limited scope of software requirements. Final cause:   to build a software that works well and is efficiently used by customers. Efficient cause: it's us, we want build software for our customers. Material cause:  the pieces of paper we write requirements on. Formal cause: well. I still have to think about this one. Aristotle used the word aition, "cause". He meant an explanation that accounts for something: "x is the aition of y" means "x explains y".
Post a Comment
More »

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.
Post a Comment
More »