Soft goal notation of the Chung NFR Framework

Soft goal notation of the Chung NFR Framework

Method “Requirement model for quality attributes”

Description of the method

This method defines a process to identify and specify quality attributes that crosscut requirements and to integrate them into the functional requirements at an early stage of the software development process (Brito et al., 2002):
Proposes a template to specify quality attributes at the requirement stage;
Extends “Use Cases” and sequences diagrams (Jacobson et al., 1992) to specify integration of quality attributes with functional requirements.

Activities of the method

The process model is compatible with UML formalism (Jacobson et al., 1998) and is composed of three important activities (Figure 1.24):
1. Identification of system requirements and selection of quality attributes relevant to the stakeholder’s requirements and application domain from those requirements;
2. Specification of requirements:
• Specify functional requirements by using “Use Case” based approach;
• Describe quality attributes by using templates and specify quality attributes crosscutting functional requirements;
3. Integration of crosscutting quality attributes with functional requirements.
Requirements addressed by this method are: functional and quality. Quality requirements are specified as “quality attributes” and are defined as “global properties of a system, assumptions, constraints or goals of stakeholders”. The quality model used by this method is a template for describing quality attributes. Tools/techniques supporting the method are Use Case approaches (UML model, sequence & class diagrams) for specifying functional requirements and templates for describing quality attributes.

Analysis and discussion of the method

The method “Requirement model for quality attributes” defines a process to identify and specify quality attributes that crosscut requirements including their integration with functional requirements.
The strengths of the method (Araujo et al., 2002 and 2003) and (Brito, 2002) are:
1. It proposes a new concept: “aspect-oriented paradigm », to integrate quality requirements (non functional requirements) with the functional requirements (Araujo et al., 2002 and 2003).
2. This method investigates other approaches such as ATAM (Architecture Tradeoff Analysis Method), composition patterns and goal oriented requirements engineering related to quality attributes and crosscutting concerns.
3. Using a template for describing quality attributes is interesting in the sense that knowledge about these attributes is collected (source, focus, decomposition, influence, requirements describing them, and their contribution to other attributes). However somr drawbacks are identified:
1. it is not specified anywhere how to identify these quality attributes from system and user requirements and how to select them according to the application domain and stakeholders (Djouab and Suryn, 2006).
2. In addition, it is not indicated in the template how quality attributes are derived from quality requirements and how they are retraced to these quality requirements.
3. Finally, It is not specified how ISO/IEC 9126 is used to specify quality characteristics and sub-characteristics.

IESE NFR method

Description of the method

IESE NFR is a systematic experience-based approach which elicits documents and analyses Non-functional Requirements (NFRs) of embedded systems. Its objective is to achieve a minimal and sufficient set of measurable and traceable NFRs (Doerr et al., 2005). IESE NFR has been introduced to palliate the drawbacks of other approaches which lack systematic guidance on how to use them and to end up with measurable NFRs. IESE NFR distinguishes between quality attributes (QAs) and NFRs where QAs are captured in quality models and NFRs are captured in templates. IESE NFR defines QAs as “QA is a non-functional characteristic of a system, user task, system task, or organization. An NFR describes a certain value of a QA that should be achieved in a specific project” (Doerr et al., 2005). The IESE NFR methodology has been used to elicit usability requirements in concert with supplementary requirements related to “Use Case” approach and high level architecture (Kerkow et al., 2003). Kerkow shows how quality aspects contribute to architectural design. The methodology uses a quality model (QM) (Figure 1.27) and quality attribute (QA) types to capture knowledge on NFRs and a template for capturing specific NFRs. In addition,
checklists are used to elicit NFRs in concert with user models, Use Cases and architecture.

Activities of this method

