This best practice explores functional requirements (dealing with user/product interactions) and non-functional requirements (dealing with product performance).
Functional requirements focus on what a product should do or look like, and what user interactions should occur. For software, this can include components such as business rules, transaction types, administrative functions that need to be performed, systems interfaces, regulatory requirements, process changes, and so on. For consumer products, this might include size, shape, use, features, and other such elements. Generally, the functional requirements are an extension of the “scope” of a project, and define in detail what is to be delivered. It often describes a set of user inputs or actions, the behavior of a system or product, and the desired outputs or results. The way the product should perform in different scenarios is often captured in “Use Cases.”
It is best to keep functional requirements simple, and in business terms. Avoid technical jargon. Often, diagrams, mockups, or pictures can help explain difficult concepts. It is also helpful to categorize the requirements as opposed to creating one big overwhelming list. A broad representative group of those who will be using the product should ideally be involved in creating and validating the requirements.
Also called technical or quality requirements, non-functional requirements focus on the performance levels the product should adhere to (i.e., performance criteria as opposed to specific functionality). Some organizations classify these as “ilities,” such as maintainability, usability, serviceability, reliability, scalability, and others. Some items may not fall under this pattern, such as security, safety, quality, etc. This applies to software, consumer products, or any other kind of deliverable.
To read the full best practice beyond this abstract, you must be a PRISMS subscriber. See your Planview administrator for details.