In general most online resources point out that the functional requirements are the responsibility of the business analyst or product manager. But developers sometimes can be the expert on a product e.g. because they have been working on it for years. Should they, in that case, be included in the functional requirements gathering process? If not, why not?

  • Hi Heinrich Heine, welcome. Can you link to some of the resources who say that? Commented Feb 19, 2021 at 9:23
  • 5
    I think the key misunderstanding here is that "responsibility" isn't supposed to mean "they come up with them all on their own". If you're responsible for making sure the requirements are going to result in a successful product, then you're responsible for making sure that it's something that people actually want to buy (ask your business analyst), and feasible to produce (ask your developers), among other things (ask your other experts).
    – M-Pixel
    Commented Feb 20, 2021 at 7:35
  • 1
    I agree with Pixel. Treat the developers as "subject-matter experts (SMEs)" in your planning processes. Commented Feb 23, 2021 at 19:08

10 Answers 10


I fail to see how you can carry out requirements engineering activities effectively without the involvement of developers.

A business analyst or product manager may be very good at working with stakeholders to understand their needs and how to close the gap between the current state of the product and the stakeholder need. However, requirements also need to be analyzed for feasibility and testability, and the technical people on the project are the best to make those assessments. The architecture of the system has an impact on the effort required to implement a requirement or set of requirements, so input from the development staff is also important to consider when applying order to the list of requirements.

I'm not sure that the technical staff needs to be involved in gathering the requirements, but they should be involved in the process at various points. Earlier involvement to bring to light issues with implementing, testing, and deploying or operating the functionality represented by the requirement will improve the overall quality of the system under design.

  • 7
    Ever relevant xkcd as to why you might want your developers involved in drafting requirements. xkcd.com/1425 Commented Feb 19, 2021 at 20:21
  • @Shufflepants - that one's good, and if you wanted to include relevant Dilbert comics you'd need about 1000 comments to hold them ...
    – davidbak
    Commented Feb 20, 2021 at 18:58
  • I agree with Thomas even though, in the past 7 years, I have not worked in a project where this was done, every project engineer/owner have sent the requirements to the development team to be executed with a schedule attached that does not reflect the real complexity of the job. which makes the developer to work overtime and sometimes cut corners, which reduces quality, to be able to deliver on time.
    – Raxl
    Commented Feb 23, 2021 at 13:35

Everyone in a development team should take responsibility for and be involved in requirements gathering to some extent, otherwise you have barriers to effective teamwork.

"The best architectures, requirements, and designs emerge from self-organizing teams" (agilemanifesto.org) Development teams follow that dictum by not limiting people to specific roles and by recognising that anyone can have something to contribute at any time.


Developer here. I have seen projects fail because a functional requirement was impossible to implement. I'll tell you a tale where I was involved.

We were working with a piece of hardware that allowed you to capture TV signal. It came with its own software that allowed you to tune in to channels and watch TV in your computer. This was before digital TV was widespread, so usually you also had to do some fine tuning on each channel to get good visual. Often some channels were impossible to tune to perfectly.

We were working for a pay TV company that had many channels. They wanted to display content from all their channels in 1/4 of the screen on one special channel, which would rotate the content being displayed every few seconds. The idea was to use the TV capture card on a computer to catch signals from all channels, then stream it to a component in our software.

Our analyst collected the functional requirement that the user should be able to preadjust the fine tuning of every channel. He did it without consulting with the devs. If he had consulted us, we would have told him that it wasn't feasible. The API for the TV capture card did not allow for fine tuning - the software that came with the card used its own driver and a separate API that were not integrable with any technology we were using. We would have to write our own driver and API's for the card to satisfy that requirement. We had neither the expertise nor the budget to do that.

We couldn't demo without the fine tuning because image quality for many channels sucked. We were about to lose a huge contract. The client was furious, but still they invited us to their place so that we could do some research and look for alternatives. The client had radio decoders for TV's that it sold, but they also had cable service with mostly the same channels. We found out that by plugging to a cable decoder no fine tuning was needed, we just needed a couple lines of code to switch from antenna to cable in our solution.