IESE NFR method is organized around stakeholder workshops to select and tailor quality models and to use these models to elicit and document the NFRs. In fact, the method starts by prioritizing the high level QAs most important to the project and by selecting the quality models associated to these QAs. These selected quality models are tailored in workshops to the needs of the project. Checklists and templates are derived from the quality model to be used (in workshops) for the elicitation process. Dependencies between QAs (general and the lowest level) in the quality models are included in the checklists and used to identify NFRs and conflicts among them. The process of IESE NFR is organized around 2 basic steps.
Tailoring the quality model: where the experience based reference model is tailored to the need of the client’s project (Figures 1.26 and 1.27). This process produces checklists and templates for use in the next process. The figures 1.28, 1.39 and 1.30 show examples of the tailoring process for the Tetris game.
Elicitation process: Based upon the previous created artifacts, the different types of activities that formulate the NFRs are defined (organizational, user task, system task and system). These NFRs are consolidated to be analyzed for possible conflicts.
Activities of the elicitation process are:
• Elicit organizational NFRs; elicit NFRs that constrain QAs of the organization;
• Elicit user task NFRs; elicit NFRs that constrain QAs of user tasks;
• Elicit system task NFRs; NFRs that constrain QAs of system tasks;
• Elicit system NFRs; elicit NFRs that constrain QAs of the system and subsystems;
• Consolidate; QAs are analyzed for conflicts and NFRs that constrain different QAs are validated according to dependencies documented within the quality model.
The checklist gives a means to identify these conflicts and a means to solve them. The process is based on the following artifacts: Prioritized questionnaire; user model; system functionality and physical architecture. The figures 1.32, 1.33 and 1.34 show examples of the elicitation process for the Tetris game.

Table des matières

INTRODUCTION
CHAPTER 1 LITERATURE REVIEW
1.1 Introduction
1.2 Quality requirements
1.2.1 Quality requirements and software quality
1.3 Software quality engineering standards
1.3.1 Software quality Requirements and ISO/IEC SQuaRE standard
1.3.2 Standard ISO/IEC 25030 SQuaRE – Software Product Quality Requirements
1.4 Quality requirements management methods
1.4.1 SPACE-UFO Project
1.4.2 MOQARE (Misuse-Oriented QuAlity Requirements Engineering) method
1.4.3 ATAM (Architecture Tradeoff Analysis Method) method
1.4.4 FDAF (Formal Design and Analysis Framework) method
1.4.5 Method “Requirement model for quality attributes”
1.4.6 IESE NFR method
1.4.7 Soft goal notation of the Chung NFR Framework
1.4.8 Prometheus Method to model quality in SPL (Software Product Lines)
1.4.9 Quality models in software packages methodology
1.4.10 Quality specification strategies for embedded software
1.4.11 Method SHEL (Software and HardwarE and Live ware)
1.4.12 BMM (Business Motivation Model)
1.4.13 Synthesis of described methods
1.5 Chapter summary
CHAPTER 2 RESEARCH OBJECTIVES AND METHODOLOGY 
2.1 Introduction
2.2 Research Goal and Objectives
2.3 Research Methodology
2.4 Chapter summary
CHAPTER 3 RESEARCH EXECUTION
3.1 How to apply methods for quality requirements management
3.1.1 Analysis and discussion of applicability of QRs management methods
3.1.2 Conclusion
3.2 Quality requirements management in an industrial environment
3.2.1 Data collection of quality requirements
3.2.2 Performing the data collection process
3.2.3 Analyzing the collected data
3.2.4 Analysis of resulted indicators from industry and academic environments
3.3 Innovative aspects of the proposed research solution: SOQUAREM (SOftware QUAlity Requirements Engineering Method)
3.3.1 Specific features of SOQUAREM method
3.3.2 Meta-Model of SOQUAREM method
3.3.3 The SOQUAREM building process
3.3.4 SOQUAREM process structure
3.4 Conclusion
CHAPTER 4 SOQUAREM: SOFTWARE QUALITY REQUIREMENTS ENGINEERING METHOD
4.1 SOQUAREM method
4.2 SOQUAREM Key concepts
4.2.1 Development of SOQUAREM concepts
4.3 The SOQUAREM process model
4.3.1 Detailed description of the six phases of SOQUAREM process
4.4 CONCLUSION
CHAPTER 5 ILLUSTRATIVE EXAMPLE OF THE BUILDING AUTOMATION SYSTEM CASE
5.1 Development of the example
5.1.1 Presentation of the example
5.1.2 Description of the MSLite system
5.1.3 Specific features of application of SOQUAREM method
5.1.4 Analysis of SOQUAREM process
5.2 Conclusion
CONCLUSION
ANNEX I QUESTIONNAIRE ON QRS OF THE SOFTWARE PRODUCT
ANNEX II QUESTIONNAIRE ON SOQUAREM METHOD
BIBLIOGRAPHY

Télécharger le rapport complet