What should I do if I keep missing points of interests in my work?

I will expand a little on @LoztInSpace 's answer.

If your company does not have a proper tool to manage requirements, it is bad but not life-ending. But your company MUST have an issue-tracking tool. There are countless tools on the market for this purpose, both open-source (for free) and proprietary (for money).

some holes/details left out of the explanations from colleagues

When a colleague tells you that you need to do something, ask them to fill in an issue report with the problem, providing there all relevant information.

or more detailed aspects that aren't explained in the documentations.

That is the purpose of the issue tracking tool: to provide the details of what needs to be improved - containing all the relevant information.

Here's my issue though, how do I know when I should ask questions (or what parts I should ask questions about)?

You do not have to know that. You need to do 2 things:

1. BEFORE working on a task: request the issue report document (in the tool discussed above), which contains all the information.
2. AFTER the job is done: request the person who gave you the task (and maybe some of your colleagues) to review the work done. if they do not like it because XYZ, then ask: "Where is XYZ mentioned? If it is not mentioned, how could I know about it?"

It is not important if you have to update requirements, design code, or if you need to test something. The process is similar.

My problem is that I tend to not know/realize that certain details need further clarification until I was asked about it, which obviously isn't very good in a professional context.

1. It is not your job to dream what other people want. You do what you are told. it is their problem to explain what they want.
2. If you are unprofessional, they are even more unprofessional.

Before you start acting on everything I explained, make sure that you have a discussion with your manager and tell him that you need better processes in your company, and ask him to provide you with support.

Additionally, ask your manager to provide you with trainings suitable to your job and suitable to the level of quality expected from you.

If there is no intention of improvement in your current company (unfortunately, it happens very often), try to get a job in a more suitable company.

a bank's IT department

I never worked for a bank, but many of the horror stories full of bad practices (according to everything I read on the internet) come from the banking industry. I would not look for a job in that area - unless really forced to do so.

Please remember: your brain is not a tape recorder, and not another type of recorder. Nobody should expect that you can remember everything just because they said so one time. If they have this expectation from you, then they are very bad people. Just tell them politely that you cannot be expected to remember everything.

BE AWARE: do not fall into the trap that you take notes according to what they talk. You give them the possibility to claim that you took notes in the wrong way.

IT IS THEM who should take responsibility for what they say, by providing you the information in written electronic form - so that it can be traced back to them.

I'd recommend you obtain (or make) a tool that's widely used in the IT industry, though not much talked about:

• a rubber duck. 

As you've found, telling someone else about a task or problem forces you to think about it in a different way, which can highlight any gaps in your understanding.  And, surprisingly, it doesn't depend upon whether the person understands, or is listening, or is even a person!

Of course, it doesn't have to be an actual rubber duck toy, though that's traditional — anything that you can talk to as if it were another person can work.  For example, I find writing tickets and comments in an issue-tracking system works well for me (and gives me a permanent record to refer back to).  Or if you work from home and have a pet, you might find they make a good audience.  Or a picture or drawing of someone — it doesn't matter, as long as you can imagine trying to explain to them the problem you're solving, and/or how you're doing so, in detail.

Then, when you have to explain it to your supervisor or boss, there shouldn't be any surprises because you've already covered that ground — and had some practice!

You haven't experienced this before, because it's not your problem. So, don't allow it to become your problem. That's a slippery slope in terms of morale and professional reputation. You can become the scapegoat for everyone's half-thought-out rubbish that doesn't work properly.

It's up to the employer to provide the parameters of work in detail. Your job is to fulfill your tasks within those. You don't read minds. I have worked in a lot of industries, I'm very inquisitive at the start as I need to quickly get my head around the business needs in terms of my work. But there's always people on the ground who know a LOT more, use them as a resource.

So be proactive with questions at any time you feel a need for it. Apart from that follow the documentation closely. With the finance industry some things are actually mandatory depending on what you're doing, it can sometimes pay to go through any applicable legislation when making a new system.

Missed requirements are due to one of 3 things

Other answers are correct, I just want to provide a different point of view.

1. Missing Requirements. "Bobby, why is this missing?" "Because it isn't in the functional or non-functional requirements." Build an RTM (Requirments Traceability Matrix) documenting each requirement and how you meet each one. A set of emails or meeting notes is a poor RTM.

2. Bad Test Conditions. "Bobby, why is this missing?" "Because it wasn't listed as a test condition, and I wasn't aware of it." Write out the test conditions, expected results, and success criteria. Do the tests and document the results via screenshots.

Note that the best requirements and test conditions have been set by operations with input from tech & QA.

3. You screwed up. By a combination of not meeting the requirements and/or not properly testing.

1 and 2 are system issues, so you need to work to improve the system as a whole. #3 is all on you, but if 1 and 2 are properly documented it's hard to mess up #3.

Do you cross reference your design against requirements and look for gaps? If there are no requirements, you can't expect to have coverage. Comparing your work against verbal/informal discussions opens up a lot of scope for gaps or ambiguity.

Once you're comfortable you have a candidate solution:

• Do you hold design reviews? You should.
• Do you hold code reviews? You should.
• Do you have acceptance criteria? You should.

These will help. It's not very modern & agile, but in banking you tend to have to be more rigorous with these things.

Also, work with your boss on training, either technical or domain knowledge. Especially only 4 months in, you should be getting constant feedback and course corrections.