Towards modelling and reasoning support for early-phase requirements engineering

2002· article· en· 1 572 citations· W2157437711 sur OpenAlex· 10.1109/isre.1997.566873

Pourquoi ce travail est-il dans la base ?

Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.

Affiliation canadienneUne personne signataire a déclaré un établissement canadien. C'est la seule voie dont dispose la base habituelle.

Organisme subventionnaire canadienUn organisme canadien l'a financé. Le travail peut ne porter aucune affiliation canadienne.

Scores machine (provisoires)

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.

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.

Tête enseignante Opus0,108

Tête enseignante GPT0,324

Écart entre enseignants: 0,215 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validation: 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écoule

Résumé

Requirements are usually understood as stating what a system is supposed to do, as apposed to how it should do it. However, understanding the organizational context and rationales (the "Whys") that lead up to systems requirements can be just as important for the ongoing success of the system. Requirements modelling techniques can be used to help deal with the knowledge and reasoning needed in this earlier phase of requirements engineering. However most existing requirements techniques are intended more for the later phase of requirements engineering, which focuses on completeness, consistency, and automated verification of requirements. In contrast, the early phase aims to model and analyze stakeholder interests and how they might be addressed, or compromised, by various system-and-environment alternatives. This paper argues, therefore, that a different kind of modelling and reasoning support is needed for the early phase. An outline of the i* framework is given as an example of a step in this direction. Meeting scheduling is used as a domain example.

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.

La notice

Revue
Thématique: Advanced Software Engineering Methodologies
Domaine: Computer Science
Établissements canadiens: University of Toronto
Organismes subventionnaires: Information Technology Research Centre
Mots-clés: Requirements engineeringRequirements elicitationRequirements managementComputer scienceRequirements analysisNon-functional requirementRequirementSystem requirementsSystems engineeringGoal modelingCompleteness (order theory)Context (archaeology)Software engineeringManagement scienceEngineeringSoftware development
Résumé présent dans OpenAlex: oui
API: /api/v1/works/W2157437711