Ver discusiones, estadísticas y autor per fi les de esta publicación en: https://www.researchgate.

net/publication/221561530

Una ontología requisitos de software.

papel Conferencia · Enero de 2006

Fuente: DBLP

CITACIONES LEE

6 365

2 autores:

Ricardo de Almeida Falbo

Instituto Federal de Espírito Santo (IFES) Universidad Federal de Espírito Santo

26 PUBLICACIONES     181 CITACIONES     172 PUBLICACIONES     1661 CITACIONES    

Ver ficha Ver ficha

Algunos de los autores de esta publicación están también trabajando en estos proyectos relacionados:

Armonización de normas Ver proyecto

Gestión del Conocimiento en Pruebas de Software Ver proyecto Julio César Nardi

Después de todo el contenido de esta página fue subido por Ricardo de Almeida Falbo el 17 de marzo de 2014. El usuario ha solicitado la

mejora de la descargado fi l.
 Una ontología Requisitos de software

Julio César Nardi, Ricardo de Almeida Falbo

Master en Ciencias de la Computación de la Universidad Federal de Espírito Santo, Vitória - ES - Brasil

julionardi@yahoo.com.br , falbo@inf.ufes.br

Abstracto. Herramienta de software de integración en entornos de desarrollo (SDE) es un problema complejo.

Una forma de mejorar la integración de herramientas es la construcción de ellos compartiendo una
conceptualización común, a cargo de las ontologías. Este documento presenta los requisitos de software a la
ontología desarrollada sirve de base para el desarrollo de herramientas para apoyar los requisitos en el proceso
de ingeniería SDE ODE (entorno de desarrollo de software basado en ontologías). Dado que en el contexto de las
ontologías de dominio Varios de ingeniería de software proyecto de ODE se desarrollaron, los requisitos de
software ontología se construyó integrada a ellos, la reutilización de las conceptualizaciones previamente
establecidos.

1 introducción

Obtener los requisitos correctos para un proyecto de software es la parte más importante y difícil del proceso
de software. Una deficiencia en los requisitos de tratamiento ha sido identificado como la causa principal del
fracaso de los proyectos de software [1]. En este contexto, el proceso de Ingeniería de Requisitos (RE) se
vuelve importante, así como soporte automatizado para él.

Según Kotonya y Sommerville [2], el proceso de ER es sistemática y abarca las actividades de elicitación, el
análisis y la negociación, documentación, validación y gestión de requisitos. Para los requisitos de ingenieros,
tratando de especificar los requisitos dentro de los plazos y presupuestos establecidos, la aplicación de métodos
y herramientas se considera crucial para el éxito. Sin embargo, a menudo interfieren herramientas para llevar a
cabo las actividades de la sala de emergencias en lugar de apoyarlos. [1] Creemos que para ser eficaz, este tipo
de herramientas debe estar construido con el apoyo de una comprensión consenso de los elementos que
intervienen en el proceso de RE.

Considerando que las necesidades son el centro del proceso de ER, es interesante tener una
comprensión clara de lo que es ser un requisito y cómo se relaciona con otros elementos del proceso de
software. Como resultado de esta comprensión, se puede construir herramientas para apoyar el proceso de
RE que son más ampliamente utilizable,
ya que estos se basan en las definiciones
requisitos de dominio compartidos.
Con el fin de establecer un concepto básico sobre los requisitos, ontología desarrollada requisitos de
software que se utilizará como base para la construcción de herramientas para apoyar el proceso de RE en
el entorno de desarrollo de software (ADS) (ODE Entorno de desarrollo basado en ontologías) de software [ 3].
Como su nombre lo indica, ODE tiene su razonamiento basado en la ontología, en el supuesto de que si las
herramientas son un ADS
construidos en base a las ontologías, la integración de los mismos se facilita debido a que los conceptos
involucrados están bien definidos. Las ontologías se utilizan en ODE, entre otros, para estructurar el medio
ambiente y su gestión del conocimiento infraestructura y para establecer una forma estándar de
comunicación entre los agentes (humanos y software) en el medio ambiente [3]. Ontologías sirven para este
propósito, en el que definen un vocabulario representación que captura los conceptos y las relaciones de un
dominio y un conjunto de axiomas que restringen su interpretación [4].

Este trabajo presenta la ontología Requisitos de software desarrollado para formalizar el conocimiento de
los requisitos de dominio, sobre todo, para apoyar el desarrollo de herramientas para la EDO. Esta ontología
se define tratar de seguir el criterio de mínimos compromisos ontológicos, por lo que puede volver a utilizar
este conocimiento de diversas maneras en el medio ambiente, como por ejemplo en la comunicación entre
las personas y el medio ambiente, entre los agentes de software que actúan sobre el medio ambiente, la
construcción y la integración herramientas, Ingeniería de Requisitos aprendizaje en el medio ambiente, etc.
Además, dado que varias ontologías se han construido en el contexto del proyecto ODE, tratamos de volver
a utilizar siempre los conceptos previamente establecidos,

