Notice bibliographique
Résumé
KPMG IT Advisory frequently reviews the requirements engineering (RE) process as part of a project review. To assist in these reviews, KPMG uses a project-wide method (PRAM) which contains RE specific questions. However, because this checklist only covers a small set of RE specific aspects and is focused specifically on a waterfall model, reviewers often have to fall back on personal knowledge and experience for a complete review. Based on brainstorm sessions with members of KPMG, we have concluded that this necessity to rely on personal experience often results in time-expensive reviews and uncertainty about the completeness of the assessment. Therefore, the goal of this research is to develop a method that focuses specifically on the assessment of the quality of the RE process. To reach this goal, the following research question is answered: • Which aspects can be used to assess the quality of the RE process for complex software development projects? A research is performed in order to answer this research question. The complete research is divided into two steps: a preliminary research and a main research. The goal of the preliminary research was to develop an initial version of the RE review method. The preliminary research is based on a literature study and on a study of the current approach. The goal of the main research was to test, improve and validate the developed method. Testing of the developed method is done by a case study of two real-life cases. Subsequently, the results of the tests are used to improve the method. Validation of the improved method is done by six members of KPMG, each with a case study of one real-life case. Based on the validation, conclusions are drawn about the performance of the new method and the new method is adapted accordingly. The results show us that it is important that the expectations concerning planning, budget and quality of the solution are realized. Therefore, the chances of not realizing these expectations have to be minimized. This can be done by assessing the performance of the RE process as well as the information in the RE documentation. For the review of the RE process, the following aspects are the most important: the scope of the project has to be clear to all stakeholders, roles and responsibilities has to be clearly communicated, an agreement has to be reached about the cost specification, the solution has to be in alignment with the business model and attention has to be paid to the influence of the solution on the business processes. For the review of the RE documentation, the following aspects are the most important: the planning has to be realistic, de planning should contain the right activities, the cost specification has to be realistic, possible risks should be described, and all requirements has to be specified on a high-level as well as on a detailed-level. The goal of this research is reached. A complete and useful method is developed, with three important benefits in comparison with the current review method: it focuses on assessing the quality of the RE process, it contains aspects that are not present in the current method and it gives examples of aspects where applicable, in order to make the judgment of these aspects easier. The focus of the method is not specifically on iterative processes, but special attention is paid to the aspects that are important in these types of projects.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction machine sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.
Scores du classifieur distillé par catégorie (deux têtes)
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,012 | 0,072 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,001 |
| Bibliométrie | 0,003 | 0,002 |
| Études des sciences et des technologies | 0,001 | 0,001 |
| Communication savante | 0,003 | 0,002 |
| Science ouverte | 0,001 | 0,001 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,002 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».