There is even a "rule" for what you espouse: YAGNI - You Ain't Gonna Need It
If all you ever going to deal with is humans in your class/API, there is no need to make it generic enough to work with all animals. The Clever Boy in all of us probably wants to implement this bit of "future proofing investment" but we need to resist the temptation.
I wish STTCPW (Simplest Thing That Could Possibly Work) made for a better acronym. Also related: KISS (which I prefer to interpret as "Keep It Stupid-Simple").
STTCPW has problems aside from its acronym; back when I was working in an XP-ish team we had any number of arguments which I eventually realized came from a fundamental ambiguity in this principle: does it mean
1. Make the simplest incremental change to the existing system to satisfy requirements, or
2. Make the simplest overall system which satisfies requirements?
The first is fine for prototyping when you're moving fast and breaking things, but guarantees technical debt out the wazoo over the longer term. The second makes for much better code but you may waste a lot of time on refactoring churn if you do too much of it before requirements have really stabilized.
Usually considering the parts of abstraction that will reduce coupling and make understanding easier, or allow making an implementation high performance or secure. You know, things nobody really states in requirements but everyone wants in the end.
Most of the time internationalization and localization are also needed but not stated outright.
Also consider things that are essentially impossible to bolt on later or inordinately expensive.
If all you ever going to deal with is humans in your class/API, there is no need to make it generic enough to work with all animals. The Clever Boy in all of us probably wants to implement this bit of "future proofing investment" but we need to resist the temptation.