should developers have a say in functional requirements

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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?"

Answer 8

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..)

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...

Answer 9

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.

Answer 10

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.