Role

I define a role as the part a person plays in a given context. For example, in UML class models I call a role the part an object plays in an association. In requirements engineering, I use the term role to assign who plans, controls, and improves the requirements engineering process. First, I assign responsibilities. Second, I decide who performs the activities. Third, I check who manages requirements.

I treat the requirements manager as a central role. In larger projects, I make this a separate role. In small projects, I give the duties part-time. Moreover, I expect the requirements manager to know requirements engineering methods. In addition, I expect technical knowledge. Furthermore, I expect management skills. Therefore, the person can set up, manage, and monitor the process. Also, I require very good communication skills. Consequently, the requirements manager stays in constant contact with all stakeholders.

I can also distribute requirements duties across the development team. For example, I let team members elicit, document, check, and manage requirements. In this case, the team performs requirements engineering without a dedicated role. However, I still recommend that someone monitors the overall process. Otherwise, I risk inconsistent documentation or missed stakeholder needs.

I often separate roles by activity or by content. For instance, I assign one role to functional requirements and another to usability requirements. In addition, I may assign multiple people or a team to cover all aspects. Furthermore, I define clear interfaces between roles. This reduces overlap. Consequently, I lower the chance of conflicts.

I require role-based access to requirements information. For example, I restrict sensitive details to specific roles. Moreover, I generate role-based views in tools. As a result, each role sees only the relevant information. Then, I set permissions so that roles can activate certain views. Therefore, one view can often serve multiple roles. In addition, I align views with stakeholder goals and with the attribute schema.

When I define views, I follow clear steps. First, I identify stakeholders and their needed views. Second, I reuse templates from past projects if possible. Third, I specify the goals for each stakeholder. Fourth, I determine which attributes each view needs. Fifth, I compare required attributes with the attribute schema. If attributes are missing, then I update the schema or create new views. Finally, I implement the views and the access rights.

I use several sources to find stakeholder roles. For example, I consult organization charts, business process documentation, and stakeholder categorization schemata. In addition, I use checklists of typical stakeholder groups. These include direct system users, business or process managers, clients or customer-representing organizations, opponents and competitors, IT staff, and governmental or regulatory institutions. Moreover, I build my own checklist over time for specific domains such as insurance.

In short, I treat a role as a clear responsibility in requirements engineering. I recommend defining roles early. Also, I recommend creating role-based views and assigning access rights. Finally, I keep communication lines open between roles and stakeholders so that requirements stay accurate and complete.