Non-functional requirements framework
 | A major contributor to this article appears to have a close connection with its subject. (December 2017) |
 | This article provides insufficient context for those unfamiliar with the subject. (November 2021) |
NFR (Non-Functional Requirements) need a framework for compaction. The analysis begins with softgoals that represent NFR which stakeholders agree upon. Softgoals are goals that are hard to express, but tend to be global qualities of a software system. These could be usability, performance, security and flexibility in a given system. If the team starts collecting them it often finds a great many of them. In order to reduce the number to a manageable quantity, structuring is a valuable approach. There are several frameworks available that are useful as structure.
Structuring Non-functional requirements
[edit]The following frameworks are useful to serve as structure for NFRs:
1. Goal Modelling The finalised softgoals are then usually decomposed and refined to uncover a tree structure of goals and subgoals for e.g. the flexibility softgoal. Once uncovering tree structures, one is bound to find interfering softgoals in different trees, e.g. security goals generally interferes with usability. These softgoal trees now form a softgoal graph structure. The final step in this analysis is to pick some particular leaf softgoals, so that all the root softgoals are satisfied.[1]
2. IVENA[1] - Integrated Approach to Acquisition of NFR The method has integrated a requirement tree. [2]
3. Context of an Organization There are several models to describe the context of an organization such as Business Model Canvas, OrgManle [3], or others [4]. Those models are also a good framework to assign NFRs.
Measuring the Non-functional requirements
[edit]SNAP is the Software Non-functional Assessment Process. While Function Points measure the functional requirements by sizing the data flow through a software application, IFPUG's SNAP measures the non-functional requirements.
The SNAP model consists of four categories and fourteen sub-categories to measure the non-functional requirements. Non-functional requirement are mapped to the relevant sub-categories. Each sub-category is sized, and the size of a requirement is the sum of the sizes of its sub-categories.
The SNAP sizing process is very similar to the Function Point sizing process. Within the application boundary, non-functional requirements are associated with relevant categories and their sub-categories. Using a standardized set of basic criteria, each of the sub-categories is then sized according to its type and complexity; the size of such a requirement is the sum of the sizes of its sub-categories. These sizes are then totaled to give the measure of non-functional size of the software application.
Beta testing of the model shows that SNAP size has a strong correlation with the work effort required to develop the non-functional portion of the software application.
See also
[edit]References
[edit]- ^ SOPHISTEN
[1] Mylopoulos, Chung, and Yu: “From Object-oriented to Goal-oriented Requirements Analysis" Communications of the ACM, January 1999 [CACM.f.doc [1] [2] Götz, Rolf; Scharnweber, Heiko: "IVENA: Integriertes Vorgehen zur Erhebung nichtfunktionaler Anforderungen". https://www.pst.ifi.lmu.de/Lehre/WS0102/architektur/VL1/Ivena.pdf [3] Teich, Irene: Tutorial PlanMan. Working paper Postbauer-Heng, Germany 2005. Available on Demand. [4] Teich, Irene: Context of the organization-Models. Working paper Meschede, Germany 2020. Available on Demand.