1. Trang chủ
  2. » Luận Văn - Báo Cáo

Pprentissage automatique applique aux tests logiciels = học máy Áp dụng cho việc phát hiện những mờ Ám ngay tại giai Đoạn thiết kế phần mềm mémoire de master, université nati

68 0 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Apprentissage automatique appliqué à la détection des ambiguïtés dans la phase de spécifications logicielles
Tác giả Lesly Roc
Người hướng dẫn Bruel Geranôn, PhD
Trường học Université Nationale du Vietnam
Chuyên ngành Informatique
Thể loại Mémoire
Năm xuất bản 2023
Thành phố Hanoi
Định dạng
Số trang 68
Dung lượng 1,11 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Cấu trúc

  • CHAPITRE 1 INTRODUCTION (14)
    • 1.3 Objectif de recherche (18)
  • CHAPITRE 2 Revue Littérature (18)
    • 2.2.1 Ils sont importants pour plusieurs raisons (19)
    • 2.4 Étapes de l'ingénierie des exigences (20)
    • 2.5 Les principes de l'Ingénierie des Exigences (21)
      • 2.5.1 Elicitation (21)
    • 2.9 Exigences de Qualités (25)
    • 3.1 Segmentation de phrases (29)
    • 3.2 Analyse syntaxique (30)
    • 3.3 Analyse sémantique (30)
    • 3.4 Modèles linguistiques (30)
    • 5. Technique de rédaction d’exigences logicielles (32)
  • CHAPITRE 3 Méthodologie (37)
  • CHAPITRE 4 Implémentation de la solution (41)
    • 4.8 Flux de fonctionnement de l'application (49)
  • CHAPITRE 5 Evaluation et Analyse Résultats (51)

Nội dung

pprentissage automatique applique aux tests logiciels = Học máy áp dụng cho việc phát hiện những mờ ám ngay tại giai đoạn thiết kế phần mềm. Mémoire de master, Université Nati

INTRODUCTION

Objectif de recherche

The aim of this thesis is to develop a tool that utilizes natural language processing techniques to detect ambiguities in software requirements specification documents To achieve this, we draw inspiration from the triplet approach proposed by Goranon, which focuses on the specification, drafting, and representation of software requirements This method involves writing software requirements in a simple and clear manner using triplets (subject, predicate, object), thereby reducing ambiguity in the requirements document In essence, each software requirement acts as an entity that triggers a system operation on a software object or component.

Revue Littérature

Ils sont importants pour plusieurs raisons

❖ Ils aident à garantir que le système logiciel répond aux besoins des utilisateurs

❖ Ils aident à éviter les changements de conception cỏteux en cours de développement

❖ Ils aident à améliorer la communication entre les utilisateurs, les développeurs et les autres parties prenantes

❖ Ils peuvent être utilisés pour évaluer le système logiciel et garantir sa conformité aux exigences

❖ Ils servent de base pour la conception, le développement et la validation du système ou du produit logiciel [17]

2.3 Le Processus d’ingénierie des Exigences : Analyse et Optimisation

The requirements engineering process, also known as the IE process, is the initial phase of the software development lifecycle It plays a crucial role in shaping the early stages of development by transforming informal stakeholder needs into a preliminary high-level requirements specification, often referred to as the requirements specification Subsequent steps in the process involve progressively refining this specification, ultimately leading to the creation of a comprehensive and detailed requirements document.

Once the initial specifications are created in this process, they are consolidated into the specifications document, which is crucial as it marks the entry point into the later phases of development where detailed specifications are developed This document reflects the agreements and decisions made among stakeholders, and for industry players, it also serves as a contractual document that defines the roles and responsibilities of both clients and providers.

This approach aims to create a clear and structured framework for managing requirements throughout the software development process It promotes effective communication and alignment among stakeholders while ensuring traceability of decisions made at each stage of the process.

Figure 2 : Le processus d’ingénierie des exigences au sein du processus de développement logiciel source[41]

Étapes de l'ingénierie des exigences

Il y a quelques activités auxquelles nous sommes confrontés lorsque nous travaillons avec les exigences Dans le cycle Ingénierie des Exigences, il y a cinq activités principales, à savoir,

1 Recueil des exigences ou Elicitation - C'est le processus d'examen, de documentation et de compréhension des besoins des parties prenantes et des utilisateurs pour la saison En utilisant ces données, nous élicitons ensuite les exigences, procédant à l'analyse et à la négociation des besoins

2 Analyse des besoins et négociation – l'analyse est le processus d'affinement des besoins et des contraintes de l'utilisateur sur la base des informations recueillies et obtenues Ensuite, nous passons à l'activité de documentation

3 Documentation/spécification des exigences – après avoir obtenu le cahier des charges, nous passons à la partie documentation Nous documentons clairement et précisément les besoins et contraintes des utilisateurs

4 Validation des exigences - enfin, dans l'activité de validation, nous insérons que les exigences de la saison sont complètes, concises et claires

Lorsque nous finalisons ces cinq activités, nous les répétons encore et encore jusqu'à ce que nous obtenions un ensemble de documents d'exigences convenus qui sont des spécifications formelles.

Les principes de l'Ingénierie des Exigences

Requirement elicitation is the process of examining, documenting, and understanding users' needs and constraints for a specific season Users require information about the domain, existing systems, regulations, and standards Based on this information, we elicit the requirements The term "elicitation" is preferred over "gathering" because gathering merely involves collecting requirements and placing them into a document, while elicitation emphasizes a deeper understanding of those needs.

In contrast, elicitation is a more intricate process that requires additional effort compared to straightforward requirements gathering During elicitation, you engage with users or clients to uncover their needs and expectations.

● Quels sont leurs objectifs pour le système/produit ?

● Comment les besoins saisonniers s'intègrent-ils dans les besoins de l'entreprise ?

● Comment le produit/système saisonnier doit-il être utilisé de manière régulière ?

Quelles sont les étapes lors de l'élicitation ? ÉTAPE 1 : Sources d'exigences

Identification des intervenants, systèmes existants, documents, concurrents, interfaces, lois et normes ÉTAPE 2 : Définition de la portée du projet

Identifying key objectives, drafting a statement of work, listing deliverables, selecting critical milestones, recognizing constraints, creating an exclusion list, and obtaining stakeholder confirmation are essential steps In Step 3, focus on elicitation tasks to ensure clarity and alignment among all parties involved.