Este trabajo se organiza como sigue: en la sección 2 discute brevemente algunos aspectos de la
Ingeniería de Requisitos y ontologías, incluyendo el método de construcción ontología utilizado en este
trabajo; Sección 3 presenta los requisitos ontología desarrollada; Sección 4 trata de trabajos relacionados; y
en la sección 5 se tejen algunas consideraciones finales.

2 Requisitos de software y ontologías

Los Ingeniería de Requisitos (RE) es el sub-campo de la ingeniería de software que se ocupa del proceso de
definición de los requisitos de software. Este proceso es sistemático y abarca diversas actividades,
tales como elicitación, el análisis y la negociación,
requisitos de documentación, validación y gestión [2].
Requisitos de software son declaraciones que expresan las necesidades del cliente, que afectan a la
calidad del software [5], o especificaciones de los servicios que el sistema debe proporcionar, las limitaciones
en el sistema y el conocimiento necesarios para desarrollarla [2]. Una vez capturados, los requisitos de
software deben ser modelados, documentadas, validadas y controladas. En este proceso, las propiedades de
un requisito y las relaciones con los otros elementos del proceso de software se definen y cambian. Por lo
tanto, la definición y la comprensión de las propiedades y relaciones en torno a un requisito es esencial en la
conducción del proceso de IR.

Los requisitos pueden ser clasificados de acuerdo a algún tipo de categorización, que puede ser ajustado
de acuerdo a las prácticas de cada organización de software. En general, se clasifican como: funcional
(representa lo que debe hacer el sistema, sus funciones, y puede ser dividido en esencial, deseable y
superfluo) y no funcionales (que representa los atributos del sistema como el software de hecho, incluyendo
la mantenibilidad, eficiencia, etc. ).
 Sobre un requisito es interesante saber, sin embargo, su origen, las partes interesadas ( las partes interesadas) y
los responsables del mismo. Con estos elementos, el análisis de la actividad y el comercio es más fácil, ya que es
posible identificar los implicados y también el punto de partida de un requisito de [2].

En el centro de la actividad de gestión de requisitos - además del control de cambios y la versión de un

requisito y el seguimiento de su estado - es la trazabilidad, es decir, la capacidad de seguir la vida de un
requisito en ambas direcciones del proceso software y durante todo el ciclo de vida. Los requisitos de
trazabilidad sólo es posible si existen vínculos explícitos entre los requisitos y demás elementos del proceso
de software. Por lo tanto, la identificación de los requisitos de composición, las dependencias entre los
requisitos, los requisitos en conflicto, la fuente de los requisitos y su interés además de lo cual el dispositivo
de identificación (documento, diagrama, etc.) producen durante un proceso de software requisito se trata, es
de fundamental importancia para la trazabilidad se puede implementar [2] [6].

Los requisitos provocados y analizados deben ser documentados. En la actividad de documentación, un

Documento de Requisitos de Software Especificación (DERS) normalmente se genera, que contiene los
requisitos de software de un proyecto en particular. Hay varios modelos de DERS y cada organización puede
definir su propio modelo de acuerdo a sus necesidades. Cualquiera que sea su forma, la DERS es uno de los
artefactos más importantes del proceso de software, ya que es la base de casi todas las actividades de
construcción posteriores. Por lo tanto, es esencial para evaluar la calidad de una DERS. Para tales
características de calidad deben ser identificados y métricas deben ser establecidos para evaluar la calidad
de DERS.

La breve declaración anterior, es posible ver la complejidad del proceso de ER. Dada esta complejidad,
construir herramientas de apoyo a las actividades de este proceso es esencial para la aplicación efectiva.
Idealmente ser ampliamente utilizable, tales herramientas deben ser construidos en base a sólidos, plantillas
de consenso. En este contexto, las ontologías son potencialmente útiles.

Una ontología define un vocabulario específico usado para describir una determinada realidad, además
de un conjunto de decisiones explícitas, establecer con precisión el significado previsto en el vocabulario.
Una ontología implica entonces un vocabulario representación que captura los conceptos, relaciones y
propiedades en algún dominio, y un conjunto de axiomas que restringen su interpretación [4]. Las ontologías
se han hecho populares, en gran parte debido a que tienen el objetivo de promover un entendimiento común
y compartido de un dominio que se puede comunicar entre personas y sistemas de aplicación.

