How to Create a Job Requirements Profile Before Any Assessment
You create a job requirements profile before you choose any assessment, not after. It defines which competencies and behaviors are actually success relevant for a specific role in a specific organization. A good requirements profile isn't built by HR writing down a list of desired traits. It's built through a proper requirements analysis of the actual work. That distinction matters, and in practice it's often skipped.
This article is for you: a practical guide to building a requirements profile grounded in a real requirements analysis instead of a wish list.
- How to Create a Job Requirements Profile Before Any Assessment
- What a Job Requirements Profile Actually Is
- Where the Requirements Actually Come From
- Why the Order Matters
- How to Build One in Four Steps
- Who Builds the Profile
- Why the Same Role Has Different Profiles
- Why Generic Assessments Fail Here
- What Happens Next
- The Legal Angle
- Checklist: What a Good Requirements Profile Looks Like
- Warning Signs
- The Bottom Line
What a Job Requirements Profile Actually Is
A job requirements profile describes which traits a person needs to perform a specific job successfully. That includes qualifications, expertise, skills, competencies, behaviors, personality traits, and, depending on the role, other requirements.
It differs from a job description. A job description answers what the task is, what the person does, and where the role sits organizationally. A requirements profile answers what a person needs to bring to perform that task successfully. It describes the target state of the person in relation to the work, not the work itself.
The German standard DIN 33430:2016-07 makes requirements analysis the central starting point of professional job-related suitability assessment, explicitly distinguishing between qualification criteria, competencies, and potential.
Where the Requirements Actually Come From
The decisive question isn't what the profile looks like, but where it comes from. There are two quality levels.
Level 1: the manager says what they want. HR asks the hiring manager what the person should do, what experience they need, and what personality they're looking for. That's fast, but methodically weak, because the manager usually describes their personal image of the ideal employee rather than the role's actual success-critical requirements. This is exactly where terms like assertive, team player, hands-on mentality, or entrepreneurial thinking come from, terms that stay open to interpretation and are rarely behavior-specific.
Level 2: a proper requirements analysis. It starts by examining the work itself, drawing on job descriptions, existing competency models, interviews with managers, job holders and subject experts, observation of the work, workshops, and the analysis of success-critical situations.
Why the Order Matters
Clean hiring runs in three steps. First, the requirements criteria get defined before anyone has a conversation. Then a structured process with diagnostics follows, measuring personality, values, motives, or abilities depending on the role. Only after that does personal, likability-driven selection decide between candidates the earlier steps have already filtered as suitable.
Likability is not the problem here. The order is. Likability at the start replaces the criterion. Likability at the end decides between people who are already qualified.
How to Build One in Four Steps
1. Analysis: build the foundation. The role gets understood in the context of the company before any requirement gets written down. That means working closely with the hiring department, because the manager knows the daily challenges and the team dynamics. A current-state versus target-state analysis clarifies what tasks are coming up over the next six to twelve months, instead of carrying forward an outdated description. A culture check examines whether working style, communication style, and values fit the team and the company.
2. Definition: derive the requirements. The critical incident technique identifies success-critical situations and derives from them the behavior that decides whether someone succeeds in those moments. A customer complains furiously about a mistake. A successful person stays calm, listens first, takes responsibility, and works out a solution with the customer. From that, requirements such as conflict resolution, emotional self-regulation, and problem-solving ability get derived, not the other way around. The requirements themselves fall into three categories: technical requirements such as education, experience, and expertise; methodological competencies such as analytical thinking, project management, and decision-making; and social competencies such as cooperation, communication, and conflict resolution.
3. Prioritization: separate must, should, and nice-to-have. A requirements profile is not a wish list. Must-have criteria are non-negotiable knockout criteria, without which an application isn't considered. Should-have criteria matter for long-term success but can still be developed after day one. Nice-to-have criteria make a candidate more attractive without deciding the outcome. Skip this separation, and you end up with the mythical unicorn profile that no real person meets.
4. Wording: behavior instead of labels. Vague terms like team player or flexible leave too much room for interpretation and are hard to check in an interview later. Here's the difference in practice: instead of "is good at handling conflict," the profile reads "raises tension early, holds their position under pushback, and looks for a workable solution at the same time." That makes a trait observable, and it means you can actually check in an interview or an assessment whether someone shows that behavior.
Who Builds the Profile
A requirements profile normally isn't built by HR alone. It comes together through HR, the hiring manager, the job holder, and subject experts, and for more complex roles, through workshops or structured interviews. The most common shortcut in practice looks different: job description plus the hiring manager's opinion plus the old job profile becomes the new posting. The organization then describes who it believes it needs, instead of finding out who actually succeeds at the work. The result is profiles full of abstract traits that sound right but leave the real question open: what concrete behavior this job requires, and in which situations.
Why the Same Role Has Different Profiles
A requirements profile is organization-dependent. A sales manager at an established corporation often needs process discipline, stakeholder management, and structured planning. A sales manager at a start-up needs independence, tolerance for ambiguity, and fast decision-making under pressure instead. The job title alone isn't enough as a foundation. The profile has to reflect the actual work situation and organizational context, not a generic template for "sales manager."
Why Generic Assessments Fail Here
An assessment is only as good as the requirements profile it measures against. Without a role-specific profile, a generic tool measures traits that aren't actually success relevant for that position. The result looks scientific but says little about whether someone will succeed in that specific role and organization.
Predictive validity is exactly where this connects. It shows how well a tool predicts actual behavior, but only for the traits it measures. A valid tool measuring the wrong traits still produces the wrong result.
What Happens Next
The finished requirements profile isn't the end point, it's the foundation for the entire selection process: requirements profile, job posting, applicant screening, interview, test or assessment, decision. If analytical problem-solving is a success-critical requirement, it doesn't just show up in the job posting, it gets measured afterward too, through structured interview questions, a case study, a work sample, or an assessment. The same criteria carry through the whole process instead of getting lost along the way.
The Legal Angle
Requirements have to be justified by the actual job, not by preference. Under German equal treatment law, applicants may not be disadvantaged based on gender, ethnic origin, religion, disability, age, or sexual identity, including through selection criteria. Section 11 of the German General Equal Treatment Act (AGG) requires job postings not to violate that principle. "Fits well with our young team" is a culture wish. "Can reprioritize quickly in a fast-changing environment" is a job-related requirement. Only the second belongs in a requirements profile.
Checklist: What a Good Requirements Profile Looks Like
- It describes behavior in concrete situations, not just trait words like "communicative" or "resilient"
- It separates technical, methodological, and social requirements
- It separates must-have, should-have, and nice-to-have instead of weighting everything equally
- It's based on a current-state versus target-state analysis of the role, not a standard template
- It's aligned with the manager who makes the hiring decision
- It translates directly into interview questions and measurable diagnostic dimensions
Warning Signs
- The profile is job description plus the hiring manager's opinion plus the old job profile
- It's just a list of soft-skill buzzwords with no behavioral anchors
- Nobody can explain why a criterion is success relevant
- The same profile gets reused for very different roles or organizations
- Culture wishes like "fits well with the team" replace job-related criteria
- The profile only gets written after the assessment tool is already chosen
The Bottom Line
A job requirements profile is the precondition for any diagnostics that should actually predict something, and for any hiring decision you can later justify. Skip it, or piece it together from a wish list, and you end up choosing a tool that may be scientifically sound but measures the wrong things. The PEATS Guides help you find, for every role, the tool that captures exactly the dimensions that matter there.
The PEATS Guides provide structured evaluation frameworks for every use case: vendor-neutral, scientifically grounded, and built around concrete roles and situations.