University/school exercises are sometimes intentionally vague as they are testing your knowledge of the subject matter as well as the programming language. For example, a exercise that requires connecting to a remote host may not specify the application should support both a hostname and IP address.
That said, requirements in practice are not a monolithic, one-time thing. Even (hypothetical) customers that provide detailed, unambiguous requirements up front may change their mind during the development as they learn more about the possible solutions and requirements change over time. Key points to consider:
- Keep open communication between the developer and the customer. Scrum does this through the sprint process and the product owner concept, for example.
- Make incomplete versions of the product available, such as through a beta program. Getting a working application into customer hands gets the best feedback you can.
- Make time in the schedule for handling changes to requirements. Planning and expectation setting is half the battle.