Types of Requirements

A goal is an objective or concern that guides the RE process. It can be used to discover and evaluate functional and non-functional requirements.

• a goal is not yet a requirement
• all requirements must be verifiable

A functional requirement is a requirement defining functions of the system under development

• describes what the system should do

A non-functional requirement (NFR) is a requirement characterized by a measurable property or quality such as system performance, robustness, usability, maintainability, etc.

A user requirement is a desired goal or function that a user or other stakeholder expects the system to achieve.

• does not necessarily become a system requirement

Application domain requirements (sometimes called business rules) are requirements derived from business practices within a given industrial sector or company, or defined by government regulations or standards.

• may lead to system requirements. Can be functional or non-functional

System requirements are the requirements for the system to be built, as a whole. In a system containing software, software requirement are derived from the system requirements.

Functional Requirements

• what inputs should the system accept
• what outputs should the system produce
• what data the system should store other systems might use
• what computations the system should performance
• the timing and synchronization of the above

the system shall enable the user to search the database by product

Non-functional requirements

• if not met, the system is useless
• may be difficult to state precisely and imprecise requirements may be difficult to verify

The system development process and deliverable documents shall conform to the MIL-STD-498 standards

Goals

• conveys the intention or the objective of one or many stakeholders
• can guide the discovery of verifiable non-functional requirements that can be tested objectively

the system must be easy to use by experienced controllers.

Application-Domain Requirements

• derived from the application domain
• describe system characteristics and features that reflect the domain
• may be new functional requirements, constraints on existing requirements, or define specific computations
• if domain requirements are not satisfied, the system may be workable

For a health info system: the system shall comply with Ontario's Personal Health Information Protection Act