The process involves careful planning, validating the project's feasibility, understanding issues, extracting requirements, seeking innovations, analyzing results, negotiating requirements, and documenting everything in the specifications Step 4 focuses on finalizing the requirements.

Compilation des exigences dans un document, sujet à des modifications ultérieures ; un processus itératif nécessitant l'application judicieuse de techniques adaptées à chaque source d'exigences

The requirements analysis process involves studying, validating, and refining documented requirements gathered during elicitation This entails understanding stakeholder needs through frequent communication to define expectations, resolve conflicts, and document key requirements Solutions may involve various workflow configurations or the implementation of a new system It is crucial to emphasize that elicitation and requirements analysis are interdependent, mutually enhancing each other during the collection, development, and analysis of requirements.

2.5.3- Objectifs de l'analyse des besoins :

1 L'objectif premier de l'analyse des besoins est de comprendre les exigences et les besoins des utilisateurs

2 Lors de la collecte d'exigences, les conflits entre sources diverses sont identifiés et résolus par l'analyse des exigences

3 Négocier les exigences avec les parties prenantes et les utilisateurs, sachant que le système ne peut répondre exactement à toutes les exigences telles qu'elles sont formulées

4 Négocier et hiérarchiser les besoins en tenant compte de l'importance variable des exigences pour les utilisateurs finaux

5 Élaborer sur les exigences pour une documentation détaillée, facilitant le développement, la conception et les tests des développeurs

6 Nous devons classer les exigences en différentes catégories et sous-catégories et répartir ensuite ces exigences dans différents sous-systèmes

7 Nous devons également évaluer les exigences de la qualité qui est souhaitée par l'organisation

8 Enfin, il faut veiller à ne rien manquer d'important

Requirements specification, also known as documentation, involves clearly and coherently recording all system and user requirements in a comprehensive document During the capture phase, requirements are gathered from various sources Analysis and negotiation activities facilitate a deep understanding of these requirements Finally, the official specifications document precisely outlines all user and system needs and constraints.

Méthode de documentation des exigences :

The OREILLES methodology, which stands for "Simple Approach to Requirement Syntax," promotes clear, concise, and comprehensible writing to enhance the workflow of requirements engineering To achieve this, certain principles must be followed, including the use of complete sentences without bullet points, acronyms, or jargon Requirements should include a subject, predicate, and appropriate verbs, utilizing terms like "must" to convey necessity and "may" to indicate optionality Each requirement should effectively explain the expected final outcome of the system.

11 et décrire la qualité attendue, facilitant ainsi la mesure de la mise en œuvre correcte de l'exigence

2.6- Quelques conseils pour les exigences de rédaction :

Vous trouverez ci-dessous quelques conseils qui peuvent vous aider à améliorer votre rédaction pour les exigences

 Utilisez des phrases courtes et significatives en privilégiant la voix active

 Adoptez le point de vue du développeur et du testeur lors de la lecture des exigences pour évaluer leur précision

 Évitez l'utilisation de 'et/ou' pour composer plusieurs exigences Préférez des phrases simples pouvant être testées individuellement

 Maintenez un niveau de cohérence et d'uniformité équivalent dans l'explication des exigences

 Minimisez les répétitions autant que possible pour faciliter la lecture tout en réduisant la maintenance

 Assurez-vous que chaque exigence est traỗable

Caractéristiques d'un cahier des charges :

● Un document d'exigence décrit efficacement toutes les exigences du système à concevoir

● Toutes les exigences décrites dans ce document sont pratiques et vérifiables

● Les entrepreneurs et les fournisseurs signent les contrats sur la base de ce document d'exigences

● Le document d'exigence est une description détaillée des notes prises lors de l'élicitation de l'exigence

● Conforme aux normes IEEE 830 – SRS

Validation is a crucial process that determines whether a system meets client expectations, essentially answering the question: "Are we building the right system?" It involves various testing methods, including black-box, white-box, integration, and unit tests, to assess the system's compliance and ensure it aligns with client requirements Validation occurs after the verification phase.

Verification aims to ensure that the system meets its intended goals without bugs or issues It addresses the question: "Are we building the product correctly?" Verification involves methods such as reviews, walkthroughs, inspections, and desk checks This is a manual process conducted prior to validation.

Différentes techniques peuvent être utilisées pour valider les exigences Ils comprennent :

During the requirements verification process, we ensure that solicitation notes are not overlooked by thoroughly reviewing documents A traceability matrix is created to guarantee that all requirements are considered, justified, and assessed for clarity and quality.

Prototyping involves creating a model or simulation of a system, a widely used technique for validating requirements This approach allows stakeholders and users to identify issues more effectively through their feedback, enhancing the overall development process.

In the test design phase, we complete the testing team and develop functional scenarios linked to each requirement outlined in the specification For non-functional requirements, traceability to the original source is essential to identify any errors or omissions in the specification.

A skilled team conducts a thorough analysis of the requirements, systematically identifying potential issues They engage in discussions about these problems, create a checklist aligned with various standards, and mark items for formal review before moving on to final approval.

Exigences de Qualités

La définition des exigences de qualité est une priorité pour gestionnaires, analystes et chercheurs qui se spécialisent dans le domaine d’ingénierie d’exigences Selon la norme ISO

ISO 9000 defines quality requirements as the ability of a set of intrinsic characteristics to meet specific demands In other words, quality requirements are specific provisions that must be fulfilled for products, services, or processes to align with the expectations and needs of stakeholders This standard serves as a fundamental pillar of quality management across various industries.

13 industriels et organisationnels, soulignant l'importance de définir et de respecter des exigences de qualité claires pour garantir la satisfaction des clients et l'amélioration continue

The Project Management Institute (PMI), a leading authority in project management, offers a unique perspective on quality requirements According to PMI, these requirements are the essential characteristics or criteria that a product, service, or project outcome must possess to meet the needs and expectations of stakeholders This definition emphasizes the connection between quality requirements and project success, highlighting the importance of clearly defining them from the project's outset.

The American Society for Quality (ASQ) emphasizes that quality requirements are specific characteristics of a product or service that meet customer needs and market expectations ASQ highlights the importance of collecting, analyzing, and documenting these requirements to ensure product and service compliance while promoting continuous quality improvement Additionally, Gilb and Graham (1993) propose a set of criteria that a quality software requirements document should meet, focusing primarily on the clarity, unambiguity, and uniqueness of the software requirements The following table outlines a set of quality criteria for software requirements.

