Faults Discovered, Faults Delivered, etc.) Extensibility (adding features, and carry-forward of customizations at next major version upgrade).Effectiveness (resulting performance in relation to effort).Efficiency (resource consumption for given load).Many categories: most organizations simply maintain a long list of non-functional requirement categories including but not limited to: reusability-ability to (re)use in future systemsĬonstraints of a System: these are characteristics of the pre-existing environment within which the new system or solution must operate, such as: legal and regulatory constraints, available development frameworks, target hardware, knowledge and skill of the development team, time and budget, etc.Įxecution requirements: Qualities a system must have which are observable at run time: security, usability, etc.Įvolution requirements: Qualities a system must have which address the nature and structure of the system and which permit a system to be evolved in the future: scalability, extensibility, etc.ģ. Although the term non-functional requirement has been in use for more than 20 years, there is still no consensus in the requirements engineering community.composability-ability to compose systems from components.
evolvability-ability to change over time and to integrate and use new technologies.modifiability or extensibility-ability to add (unspecified) future functionality.localizability-ability to make adaptations due to regional differences.Development-time Qualities: A subset of non-functional requirements, these are qualities of the system, architecture, documentation, and design which have an impact on the effort, ease, and cost of maintaining and changing the system over time:.quality of service requirements: performance, response time, latency, etc.Run-time Qualities: A subset of non-functional requirements, these are generally qualities which describe how well the functional requirements behave/are perceived when the system is being used:.Qualities of a System: these are characteristics or properties of a system that the stakeholders care about.
Non functional requirements iso#
The categories from the attached sample and template are based on the ISO 25010 Product Quality Model standard, as this ensures that no aspect of the system is missed. It is important to group NFRs in a standard way. Here are some common ways of categorizing requirements: Non-Functional Requirements (NFRs) Contains the list of NFRs and their related acceptance criteria. There are many different ways to categorize non-functional requirements depending on the type of system, project, organization, or preference.
0 kommentar(er)
