When working as part of a team I like to break down the barriers as much as possible between people. Part of that is breaking down team members roles from tester, analyst, developer, dba etc into the vanilla "team member." The benefit you get is a unity of purpose.
As an individual I find it hard to position myself with just one title, although you often have to ascribe a title to what you do so you can fit into other people's mental models. Business Analyst, Consultant, Project Manager, Scrum Master, Coach as all labels I have used at various times. My favorite is team member.
Within project teams you have a certain flexibility that lets you do this. In the larger context of HR administered job descriptions it becomes a little more complex.
How, for example, do I deal with the concept of senior and junior project manager? If they both work on the one program how do I break down the inherent power relationships in the role titles? And when trading players across teams, how do these role specifications help weigh the value of someone in a new team?
If you have to give a hierarchy to roles for career progression it's best to make it as transparent and objective as possible. And it should say what it is - which means being more specific that senior (older?) and junior (graduate?)
Both the IIBA and the PMI have capability models that check an individual's competencies against a framework. That's a nice start, as it enables you to verify a person's capability against their roles, but there really isn't a categorization in the frameworks for senior and junior yet.
Maybe what we need to have is the concept of apprentice, journeyman and master. We keep coming back to that don't we? Why isn't it the dominant model I wonder?