The Community Blog for Business Analysts

Seven Words You Can Never Use in a Requirements Specification

This is the text of a presentation my boss had attended at a Telelogic conference and which, she later shared with the BA team at work. It lists specific words that when used in requirements, compromise the quality of the very requirements. I'll let the article describe further. Looking forward to some feedback...Les, thanks for your wisdom.

SEVEN WORDS YOU CAN NEVER USE IN A REQUIREMENTS SPECIFICATION
Les Grove
Tektronix, Inc.

Prepared for the 2006 Telelogic Americas User Group Conference

A requirement specification is the one place where all of the stakeholders involved with a project have a vested interest. Unfortunately, requirements are often not written clearly for the people who depend on them. This [article] will help people to use precise language in writing their requirements, detect problems when reviewing requirements, and avoid misunderstandings when using requirements.
The seven bad words referenced in the title were selected from real Tektronix specifications in various forms of readiness (draft, pre-review, post-review, released). Each word is representative of a particular type of word.

The Seven Bad Words

#7 Always
The problem with this word is that it implies certainty, but can never be verified. How does one verify that “Values shall always be available”? Similar words include all, every, and never.

#6 Some
This term is just plain vague and can thus be interpreted a number of ways. When a requirement states that “There will be some restrictions on changes a user can make,” this leaves it up to the designer to either spend time talking with the author or guessing at what the restrictions should be. Similarly vague words include most, sometimes, and usually.

#5 Appropriate
This is a vague adjective that indicates that the requirement has not been thoroughly considered. An author may think that anyone would understand “Put up an appropriate message when there are no more available slots,” but this type of use could indicate something more problematic. What is the real requirement here? There needs to be an indication that there are no available slots, but the author dabbled into design by stating that the solution is some sort of message—and just didn’t want to specify the message. So, in this example, a more basic problem is uncovered by catching the vague adjective. Other adjectives to watch out for include easy, user-friendly, fast, and graceful.

#4 Handle
Vague verbs such as this do not describe what the system will actually do. It is a sign that the author has thrown up their hands in frustration because the system should do something in a given situation, but can’t decide what. When a requirement states that “The application must handle suppressed data,” the designer has nothing to base any design decisions on. Similar words include improve, provide, reject, and support.

#3 Etc.
Words like this indicate two problems. First, there is an incomplete requirement that leaves the designer to complete the list. “The user shall be notified of loss of signal, loss of clock, etc.” indicates that there are other states and conditions that the user should be notified about, but are not specified. The second problem with statements like this is that there are usually multiple requirements in the single statement that need to be separated out. Similar words are another, other, including, not limited to, and such as.

#2 It
Pronouns in requirement statements can be very clear to the author, but misleading to the readers. The statement “Touch screen operations provide audio feedback. User can turn it on or off’” does not indicate whether it refers to the touch screen or the audio feedback. Also, it indicates that there are two requirements: audio feedback and some sort of switching capability. Simply separating the two sentences in this example does not solve any problems either because the second sentence totally loses its context due to the pronoun. The word this is another pronoun to avoid.

#1 Should
At Tektronix, this word is the worst offender, as it is used more frequently than any of the other words in this list. This opinion goes against some other requirements books and the practices of some very large companies (particularly defense and finance), but Tektronix relies on DOORS attributes to indicate requirement priority. Because it implies uncertainty, testers cannot be sure there is an error if the negative occurs. When a requirement states that “The default should be auto-detection,” is it an error during testing if the default is something else? Other uncertain words are and/or, can, could, if possible, and may.

This entry was published on Oct 16, 2008 / . Posted in . Bookmark the Permalink or E-mail it to a friend.
Like this article:
  0 members liked this article

Related Articles

COMMENTS

Wade Courtney posted on Monday, January 5, 2009 3:15 PM
Interesting article, but it would have been nice to show alternative verbiage along with the "what not to do" stuff.
savy davis posted on Thursday, January 8, 2009 3:40 AM
good one...'Should' is encountered in most of the software documentation...

Leslie posted on Friday, January 9, 2009 6:19 PM
Should - This is often used to indicate an optional requirement. But you are correct, it cannot be tested.

Others:
Not - Always try to write requirements in a positive sense, it is normally impossible to test every negative instance of a requirement. (For example, the system shall not be 'red' in color. Instead state what colors are allowed and let the designers choose.)
Any adjective - Words cannot be given an exact definition should be avoided. If the has been defined to mean something other than its English definition (and everyone knows this) then it's fine.

Les (A different one).
Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
15 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Copyright 2006-2019 by Modern Analyst Media LLC