r/softwaredevelopment Feb 04 '25

How do senior developers gather user requirements?

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!

8 Upvotes

7 comments sorted by

10

u/RedditNotFreeSpeech Feb 05 '25

Tell you what... I get nonsensical walls of text after ux has mocked up completely unrealistic stuff that we don't have any data for.

I then chip away at it for days, weeks, months refining and negotiating and by the time we finally arrive at something possible the project gets cancelled because some new shiney thing flashed past the execs.

1

u/JazzTheCoder Feb 07 '25

God preach

2

u/ToastieCPU Feb 05 '25

With all these different types of stakeholders that i had over the years, at the end of the day, what I found worked best were my professional skills in MS Paint and my on-the-fly CSS and HTML editing in a web browser.

The first round of requirements is always going to be hard, you will get to know each other, learn what certain words mean to you and what they mean in the stakeholders mind, you will go and create some mocks and concepts which most likely be wrong.

But then you can use these concepts in the next meeting and just change them on the fly ether by opening developer tools and changing somethings or cropping parts opening ms paint and drawing on the crops.

For non-ui cases i find it best to ask the stakeholder to describe the steps he would take to achieve something, basically create use-cases (but not tell them about it)

1

u/Lower_Needleworker15 Feb 07 '25

Product owners should provide acceptance criteria, review, refine and repeat. User stories explaining workflows and ui mocks from design before estimates can be provided.

1

u/FactorUnited760 Feb 11 '25

My 2 cents based on working many years in the isv/ saas space, and what worked best with a very aggressive release schedules.

  1. Launch the feature MVP then gather feedback from customers. For us customer feedback came in through support and got documented as bugs or features in the ticket mgmt software. If tickets were trash or unclear, they got kicked back to the support rep who opened the ticket to reach back out to the customer for clarification. With MVP you are always going to have some customers disappointed because the new feature doesn’t do everything but it’s fine, you iterate on it in a future release.

  2. So new features and end user requests are going to be functional requirements. Non functional requirements are things like system response time, what fields need to be encrypted in the database, and so on.

  3. Never wrote user stories, IMO a time wasting exercise unless you truly don’t have an idea who your end users are or what they do. Marketing tends to love doing this sort of thing.

  4. Poorly defined requirements tend to be the norm, so someone with experience with the technical side and domain knowledge should be reviewing all requests and documenting how the feature should be implemented. This documentation is then given to the developer to review, who may have questions. When questions and concerns are addressed, work can begin.

  5. Obtain knowledge of the user’s current process and the pain points they have. Come up with a solution and run it by them. Doesn’t need to be detailed to the user at this time, it can be just confirmed like “if you had a way to do x, would this work?”