Como cualquier artefacto de ingeniería de software, ontologías tienen que ser construidos según los
métodos y técnicas adecuadas. Para desarrollar los requisitos de software ontología, se adoptó el método
racional ( S ystematic la nfoque de
B u yo lding la ntologies) [ 7] [8]. Wise define un proceso para la construcción de ontologías, cuyas actividades
principales son: (i) identificar la especificación de propósito y requisitos, que tiene como objetivo identificar los
problemas que la ontología debe ser capaz de responder a cuestiones jurisdiccionales (), (ii) la captura de la
ontología, el cual tiene como objetivo captar los conceptos, relaciones, propiedades y restricciones relevantes
sobre el dominio en cuestión; y (iii) la formalización, que trata de escribir los axiomas de la ontología en un
lenguaje formal (en este trabajo, se optó por la lógica de primer orden).
Junto a todas estas actividades, existen las siguientes actividades: (iv) la integración con las ontologías
existentes, que pretende volver a utilizar los conceptos existentes e integrar el desarrollo de ontologías a una
red más amplia ontologías; (V) Evaluación de la ontología, que, entre otros, es evaluar si la ontología es
capaz de responder a la cuestión de la competencia; y (vi) la documentación de la ontología, cuyo objetivo es
registrar el desarrollo de la ontología. En su versión más reciente [8] Wise aboga por el uso de una extensión
del UML como un lenguaje gráfico para representar ontologías. Esta extensión se propone el uso de un
subconjunto de elementos UML que realizan la misma función de la calificación LINGO [7], el lenguaje
propuesto originalmente. LINGO tenía primitiva para representar conceptos, relaciones y propiedades, y
algunos tipos de relaciones que tenían una semántica bien establecidas, tales como las relaciones entre
todos los partidos y sub-clase-de, por el que un conjunto de axiomas formales, según se definió
epistemológico axiomas. Así, a pesar de la utilización de los elementos del modelo de UML, la semántica
impuesta es el mismo que el establecido para los elementos correspondientes en LINGO, como se muestra
parcialmente en la figura 1. De acuerdo con esta clase de extensión UML con estereotipo << concepto >> representar
conceptos de la ontología. Las relaciones se definen como asociaciones con nombre. Las propiedades de los
conceptos y las relaciones se representan como atributos. Las relaciones que contienen o han propiedades
superiores aridad que dos clases se representan como asociaciones con el estereotipo << >> relación. relaciones
supertipo y todo-parte se representan como una relación de generalización / especialización y la agregación /
composición,

respectivamente. Por último, las limitaciones son las relaciones entre

representado por restricciones entre las asociaciones [9].

<< >> Relación

Concepto
Conceito1 << >> Concepto Concepto
propiedad 1..n 0..n
0..n Relação2
Conceito2 << >> Conceito3 << >>
+papel
Atasco
2 de + Tamaño1 0..n
0..n
0..n
Relación >> 0..n << >> Relación
Relação1
<< propiedad Relação3
>> Concepto
Concepto ParteConceito2 << 0..n
SubTipoConceito1 << >> Concepto
Conceito4 << >>

Axiomas: todos Sub-tipo:

los partidos (SA7) ( ∀ x, y, z) (subtipo (x, y) ∧ subtipo (y, z) →
(AE1) ∀ x ¬ parte (x, x) (E2) ∀ x, y de (y, x) ↔ todo (x, y) (AE3) ∀ x, y supertipo (x, z)) (AE8) ( ∀ x, y) (subtipo (x, y) → supertipo (y,
de (y, x) → ¬ parte (x, y) (E4) ∀ x, y, z de (z, y) ∧ parte (y, x) → Parte x))
(z, x) (SA5) ∀ x, y disjuntos (x, y) → ¬∃ Parte z (z, x) ∧ de (z, y) (AE6) ∀ O acondicionado exclusiva:
x atómicas (x) → ¬∃ de y (y, x) (AE9) ( ∀ la ∈ C2) (( ∃ b) (b ∈ C3) ∧ R2 (a, b)) → ¬ ((∃ c ∈ C4) ∧
R3 (a, c))) (AE10) ( ∀ la ∈ A) (( ∃ c) (c ∈ C4) ∧ R3 (a, c)) →
¬ ((∃ b ∈ C3) ∧ R2 (a, b)))

Fig. 1. Las principales clasificaciones de la extensión de UML utilizado y los axiomas asociados a ella.
3 Requisitos de software Una ontología

Esta sección presenta los requisitos Ontología software propuesto, basado en los artefactos definidos por el
método racional. Así que empezamos por la especificación de requisitos, enumerando las cuestiones
jurisdiccionales planteadas: CC1. ¿Qué es un requisito? CC2. ¿Cuál es la naturaleza de un requisito? QC3. ¿Cuáles
son los requisitos de un proyecto de software? QC4. Para los módulos del sistema se le asigna un requisito?
QC5. Que son responsables de un requisito? QC6. Lo que interesa ( las partes interesadas) en un requisito?
QC7. ¿Cuál es el origen de un requisito? QC8. ¿Cuál es el estado de un requisito? QC9. Como requisito
particular, se descompone en otros requisitos? QC10. ¿Qué requisitos son dependientes de un requisito
particular? QC11. ¿Qué requisitos son contradictorios entre sí? QC12. Lo que es una especificación de
requisitos de software (ERS)? QC13. Los artefactos que describen, modelo o implementan un requisito?
QC14. La gestión de los requerimientos cambiantes y artefactos relacionados con ellos? QC15. ¿Cómo
evaluar los requisitos de calidad?

Una vez que los requisitos están en el mundo de la ingeniería de software, es útil examinar otras
ontologías ese dominio. En este trabajo los siguientes fueron inspeccionados ontologías construidas de
manera integrada dentro del Proyecto ODE:

• Ontología de Procesos de Software: desarrollado en [7] y recientemente revisado en [10] ontologías, esta
ontología se compone de actividad, y el procedimiento de apelación y se ocupa de los conceptos básicos
sobre el campo de los procesos de software, que abordan los conceptos de actividad, proceso, diseño,
dispositivo y función .
• Los artefactos ontología desarrollado en [11] tiene como objetivo proporcionar una comprensión común
de algunos tipos de artefactos (documento, diagrama y código fuente), la definición de sub-ontologías
para ellos.
• Ontología Software Gestión de la Configuración: desarrollado en [11] trata de abordar conceptos
relacionados con la gestión de configuración de software.
• Ontología de la Calidad del Software: desarrollado en [12] apunta a la conceptualización acerca de la calidad
del software de campo, que trata de temas como la evaluación de la calidad, las características de calidad y
métricas.
• Organizaciones de software ontología: Su objetivo es proporcionar un vocabulario común que se puede
utilizar para representar el conocimiento útil sobre las organizaciones de software, incluidas las
habilidades de sus miembros. La Figura 2 muestra las ontologías integrados, destacando las
dependencias entre ellos. Proceso de Ontología, fueron reutilizados conceptos Actividad del proyecto y

Artefacto. Estos requisitos se establecen en virtud de un diseño y por lo tanto es importante relacionar los
conceptos de requisito y Proyecto. Pero el concepto de actividad Fue utilizado para componer el contexto en el
que se origina un requisito, como requisito puede resultar de una actividad del proceso. Por último, el
concepto de artefacto trazabilidad es importante para la captura de un requisito de que los artículos son
tratados.
 Ontología proceso Gestión de la Configuración de ontología de la
Software ontología calidad
ontología ontología
actividad recurso

Procedimiento
ontología

Requisitos
ontología

Organizaciones ontología
software

ontología de artefactos

documento ontología de artefactos Diagrama de la

Ontología código ontología

Fig. 2. Los requisitos de la ontología y dependencias con ontologías utilizadas.

Cabe destacar que los aspectos ER del proceso en sí mismo, tales como actividades, sub-actividades,
procedimientos, etc., no se trataron en los requisitos de la ontología, puesto que ya son tratados por la
ontología proceso. De hecho, una descripción del proceso de RE puede ser realizada por instancias de la
ontología proceso.
La ontología de artefactos y sus sub-ontologías definen conceptos sobre algunos tipos de artefactos y sus
estructuras. Para este trabajo, fue especialmente importante a la ontología de documentos, como un
Documento de Requisitos de Software Especificación (DERS) es una Documento. Por lo tanto, todos los
conceptos utilizados para describir los dispositivos y, más concretamente, los documentos, se volvió a utilizar
para tratar derss, incluyendo la definición de plantillas de documentos para documentos de organización [11].

Cabe señalar que el concepto de artefacto El proceso se define en la ontología y no artefacto en la

ontología. Esto se debe a la ontología de artefactos propone conceptualizar algunos tipos de artefactos y no lo
que es un artefacto. El concepto dispositivo es tratado por el proceso de la ontología, definido como un
producto o materia prima para las actividades en el proceso de software [7].

Ya que es esencial para evaluar los requisitos de calidad, también se utilizó el software de calidad
Ontología, especialmente con respecto a la calidad de los artefactos de software aplicados a DERS. Esta
definición incluye Características de calidad directa e indirectamente medible, Medidas métricas, etc. [12].

La Gestión de la Configuración de Software ontología se ocupa de los conceptos relacionados con los temas
de control de versiones y la configuración de cambio de control, estos elementos que representan el proceso de
software que están bajo la administración de configuración [12]. Como derss y requisitos deben ser su
configuración administrados, esta ontología también se integró en los requisitos de la ontología.
 Organizaciones de software ontología que volver a utilizar los conceptos Individuales y de equipo. El primero
es el de los individuos en una organización. Este concepto es útil para definir las partes interesadas ( las partes
interesadas) y los responsables de un requisito. El segundo concepto, equipo, define los equipos de proyecto de
una organización.
A través de la reutilización de ontologías, asociando conceptos de estas ontologías términos definidos para
los requisitos de la ontología, fue posible responder a la pregunta planteada anteriormente de la jurisdicción,
como veremos a continuación.

3.1 Captura y requisitos de inscripción Ontología

El análisis de las cuestiones de jurisdicción por encima relacionados, hemos identificado algunos aspectos
relevantes discutidos en la secuencia:
1. Definición y requisitos Taxonomía (preguntas 1-4 y 12)
2. De aprobación y de interés en los requisitos (preguntas 5 y 6)
3. Gestión de requisitos (preguntas 7 a 11, 13 y 14)
4. Los requisitos de calidad (pregunta 15)

Requisitos Definición y Taxonomía

En general, los requisitos son declaraciones que describen los servicios que un sistema debe proporcionar,
restricciones que debe obedecer y características que debe tener ( QC1). Además, los requisitos se definen
dentro de un proyecto ( QC3).
Como se discutió en la sección anterior, uno es un DERS Artefacto. Más específicamente, un DERS es
una Documento (QC12) la cual, de acuerdo con [11], que es un artefacto de software no es ejecutable, por lo
general compuesta de sentencias en texto, por lo general asociados con los patrones de organización
(scripts y plantillas de documentos) que definen cómo debe ser producido.