Clarté Les exigences doivent être rédigées de manière claire et comprộhensible, ộvitant toute ambiguùtộ

Cohérence Les exigences ne doivent pas entrer en conflit les unes avec les autres et doivent être alignées sur les objectifs du projet

Complétude Toutes les fonctionnalités et contraintes essentielles doivent être correctement spécifiées, laissant peu de place à l'interprétation

Traỗabilitộ Chaque exigence doit ờtre tracộe de maniốre à pouvoir remonter jusqu'à son origine, et inversement

Non-ambiguùtộ Les exigences ne doivent pas prờter à confusion et leur signification doit être indiscutable

Testabilité Les exigences doivent être formulées de manière à permettre une vérification efficace lors des tests

Pertinence Les exigences doivent être directement liées aux besoins du client ou de l'utilisateur, sans ajout inutile

Priorisation Les exigences doivent être hiérarchisées en fonction de leur importance pour permettre une gestion efficace des ressources

Stabilité Les exigences doivent être relativement stables tout au long du projet pour minimiser les changements de dernière minute

Cohérence temporelle Les exigences doivent être cohérentes dans le temps, sans contradictions entre les besoins actuels et futurs

Tableau 1.- Résumé des critères de qualités d’exigences logicielles

Ambiguity in requirements refers to a situation where project specifications, typically outlined in documentation, can be interpreted in multiple ways This creates uncertainty or confusion regarding the true meaning or intent of the stated requirements Such ambiguity may arise from vague terms, ambiguous phrasing, subjective expressions, or a lack of sufficient detail for unambiguous interpretation.

Ambiguous requirements lead to confusion, wasted efforts, and additional revisions This ambiguity arises from two main sources: lack of information and communication errors These errors can be categorized into two distinct types The first category includes errors independent of the writer, which can be resolved without requiring specific domain knowledge.

Grammatical errors, such as those related to the author’s understanding, require a deep comprehension of the subject matter to be effectively corrected For instance, a lack of detail in the writing must be addressed to rectify these errors.

There are two main categories of ambiguities: linguistic ambiguities and software engineering ambiguities Linguistic ambiguities can be identified by any reader with a good command of the language The Manual of Ambiguities outlines various types of linguistic ambiguities In contrast, software engineering ambiguities are contextual and can only be recognized by readers who possess sufficient knowledge of the relevant field.

Ambiguùtộs Type d'ambiguùtộ Sous-type

Ambiguùtộ Analytique Ambiguùtộ de l'Attachement Ambiguùtộ de la

Ambiguùtộ Sộmantique Ambiguùtộ de Portộe

Ambiguùtộ Pragmatique Ambiguùtộ Rộfộrentielle Vaguité-Erreur de Langage-

Ambiguùtộ du Document des Exigences Ambiguùtộ du Domaine d'Application Ambiguùtộ du Domaine du Systốme Ambiguùtộ du Domaine de Dộveloppement

Tableau 2.- Rộsumộ des types d’Ambiguùtộs[26]

Most ambiguities in software engineering stem from the unique characteristics of the field, while those strictly related to language have a relatively minor impact In article [27], the authors identified various types of ambiguities specific to requirements engineering (RE) We have synthesized these two categories of ambiguities—language-related and RE-specific—into Table 2 Detailed descriptions and relevant examples are available in the article.

[26], qui traite de l'ambiguùtộ linguistique, et dans [27], qui se concentre sur l'ambiguùtộ spécifique à l'IE

3.- Le traitement automatique du langage naturel

Natural Language Processing (NLP) encompasses a variety of computational techniques grounded in theory to analyze and represent natural language across multiple linguistic levels The goal is to facilitate human language processing for various tasks and applications The term "levels of linguistic analysis" refers to phonetic, morphological, lexical, syntactic, semantic, discursive, and pragmatic analysis, based on the assumption that humans typically utilize all these levels to produce or comprehend language.

[12] Les systèmes TLN peuvent prendre en charge différents niveaux ou combinaisons

The effectiveness and robustness of a Natural Language Processing (NLP) system are determined by the number of analysis levels it supports Currently, advanced NLP technologies have primarily achieved lexical and syntactic analysis for the ever-evolving English language, with only limited semantic capabilities, aside from a few pioneering efforts in discourse analysis and pragmatics.

Text Mining approaches can be categorized into symbolic and statistical text mining While both types have been studied since the inception of the field in the 1950s through the 1980s, symbolic text mining has predominated Originating from artificial intelligence, symbolic text mining relies on the explicit representation of linguistic facts and associated algorithms, utilizing this knowledge for in-depth analysis of linguistic phenomena Symbolic text mining approaches include rule-based systems and semantic networks, where linguistic knowledge is represented either as facts or production rules in rule-based systems, or as interconnected concepts in semantic networks.

Symbolic natural language processing (NLP) approaches lack the flexibility needed to dynamically adapt to new linguistic phenomena, as they rely on pre-established rules or explicit representations derived from human analysis of well-formed examples This reliance on fixed rules can lead to management challenges, and these symbolic methods often struggle when faced with unfamiliar or ungrammatical inputs.

Pour atteindre ces objectifs, le TLN utilise différentes techniques et outils Voici quelques- uns des concepts clés du TLN pertinents pour l'analyse des exigences logiciels :

Segmentation de phrases

Sentence segmentation in natural language processing (NLP) is the process of breaking down text into individual sentences This task is essential for understanding and processing human language, as it allows for the division of text into smaller units, thereby enhancing analysis and comprehension.

Analyse syntaxique

Syntactic analysis, also known as parsing, aims to understand the grammatical structure of a sentence by determining the relationships between words and groups of words This process helps identify noun phrases, verb phrases, and adjective phrases, while recognizing the dependencies among various elements.

Analyse sémantique

Semantic analysis focuses on the meaning of words and phrases, aiming to understand their significance and access associated knowledge for improved contextual comprehension This process includes the detection of named entities, such as names of people or places, and the recognition of semantic relationships between these entities.

Modèles linguistiques

Language models are statistical tools designed to capture the relationships between words and phrases within a linguistic corpus They can predict the likelihood of specific word sequences, assist in automatic typo correction, and aid in forecasting the next expression during a conversation.

