Coloration de listevignette|301x301px| Une instance de coloration de liste du graphe biparti complet K 3,27 avec trois couleurs par sommet. Pour tout choix de couleurs des trois sommets centraux, l'un des 27 sommets extérieurs ne peut être coloré, ce qui montre que le nombre chromatique de liste de K 3,27 est au moins quatre. En théorie des graphes, la coloration de liste est une coloration des sommets d'un graphe où la couleur de chaque sommet est restreinte à une liste de couleurs autorisées.
Morphisme de graphesUn morphisme de graphes ou homomorphisme de graphes est une application entre deux graphes (orientés ou non orientés) qui respecte la structure de ces graphes. Autrement dit l'image d'un graphe dans un graphe doit respecter les relations d'adjacence présentes dans . thumb|alt=Un homomorphisme entre deux graphes|Le graphe de gauche se projette dans le graphe de droite, par exemple de cette façon là Si et sont deux graphes dont on note les sommets V(G) et V(H) et les arêtes E(G) et E(H), une application qui envoie les sommets de G sur ceux de H est un morphisme de graphes si : , .
Software requirementsSoftware requirements for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as: A condition or capability needed by a user to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
CographeUn cographe est, en théorie des graphes, un graphe qui peut être généré par complémentation et union disjointe à partir du graphe à un nœud. La plupart des problèmes algorithmiques peuvent être résolus sur cette classe en temps polynomial, et même linaire, du fait de ses propriétés structurelles. Cette famille de graphe a été introduite par plusieurs auteurs indépendamment dans les années 1970 sous divers noms, notamment D*-graphes, hereditary Dacey graphs et 2-parity graphs.
Business requirementsBusiness requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system's end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems. Three main reasons for such discussions: A common practice is to refer to objectives, or expected benefits, as 'business requirements.
Exigence (ingénierie)Une est, dans le domaine de l'ingénierie, un besoin, une nécessité, une attente auquel un produit ou un service doit répondre ou une contrainte qu'il doit satisfaire. L'exigence peut être exprimée par une partie prenante (utilisateur, client, commercial, analyste de marchés, gestionnaire de produits, etc.) ou déterminée par les processus d'ingénierie et en particulier les activités d'études. L'approche commune à tous les domaines d'ingénierie est de définir les besoins, d'envisager des solutions, et de livrer la solution la plus appropriée.
Kempe chainIn mathematics, a Kempe chain is a device used mainly in the study of the four colour theorem. Intuitively, it is a connected chain of points on a graph with alternating colors. Kempe chains were first used by Alfred Kempe in his attempted proof of the four colour theorem. Even though his proof turned out to be incomplete, the method of Kempe chains is crucial to the successful modern proofs (Appel & Haken, Robertson et al., etc.). Furthermore, the method is used in the proof of the five-colour theorem by Percy John Heawood, a weaker form of the four-colour theorem.
Analyse des exigencesEn ingénierie des systèmes et en ingénierie logicielle, l'analyse des exigences comprend les tâches qui ont pour but de déterminer les exigences d'un système nouveau ou à modifier, en prenant en compte le conflit possible entre les exigences de diverses parties prenantes, telles que les utilisateurs. L'analyse des exigences est critique pour le succès d'un projet. Les interviews de parties prenantes sont une méthode communément employée dans l'analyse des exigences.
Tempsthumb|Chronos, dieu du temps de la mythologie grecque, par Ignaz Günther, Bayerisches Nationalmuseum à Munich. vignette|Montre à gousset ancienne Le temps est une notion qui rend compte du changement dans le monde. Le questionnement s'est porté sur sa « nature intime » : propriété fondamentale de l'Univers, ou produit de l'observation intellectuelle et de la perception humaine. La somme des réponses ne suffit pas à dégager un concept satisfaisant du temps.
Ordonnancement dans les systèmes d'exploitationDans les systèmes d'exploitation, l’ordonnanceur est le composant du noyau du système d'exploitation choisissant l'ordre d'exécution des processus sur les processeurs d'un ordinateur. En anglais, l'ordonnanceur est appelé scheduler. Un processus a besoin de la ressource processeur pour exécuter des calculs; il l'abandonne quand se produit une interruption, etc. De nombreux anciens processeurs ne peuvent effectuer qu'un traitement à la fois.
Stable (théorie des graphes)thumb|280px|L'ensemble des sommets en bleu dans ce graphe est un stable maximal du graphe. En théorie des graphes, un stable – appelé aussi ensemble indépendant ou independent set en anglais – est un ensemble de sommets deux à deux non adjacents. La taille d'un stable est égale au nombre de sommets qu'il contient. La taille maximum d'un stable d'un graphe, noté I(G), est un invariant du graphe. Il peut être relié à d'autres invariants, par exemple à la taille de l'ensemble dominant maximum, noté dom(G).
Non-functional requirementIn systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.
