Non Functional Requirements
Previous Topic  Next Topic 

This is a general list of items for consideration when writing the URS. They generally fall into the category of Non Functional Requirements.

These requirements are often Constraints - limitations on how the system shall be constructed for example to use a specific system.

Others can be more subtle

Code Ownership is a potential issue when a third party (where the first is the final user and the second is the system hardware supplier and the third the systems integrator)  is employed. Sometimes the integrator might quote for example copyright to claim ownership of the code, even though it has been writtend specifically for you. It is essential that you spell out in the contract that you will own the code.

Example wording

All applicattion code provided by the supplier must be provided with source and documentation and the ownership of the code transfered to the end user at an agreed point in time.

Alarm Handling

The general principles of alarm handling should be defined in the URS

Wikipedia definition of Non Functional Requirements

This web is funded by advertising, but the advertisers have no influence on the web site. Please visit them.