Aunque los requisitos se definen dentro de un proyecto, también es importante definir módulos del
proyecto se asigna dicho requisito ( QC4). Para responder a esta pregunta se definieron los conceptos alcance y
Módulo. Un proyecto de software ha su alcance normalmente dividido en módulos y estableciendo una
relación entre requisito y módulo, Puede seguir los módulos que un requisito se asigna y viceversa.

Ya que puede haber varios tipos de requisito, es necesario crear una taxonomía para organizarlos.
Entendemos que no hay consenso acerca de los tipos de requisitos. Por lo tanto, se decidió crear el concepto Tipo
requisito, que admite subtipos, y un subtipo puede tener varios supertipos y para cada supertipo, se pueden
crear varios subtipos ( CC2).

La Figura 3 muestra la parte del modelo de la ontología relacionadas con cuestiones jurisdiccionales
referencia anteriormente. Recuerde que la notación utilizada implícitamente impone algunos axiomas. Por
ejemplo, los axiomas (AE1) a (AE6) de la Figura 1 se aplican a todas las relaciones parte-todo mostrados en
la Figura 2 (entre Alcance y módulo de entre los módulos y entre los requisitos de los tipos), así como los
axiomas (SA7) y (AE8) de la figura 1 se aplica a las relaciones de tipo sub entre Artefacto, y documento
Documento Software especificación de requisitos. Además de estos axiomas, según se definieron
epistemológicos, otros axiomas, algunas de ellas discuten en secuencia.
 << >> Concepto << >> para Concei
Concepto producción
determinación Proyecto (de Proceso Artefacto (de Proceso
Ámbito << >>
de Ontología ... de Ontología ...
1 0..n
1 1
1

dependencia 0..n
definición
tratamiento
0..n 1
0..n 0..n 1
Concei 0..n << >> para Concei
Concei indicar << >> para
0..n asignación Requisi para
0..n Documento (de la
<< >> Módulo de
ontología artefacto)
0..n
+ superMódulo

0..n
0..1 0..n
+ submódulos 1 clasificación

Concepto
0..n
<< >> para Concei
TipoRequisito << >>
+ subtipos ficación documento especí
Requisitos de software
+ supertipos 0..n

Fig. 3. Requisito Definición y Taxonomía

Para formalizar aspectos importantes en la asignación de requisitos a los módulos, se utilizaron los
siguientes predicados: Asignación (r, m) lo que indica que la condición r Se asigna al módulo m; y sub-módulo
(m1, m2) lo que indica que m1 Es un sub-módulo
m2. Estos predicados se relacionan de acuerdo con la siguiente frase, señalando que los requisitos asignados
a un módulo también se asignan a sus super-módulos:

( ∀ r, m1, m2) (sub-módulo (m1, m2) ∧ Asignación (m1 R) → Asignación (r, m2)) (A1)

Además, lo siguiente es válido axioma que define un requisito sólo puede ser asignado a un módulo que
está dentro del alcance de este diseño conjunto requisito. Este axioma el predicado ajuste (r, p) indica que el
requisito previo r Se define en el proyecto p; Composición (m, e) Indica que el módulo m componer el alcance y;
y
determinar (e, p) indica que el alcance y Se determinó para el proyecto p. ( ∀ p, r, m) (asignación (r,

m) ∧ ajuste (r, p) ∧ Composición (m, e) →

determinar (E, P)) (AC1)

Cabe señalar la diferencia entre los axiomas (A1) y (AC1). El axioma (A1) se derivan nueva información
(y por lo tanto se llama un axioma ontológica), mientras que el axioma (AC1) no deriva nueva información,
pero sólo restringe el establecimiento de relaciones. Axiomas de este tipo se dice axiomas de consolidación
[7].
Teniendo en cuenta el espacio limitado, este artículo no presenta otros axiomas definidos. Sólo para que
conste, la relación de dependencia entre módulos es transitiva y simétrica. Además, existe un axioma de la
consolidación de la participación de las relaciones entre Requisito, Diseño y Artefacto.

Además de los modelos gráficos y axiomas formales, sabia el propósito de elaborar un diccionario de
términos con una entrada para cada término definido en la ontología (conceptos, relaciones y propiedades).
Una vez más, debido a limitaciones de espacio, este
Artículo presentes sólo los términos relacionados con los conceptos definidos en los requisitos de la ontología
que se muestran en la Tabla 1. Los términos en esta tabla en negrita corresponden a otros términos descritos en
términos de diccionario completo.

Tabla 1. Parte Términos de Requisitos Ontología diccionario.

proporcionando,
requisito Representa las limitaciones
especificaciones del sistema
de los servicios y el desarrollo
que el sistema debe y conocimientos
necesarios para construir el sistema.
Es un documento, por lo tanto uno artefacto software, que se utiliza para la
La especificación comunicación formal de los requisitos a los clientes, usuarios, etc., proporcionando
de requisitos del la base para muchos actividades de
documento proceso el software. Como documento, se asocia generalmente con las normas
software de organización ( scripts) definir cómo debe ser producido.

Conceptos utilizados en la caracterización de un requisito para retratar el tamaño

Tipo
trata de abordar el requisito como funcional y no funcional, etc.
requisito

Es una porción sistema utilizado para organizar y agrupar, por ejemplo, artefactos,
módulo requisitos y otros módulos que tienen una cierta afinidad.

Determina los límites de una proyecto, que abarca la parte de la diseño y lo que
alcance no. Un ámbito de aplicación se puede descomponer en módulos.

Las características que la situación en la que una requisito aparecido, tratando

de describir lo personas involucrados que
contexto
artefactos analizado y que actividad de proceso surgió requisito de software.

Aprobación e interés en Requisitos

El proceso de Ingeniería de Requisitos implica a varias personas de diferentes áreas y diferentes
perspectivas. Por lo tanto, es interesante saber a los interesados ​en cada requisito, a fin de facilitar su
localización para facilitar las negociaciones, aclaraciones y discutir los impactos del cambio ( QC6).

Además, es esencial que hay personas responsables de un requisito dado. Dichas personas pueden, por
ejemplo, aprobar un requisito antes de que se trata mediante las actividades subsiguientes del proceso de
desarrollo ( QC5).
La figura 4 muestra la parte de los requisitos ontología que tratan estas cuestiones. El concepto requisito Se
relaciona con el concepto persona Organizaciones de software a través de relaciones de ontologías interés y responsabilidad.
Como el nombre sugiere, la primera relación es el interés de la gente en un requisito y la segunda es
responsable de un requisito.

Entre los axiomas definidos para esta parte de la ontología destacamos los siguientes axiomas de la
consolidación:

( ∀ r, p, y pr) (interés (p, r) → participación (p, e) ∧

alocação_pessoal (y Pr) ∧ también la definición (r, Pr)) (AC2)
 << >> Concepto << >> Concepto
diseño asignación de personal equipo
(Del procedimiento ontología Sw) (De Organización ontología)
0..n 0..n

0..n

definición
0..n
0..n 1
<< >> Concepto
Concepto
interés persona
Requisito << >>
(De Organización ontología)
0..n 0..n

0..n
0..n
responsabilidad

Fig. 4. La aprobación y el interés en el requerimiento.

( ∀ r, p, y pr) (responsabilidad (p, r) → participación (p, e) ∧

alocação_pessoal (y Pr) ∧ también la definición (r, Pr)) (AC3)

El axioma (AC2) garantiza que para que una persona sea interesado en un requisito, debe ser asignado a
un equipo de proyecto en el que se ha establecido el requisito. Pero el axioma (AC3) garantiza que por una
persona que se encargue de un requisito, sino que también debe ser asignado a un equipo de proyecto que
define el requisito. En estos axiomas, se utilizaron los siguientes predicados: interés (p, r) indica que la
persona
p Tiene un interés en el requisito r; responsabilidad (p, r) indica que la persona p Es responsable de la
condición r; participación (p, e) indica que la persona p parte del equipo y; y alocação_pessoal (y Pr) indica que
el equipo y Se asignó al proyecto pr.

Gestión de requisitos
De acuerdo con [6], los requisitos de gestión incluye el control de cambio, control de versiones, los
requisitos de monitorización de estado y la trazabilidad.
En cuanto al cambio de control y la necesidad de control de versiones, podemos ver que estamos
hablando de ajuste de los requisitos de gestión (y documentos de especificación de requisitos de software -
DER). Como se ha señalado en el apartado anterior, la ontología de la gestión de la configuración del
software se ocupa de estas cuestiones. El concepto central de esta ontología es el concepto de Elemento de
Configuración, que es algo que está debajo de gestión de la configuración y por lo tanto sólo puede ser
cambiado de acuerdo con un procedimiento de control de cambio establecido y documentado formalmente.
una Elemento de configuración tiene varias variaciones, que puede ser o bien del tipo variante como Versión. Por
lo que los requisitos Ders y están sujetos a la gestión de configuración, sólo tiene que relacionar con Elemento
de Configuración, utilizando la relación shunt, como se define en [11] y parcialmente se muestra en la Figura
5.

También en relación con el control de cambios y la trazabilidad también implica, es necesario establecer
una red de conexiones con el fin de detectar más fácilmente el impacto de los cambios. Estos enlaces por lo
general tratan de proporcionar información sobre la dependencia ( QC-10) composición ( QC9) y el conflicto ( CQ11)

entre los requisitos, información acerca de donde se describe un requisito, modelada y codificada ( QC13) y el
origen de una solicitud ( QC7). Un modelo para el 6 trata de abordar estas cuestiones.
 << >> Concepto
Concepto
artefacto
Requisito << >>
{O} exclusiva (Del procedimiento ontología Sw)

1
1
derivación
0..1 0..1 1
<< >> Concepto << >> Concepto
Elemento de configuración documento
(A partir de Gestión de la Configuración de ontología) (De Ontología Artefacto)

1
estado
1..n 1

<< >> Concepto << >> Concepto

variación Documento de especificación de
(A partir de Gestión de la Configuración de ontología) requisitos de software

Fig. 5. Gestión de la Configuración de Software aplicado a los requisitos y derss.

<< >> Concepto

<< >> Concepto

artefacto 0..n 0..1 Actividad (de Proceso de

(Proceso De Ontología ... Ontología ... ...

0..n
artefacto caracterización actividad caracterización
0..n 0..n

tratamiento << >> Concepto

fuente
contexto
1
0..n 1..n

... 0..n
0..n
0..n requisito persona caracterización
<< estado Arrogancia
0..n
conflicto 0..n

<< >> Concepto

0..n
persona
0..n 0..n
(Ontología de La ...
dependencia

Fig. 6. las relaciones importantes para la trazabilidad.

La dependencia permite establecer vínculos de dependencia entre los requisitos ( QC-10) lo que indica
que, si se cambia un requisito otros requisitos que dependen, es probable que la necesidad de cambiar en
función de las necesidades.
En el caso de la composición, la situación es similar. A través de esta relación, es posible tratar la
descomposición de una condición en la que otros ( QC9). Si se altera un requisito es probable compuesto que
partes tienen que ser revisado, y viceversa.
Por último, se puede establecer relaciones de conflicto entre los requisitos ( QC11)
que le permite controlar estos conflictos, manteniéndolos aceptable o detectar definitivamente no puede existir
un conflicto, dando lugar a la revisión de los requisitos en cuestión.
Para tener un control de los cambios más eficaces, es interesante para poder evaluar el impacto de los
cambios a un requisito en otros artefactos del proceso de software. Por lo tanto, es importante saber qué
artefactos (por ejemplo, el documento
requisitos de la especificación, modelos de análisis y esquemas y diseño, o incluso el código fuente) tratar
con un requisito para poder pisar cambios en un requisito para estos artefactos y viceversa ( QC13).

Para mantener la trazabilidad de un requisito desde su concepción, es necesario conectar el requisito de

su fuente, o conectarlo al contexto en el que se originó ( QC7). Este contexto puede caracterizarse por análisis
de los artefactos, la interacción entre las personas, consultoría sitios Internet, etc. y también puede ocurrir
como parte de una actividad en el proceso de software.

El estado de un requisito es útil tener el control, en un momento dado, la forma de caminar su desarrollo ( QC8).
Los estados posibles se definen exigencia de una organización a otra, y pueden ser, por ejemplo:

propuesto en Modificación En Comprobar, Rechazado etcétera

Por último, vale la pena señalar que la cuestión de la competencia QC14 Que es contestada por el concepto
discutido anteriormente.

Requisito calidad y ERS

La calidad del software de documentos de Especificación de Requisitos (DERS) es crucial para el éxito del
proyecto. De acuerdo con la calidad del software Ontología [12], la calidad de un artefacto de software puede
ser evaluado mediante la definición de calidad y uso de indicadores para medirlos. Por lo tanto, la adopción
del concepto de esta ontología, la cuestión de la competencia QC15

pueden ser respondidas, como se muestra en la Figura 7. En esta ontología, cada dispositivo puede tener
una serie de características de calidad del producto pertinentes para la evaluación de su calidad. Estas
características de calidad pueden medirse directa o indirectamente, con el correlato directamente medible
con métricas, mientras que indirectamente medible puede medirse mediante la combinación de los valores
de sus sub-características.

4 Trabajo relacionado

Pocos estudios han tratado de ontologías para los requisitos. En [13] se presenta una ontología requisitos
diseñados para apoyar a los requisitos de gestión de procesos genéricos en el ámbito de los proyectos de
ingeniería. Esta ontología forma parte de una ontología más general para capturar el conocimiento de
proyectos de ingeniería. Sus problemas de competencia se agrupan en las siguientes categorías: requisitos
de refinamiento, los requisitos de trazabilidad, un requisito de la satisfacción, la liberación y el cambio, los
requisitos de las partes y la estructura del producto relacionados. A pesar de las categorías mencionadas y
abordan cuestiones habilidades están muy cerca de este trabajo, nuestros Requisitos ontología se centra en
los requisitos de software de dominio, por lo que, la realización, la interacción con otros dominios de
ingeniería de software ontologías,
 << >> para Concei

Lo característico de la edad (de 0..n valuación

Ontología lo que la edad) 0..n

2..n 2..n

<< >> para Concei << >> para Concei << >> para Concei

Característica medible directamente Característica Indi justamente medible

Ontología Qué edad) (A partir de qué edad ontología) (A partir de qué edad ontología)

0..n pertinencia
característica de producto (de 1..n

0..n correlación
1
<< >> Concei a la
Artefacto (de Proceso de << >> para Concei << >> para Concei
cuantificar
ontología Sw) Métrica (de Ontología Medir (de Ontología
Qué edad) Qué edad)
0..n 1

<< >> para Concei

<< >> para Concei
Documento (de la
Documento especi ficación de tos Software Requisi
ontología artefacto)

Fig. 7. Requisitos de calidad

En el contexto de los requisitos de software, Ramesh y Jarke [14] presentar un meta-modelo que
proporciona primitivas de categorización y descripción de modelos de trazabilidad y trata a las siguientes
preguntas: ¿Qué información se representa? Que están interesados ​en jugar diferentes papeles en los
objetos de control? Donde se representan los objetos? ¿Cómo se representa la información? ¿Por qué se
crea o modifica un determinado objeto? Cuando se creó la información, etc capturado? A partir de este
meta-modelo son instanciados otros modelos de trazabilidad que incluyen aspectos más específicos, tales
como la derivación de los requisitos, la asignación de los requisitos subsistemas y componentes,
necesidades de la organización, etc.

Aunque el trabajo de Ramesh y Jarke No sería una ontología, está claramente correlacionada con los
requisitos de la ontología que se presentan en este trabajo. Algunas de las cuestiones planteadas por ellos
también figuraban como cuestiones de jurisdicción en este trabajo. Sin embargo, aquí, hemos intentado tratar la
manera más amplia los requisitos de dominio, más allá de los requisitos de trazabilidad.

5 Comentarios finales

En este trabajo una ontología Requisitos de software presentó con el objetivo de definir los conceptos y las
relaciones de dominio sobre los requisitos formales facilitar la comunicación entre las personas, entre agentes
de software, herramientas de construcción para apoyar la ingeniería de requisitos (RE) más ampliamente
utilizable y ayudar en estudio sobre los requisitos de software en el contexto del Proyecto ODE. Durante la
construcción de esta ontología, varias otras ontologías sobre el dominio de la ingeniería de software
 Ellos fueron analizados y reutilizados. Por lo tanto, trató de volver a utilizar conceptos ya establecidos.

Como continuación de este trabajo, se está construyendo una sala de emergencias herramienta de apoyo
basado en la ontología propuso ODE integrado.

Agradecimientos

Este trabajo fue apoyado por el CNPq y CAPES, las entidades gubernamentales brasileñas dedicadas al
desarrollo científico y tecnológico, FAPES, Fundación de Apoyo a la Ciencia y Tecnología del Espíritu Santo,
y VixTeam Consultoría y Sistemas, una empresa asociada que ha financiado el proyecto y la
retroalimentación dada desde su aplicación a casos reales.

referencias

1. HFHofmann, F. Lehner. "Ingeniería de Requisitos como un factor de éxito en proyectos de software, IEEE Software,
julio / agosto de 2001.
2. G. Kotonya I. Sommerville. "Ingeniería de Requisitos: Proceso y Técnicas". 1ª Edición. Wiley Publishing.
1998.
3. RA Falbo, et al., "Las ontologías y Software entornos de desarrollo Semántica" JIISIC'2004.

4. N. Guarino. "Ontología formal en el Sistema de Información". En: Actas de la Primera Conferencia Int sobre ontología
formal en Sistemas de Información, Trento, Italia, junio de 1998. p.3-15 ..
5. La leche JCSP. "Administración del software con requisitos de calidad de la base". En: Calidad de Software:
Teoría y Práctica. 1er. Edición. Prentice Hall. 2001. pp 238-246.
6. S. Robertson; J. Robertson. Dominar el proceso de los requisitos. 1ª Edición. Editorial ACM Press, Addison Wesley.
1999.
7. RA Falbo. "La incorporación de conocimiento en un entorno de desarrollo de software." Tesis Doctoral, la
COPPE / UFRJ, RJ, diciembre de 1998.
8. RA Falbo. "experiencias en el uso de un método para la construcción ontologías de dominio". Proc. del Taller Internacional
de Ontología En Acción, Banff, Alberta, Canadá, junio de 2004.
9. GE Mian, RA Falbo, "Desarrollo con oded ontología de apoyo", Revista de la Computer Science, vol
brasileño. 9, no. 2, pp 57-76, noviembre de 2003.
10. RA Falbo, G. Bertollo, "El establecimiento de un vocabulario común para las organizaciones de software Entender los
procesos de software", Taller Internacional sobre vocabularios, ontologías y Reglas para la Empresa, VORTE'2005,
Enschede, Países Bajos, septiembre de 2005.
11. Ng BV. "La integración de gestión de la configuración del software, documentación y gestión del conocimiento
en un entorno de desarrollo de software." 2005. Disertación (Maestría en Ciencias de la Computación)
-Universidad Federal del Espíritu Santo.
12. KC Duarte. "Un marco Reutilizar en el Dominio de Calidad de Software ".
Tesis de maestria. Departamento de Informática (DI) de la Universidad Federal de Espírito Santo (UFES).
ES-ganar. Junio ​de 2001.
13. J. Lin, MS Fox, T. Bilgic. "El requisito para el diseño de ingeniería de la ontología", en: M. Sobolewski, M. Fox
(Eds.), Actas de Avances en Ingeniería Concurrente (CE'96), Toronto, 1996, pp. 343-351.

14. B. M. Jarke y Ramesh, "Hacia modelos de referencia para los requisitos de trazabilidad", IEEE Transactions on
Software Engineering, Vol. 27, No. 1, 2000.

Ver publicación
publicación estadísticas
Ver de