#10- You cannot quickly understand new concepts.

Fear not, this doesn’t mean you are stupid. It just means you think through problems in a way that does not lend itself to good requirements gathering. In the role of a requirements expert, you have to be able to think on your feet, grasping new ideas from the business and immediately be able to converse about them in depth with the team.

#9 – You don’t have patience to deal with customers.

All requirements come from a “customer” of sorts. So even if you are not a consultant or dealing with outside end user customers, you are always dealing with some sort of customer that you must be willing to hear. This means when they do not know what they want, and they change their mind ten times, you need to be able to focus them and come to agreement – not get frustrated and run away.

#8 – You have low attention to detail

If the previous line didn’t jump out at you as an error, then you probably wouldn’t enjoy working with the detailed nuts that did notice it, because they will forever point out such errors in your writing. Attention to detail is important, to ensure the document is easy to read and the low level requirements are not missed.

#7 – You’re not willing to work hard.

By working hard, I really do not mean working long hours, because frankly you cannot concentrate at this type of role for long hours and still be effective. What I do mean is that you need to be able to think intensely about problems, write requirements in great detail, identify gaps and inconsistencies, and facilitate groups of people to consensus – all while juggling lots of balls in the air without letting a single one drop. No one said the job was easy!

#6 – You hate working alone.

Writing requirements inherently means a lot of heads down writing and reviewing, which you will have to do alone. If you cannot stand the quiet time by yourself, you will go crazy trying to do this and unfortunately produce poor results by shortcutting it.

#5 – You hate working with people.

Writing requirements involves gathering requirements first, and this means you have to work with people. So, while you do have to tolerate working alone to write the requirements, you have to also enjoy working with people to discover the requirements.

#4 – You cannot form a mental model of all the pieces.

You can use models to help identify the requirements. You can use models to help cleanly articulate the requirements to others. But at the end of the day you also have to be able to keep a clear model of the requirements in your mind. Without this mental model, you will not be able to look at the requirements as a set, to identify missing and inconsistent requirements.

#3 – You are unwilling to bend the rules.

Don’t worry, I don’t mean breaking ethical boundaries here, but rather the rules around writing requirements. Not everything fits in a perfect world where we can define boundaries and never cross them. Sometimes we need to cross into design when writing requirements. Sometimes we need to let IT help suggest requirements to the business. I like to suggest guidelines for writing requirements, but then use them only as guidelines and apply good judgment to each project.

#2 – You only see grammar and spelling errors when you review requirements documents.

When you review requirements, if all you find are grammatical and spelling errors, then either you are working with a fabulous and unheard of requirements expert, or you are missing the important issues. A true requirements expert needs to be able to find inconsistencies and holes in the requirements. These issues are arguably where most missing requirements lie, leading to failed development projects.

And the number one sign you should not pursue a career writing requirements…

#1 – You don’t like to write.

This is pretty obvious, but you have to enjoy writing. Writing requirements does in fact require you sit down at a computer and churn out good requirements. In theory you could verbally dictate them and have someone write for you, but that will not sufficient within most organizations.

Oh and in the spirit of scope increase, which so frequently plagues the software industry, the final sign…

#0 – You think that all software projects should be developed using agile methods.

In this methodology, you will not get to write many requirements. I’m by no means an expert in agile, but there is clearly less upfront product definition, and therefore less requirements work. In the end, agile developers attempt to get to the requirements their own way, but it is not by writing requirements documentation before developing.