Non-Functional Requirements

Owned by ScottS
Last updated: Oct 14, 2008Version comment
3 min read

Non-Functional Requirements

Performance

  • The system will have a low number of systems of record attempting to access it. These systems of record could be transporting large amounts of data to be processed. Care should be taken to be able to parallelize the processing of this data as much as possible to minimize the amount of time it takes to process. If data takes too long to process the next update could come in before the data was processed.
  • Similarly the system could also be pushing data out to a select set of resources (such as an LDAP server and other database). These updates need to complete before the next updates would begin.

Scalability

  • Performance should get incrementally better if more instances are added. Instances should be able to work together to divide up work, etc.
  • The system will need to be smart enough to detect how to push out updates (in case one of the machines gets one part and another gets a second part) or tasks will need to be properly grouped together such that portions that are dependent are not split across machines.

Capacity

  • System needs to be able to handle everything from low number of users with large datasets once or twice a day to low number of users pushing small data at the system constantly.

Availability & Reliability

  • It should be assumed that this application requires as close to 24/7 uptime as possible thus all changes should be able to happen in real-time without application restarts.

Recoverability

  • Though the goal is 24/7, the system should be able to recover and continue from where it was if there is a scheduled or unscheduled interruption of service.

Maintainability

  • Code should be architected and developed such that common extension points are exposed so that deployers can plug in their institution/organizational code without forking the codebase making local maintenance a nightmare. At the same time, developers of the OpenRegistry system need to balance their own maintainability needs such as making the system too extensible which can make it a burden to do future revisions or increase support requests as people are overriding something they probably should not be overriding.

Serviceability

Security

  • All actions that result in a change, or the viewing of confidential information should be capable of being logged (and its up to the deployers on whether they want to or not).
  • Logging of actions should be configurable such that deployers can dictate where information is logged.
  • System should be able to protected which resources and actions can be taken by a user, as well as on behalf of a user.

Regulatory

The software itself has no regulatory requirements. However, it should be designed such that it supports existing United States and EU regulations including FERPA.

Manageability

The services should be able to be deployed on standard hardware and software including being operating system and servlet container agnostic. This should allow deployers to maintain their servers consistently. In addition, the software should follow any available standards for making manageability easier, including JMX.

Environmental

Data Integrity

  • A transaction must either fully complete or completely fail. It cannot be left in an inconsistent state. The system should also be able to determine where it left off during a failure. This may include having to do distributed transactions.

Usability

  • Any graphic user interfaces should conform to current Internet standards and be render-able in any modern browser that complies with external link: Yahoo's Grade A support.
  • Where possible, prefer configuration via GUI vs. configuration at build-time.

Interoperability

  • Modules of the OpenRegistry System (i.e. PersonRegistry, CredentialsRegistry, etc.) and their accompanying components should be de-coupled from each other such that they can be deployed and upgraded/updated independently of each other. This does not preclude the systems from speaking to each other or from there being enhanced functionality when more than one is deployed. Systems may also have common libraries, but these libraries should not be part of any specific project and their usage should not need to be coordinated.
  • Modules should expose an API integration point for interacting with other systems. This does not preclude them from including default implementations that work well with other OpenRegistry systems.