Despite the advancements made, challenges remain in utilizing Natural Language Processing (NLP) for software requirement analysis Key issues include addressing lexical and grammatical ambiguities, understanding idiomatic or informal expressions, and considering the specific context of the application domain.

In conclusion, Natural Language Processing (NLP) holds significant potential for enhancing the efficiency and accuracy of software requirements analysis By employing advanced NLP techniques, such as syntactic and semantic analysis, along with leveraging linguistic models, organizations can gain a better understanding of end-user needs and develop more tailored software solutions Nevertheless, it is crucial to continue exploring new approaches and addressing specific challenges in this field to optimize the application of NLP in software requirements analysis.

4.- Présentation du GPT-3 l’approche LNP utilisé dans le cadre de cette recherche

Launched by the American company OpenAI in 2018, GPT-3 is a deep learning model from the GPT family (Generative Pre-trained Transformer) It represents advanced generative models for natural language processing (NLP), enabling sophisticated applications in understanding and generating human language.

With 175 billion parameters, GPT-3 belongs to the family of large language models (LLMs) It is designed for various tasks, including question-answering, translation, text composition, problem-solving, and application code generation.

Like most large language models (LLMs), GPT-3, along with other members of the GPT family, is built on a transformer architecture Similar to recurrent neural networks (RNNs), transformers are artificial neural networks designed to process sequential data, making them particularly well-suited for natural language processing.

Unlike RNNs, transformers do not process data as a continuous flow while adhering to the order of words in sentences This characteristic allows them to segment processing and parallelize calculations during the learning phase As a result, transformers are significantly faster to train than RNNs.

4.2- Pourquoi le choix du GPT-3 D’open AI

As part of our research project on detecting ambiguities in software requirements, we have opted to utilize the GP3-OpenAI model This choice is both strategic and well-founded for several reasons.

The GP3-OpenAI model is a powerful language model that comprehensively understands the meaning of text It can identify relationships between words and phrases while considering the context in which they are used This capability allows it to detect ambiguities more accurately than traditional models.

Secondly, the GP3-OpenAI model has the ability to learn and improve over time It can be trained on datasets that contain ambiguities, enhancing its performance in detecting such ambiguities.

The GP3-OpenAI model is available as open source, allowing anyone to use it for free This accessibility enables a diverse range of individuals and organizations to leverage the model for ambiguity detection.

In the realm of detecting ambiguities in software requirements, leveraging a powerful language model like GP3-OpenAI proves to be highly beneficial for several reasons.

Software requirements can be lengthy and intricate, making it challenging for humans to read thoroughly and identify all ambiguities Powerful language models can analyze these requirements more quickly and efficiently, enabling them to detect a greater number of ambiguities.

Software requirements are frequently drafted by various individuals, leading to inconsistencies and contradictions that may create ambiguities Powerful language models can detect these inconsistencies and contradictions, enabling their correction.

In conclusion, utilizing the GP3-OpenAI model for detecting ambiguities in software requirements is a wise and justified choice This model can assist in identifying ambiguities more accurately, quickly, and efficiently than human efforts.

Technique de rédaction d’exigences logicielles

Documenting software requirements is crucial for the success of software development projects, as this deliverable is utilized throughout the development process and serves as a baseline for design, implementation, and testing To achieve this, software requirements must be written in a clear and simple format to minimize ambiguity in the software requirements specification document.

Dans ce chapitre, nous explorerons deux techniques fondamentales pour la rédaction des exigences logicielles Ces techniques sont essentielles pour articuler les besoins et les fonctionnalités attendues d'un logiciel

5.1- Les Cas d’utilisation ( Use Cases )

The Use Case approach serves as a comprehensive methodology for capturing software requirements by thoroughly detailing the interactions between the system and its users Each Use Case illustrates a specific scenario where an actor, whether a user or an external system, engages with the software to achieve a defined objective.

Use Cases provide detailed descriptions of user actions, system responses, and expected outcomes based on real scenarios Unlike User Stories, they emphasize the sequences of events and specific actions that lead to a particular result, offering a clearer understanding of the interaction between users and the system.

The strength of Use Cases lies in their ability to provide a comprehensive view of user interactions with the system, offering a deep understanding of the required functionalities By utilizing Use Cases, development teams can better grasp user needs and design features that align with these requirements.

Use cases provide a detailed context for defining software requirements, offering a comprehensive view of usage scenarios They serve as a powerful tool for documenting and communicating the software's functional needs, establishing a solid foundation for the development process.

This expanded version provides more details on Use Cases, emphasizing their role in capturing detailed requirements and their impact on the software development process.

5.2- Les récits d’utilisation (User Stories)

User Stories are fundamental to Agile methodology, serving as concise descriptions that highlight specific functionalities required by the software These narratives illustrate how a user or particular stakeholder intends to interact with the system.

21 atteindre un objectif bien défini Structurées en quelques lignes de langage naturel, les User Stories évitent les termes techniques pour garantir une compréhension facile et directe

User Stories are essential as they prioritize the end user's needs and goals They are designed to capture functional and behavioral requirements in a way that is easily understandable for all team members, including those without advanced technical skills.

This user-centered approach prioritizes the user experience and ensures that the developed features align with the actual needs of users By grounding the development process in these narratives, the creation of features becomes more precise and directly meets the expectations of end users.

5.3- Exemple de rédaction d’un cas d’utilisation

Titre : Réaliser un Achat en Ligne

Permettre à l'utilisateur enregistré d'acheter un produit en ligne de manière sécurisée

L'utilisateur est connecté au système

1- L'utilisateur navigue sur le site et sélectionne un produit

2- Le système affiche les détails du produit et permet à l'utilisateur de l'ajouter au panier 3- L'utilisateur accède à son panier, vérifie les articles et procède à la caisse

4- Le système demande à l'utilisateur de choisir une méthode de paiement

5- L'utilisateur sélectionne une carte de crédit comme méthode de paiement

6- Le système demande les détails de la carte de crédit de l'utilisateur

7- L'utilisateur saisit les détails de la carte et confirme le paiement

8- Le système valide les informations de la carte, effectue la transaction, et confirme la commande

9- L'utilisateur reỗoit une confirmation de commande avec les dộtails et la date de livraison estimée

