This would be a combination of a use case and certain aspects of the rules. There are many practices and different opinions of what steps you should take in creating requirements.
Different businesses have different templates. It depends on what works for you. I suggest you read a few books to come up with something.
A use case describes the action the user takes in regards to the system and what happens when the user clicks here or there. Think of telling a story of the relationship between the user and the system.
In your above example, the rule defines the values of each field (max of 8 alphanumeric characters), and the details of the message that might appear if a user clicks cancel, for example. You can all sorts of requirements though. This is not all encompassing. There are business requirements, functional requirements(use cases), non-functional requirements, software requirements (message appears when you click Save), etc.
In most documents I write, the business rules are at the beginning of the document and provide general requirements of the project. Then a use case might appear, and then throughout the document I outline the details of each portion of the UI or whatever the design is.