Looking for Archivematica the software project? see: archivematica.org

archivemati.ca

archivemati.ca header image 1

System Requirements

November 4th, 2005 · No Comments · System Requirements, Terms & Definitions

System requirements state what a system’s behaviours, properties, characteristics and features are in as unambiguous a way possible. The purpose of system requirement specifications is to accurately capture the requirements of the system’s owners, users and stakeholders.

System requirements are drafted to ensure that all parties are in agreement on what system should be built before development and implementation begins and modifications become costly, time-consuming or (yikes!) impossible. System requirement specifications are therefore often used as the basis and criteria for acceptance testing to ensure that the system which has been been built matches the original vision and needs of the system owners, users, and stakeholders.

The most common way to organize system requirements is functionally. System requirements are, in fact, often referred to as functional requirements. Functional requirements state ‘what’ a system must be able to do without necessarily specifying ‘how’ it should be done.

  • e.g. ‘the system must provide the ability to enter a search query’

Functional requirements are typically supported by data requirements and non-functional requirements such as technical requirements, usability requirements or quality requirements.

Data or metadata requirements state what information will be created or used by the system.

  • e.g. ‘the search query will include a query string, name of the collection which is being searched, and the date/time of the query’

Technical requirements are functional requirements that declare the required functionality of the system from the perspective of the technology, standards and features that must be supported by the system.

  • e.g. ‘the search query must support boolean logic statements’

Usability requirements declare the required functionality of the system from the perspective of the user and their expectations on how they will interact with the system.

  • e.g. ‘the search query feature will provide context-sensitive help and instructions’

Quality requirements are restrictions or expectations on ‘how well’ a functional, technical, data, or user requirement is to be met or the degree to which a function or feature should be provided (these can include criteria for system performance, security or user-friendliness).

  • e.g. ‘the maximum time for the system to return search query results is 3 seconds’

There are many different requirements analysis methodologies and practices, each with their own preference for the types of requirements to include and what to call each type. Requirements can be specified textually, using diagrams (e.g. UML, DFD, E-R, IDEF), or a combination of text and diagrams.

Below is a list of quality characteristics for requirement specifications based on software engineering best practices. (1) These are applicable regardless of what methodology or diagram modeling syntax is used.

Quality Criteria for Requirements Specifications

  1. Complete: The functionality to be delivered is fully and accurately described. All of the information necessary to design and implement the system functionality is provided.
  2. Unambiguous: All readers of the requirement specification will be able to arrive at a single consistent interpretation of the description.
  3. Consistent: Any one requirement specification should not conflict with another requirement.
  4. Valid: Only the functionality that is within the system’s scope and that has been approved by the system owner is described.
  5. Feasible: Only the functionality that may be realistically implemented within the known capabilities of existing technologies and the known capacity and resources of the system owner is described.
  6. Prioritized: An indication is given whether the requirement is mandatory or optional. Within these two categories, each requirement is ranked in order of importance against other requirements.
  7. Unique: Each requirement specification will be uniquely identified so that it can be distinctly referred to and to allow for the maintenance of a requirement revision history.
  8. Traceable: The requirement specifications will be organized in such a way that they can be linked to their source, to additional design documentation, to software and hardware components within the deployed system and to test cases that verify the correct implementation of the requirements.

—–
1) see: