In reality we as programmers need to turn what the stakeholders want into code. They will talk in meetings: we better take notes. They will write things down [in English or whatever language they speak], but it won't be code. There will be conflicting requirements, and we as programmers need to understand the topic well enough to make reasonable decisions on the easy stuff, while going back on the harder stuff - easy and hard is as the decision makes see things not as a programmer sees them: better know that too.

Once you figure out what stakeholders want turn it into code. It is useful to have integration tests for scenarios that they care about (some of them are stupid - the last version of an embedded product I worked in had a 5 length array, and it turns out some customers needed 7, and later analysis proved that 7 was the mathematical max anyone would ever want. The current version is C++ using a vector so the potential length is unlimited (limited by free memory), but we still have a test proving 7 works because the mistake in the past burned enough people)