What to do about manager who does not want to give detailed requirements?

Question

I work as a developer in a small to mid size company in North America. I happen to work directly under the owner of the company with my small team so we have the most visibility in the company in terms of tasks and workload.

Recently we (the developers) have had an issue where because we do not have detailed requirements, we are prone to make mistakes. For clarity, the "requirements" are typically a single line item in a document written as a technical requirement. Good examples of this are similar to "Port all bug fixes from previous version to new version", "Create a feature that does something", "Add new table for this".

The issue, is that due to the lack of requirements we tend to make mistakes. We will be told to finish a change in a specific area, but not realize an entirely different section of code requires changes because of an unknown business rule. Or we will be asked to implement a feature, but not realize the implications across the application in other areas. Our boss has decided that writing detailed requirements is similar to spoon feeding an infant, and as such does not do it.

The only solutions I see are not great:

• Take additional time to do analysis on the changes. This will likely cause us to go over development deadlines (thus making me look worse then if I had just missed a requirement).
• Start demanding more detailed requirements, or asking a lot of follow up/clarification questions (already attempting this, typically met with resistance and off-hand comments like "this should be obvious").
• Find a new job.

How can I either manage a situation like this, or find a way to get better requirements in place to prevent this in the future?

Answer 1

Business Analyst here. Your requirements are written as a Business Requirement. I would assume you guys don't have a documentation that translates the Business to Technical. Which is mandatory to avoid all confusion on what components should be updated.

Discuss this with your management that you guys need to either

1. Hire a proper BA that can gather business requirements > translates those requirements to technical component changes. Create test cases/scenarios and implementation before this goes to live.

2. Don't hire a BA, and do #1 yourselves.

Answer 2

As developer, you ought to be the expert on requirements. When something is unclear you should request further information. Be specific on what you are missing and why. When you are uncertain of what technical prerequisites some changes require, you should do an analysis. Get active and mange these things.

Treat your boss as you would an external client. Be polite but don´t start without knowing what to do - and don´t make promises on deadlines before you know what to do.

This could cause some protest at first, but if you stay firm people will learn that your estimations and appraisals tend to work an will begin to trust your judgment. (If not, get another job)

There is a saying:

Weeks of programming can save you hours of planning.

Don´t waste your bosses money!

Answer 3

In a previous gig I earned the nickname Dev Nazi based on the Seinfeld character Soup Nazi, because I would not estimate requests without detailed requirements.

No requirements? NO DEV FOR YOU!!

I was asked about this so much I actually wrote a couple of highly entertaining articles on it..

Requirements Document Template for a Reporting Project

Requirements Document Template for an ETL Project

Some blurbs from these articles that immediately answer your question..

• Any confusion in requirements is going to be defined differently by different people, resulting in time and effort, and goodwill if that confusion is between you and the client.

• "But wait, we're a really small operation, and this isn't a big deal" you say? Fine, as long as you can roll with that, but the moment somebody has an requirement expectation that wasn't delivered that can change, forcing you to function as the gatekeeper of requirements in a more formal way.

• And yes, just because person x told person y a month ago that it’s in requirements, or this email two months ago said it’s in, or was mentioned on the golf course last year during preliminary negotiations means that it’s in. I've also known more than a couple of clients that will negotiate effort, cost, and time, and then scope creep the hell out of a project in order to make themselves look better. Been there, dealt with that.

Good luck.

As an aside...

• Take additional time to do analysis on the changes. This will likely cause us to go over development deadlines

Who and how are these one-liner requirements estimated? Sounds unrealistic, as the smaller the requirements generally means a really wide estimate (say 8-24 hours), and a developer cannot narrow that estimate without more detailed requirements.

Answer 4

The owner of the company is ultimately responsible for direction and strategy. It's no surprise that he wants to make directive statements ("add a feature" "fix all the bugs") and not define specific requirements. You probably won't get anything better from him.

As you're identifying, that leaves a gap in terms of "detailed requirements" for you to work from. Before we can solve that gap, we need to answer a different question: Who is your ultimate consumer? I'm assuming the owner is not the one sitting at a desk using your software all day. If your software is used internally, do you have a relationship with the people who own and carry out the processes your software supports? If your software is sold commercially and you don't work with the actual users, do you at have a sales or support team internally who do?

It sounds like you don't have an "official" software development process that identifies the people who can help you flesh out your requirements, and if you don't, it may be a challenge to try to implement one. But at the very least, you can start by developing an informal relationship with whomever you can identify that may be able to help you add some details. Even if you, or someone on your team, is ultimately writing down the information and doing the actual work, having someone (other than your owner) provide input sounds like the answer to your problem.

On a different note:

I may be misinterpreting, but some of your statements sound more like gaps in the rigor of your development process than a lack of requirements:

"Port all bug fixes from previous version to new version"

We will see a place something was implemented and do the same thing, but not realize an entirely different section of code needs the same change

Do you have any sort of versoning tool or code repository that can help you track bugs and versions?

Also, to address this:

Take additional time to do analysis on the changes. This will likely cause us to go over development deadlines

I can assure you, taking the time to get requirements upfront is going to ultimately make the process quicker. Sometimes there's the pain of delays/issues that come along with any process change, but once you get past that, things will likely be faster in the future, even if you're talking the "additional" time to do it right.

Answer 5

Something that hasn't been said but you need to learn some business knowledge. I am not saying become an area expert but enough to be able to go to your boss with sensible questions

Hey boss this change will it effect this other area as well?

I bet your boss will respond to this more kindly than really open questions, and even if the answer is no they might expand on why it doesn't and possibly think of other places it will effect.

How to get the knowledge? is there somebody else in the company who could run an internal course?

In comments you said the only person who has any business knowledge in the company is the owner. I would word your request along the lines of

"boss our team has made mistakes recently because we do not understand the business area in enough detail. Is there any resource we can use to increase our understanding?"

You also said you were a junior developer, as though you were expecting fully detailed specs to land on your desk. This is not how small companies work in my experience. Small companies expect you all to be self motivated enquiring engineers.