In the end we dev's saved everybody in the company's behinds, because that project was the one cash cow for the company for a long time.

  • Hi Geeky Guy, welcome and thank you for your contribution! (+1) Commented Feb 19, 2021 at 16:40
  • 6
    This is a pattern I've seen (business + marketing decide on a product and schedule, then announce it to developers), and it never ends well. The more insidious version, however, is when a developer is asked about viability, but it's mid- or entry-level developer who is inclined to "yes-man" and think about bare feasibility, rather than a senior developer/architect/TD who can perceive whether something is feasible within the given budget and at a level of quality that is acceptable.
    – M-Pixel
    Commented Feb 20, 2021 at 7:49

Anyone can have a say in the product requirements. Even the analyst's mistress may offer some input. That said, it is analysts' job to analyze, combine, synthesize, and prioritize both requirements and requirements sources.

Consider the following:

  • Customers (rarely but still) can explain what their difficulties are
  • Engineers can help to understand technical constraints
  • Project owners can set budget/time constraints
  • Regulators provide compliance requirements
  • Market trends show where the market may be going
  • Prospects (potential customers) can give you ideas to expand the offering
  • Experienced users can help you to refine the solution
  • Domain experts can help with understanding the problems software is about to solve and refine potential solutions
  • Social media posts can help you to gauge customers sentiment
  • Product telemetry tells you how the product is being used in the field
  • and so on...

How much each input matters depends on the project/domain/feature. You probably do not want to listen to all sources equally as it would be too much noise. Or, consider input outside one's area of competence. e.g. project owners offering their strong opinions on GUI design.


You should treat the developers as Subject-Matter Experts (SMEs) with regard to how the existing system works and therefore how the requested functionality can be implemented – or, indeed, if it can.

A purely-abstract "functional requirement" simply says that "the software needs to be able to 'do' this." But, as Perl programmers love to say, "TMTOWTDI = There's More Than One Way To Do It.™" Which is the best way? That's what your developers will know the very best.


Softwaree developers know better than anyone else what can be implemented, and at what cost. And software developers are usually quite clever.

You can create functional requirements all you want, but if you don't involve the developers early they might tell you that your functional requirements cannot be reasonably produced, either not at all, or only by a much bigger team with some people that are significantly more clever than anyone you have. Or they might tell you that very similar but not quite identical functional requirements could be implemented at half the cost. Or they might tell you that your requirements are contradictory - if you state on page 3 line 7 that button A does X, and on page 9 line 21 you state that the same button A does Y, developers will spot them. They will spot requirements that are useless which you didn't see, and so on.

So if you ignore your developers, you can lose out big time.

  • 3
    As a lifelong software developer, I think the statement "Software developers know better than anyone else what can be implemented, and at what cost" is an untrue generalization. Most developers consistently under-estimate how long things will take and how difficult they will be. Most business and marketing roles severely under-estimate these. A shocking few (highly experienced) producers, managers, and developers are able to project viability and cost within a 30% or less margin of error.
    – M-Pixel
    Commented Feb 21, 2021 at 17:09

Very clearly they should.

Until they do, we will will be stuck with the current process, which boils down to:

Project Manager: "Does what we have meet the design spec?"

Techies: "Pretty much, but we've noticed this, that and the other…"

PM: "Never you mind what you've discovered… Does what we have meet the design spec… Yes or no?"


Within a Scrum team, coming up with the requirements is usually part of the Product Owner's job - he or she represents the customer and its needs, desires, problems - and how "we as a team" shall address them and deliver a product (and within Scrum, we usually focus on the Sprint and its deliverables / the Increment) for meeting them.

Therefore I as a Product Owner (who is using the CYSU remote Scrum application with integrated requirements-engineering & CFLX-enhanced discussion-threads, btw) start with a "Sprint Vision Board" (analog to a "Product Vision Board") in which I make exact these filling for every single Sprint for bringing in more context for a better understanding about the real requirements, about the "why"... ... and I do add the "HOW" and with which "Acceptance Criteria" / requirements additionally to the User-Story to the PBIs (using modifiable dropdown-elements for gaining productivity and stick with the wording, btw...) And of course: This is a process which is performed within a participative approach! ... good discussion is the key. ... or even: context-enriched discussion for a better understanding / for better guesses about the meaning / more hits related to the interpretation is the way for better collaboration and better results, motivation, understanding of the big-picture...

