I define an attribute as a characteristic property of an entity or an object. First, I follow the ISO/IEC/IEEE 29148:2011 idea. It says an attribute is an inherent property that you can distinguish quantitatively or qualitatively. Therefore, I treat attributes as meta-information about requirements. For example, I use attributes such as Status, Priority, Owner, Version, and Criticality. In addition, I apply attributes to documents, change requests, and model elements. However, I do not confuse requirements attributes with class attributes in a UML class diagram. In other words, class attributes belong to the content. Conversely, requirements attributes serve as metadata.
Next, I document attribute schemas clearly. I present them in a table for simple cases. Moreover, I use an information model when the schema grows complex. Then, I map the schema to the fields of my requirements management tool. For instance, I add a separate column in a requirements list. Also, I create separate fields in a database. This approach improves traceability. Consequently, stakeholders can filter and report reliably.
When I change an attribute schema, I act carefully. First, I try to avoid retrospective changes during a project. If I must add an attribute, I update existing requirements. Otherwise, reports and views become inconsistent. If I change an attribute name, I update designations in all documents and interfaces. If I need to delete an attribute, I check whether other views or systems still query it. Instead of deleting, I often rename it to include “(no longer used)”. This choice reduces integration problems.
When I add or change possible attribute values, I review impacted requirements. For example, if I add a new Criticality value “Very high”, then I reclassify requirements that were “High”. Otherwise, the analysis may miss critical items. Furthermore, I check whether the tool supports the new values technically. If not, I adjust the schema or the tool settings.
If users do not populate an attribute, I investigate why. First, I ask whether the attribute remains relevant. Next, I check if users understand its definition and benefit. If they do not, I provide training; if users still do not fill the attribute, I consider making it mandatory.; and if I make it mandatory, then I update existing requirements retrospectively. For example, I populate missing values automatically with a default value. Alternatively, if the attribute no longer serves the project, I remove it. Thus, I keep the schema lean and useful.
Moreover, I reuse attribute schemas when possible. For example, I adopt a reference schema from the organization. Or, I adapt a schema from a similar project. In addition, I involve stakeholders when I design the schema. Therefore, I ensure the schema meets reporting and planning needs. Finally, I ask stakeholders whether they find the information they need in their views. If not, I add missing attributes or attribute values.
In summary, attributes help me categorize and manage requirements. Specifically, they provide meta-information for release planning, status tracking, and change control. Consequently, I improve overview and decision making. To conclude, I design attribute schemas deliberately, document them clearly, and manage changes carefully. Thus, I keep requirements data consistent, useful, and traceable.