Si le paiement échoue, le système affiche un message d'erreur et permet à l'utilisateur de réessayer ou de choisir une autre méthode de paiement

Si l'utilisateur annule la commande avant la confirmation du paiement, le système annule la transaction et retourne les articles au panier

La commande est enregistrộe dans le systốme, et l'utilisateur reỗoit une confirmation de commande

This article provides a clear overview of the online purchasing process, highlighting the key players involved, specific actions taken, and the various paths the scenario can take depending on the circumstances.

5.4- Limites des approches, méthodes ou techniques de rédaction d’exigences du logiciel

Requirements engineering is a critical phase in software development that establishes the conditions the software must meet to fulfill the contract between the client and the supplier, as outlined by IEEE 729-1990 This vital step includes various activities such as elicitation, analysis, specification, verification, and validation of requirements, which are essential for the success of software projects, as noted by Wiegers.

Traditional methods of requirement writing, such as the use of use cases and user stories, have significant limitations These approaches, often articulated in natural language, are prone to inherent ambiguities As highlighted by Ambler, there is also a substantial risk of software development project failures due to unimplemented specifications.

The traditional approach to requirement writing, which demands detailed documentation of requirements early in the project lifecycle, often has significant shortcomings, as users' actual needs may emerge later Furthermore, ensuring traceability of requirements throughout the software lifecycle can frequently be problematic.

23 constate Ambler [43], notamment lors des phases de test ó des écarts entre le logiciel final et les spécifications initiales peuvent devenir apparents

In response to ongoing challenges, an innovative approach utilizing triplets and descriptive logic is proposed This method aims to overcome the limitations of conventional techniques by making requirements clearer, reducing inherent ambiguity, and facilitating the automation of the functional size measurement process for software.

Nuseibeh and Easterbrook's work highlights significant gaps in the traditional approach to software development, particularly the lack of specified semantic links between development artifacts, the challenges stakeholders face in producing formal requirements specifications, and the frequent absence of traceability link specifications They propose a new requirements writing technique centered on the use of triplets to address these issues, paving the way for increased automation in measuring the functional size of software and presenting a promising outlook for the future of requirements engineering in software development.

5.5- Spécification des exigences logicielles avec l’approche par triplets

Notre proposition pour la conception d’un outil de détection d’’ambigüité dans le document d’exigences de rédiger les exigences logicielles en utilisant l’approche par triplets [1]

Le sujet représente l'acteur ou l'utilisateur fonctionnel interagissant avec le système logiciel

Méthodologie

3.1- Présentation de la méthodologie adoptée

The focus of our research is on the ambiguity of requirements in the Software Requirements Specification (SRS) document Our primary objective is to develop a tool that detects ambiguity errors during the specification phase To achieve this, we utilize a research methodology known as Design Science Research, proposed by Hevner et al This methodology outlines essential characteristics that a research project in information technology, particularly in computer science, must adhere to, including the creation of innovative techniques or tools that address specific needs, and ensuring that the proposed tool effectively resolves a particular problem, contributing to the advancement of the field.

Our research approach is structured into four key stages The first stage involves describing and analyzing software requirements writing techniques In the second stage, we justify and propose Gérancon's triplet model as a framework for the specification, representation, and drafting of software requirements The third stage focuses on designing a tool that detects ambiguities in specification documents derived from functional requirements expressed in natural language Finally, in the fourth stage, we evaluate our tool using three natural language specification documents, comparing its ambiguity detection results with those identified by human reviewers.

3.1.1- Évaluation des techniques de rédaction des exigences logicielles

In this initial phase, we conduct a comprehensive analysis of the various methods and approaches commonly employed in software requirements writing We explore widely adopted specification practices, along with the tools and standards related to requirements documentation.

The evaluation of software requirements writing techniques highlights significant challenges and urgent needs These issues arise in two primary ways: firstly, automation tools face various limitations and constraints; secondly, commonly used methods and techniques for drafting software specifications lack the technical details necessary to enhance the automation of the requirements evaluation process.

Improving software requirement writing techniques is crucial due to inherent weaknesses identified by researchers like Wiegers and Beatty These weaknesses include inconsistency, ambiguity, and non-atomicity of requirements, which often lead to conflicts, multiple interpretations, and an inability to clearly express unique needs Additionally, Trudel and Boisvert highlight that many software requirements in the industry are either unhelpful—failing to contribute to business value—or unusable, underscoring the need for enhanced clarity and precision in requirement documentation.

Many software requirements are often ambiguous or incomplete, leading to their underutilization, particularly when they are deemed unnecessary This indicates that a significant portion of industrial software requirements lacks relevance for consumers or clients, resulting in limited usage Therefore, it is crucial to enhance the existing approaches to drafting software requirements to better align them with user needs.

In summary, enhancing software requirement writing techniques is crucial for addressing issues of inconsistency, ambiguity, and non-atomicity in requirements, while ensuring their relevance and usefulness for stakeholders.

3.1.2- Choix de la technique par triplets pour la conception de notre outil

The recommended method for simplifying software requirement writing is the triplet approach, initially proposed by Gerano This method structures software requirements into triplets, where each triplet consists of a subject (actor), a predicate (scenario or action), and an object (software component) The primary goal of this approach is to enable a concise expression of user needs while eliminating unnecessary details, thereby enhancing the clarity of requirements Additionally, this approach facilitates the automation of processing software requirements, allowing for more efficient measurement of software TF from natural language specifications Ultimately, the triplet approach complements traditional methods such as Use Cases and User Stories, providing a more effective strategy for writing and automating software requirements.

3.1.3- Conception d'un outil basé sur l'approche par triplet

Based on a triplet approach, we have developed an innovative tool featuring a simple and clear user interface This user-friendly interface enables users, particularly analysts and software requirement writers, to work intuitively Our tool incorporates advanced natural language processing (NLP) techniques to analyze specifications and automatically identify any potential ambiguities.

The primary goal of this tool is to streamline the writing of requirements while enhancing the quality of software specifications By automating the detection of ambiguities, it helps ensure that requirements are clearer, more consistent, and free from contradictions.

27 l'interface utilisateur conviviale favorise une utilisation efficace de l'outil par les parties prenantes impliquées dans le processus de spécification des exigences

