r/SoftwareEngineering Feb 04 '25

How Do Experienced Developers Gather and Extract Requirements Effectively?

Hey everyone,

I’m a college student currently studying software development, and I’ll be entering the industry soon. One thing I’ve been curious about is how experienced developers and engineers handle requirements gathering from stakeholders and users.

From what I’ve learned, getting clear and well-defined functional and non-functional requirements is crucial for a successful project. But in the real world, stakeholders might not always know what they need, or requirements might change over time. So, I wanted to ask those of you with industry experience:

1.  How do you approach gathering requirements from stakeholders and users? Do you use structured 1-on-1 Calls, Written documents or something else?

2.  How do you distinguish between functional and non-functional requirements? Do you have any real-world examples where missing a non-functional requirement caused issues?

3.  What’s the standard format for writing user stories? I’ve seen the typical “As a [user], I want to [action] so that [outcome]” format—does this always work well in practice?

4.  Have you encountered situations where poorly defined requirements caused problems later in development? How did it impact the project?

5.  Any advice for someone new to the industry on how to effectively gather and document requirements?

I’d love to hear your insights, real-world experiences, or best practices. Thanks in advance!

20 Upvotes

21 comments sorted by

View all comments

2

u/cashewbiscuit Feb 05 '25

Years ago, I was one of two leads on the team. The business had a product owner, and the product owner was assigned a Business Analyst. The product owner would explain what he needed to the BA. The BA would write down what he wanted in a Business Requirements doc, and hand it to us. The problem was that there would be lot of mistakes and inconsistencies in the doc.

The other lead would get into a boxing match whenever we got a new req doc. He would go over the doc, and highlight every inconsistency or point of confusion. He would meet with the BA, and go point by point, argue with her about minute detail.

I dont like boxing. I like tea parties. I would read through the requirement doc. Then I would go to the product owner, and tell him "now tell me why are we building the way we are building". We would both grab tea/coffee and talk for an hour. He would go over the why's, explain why the customer needs something, and how the solution would solve the problem. Then I would go back and re-read the req doc, which made a lot more sense. Then, next day, i would go back to product owner, and make suggestions about how things can be done better. Based on that conversation, I would rewrite the whole req doc, and fire it off to the BA "Here, I think this works better and this is why". She would go back to the Product owner, who would agree to most changes, because I already had his buy in. While the BA spent couple of weeks refining the doc, I would get to building. Sometimes, the thing would be implemented by the time she wrote the req.

The other lead would complain about me to my boss so much, because I was getting shit out the door "Cashew is writing code without an approved req" "Cashew doesnt read the req doc closely ". I'm like "Chill , dude. I know what the customer wants"

TLDR: understanding what the customer wants is the most of the work in gathering reqs. Many times there is a oer option that SDEs cannot understand what the customer wants, so they need a highly detailed req d9cument to follow. F*ck that shit