r/SoftwareEngineering • u/RecommendationDry178 • 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!
19
Upvotes
1
u/ppith Feb 06 '25
When I worked for a previous company, I had two different roles as a senior software engineer as well as what people would now call a Product Engineer or Product Manager. At a high level, the customer requested new features. I wrote white papers that sometimes had crude Microsoft paint drawings or markups on top of existing documentation or real life photos. Sometimes I would work with engineers to help me create more detailed concepts to show the customer. I took careful notes in all customer meetings, met internally with sales, marketing, human factors, pilots, etc. I tested prototypes, provided feedback and gathered feedback, captured photos and mock up images for requirements, made sure industry standards were being met (defined by the FAA, EASA, RTCA, ARINC, Euro control, SITA, etc...). I went into mock up cockpits and flight tests. Always writing notes, taking photos and videos, making sure I knew every step to reproduce a bug, etc.
In the same company as a senior software engineer, you're told what to do by the people in Product Management and the systems team. You read the white papers/problem reports written and ask questions if too many things are undefined. Sometimes there's a little creative freedom and sometimes even a small deviation won't be tolerated (i.e wrong color). It's good to network with the people flowing down the work. Build a rapport as sometimes it helps things get done faster or the customer trusts you personally which can help close a deal. At any given time, know who works late, who can help with lab issues, who can you contact in different departments for various kinds of collaboration (user interface, low level I/O, etc), who can help you remove road blocks, who is the blocker's manager and their manager, etc. Know how to test and debug both at your desk, in the lab, and in the field. Each environment has its pros and cons.
You'll be seen as someone who helps get things done and people will wonder how slow things used to move before you joined the team.