This combination of a triplet approach, integration of NLP techniques, and an intuitive user interface provides a comprehensive solution for drafting, clarifying, and automating software requirements It also enhances the reliability of measuring software TF from natural language specifications Ultimately, our enriched approach effectively addresses the challenges of writing and automating software requirements while facilitating collaboration among teams involved in the software development process.

In the fourth step of our process, we conducted a thorough evaluation of our tool by utilizing three software requirements specification documents written in natural language This critical phase aimed to compare the results generated by our tool with those obtained from manual ambiguity detection performed by human experts in the specification documents.

To achieve this, we submitted the documents to our system to test its ability to identify and report potential ambiguities The results obtained were meticulously analyzed and compared with human detections, allowing us to evaluate the effectiveness and accuracy of our tool in detecting ambiguities in specification documents.

L'évaluation de l'outil s'est déroulée en plusieurs étapes, notamment :

 Prétraitement des Documents : Tous les documents, y compris ceux provenant d'Internet, ont été prétraités pour éliminer les informations sensibles ou redondantes

 Analyse Automatisée : Chaque jeu de données a été soumis à l'outil "Ambiguity Finder" pour une analyse automatisộe de la dộtection des ambiguùtộs

The tool was assessed using a custom dataset specifically designed for evaluation purposes This approach enabled the verification of its ability to detect deliberately inserted ambiguities.

The evaluation results, based on the aforementioned metrics, have been documented for each dataset These findings will be thoroughly discussed in the results summary and the report, enabling conclusions to be drawn regarding the effectiveness of the Ambiguity Finder tool in detecting ambiguities in software requirements documents.

Implémentation de la solution

Flux de fonctionnement de l'application

Our architecture unfolds in three distinct stages to accurately detect textual ambiguities The first phase establishes a seamless user interface and initiates communication with the OpenAI API Next, the second phase incorporates syntactic analysis using Spacy to extract key triplets (subject-predicate-object) Finally, the third phase harnesses the power of ChatGPT to refine the analysis by generating contextual responses Each stage is meticulously orchestrated, creating a systematic approach for advanced and effective ambiguity detection.

Phase 1 : Interface Utilisateur et Communication avec OpenAI API

Description : La première étape de notre architecture est l'interface utilisateur créée avec

Streamlit Cette interface permet à l'utilisateur d'interagir avec l'outil de détection d'ambiguùtộ

Rôle : L'interface utilisateur recueille les données textuelles à analyser

Once the user submits text through the interface, our system interacts with the OpenAI API This interaction is essential for leveraging the advanced language processing capabilities of GPT-3.

Rôle : L'API OpenAI est sollicitée pour générer des réponses basées sur le texte d'entrée 3- Fonction Main :

Description : La fonction principale coordonne le flux d'exécution global du programme

Elle gère la réception des données de l'interface utilisateur, la communication avec l'API OpenAI, et l'orchestration de toutes les étapes du processus

Rôle : La Fonction Main agit comme le cerveau de l'application, guidant le traitement des données à travers les différentes phases

Phase 2 : Analyse Syntaxique et Fonctions Utilitaires

Description : L'analyse syntaxique avec Spacy est intégrée pour comprendre la structure grammaticale des phrases Elle joue un rôle clé dans la détection du triplet (Sujet-Prédicat- Objet)

Rôle : Spacy est utilisé pour analyser les relations grammaticales entre les mots et extraire les entités pertinentes

Description : Les fonctions utilitaires, telles que la génération de couleurs aléatoires et la comptabilisation des phrases, ajoutent des fonctionnalités supplémentaires à l'outil

Rôle : Ces fonctions améliorent l'expérience utilisateur et fournissent des informations supplémentaires sur le texte analysé

Phase 3 : Interaction entre le Triplet et ChatGPT

Description : Intégrez ChatGPT dans le schéma C'est une étape cruciale ó le texte, préalablement analysé par Spacy, est envoyé à ChatGPT pour une analyse plus approfondie

Rôle : ChatGPT génère des réponses basées sur le contexte du triplet, aidant ainsi à détecter les ambiguùtộs

2- Interaction entre le Triplet et ChatGPT :

Description : Ajoutez des flèches représentant le flux de données entre la détection du triplet par Spacy et l'utilisation de ChatGPT pour l'analyse d'ambiguùtộ

Rôle : Cette interaction illustre comment les résultats de l'analyse syntaxique influent sur la génération de réponses par ChatGPT.

Evaluation et Analyse Résultats

5.1- Présentation de l'outil logiciel "The Roc Ambiguity Detect"

It is now clear that natural language requirements often lead to ambiguity Therefore, a preliminary step in processing the software requirements specification (SRS) document is essential The primary goal of this process is to identify ambiguous phrases within the SRS and enhance users' understanding of their ambiguous nature This identification allows for corrections, ultimately improving the overall quality of the SRS In this chapter, we will delve deeper into the methodological approach we adopted to achieve our ambitious goal of detecting ambiguities in software requirements, utilizing our tool named "The Roc Ambiguity Detect." This section is crucial for understanding the detailed research and development mission we undertook.

The system features a user-friendly interface developed with Streamlit, a Python library known for simplifying web application creation Designed to provide a smooth and intuitive experience, the interface allows users to easily upload text files, whether they are documents, reports, or other relevant textual content.

Upon uploading a file, the system conducts a thorough analysis to detect and identify potential ambiguities within the text The user-friendly interface is a significant advantage, designed to make the ambiguity analysis process accessible to all users, regardless of their technical expertise This means that professionals from various fields, whether linguistic experts or individuals aiming to enhance the clarity of their documents, can benefit from this tool.

The "Roc Ambiguity Detection" tool is designed with specific goals to enhance the quality and clarity of software specification documents Its primary objectives include identifying ambiguous language, improving communication among stakeholders, and ensuring that requirements are clearly understood and accurately implemented.

The primary goal of "The Roc Ambiguity Detect" is to offer an automated solution for detecting ambiguities in software specification documents It aims to identify areas of text that are ambiguous or open to multiple interpretations, which can lead to misunderstandings or errors in software development.

By identifying ambiguities, the tool enhances the understanding of software specifications among stakeholders, including developers, testers, and clients It clarifies the language used in documentation, helping to minimize the risks of misunderstandings and incorrect interpretations.

5.3.3- Augmentation de la Qualité des Spécifications

