Ahoy MoT Club!
My latest YouTube short is out today: Avoid the word “Should” in your requirements
I previously tweeted about it, and thought it would make for a good video.
What do you think?
5 Likes
It should, it could but it does not mean it would
1 Like
Interesting. I perceive this Should more as order or a wish. A nice intended phrasing.
“Please make the software does X.”
“I intend that the software does X.”
I agree on dropping Should.
Just describe how the software should (
) work, but do not use ‘should’. Such text is often the literary variante of an UML diagram.
I do not care for a nice phrased text. Its a technical description, not a conversation.
I care if the writer is nice to me in person/conversations. But not in requirements.
2 Likes
Reminded me of this rap masterpiece:
Please don’t mind me I’m hopelessly childish 
2 Likes
“Should” also makes requirements unnecessarily wordy and long.
Instead of “It should do” just write “It does”. Carries the same amount of information with less charters.
5 Likes
What common challenges have been received when trying to remove ‘should’ from requirements?
Or are teams generally on board when this has been explained.
1 Like
Completely agree @ThePirateTester … I have advocated this for years. Glad to hear other feel the same. 
3 Likes
I’ve found that when I challenge “should”, and if what they are asking for is optional as well as what happens if it doesn’t happen, they realise the issue with their wording, and become more strict in their wording.
Exactly!
“It will”, “it must”, words like that where you can then give error handling or an alternate path if those things don’t happen, make it much clearer.