Any use case may have attributes assigned to it. Attribute is a small-caps English word, without spaces or numbers inside. For example:
:UC3.2 is a must.
:UC8 is delivered.In this example, must is an attribute of UC3.2 and
delivered is an attribute of UC8.
We recommend to use attributes for requirements prioritization, according to MoSCoW method:
must
should
could
would
We also recommend to use attributes for requirements prioritization:
specified
implemented
delivered
accepted
Seals
When attribute is specified, it is possible to “seal” it. A seal is a 6-signs hexadecimal number, calculated by Requs engine, as an MD5 hash function of the use case content.
For example, these two use cases will have two different seals:
UC3 where nothing happens: "tbd".
UC3 where nothing really happens: "tbd".Their signatures are different, that’s why their seals are also different.
In order to calculate a seal for your use case, just add
a random seal (for example, ffffff)
and run mvn requs:compile:
ffffff:UC3 is a must.You will get an error message, similar to this:
[ERROR] 17:0 Seal "2edb8f" at the method UC3 doesn't match "ffffff" at the attribute "must"The message means that Requs engine is expecting 2edb8f as
a seal for all UC3 attributes. We set it to ffffff — this
breaks the build and makes our Requs specification in-compilable.
Now, we can change ffffff to 2edb8f in the specification
and Requs won’t complain any more.
When, in the future, someone changes the content of UC3, they will
break the build and will have to change the seal for all attributes.
This mechanism exists in Requs in order to be able to baseline individual requirements in a continuously changing document.
Say, use case UC3 is already implemented and delivered to
the product owner. It has an attribute delivered in the SRS,
and this attribute is sealed.
Then, someone is changing the description of UC3. The seal
doesn’t work any more and Requs starts complaining. In order to
make the build clean again, the author of these changes has to
remove the seal from the document.
UC3 doesn’t have a seal any more. It is clear for the project
manager, that this use case needs to be implemented and delivered to the
product owner again.
Thus, being a system analyst working with the SRS, be aware that if any seal doesn’t match its expected value after your changes, you should just remove the seal.
Seals are supposed to be placed in the SRS by a project manager. Well, not necessarily a PM, but a person who is responsible for changing statuses or priorities of requirements.
Usually it happens on project milestones, when priorities are set and requirements are baselined.