Another key objective is to enhance the overall quality of software specifications by eliminating ambiguities Clearer and better-defined specifications facilitate the design, development, and testing of software, which can lead to a reduction in errors and delays.

5.3.4- Gain de Temps et d'Efforts

En identifiant les ambiguùtộs de maniốre automatisộe, l'outil " The Roc Ambiguity Detect " vise à économiser du temps et des efforts précieux pour les équipes de développement Plutôt

40 que de dépendre d'examens manuels intensifs des spécifications, les équipes peuvent se concentrer sur des zones identifiées comme potentiellement problématiques

5.3.5- Support pour la Conformité aux Normes

In various sectors, particularly in the security industry, adherence to strict standards is crucial The tool "The Roc Ambiguity Detect" assists in ensuring that software specifications meet compliance requirements by identifying and rectifying ambiguities that could lead to compliance issues.

5.4- Problèmes Résolus par " The Roc Ambiguity Detect "

L'outil " The Roc Ambiguity Detect " s'attaque à plusieurs problèmes courants dans la dộtection des ambiguùtộs dans les documents de spộcifications logiciels, notamment :

Les spécifications logicielles peuvent contenir des termes ambigus, des phrases mal construites ou des formulations imprécises “ The Roc Ambiguity Detect” identifie ces ambiguùtộs linguistiques et les signale

Les documents de spécifications peuvent être sujets à des interprétations multiples par différentes personnes L'outil vise à aligner l'interprétation des spécifications entre les membres de l'équipe

Les incohérences dans les spécifications, telles que des informations contradictoires, sont identifiées par l'outil pour garantir que toutes les parties des spécifications sont cohérentes entre elles

The tool provides a robust set of features designed to streamline the detection and management of ambiguities in software specification documents Its key functionalities include advanced analysis capabilities, user-friendly interfaces, and efficient tracking systems, all aimed at enhancing clarity and precision in software development processes.

5.5.1- Importer un Document ou Écrire un Texte

Our user-friendly interface features a file browsing button that allows you to easily select the requirements document for ambiguity detection, along with a text area where you can input the text you wish to analyze This enables you to work on the relevant document with ease.

After uploading the document or entering the text, simply click the "Analyze Ambiguities" button Our powerful system will then analyze the text for potential ambiguities.

Once the analysis is complete, the detected ambiguities are presented to you in an interactive format Each ambiguity is highlighted with a color corresponding to its type, greatly enhancing the visualization and understanding of the issues.

Vous avez la possibilitộ de sộlectionner n'importe quelle des ambiguùtộs dộtectộes dans la liste En cliquant sur une ambiguùtộ spộcifique, vous accộdez à des dộtails importants pour la clarification

The details regarding each identified ambiguity are clearly presented, including the type of ambiguity detected and suggestions for clarification This provides you with all the necessary information to implement effective corrective actions.

Dans cette section, nous allons explorer en détail comment nous avons évalué l'efficacité et les performances de notre outil, connu sous le nom de “ The Roc Ambiguity Detect”

5.6.1- Présentation des résultats Obtenu des deux méthodes utilisées

In this section, we present the results derived from applying two distinct evaluation methods for our tool The first method involves a manual analysis conducted by a software specifications expert who reviews documents to identify ambiguities The second method utilizes an automated analysis, where our specialized system examines the same documents for ambiguities This dual approach enables a meaningful comparison between human performance and that of our tool The results at the end of this section will provide insights into the effectiveness of our application in detecting ambiguities, highlighting its potential advantages in the field of software specifications.

The primary data collection for this project focused on Software Requirements Specifications (SRS), marking an initial step in the automated detection of ambiguous requirements within SRS documents written in both French and English A meticulous selection of three SRS documents was undertaken, each sourced from distinct software development projects found online Among these, one document was written in French, another in English, while the third was crafted by our team according to criteria established within the triplet approach.

