The set of requirements for the system is listed in Table 9-1. These requirements give more detail on the functionality of the system described above.
Table 9-1. Requirements for the Software Licensing Application.
R No. | Requirement Text |
|---|
R1 | Application developers must register applications with the server. |
R2 | Application registering results in the assignment of a unique number generated to identify all clients. |
R3 | After application registration, developers and vendors can register applications for distribution, including registration of application details, system requirements, and usage rights models for a particular application. |
R4 | Application registering includes entering authentication information and contact details. |
R5 | After application registration, the developer uploads the application and the usage rights enforcement code. |
R6 | The enforcement code allows or disallows usage of an application according to a particular usage rights model. |
R7 | A user can browse through the applications and download applications and particular licenses. |
R8 | Downloading an application packages the application with the chosen usage rights model. |
R9 | The usage rights management system (server) must be used to verify and enforce usage rights according to specific models. |
R10 | Whenever an application is launched, the usage rights should be checked according to the relevant model. |
R11 | Several usage rights models may be enforced: unlimited-usage named-user license time-limited feature-based subscription-based pay-per-use audit-based concurrent node-locked |
R12 | Unlimited-usage: With this model, the server retains evidence of a single payment by the client, which, when found, allows usage. |
R13 | Named-user license: Clients provide their identification, and their registration is checked. |
R14 | Under a named-user license, if a client is registered for use, usage is allowed. |
R15 | Time-limited: The client retains a log of when the license started and its expiry date. |
R16 | Once the time limit is reached, usage is disallowed. |
R17 | Feature-based: When a feature is invoked, the client checks usage rights from the server. |
R18 | In feature-based, usage is allowed based on identity. |
R19 | Subscription-based: The user pays a monthly fee and checks at application launch whether the fee has been received. |
R20 | Pay-per-use or audit-based: Each time an application is launched, the client is billed. |
R21 | Node-locked: Usage is allowed based on node-identification such as IP address. |
R22 | In an audit-based model, users must send the logs of the previous application usage to the server for billing. |
R23 | Concurrent usage: A certain number of nodes or users are allowed to access the application at a time. |
R24 | In the concurrent model, users can satisfy the usage rights for the application only if the number of users who have concurrent usage rights at any one time does not exceed the maximum number of granted rights. |
R25 | The audit-based model, pay-per-use model, and concurrent usage model require server contact to determine usage allowance. |
R26 | For pay-per-use, audit-based, and feature-based models, usage data is logged at application launch and, additionally, according to the usage model. |
R27 | For the audit-based model, the logged usage data is sent to the server once a month for customer billing purposes. |
R28 | The time-limited model can be extended by purchasing a new license with a new expiry date. |
