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?

  • ...we tend to make mistakes. 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. Or we will be asked to implement a feature, but not realize the implications across the application in other areas. These mistakes are your (dev team) fault. I would expect you to know the codebase and know how a change in one area affects another area. Why would your boss know this?
    – user69461
    Commented Mar 21, 2018 at 18:48
  • @tima Sorry, this is not specifically a code change only. These happen of course and are a mistake, but not the real cause of frustration. Specifically, these would be things like business practices or workflow. A quick example might be "We have one report called X that shows this column, please change it to show (something different)". However there is actually X, Y, and Z reports (all unique) but have that same column presented in different ways. We might only change the one mentioned in the request and not look at the others. Commented Mar 21, 2018 at 19:25
  • @tima One additional thought - the flow changes are also outside specialty. I'll pick an example (randomly) but our software deals with "Medical" supplies, and as a developer I do not understand how certain supplies might be used, handled, etc. Commented Mar 21, 2018 at 19:26
  • so what happens if in your example you only changed the column in the X report and didn't change it in the other reports? Who decides that this is a mistake? And is the given requirement ignored?
    – user69461
    Commented Mar 21, 2018 at 19:31
  • 3
    This is the single most common question on this site. "Surprisingly, software development is a shambles." It has been discussed so often there's nothing more to say.
    – Fattie
    Commented Mar 21, 2018 at 23:20

5 Answers 5


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.

  • 2
    Yes, by being obstinately vague about tasks, the OP's boss is effectively telling him that he wants the OP to "own" the analysis as well. Some bosses will simply leave it up to their reports to figure out that's what they want.
    – teego1967
    Commented Mar 21, 2018 at 17:41
  • After reading some other comments, this question is less about the programming and technical side, more about the business requirements needing clarification. As I doubt we will hire anyone else, I expect we will have to try to figure out how to get business requirements instead of technical requirements. At least that way we can fulfill the requirement given rather then guessing. Commented Mar 21, 2018 at 19:36
  • Agreed OP. @Sh4d0wsPlyr. I was a BA for 3 Devs so I know how much work it requires. Good luck. Pick your best answer and accept it, so other people won't need to comment
    – Isaiah3015
    Commented Mar 21, 2018 at 20:12
  • @Sh4d0wsPlyr. I'd add to this by saying you can't get proper requirements if you don't know who all the stakeholders are. Seems like all OP gets in doc form is a generic change request; I see no mention of a problem statement or list of impacted people/processes/teams that would give the information you need to actually gather accurate requirements. Commented Mar 23, 2018 at 13:53
  • @DianaTortolini Our business is rather secretive, most of the time (unless I work with the clients directly) I do not know who we are working for. I'd love to see a generic change request form be introduced (impact, problem statement, etc). Maybe I'll bring this up during our next meeting, thanks for the advice. Commented Mar 23, 2018 at 16:37

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!

  • 1
    Love the quote - and I expect something similar to this is where I will end up going. The issue is that I might not understand the business or requirements I am programming for until after. An example is when the requirement is given I clarify and do it properly, however may not realize other sections of the software are also going to need to be impacted (think side effects that are business specific, but I do not know the business rules, only my boss knows them). Commented Mar 21, 2018 at 19:31
  • As a team, own the code. If the boss wants bugs fixed, it's up to you to work out how to fix them, what reversion testing is required, how to configure the code, and so on.
    – Simon B
    Commented Mar 21, 2018 at 22:08

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.

  • I would say our process is generally governed in this order; Owner/Manager meet and discuss proposed changes, estimate the expected time to be delivered, write up a "requirement" document (typically single bullet requirements), development is expected to begin immediately (since we only receive these when they want it to start). Not surprisingly scope creep is also another issue we have had. Commented Mar 21, 2018 at 19:39

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.

  • To answer your questions: We do use version control. The specific point I mentioned was an issue with business requirements being different in different products we maintain. Specifically we fixed bugs in one, then ported them over to our other project (which shares about 60% common code). However the other 40% of code required some additional unknown changes as well (that were based on business rules we were unaware of, or in what we thought were unaffected sections of the code base). We have bugzilla, but due to tight deadlines we have dropped it for a more informal bug list (devs only). Commented Mar 21, 2018 at 19:44

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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .