General Comments

You shouldn't be making design decisions at this point. Deployment via a Departmentally-administered web server is a design decision unless the stakeholders told you it MUST be done this way (then it's a non-functional requirement).

Remember the definition of 'use case': "A use case is a single task, performed by the end user of a system, that has some useful outcome." Be careful you don't confuse a "business process" with a use case. A business process is typically more complex and may involve several use cases.

Use cases describe interactions with a computer system. Don't include in its description other aspects of the business process in which context the use case is performed. For example, "check in book" might be a use case, but putting the book back on a library shelf is not part of it.

These comments correspond to circled numbers on your delivered Group Organisation reports.

1 When specifying requirement risk, you should indicate aspects of your specification that you believe may be incomplete or incorrect. In other words, how confident are you that your requirements are right?

2 If a use case has no postcondition, then it means there has been change in the system's state as a result of the use case interaction.

3 You have confused requirements of the validation prototype with requirements for the proposed system.

4 Try to use a verb phrase as a name for a use case. E.g., "Check out book.", "Search for book".