Ngày đăng: 07/03/2025, 00:33

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
1- B. Gộranỗon ; S. Trudel, R.Nkambou, S. Robert. ‘’Software Functional Sizing Automation from Requirements Written as Triplets’’ .In : International Conference on Software Engineering Advances, Barcelona, Spain, 16, 23–29,(2021)(visité le 28/09/2023) Sách, tạp chí
Tiêu đề: Software Functional Sizing Automation from Requirements Written as Triplets
Tác giả: B. Gộranỗon, S. Trudel, R.Nkambou, S. Robert
Nhà XB: International Conference on Software Engineering Advances
Năm: 2021
2- Benoợt Lebeaupin. ‘’Vers un langage de haut niveau pour une ingộnierie des exigences agile dans le domaine des systèmes embarqués avioniques’’.In : https://theses.hal.science/tel-01761690 , (2018) )(visité le 28/09/2023) Sách, tạp chí
Tiêu đề: Vers un langage de haut niveau pour une ingénierie des exigences agile dans le domaine des systèmes embarqués avioniques
Tác giả: Benoît Lebeaupin
Năm: 2018
3- Nuseibeh, B. and S. Easterbrook. ‘’Requirements Engineering : A Roadmap. In The Future of Software Engineering ‘’. In : International Conference on software Engineering at Limerick, Ireland . (2000)( visité le 28/09/2023) Sách, tạp chí
Tiêu đề: Requirements Engineering : A Roadmap
Tác giả: B. Nuseibeh, S. Easterbrook
Nhà XB: International Conference on Software Engineering
Năm: 2000
4- Berry, D. M., Kamsties, E., & Krieger, M. M. 2003. ‘’From contract drafting to software spécification: Linguistic sources of ambiguity’’. In :Technical Report, University of Waterloo,Waterloo,Canada.http://se.uwaterloo.ca/~dberry/handbook/ambiguityHandbook.pdf (2003)( visité le 29/09/2023) Sách, tạp chí
Tiêu đề: From contract drafting to software spécification: Linguistic sources of ambiguity
Tác giả: D. M. Berry, E. Kamsties, M. M. Krieger
Nhà XB: Technical Report, University of Waterloo
Năm: 2003
5- Anuar, U., S. Ahmad, and N.A. Emran. ‘’A Simplified Systematic Literature Review: Improving Software Requirements Specifications Quality With Boilerplates’’.In : 9 th Malaysien Software Engineering Conference (MySEC), 2015. IEEE. (Visité le 30/09/2023) Sách, tạp chí
Tiêu đề: A Simplified Systematic Literature Review: Improving Software Requirements Specifications Quality With Boilerplates
Tác giả: U. Anuar, S. Ahmad, N.A. Emran
Nhà XB: IEEE
Năm: 2015
6- Soares, H.A. and R.S. Moura. ‘’A methodology to guide writing Software Requirement Specification document’’. In : Computing Conference (CLEI), 2015 Latin American.2015. IEEE. (Visité le 30/09/2023) Sách, tạp chí
Tiêu đề: A methodology to guide writing Software Requirement Specification document
Tác giả: H.A. Soares, R.S. Moura
Nhà XB: IEEE
Năm: 2015
7- Takoshima, A. and M. Aoyama. ‘’Assessing the Quality of Software Requirements Specifications for Automotive Software Systems’’. In : Software Engineering Conference (APSEC), 2015 Asia Pacific. 2015. IEEE. (Visité le 30/09/2023) Sách, tạp chí
Tiêu đề: Assessing the Quality of Software Requirements Specifications for Automotive Software Systems
Tác giả: A. Takoshima, M. Aoyama
Nhà XB: IEEE
Năm: 2015
8- Umber, A. and I.S. Bajwa. ‘’Minimizing ambiguity in natural language software requirements specification’’. In :Sixth International Conference on Digital Information Management (ICDIM). 2011.IEEE(Visité le 01/10/2023) Sách, tạp chí
Tiêu đề: Minimizing ambiguity in natural language software requirements specification
Tác giả: A. Umber, I.S. Bajwa
Nhà XB: IEEE
Năm: 2011
10- Nigam, A., Nigam, B., Bhaisare, C., & Arya, N. ‘’Classifying The Bugs Using Multi- Class Semi Supervised Support Vector Machine’’. In : International Conference on Pattern Recognition, Informatics and Medical Engineering (PRIME),. 2012. IEEE(Visité le 01/10/2023) Sách, tạp chí
Tiêu đề: Classifying The Bugs Using Multi- Class Semi Supervised Support Vector Machine
Tác giả: A. Nigam, B. Nigam, C. Bhaisare, N. Arya
Nhà XB: IEEE
Năm: 2012
11- E. D. Liddy, "Natural Language Processing," In : Encyclopedia of Library and Information Science, , 2nd ed. New York : Marcel Decker, Inc., 2001. (Visité le 30/09/2023) Sách, tạp chí
Tiêu đề: Natural Language Processing
Tác giả: E. D. Liddy
Nhà XB: Marcel Decker, Inc.
Năm: 2001
12- G. G. Chowdhury, "Natural language processing," Annual review of information science and technology, vol. 37, pp. 51-89, 2003. (Visité le 30/09/2023) Sách, tạp chí
Tiêu đề: Natural language processing
14- P. M. Nadkarni, L. Ohno-Machado, and W. W. Chapman, ‘’Natural language processing: an introduction’’. In : Journal of the American Medical Informatics Association, vol. 18, pp. 544-551, 2011. (Visité le 01/10/2023) Sách, tạp chí
Tiêu đề: Natural language processing: an introduction
Tác giả: P. M. Nadkarni, L. Ohno-Machado, W. W. Chapman
Nhà XB: Journal of the American Medical Informatics Association
Năm: 2011
15- IEEE. ‘’ISO/IEC/IEEE 29148:2018 - Software and Systems engineering - Life cycle processes-Requirementsengineering ‘’.In : https://www.iso.org/standard/72089.html.2018(Visité le 01/10/2023) Sách, tạp chí
Tiêu đề: ISO/IEC/IEEE 29148:2018 - Software and Systems engineering - Life cycle processes-Requirements engineering
Tác giả: IEEE
Năm: 2018
16- IEEE.‘’Software Engineering Standards Committee’’In : https://ieeexplore.ieee.org. (2010). (Visité le 01/10/2023) Sách, tạp chí
Tiêu đề: Software Engineering Standards Committee
Tác giả: IEEE
Nhà XB: IEEE
Năm: 2010
17- IEEE Std 830-2010. ‘’IEEE Recommended Practice for Software Requirements Specifications’’ In : www.math.uaa.alaska.edu.(2010) (Visité le 01/10/2023) Sách, tạp chí
Tiêu đề: ’IEEE Recommended Practice for Software Requirements Specifications
18- Éric Chaumette. ‘’Caractérisation des problèmes conjoints de détection et d’estimation’’. In :https://theses.hal.science/tel-01010450 (2014). (Visité le 02/10/2023) Sách, tạp chí
Tiêu đề: Caractérisation des problèmes conjoints de détection et d’estimation
Tác giả: Éric Chaumette
Năm: 2014
19- IEEE Std 830-2010. ‘’IEEE Recommended Practice for Software Requirements Specifications’’ . In : www.math.uaa.alaska.edu.(2010).(Visité le 02/10/2023) Sách, tạp chí
Tiêu đề: ’IEEE Recommended Practice for Software Requirements Specifications
Tác giả: IEEE Std 830-2010. ‘’IEEE Recommended Practice for Software Requirements Specifications’’ . In : www.math.uaa.alaska.edu
Năm: 2010
20- Davis, A. M. ‘’Software requirements : Objects, functions, and states’’ (p.14).In : https://dl.acm.org/doi/book/10.5555/113586.(1993) .(Visité le 02/10/2023) Sách, tạp chí
Tiêu đề: Software requirements : Objects, functions, and states
Tác giả: A. M. Davis
Năm: 1993
21- Carlson N, Laplante P. ‘’The NASA automated requirements measurement tool : a reconstruction’’. In : Innovations System Software Engineering. (2014) (Visité le 05/10/2023) Sách, tạp chí
Tiêu đề: The NASA automated requirements measurement tool : a reconstruction
Tác giả: Carlson N, Laplante P
Nhà XB: Innovations System Software Engineering
Năm: 2014
22- Hussain I, Ormandjieva O, Kosseim L. ‘’Automatic quality assessment of SRS text by means of a decision-tree-based text classifier. Proceedings’’. In : International Conference on Quality Software. (Qsic) (2007). (Visité le 05/10/2023) Sách, tạp chí
Tiêu đề: Automatic quality assessment of SRS text by means of a decision-tree-based text classifier
Tác giả: Hussain I, Ormandjieva O, Kosseim L
Nhà XB: International Conference on Quality Software
Năm: 2007

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm