In addition to requirements characteristics,
we use attributes to support analysis and management.
And so, a requirement could be allocated a number of attributes.
In fact, there could be many such attributes to,
to a requirement sometimes, up to some 300.
Here we only identify a small number which would be the major attributes.
But you get the idea of the sorts of things that an organization might wish to
attach to a requirement to allow that organization to
manage that requirement better over the life of the system.
The first, of course, is the unique identifier.
Words that are general and long lists of words become difficult to manage.
So, each requirement must have a separate unique number to
identify the unique statement.
And of course, you know, requirements database that generally tends to come for
free, as you are allocated a key to the database.
But the point is that, whichever way we manage them, we need a unique identifier.
That number of course is also not terribly useful.
So it helps to add to the number a short title.
And that short title then, in three words, four words long,
simply summarizes the requirement.
It's not as useful as the requirement, obviously, but
it is useful to refer to the requirement by its short title rather than reading out
a number which doesn't seem to make sense or reading the long sentence every time.
Each requirement also needs to have attached to it a priority.
And that's important because later on, we'll talk about the idea of design space.
That is that the designers can trade off weight for range, for burn rate, for
leg room and so on, on a platform like an aircraft.
If we don't understand which is more important to the customer,
then it's very difficult to use that design space to design the system.
So priority is a way which the originator of the requirement communicates to
the designers, and how important each those aspects is to them.
Now, it's not mandatory, but it's also very useful whilst writing
the requirement to attach to the requirement some indication of risk.
It could be a risk level, or
could actually be a risk statement in some, in some, systems.
That is when the writer of the requirement articulates it,
they also have to think a little while about what risk is attached to that, and
that goes back to as we were talking before about
the feasibility of the requirement, and, and also the ability to verify.
If we need to ever in the future discuss the requirement,
we might need to go back to the source.
Now it could be a standard, it could be a regulation.
But it's also commonly of course, an individual or
an organization, or a committee, or a workshop.
Also molicitation process that gave us the requirement.
And so we need to know where it came from in case we need to
go back to discuss perhaps if two requirements conflict, for example.
We might need to go back to reconcile that with the original sources.
Another useful attribute, as we saw before, is a rationale.
Some people would write a rationale statement.
Others might include rationale in the attributes.
I doubt that it matters really either way, but what's important again, as we
said before, that we record the reason for the existence of the requirement.
We also might want to record some history.
Now again, of course, in a relational database the history is tracked
generally by the database so it sort of comes for free.
But we want like to know, when was this requirement raised?
How often has it been changed?
Have we deleted it?
So where are the old requirements that we deleted?
So, history is a really useful thing to help us understand how it's changed in
the future.
We also might like to know, as we saw before, and
we'll talk again later about traceability.
How does this requirement relate to other requirements?
And so those relationships ought to be tracked as well.
Again, it could be in the attributes or it could be part of the relational
database in the modern requirements management system.