below two screenshots (1x the vision-board; 1x using the requirement template ... just realized it's an older screenshot, today the two templates are for declarative and procedural requirements. functional/nonfunctional makes no sense from a writing perspective..)

here's the link to the CYSU for doing remote Scrum, btw: https://sourceforge.net/projects/cybr/ (running on docker / docker-compose, just follow the steps in the readme..) sprint goal vision board for more context requirements template dropdown elements

the link to the CYBR-SUITE (CYSU) remote Scrum App at Sourceforge: https://sourceforge.net/projects/cybr/

You can ask me for help if you need to (I do have additional documentation, presentations, videos...) DISCLAIMER: it's my own project...


I am going to take a bit of a different view than the other two answers. Role boundaries are a thing for a very good reason. People departing from their role and assuming tasks in another, while maybe good intentioned, can cause a lot of issues. In the workplace, folks jump out of their swim lane all the time and, while at times it may have been helpful, I suspect it causes more problems than not.

That's not to say that developers do not have in-scope tasks in the development of functional requirements. I think they do in a lot of cases; however, there are tasks in that development that the BA and PO own that the developer should not engage and vice versa.

I know my answer won't be popular with those in SW and who prefer an Agile approach, but can you imagine an electrician helping to draw the architecture documents? There is a tiny overlap perhaps but the roles are quite defined and adhered to...and there are very good, obvious reasons for that.

  • 7
    I can very much see an electrician give input into the architecture, in terms of "I frequently get requests to place additional outlets in that area. Can we take that along right from the beginning?" There can always be requirements that often come up in a later stage and that somehow bypass the BA/PM but which are known to the developers. Commented Feb 19, 2021 at 11:43
  • 3
    @DavidEspina You might get more upvotes if you explain why you think it ‘can cause a lot of issues’, what sort of problems are caused, and what tasks developers should not engage in. Examples and evidence are always helpful.
    – gidds
    Commented Feb 19, 2021 at 19:08
  • 4
    The downvotes aren't because this answer is wrong, but because it doesn't answer the question. The question isn't about developers taking on the role of a BA/PO, but involving developers in the process. The last paragraph detracts from the answer. I can imagine an electrician being involved in architecture drawings. I worked in manufacturing and engineers who were responsible for the drawings worked with the folks from the manufacturing floor to make sure the drawings were more easily buildable. Building quality in almost always requires a breadth of skills from across the product life cycle.
    – Thomas Owens
    Commented Feb 20, 2021 at 17:33
  • 4
    I had a mate working in a chemistry lab, and they hired an architect to design a new chemistry lab. The architect knew it all, didn't listen to anybody. When he presented his drawings, some senior lab technician took a big pen, walked to his paper drawings, said "this here is illegal" and drew a big fat line through one big part of the plans, "this here is also illegal" and a second part was gone, then some more parts. I think one problem was that lab technicians must be able to leave the lab very quickly if they have to. Faster than through an emergency exit.
    – gnasher729
    Commented Feb 20, 2021 at 21:04
  • 3
    Imagine the building is done, and then the electrician comes and says "and how am I supposed to connect anything to the power lines in this building?" Much cheaper to fix before building work starts, sometimes during the drawing of plans.
    – gnasher729
    Commented Feb 20, 2021 at 21:08

It is not the role of a developer to have a say in the defining of functionality in a project. The design of the project is based on the end user and any other stakeholders based on business requirements not on any specific technical issue. Developers sometimes just don't understand the difference between not knowing about a task and how to think about how to accomplish a task, sometimes the answer isn't black and white but gray. You don't accomplish anything by not not pushing yourself into finding solutions instead of complaining it can't be done. The object of the project solution is to get the job done regardless if you use Agile or any other process, I believe Agile is just an excuse to either be late or to deliver an unfinished project on time.

  • 3
    So if the stakeholders design a project based on the business requirement that, say, a system be capable of fluent translation with quality beyond what modern machine translation can provide, the developers should do what exactly? Saying the developers should try harder doesn't really help. If the developers have no say, you have no insight into the scope of the functionality you're designing, so how can you know whether you're asking for something that takes a day or a world-class research lab and a couple of years and we'll see what happens? Commented Feb 19, 2021 at 23:10
  • 3
    The customer demands a program that can divide by zero...
    – barbecue
    Commented Feb 20, 2021 at 6:33
  • Or seven perpendicular lines ...
    – meriton
    Commented Feb 21, 2021 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.