2.

INGENIERÍA REQUERIMIENTOS
1 REQUERIMIENTOS DEL SOFTWARE son los estándares en los procesos que deben
utilizarse; los requerimientos de implementación.
1.1 1. REQUERIMIENTOS FUNCIONALES Y NO
como los lenguajes de programación o el método de
FUNCIONALES
diseño a utilizar, y los requerimientos de entrega que
1.1.1 REQUERIMIENTOS FUNCIONALES especifican cuándo se entregará el producto y su
documentación.
Describen lo que el sistema debe hacer. Estos
requerimientos dependen del tipo de software que Requerimientos externos.
se desarrolle, de los posibles usuarios del software y
Este gran apartado incluye todos los requerimientos
del enfoque general tomado por la organización al
que se derivan de los factores externos al sistema y
redactar requerimientos. Cuando se expresan como
de su proceso de desarrollo. Éstos pueden incluir los
requerimientos del usuario, habitualmente se
requerimientos de interoperabilidad que definen la
describen de una forma bastante abstracta. Sin
manera en que el sistema interactúa con sistemas de
embargo. los requerimientos funcionales del
otras organizaciones; los requerimientos legislativos
sistema describen con detalle la función de éste, sus
que deben seguirse para asegurar que el sistema
entradas y salidas, excepciones, etcétera
funcione dentro de la ley. y los requerimientos
1.1.2 REQUERIMIENTOS NO FUNCIONALES éticos. Estos últimos son puestos en un sistema para
asegurar que será aceptado por sus usuarios y por el
Los requerimientos no funcionales, como su nombre
público en general.
sugiere, son aquellos requerimientos que no se
refieren directamente a las funciones específicas 1.2 2. REQUERIMIENTOS DEL USUARIO
que proporciona el sistema, sino a las propiedades
1.2.1 Describen los requerimientos funcionales y no
emergentes de éste como la fiabilidad, el tiempo de
funcionales de tal forma que sean comprensibles
respuesta y la capacidad de almacenamiento. De
por los usuarios del sistema sin conocimiento
forma alternativa, definen las restricciones del
técnico detallado. Únicamente deben especificar el
sistema como la capacidad de los dispositivos de
comportamiento externo del sistema y deben evitar,
entrada/salida y las representaciones de datos que
tanto como sea posible, las características de diseño
se utilizan en las interfaces del sistema.
del sistema. Por consiguiente, si se están redactando
TIPOS DE REQUERIMIENTOS NO FUNCIONALES requerimientos del usuario, no se debe utilizar jerga
del software, notaciones estructuradas o formales, o
Requerimientos del producto.
describir los requerimientos por la descripción de la
Estos requerimientos especifican el implementación del sistema. Deben redactarse en
comportamiento del producto. Algunos ejemplos un lenguaje sencillo, con tablas y formularios
son los requerimientos de rendimiento en la rapidez sencillos y diagramas intuitivos.
de ejecución del sistema y cuánta memoria se
1.2.2 Problemas cuando se redactan con frases del
requiere; los requerimientos de fiabilidad que fijan
lenguaje natural
la tasa de fallos para que el sistema sea aceptable;
los requerimientos de portabilidad, y los l. Falta de claridad. Algunas veces es difícil utilizar el
requerimientos de usabilidad. lenguaje de forma precisa y no ambigua sin hacer el
documento poco conciso y difícil de leer.
Requerimientos organizacionales.
2. Confusión de requerimientos. No se distinguen
Estos requerimientos se derivan de políticas y
claramente los requerimientos funcionales y no
procedimientos existentes en la organización del
cliente y en la del desarrollador. Algunos ejemplos
funcionales, las metas del sistema y la información Son notaciones que se basan en conceptos
para el diseño. matemáticos como el de las máquinas de estado
finito o los conjuntos. Estas especificaciones no
3. Conjunción de requerimientos. Diversos
ambiguas reducen los argumentos sobre la
requerimientos diferentes se pueden expresar de
funcionalidad del sistema entre el diente y el
forma conjunta como un único requerimiento.
contratista. Sin embargo, la mayoría de los dientes
1.3 3. REQUERIMIENTOS DEL SISTEMA no comprenden las especificaciones formales y son
reacios a aceptarlas como un contrato del sistema.
1.3.1 Deben describir el comportamiento externo
del sistema y sus restricciones operativas. No deben 1.4 4. ESPECIFICACIÓN DE LA INTERFAZ
tratar de cómo se debe diseñar o implementar el
1.4.1 tipos de interfaces
sistema. Sin embargo, en el nivel de detalle
requerido para especificar completamente un Interfaces de procedimientos
sistema software complejo, es imposible, en la
en las cuales los programas o subsistemas existentes
práctica, excluir toda la información de diseño.
ofrecen una variedad de servicios a los que se
1.3.2 Es esencial redactar los requerimientos del accede invocando a los procedimientos de la
usuario en un lenguaje que los no especialistas interfaz. Estas interfaces a veces se denominan
puedan entender. Sin embargo, se pueden redactar Interfaces de Programación de Aplicaciones (APls).
los requerimientos del sistema en unas notaciones
Estructuras de datos
más especializada como ser:
que pasan de un subsistema a otro. Los modelos
Lenguaje natural estructurado
gráficos de datos son las mejores notaciones para
Este enfoque depende de la definición de este tipo de descripción. Si es necesario, se pueden
formularios o plantillas estándares para expresar la generar automáticamente descripciones de
especificación de requerimientos. programas en Java o C++ de estas descripciones.
Lenguajes de descripción de diseño Representaciones de datos establecidas para un
subsistema existente.
Este enfoque utiliza un lenguaje similar a uno de
programación, pero con características más Estas interfaces son muy comunes en sistemas de
abstractas, para especificar los requerimientos por tiempo real embebido. Algunos lenguajes de
medio de la definición de un modelo operativo del programación corno Ada (aunque no Java) soportan
sistema. Este enfoque no se utiliza ampliamente en este nivel de especificación. Sin embargo, la mejor
la actualidad, aunque puede ser útil para forma de describir éstos es probablemente utilizar
especificaciones de interfaces. un diagrama de la estructura con anotaciones que
expliquen la función de cada grupo de bits.
Notaciones gráficas
1.5 5. EL DOCUMENTO DE REQUERIMIENTOS DEL
Para definir los requerimientos funcionales del
SOFTWARE
sistema, se utiliza un lenguaje gráfico,
complementado con anotaciones de texto. Uno de 1.5.1 Es la declaración oficial de qué deben
los primeros lenguajes gráficos fue SADT implementar los desarrolladores del sistema. Debe
Actualmente, se suelen utilizar las descripciones de incluir tanto los requerimientos del usuario para el
casos de uso (Jacobsen et 0/. 1993) Y105 diagramas sistema como una especificación detallada de los
de secuencia requerimientos del sistema.
Especificaciones matemáticas 1.5.2 Posibles usuarios del documento y cómo lo
utilizan.
Clientes del sistema 2 PROCESOS DE LA INGENIERÍA DE
REQUERIMIENTOS.
Especifican los requerimientos y los leen para
verificar que cumplen sus necesidades. Los clientes 2.1 CONCEPTO
especifican los cambios en los requerimientos
2.1.1 La meta del proceso de ingeniería de
Administradores requerimientos es crear y mantener un documento
de requerimientos del sistema. El proceso general
Utilizan el documento de requerimientos para
corresponde cuatro subprocesos de alto nivel de la
planificar una oferta por el sistema y para planificar
ingeniería de requerimientos.
el proceso de desarrollo del sistema
Ingenieros de sistemas
Utilizan los requerimientos para comprender qué
sistema debe desarrollarse
Ingenieros probadores del sistema
Utilizan los requerimientos para desarrollar las
pruebas de validación para el sistema
Ingenieros encargados del mantenimiento del
sistema
Utilizan los requerimientos para comprender el
sistema y las relaciones entre sus partes
1.5.3 Estructura para los documentos de
requerimientos
2.2 SUBPROCESOS DE LA INGENIERÍA DE
REQUERIMIENTOS
2.2.1 CONCEPTO
Es una descripción resumida del sistema y de cómo
éste pretende contribuir a los procesos del negocio.
Los resultados del estudio de viabilidad deberían ser
un informe que recomiende si merece o no la pena
seguir con la ingeniería de requerimientos y el
proceso de desarrollo del sistema.
2.2.2 1. ESTUDIOS DE VIABILIDAD
Es un estudio corto y orientado a resolver varias
cuestiones:
1. ¿Contribuye el sistema a los objetivos generales
de la organización?
2. ¿Se puede implementar el sistema utilizando la
tecnología actual y dentro de las restricciones de
coste y tiempo?
3. ¿Puede integrarse el sistema con otros sistemas
existentes en la organización?
2.2.3 2. OBTENCIÓN Y ANÁLISIS DE
REQUERIMIENTOS
En esta actividad, los ingenieros de software
trabajan con los clientes y los usuarios finales del
sistema para determinar el dominio de la aplicación,
qué servicios debe proporcionar el sistema, el
rendimiento requerido del sistema, las restricciones
hardware, etcétera.
El término stakeholder
se utiliza para referirse a cualquier persona o grupo
que se verá afectado por el sistema, directa o
indirectamente. Entre los stakeholders se
encuentran los usuarios finales que interactúan con 2.2.4 3. VALIDACIÓN DE REQUERIMIENTOS
el sistema y todos aquellos en la organización que se
pueden ver afectados por su instalación Es el proceso de recoger información sobre el
sistema propuesto y los existentes y extraer los
Obtener y comprender los requerimientos de los requerimientos del usuario y del sistema de esta
stakeholders es difícil por varias razones: información. Las fuentes de información durante la
fase del descubrimiento de requerimientos incluyen
la documentación. los stakeholders del sistema y la
especificación de sistemas similares. Usted se
relaciona con los stakeholdcrs a través de entrevistas
y de la observación y puede utilizar escenarios y
prototipos para ayudar al descubrimiento de
requerimientos.
La validación de requerimientos trata de mostrar
que éstos realmente definen el sistema que el
cliente desea. Coincide parcialmente con el análisis
ya que éste implica encontrar problemas con los
requerimientos. La validación de requerimientos es
importante debido a que los errores en el
documento de requerimientos pueden conducir a
importantes costes al repetir el trabajo cuando son
descubiertos durante el desarrollo o después de que
el sistema esté en uso.
Las actividades del proceso son:
2.2.5 4. GESTIÓN DE REQUERIMIENTOS
La gestión de requerimientos es el proceso de
comprender y controlar los cambios en los
requerimientos del sistema. Es necesario
mantenerse al tanto de los requerimientos
particulares y mantener vínculos entre los 3.2.1 Un modelo del sistema es una abstracción del
requerimientos dependientes de forma que se sistema que se está estudiando en lugar de una
pueda evaluar el impacto de los cambios en los representación alternativa de ese sistema
requerimientos.
Representación de un sistema debería mantener
Desde una perspectiva evolutiva, los requerimientos toda la información sobre la entidad que se está
se dividen en dos clases: representando
l. Requerimientos duraderos Una abstracción simplifica y resalta de forma
deliberada las características más relevantes.
Son requerimientos relativamente estables que se
derivan de la actividad principal de la organización y 3.3 Ejemplos de tipos de modelos del sistema
que están relacionados directamente con el dominio
3.3.1 1. Un modelo de flujo de datos. Los modelos
del sistema. Por ejemplo, en un hospital siempre
de flujo de datos muestran cómo se procesan los
habrá requerimientos que se refieren a los
datos en el sistema en diferentes etapas.
pacientes, médicos, enfermeras y tratamientos.
3.3.2 2. Un modelo de composición. Un modelo de
2. Requerimientos volátiles.
composición o agregación muestra cómo las
Son requerimientos que probablemente cambian entidades del sistema están compuestas por otras
durante el proceso de desarrollo del sistema o entidades.
después de que éste se haya puesto en
3.3.3 3. Un modelo arquitectónico. Los modelos
funcionamiento. Un ejemplo serían los
arquitectónicos muestran los principales
requerimientos resultantes de las políticas
subsistemas que componen un sistema.
gubernamentales sobre sanidad.
3.3.4 4. Un modelo de clasificación. Los diagramas
3 Modelos del sistema.
de clases/herencia de objetos muestran cómo las
3.1 Introducción entidades tienen características comunes.
3.1.1 Pueden usarse modelos en el proceso de 3.3.5 5. Un modelo de estímulo-respuesta. Un
análisis para comprender el sistema existente que modelo de estímulo respuesta o diagrama de
debe ser reemplazado o mejorado, o para transición de estados muestra cómo reacciona el
especificar el nuevo sistema que sea requerido. sistema a eventos internos y externos.
Pueden desarrollarse diferentes modelos para
3.4 1. Modelos de contexto
representar el sistema desde diferentes
perspectivas. 3.4.1 En una de las primeras etapas de la obtención
de requerimientos y del proceso de análisis se deben
Por ejemplo
definir los límites del sistema. Esto comprende
Una perspectiva externa, en la que se modela el trabajar conjuntamente con los stakeholders del
contexto o entorno del sistema. sistema para distinguir lo que es el sistema y lo que
es el entorno del sistema.
Una perspectiva de comportamiento, en la que se
modela el comportamiento del sistema. 3.4.2 La definición de un límite del sistema no es una
decisión arbitraria. Aspectos sociales y
Una perspectiva estructural, en la que se modela la
organizacional pueden implicar que la situación de
arquitectura del sistema o la estructura de los datos
los límites de un sistema puedan ser determinados
procesados por el sistema.
por factores no técnicos.
3.2 Concepto
3.5 2. Modelos de comportamiento
3.5.1 Se utilizan para describir el comportamiento Es una lista de nombres ordenada alfabéticamente
del sistema en su totalidad incluida en los modelos del sistema. Debería incluir,
además del nombre, una descripción asociada de
3.5.2 tipos de modelos de comportamiento
dicha entidad con nombre y, si el nombre representa
Modelos de flujo de datos un objeto compuesto, una descripción de la
composición. Se puede incluir otra información,
modelos de flujo de datos, que modelan el
como la fecha de creación, el creador y la
procesamiento de los datos en el sistema
representación de la entidad dependiendo del tipo
Son una forma intuitiva de mostrar cómo los datos de modelo que se esté desarrollando.
son procesados por un sistema. A nivel de análisis,
Las ventajas de usar un diccionario de datos
deberían usarse para modelar la forma en la que los
datos son procesados en el sistema existente. Estos . Es un mecanismo para la gestión de nombres.
modelos son una parte intrínseca de los métodos
Sirve como un almacén de información de la
estructurados que han sido desarrollados a partir de
organización.
este trabajo.
3.7 4. Modelos de Objetos
La notación
3.7.1 Los modelos de objetos que usted desarrolla
Procesamiento funcional (rectángulos
durante el análisis de requerimientos pueden
redondeados),
utilizarse para representar tanto los datos del
Los almacenes de datos (rectángulos) sistema como su procesamiento. A este respecto,
dichos modelos combinan algunos de los usos de los
Flujo de datos entre funciones (flechas etiquetadas).
modelos de flujo de datos y los modelos semánticos
Modelos de máquina de estados de datos. Los modelos de objetos también son útiles
para mostrar cómo se clasifican las entidades en el
Describe cómo responde un sistema a eventos
sistema y se componen de otras entidades.
internos o externos. El modelo de máquina de
estados muestra los estados del sistema y los 3.7.2 Modelos de herencia
eventos que provocan las transiciones de un estado
El modelado orientado a objetos implica la
a otro. No muestra el flujo de datos dentro del
identificación de clases de objetos que son
sistema
importantes en el dominio que se está estudiando.
3.6 3. Modelos de datos
Una taxonomía es un esquema de clasificación que
3.6.1 Una parte importante del modelado de muestra cómo una clase de objetos está relacionada
sistemas es la definición de la forma lógica de los con otras clases a través de atributos y servicios
datos procesados por el sistema. Estos se comunes.
denominan a menudo modelos semánticos de
Para mostrar esta taxonomía, las clases se organizan
datos.
en una jerarquía de herencia con las clases de
3.6.2 La técnica de modelado de datos más objetos más generales al principio de la jerarquía.
ampliamente usada es el modelado Entidad- Los objetos más especializados heredan sus
Relación-Atributo (modelado ERA) , que muestra las atributos y servicios. Estos objetos especializados
entidades de datos, sus atributos asociados y al igual pueden tener sus propios atributos y servicios.
que todos los modelos gráficos, a los modelos de
3.7.3 Agregación de objetos
datos les faltan detalles
Así como se adquieren atributos y servicios a través
3.6.3 Los diccionarios de datos
de una relación de herencia con otros objetos,
algunos objetos son agrupaciones de otros objetos. 4. Un diccionario de datos que mantiene
Es decir, un objeto es un agregado de un conjunto de información sobre las entidades utilizadas en el
otros objetos. Las clases que representan a estos diseño de un sistema.
objetos pueden modelarse utilizando un modelo de
5. Herramientas de generación y definición de
agregación
informes que obtienen información del almacén
3.7.4 Modelado de comportamiento de objetos central y generan automáticamente la
documentación del sistema.
Para modelar el comportamiento de los objetos, se
tiene que mostrar cómo se utilizan las operaciones 6. Herramientas de definición de formularios que
proporcionadas por los objetos. En UML , se permiten especificar los formatos de pantallas y de
modelan los comportamientos utilizando escenarios documentos.
que son representados como casos de uso UML
7. Facilidades para importar/exportar que permiten
3.8 5. Métodos estructurados el intercambio de información desde el repositorio
central con otras herramientas de desarrollo.
3.8.1 Un método estructurado es una forma
sistemática de elaborar modelos de un sistema 8. Generadores de código que generan código o
existente o de un sistema que tiene que ser esqueletos de código de forma automática a partir
construido. Fueron desarrollados por primera vez en del diseño capturado en el almacén central.
la década de los 70 para soportar el análisis y el
4 ESPECIFICACIÓN DE SISTEMAS CRÍTICOS
diseño del software (Constantine y Yourdon, 1979;
Gane y Sarson, 1979; Jackson, 1983) y evolucionaron 4.1 CONCEPTO
en las décadas de los 80 y de los 90 para soportar el
4.1.1 La especificación de los sistemas críticos refleja
desarrollo orientado a objetos (Rumbaugh et al.,
con exactitud las necesidades reales de los usuarios
1991; Robinson, 1992; Jacobsen,
del sistema. Si no se consigue la especificación
3.8.2 Las herramientas que soportan métodos correcta, entonces, independientemente de la
completos, calidad del desarrollo del software. el sistema no
será confiable.
1. Editores de diagramas utilizados para crear
modelos de objetos, modelos de datos, modelos de 4.1.2 La necesidad de confiabilidad en los sistemas
comportamiento, etcétera. Estos editores no son críticos genera requerimientos funcionales y no
simplemente herramientas de dibujo puesto que funcionales del sistema:
identifican los tipos de entidades en el diagrama.
1. Los requerimientos funcionales del sistema se
Captan la información sobre estas entidades y
generan para definir la comprobación de errores y
guardan esta información en el repositorio central.
facilidades de recuperación y características que
2. Herramientas de análisis y comprobación de proporcionan protección frente a fallos de
diseños que procesan el diseño e informan sobre funcionamiento del sistema.
errores y anomalías. Pueden integrarse con el
2. Los requerimientos no funcionales se generan
sistema de edición para que los errores del usuario
para definir la fiabilidad y disponibilidad requeridas
sean detectados en etapas tempranas del proceso
por el sistema.
de desarrollo.
4.2 1. ESPECIFICACIÓN DIRIGIDA POR RIESGOS
3. Lenguajes de consulta del repositorio que permite
al diseñador encontrar diseños e información 4.2.1 Su objetivo es comprender los riesgos con los
asociada a los diseños en el repositorio. que se enfrenta el sistema y generar requerimientos
de confiabilidad para tratar dichos riesgos. La
especificación dirigida por riesgos es una que definen la fiabilidad y disponibilidad de la
aproximación que ha sido ampliamente utilizada por protección del sistema. Dichos requerimientos están
los desarrolladores de sistemas de seguridad críticos basados en la forma esperada de uso del sistema de
y sistemas de protección críticos. protección y pretenden asegurar que dicho sistema
funcionará cuando sea necesario.
4.2.2 1. Identificación de riesgos.
4.4 3. ESPECIFICACIÓN DE LA PROTECCIÓN
Se identifican los riesgos potenciales que podrían
surgir. Éstos dependen del entorno en el que se va a 4.4.1 La especificación de los requerimientos de
utilizar el sistema. protección para los sistemas tiene algo en común
con los requerimientos de seguridad. No es práctico
4.2.3 2. Análisis y dasificación de riesgos.
especificarlos cuantitativamente, y los
Los riesgos se consideran de foma independiente. requerimientos de protección son a menudo
Aquellos que son potencialmente serios y no requerimientos «no debería» que definen
previsibles se seleccionan para un análisis posterior. comportamientos inaceptables del sistema en lugar
En esta etapa, algunos riesgos pueden eliminarse de funcionalidades requeridas del mismo.
simplemente debido a que es muy improbable que
4.4.2 Las etapas de este proceso son:
surjan (por ejemplo, tormentas eléctricas y
terremotos). 1. Identificación y evaluación de activos.
4.2.4 3. Descomposición de riesgos. Se identifican los activos (datos y programas) y su
grado de protección requeridos. Dicha protección
Cada riesgo se analiza individualmente para
requerida depende del valor del activo, de forma
descubrir las causas potenciales fundamentales de
que un fichero de contraseñas (por ejemplo) es
ese riesgo. Se pueden utilizar técnicas tales como el
normalmente más valioso que un conjunto de
análisis del árbol de defectos
páginas web públicas, ya que un ataque con éxito
4.2.5 4. Valoración de la reducción de riesgos. sobre el fichero de contraseñas tendrá
consecuencias serias en todo el sistema.
Se hacen propuestaloi sobre las formas en las que
los riesgos identificados pueden reducirse o 2. Análisis de amenazas y valoración de riesgos.
eliminarse. Éstos generan entonces requerimientos
Se identifican posibles amenazas de protección y se
de confiabilidad del sistema que definen las
estiman los riesgos asociados con cada una de estas
defensas frente al riesgo y cómo el riesgo va a ser
amenazas.
gestionado si ocurre.
3. Asignación de amenazas.
4.3 2. ESPECIFICACIÓN DE LA SEGURIDAD
Las amenazas identificadas se relacionan con los
4.3.1 El proceso de especificación y garantía de
activos de forma que para cada activo identificado
seguridad es parte de un ciclo de vida completo de
exista una lista de amenazas.
seguridad definido en un estándar internacional
para la gestión de seguridad lEC61508 (lEC. 1998). 4. Análisis de la tecnología.
Este estándar se desarrolló específicamente para la
Se evalúan las tecnologías disponibles y su
protección de sistemas
aplicabilidad contra las amenazas identificadas.
4.3.2 l. Requerimientos de seguridad funcionales
5. Especificación de los requerimientos de
que definen las funciones de seguridad del sistema. protección.
4.3.3 2. Requerimientos de integridad seguros Se especifican los requerimientos de protección. En
donde sea apropiado, éstos identificarán
explícitamente las tecnologías de protección que 5.1.2 La denominación métodos formales se usa
pueden utilizarse para proteger al sistema contra las para referirse a cualquier actividad relacionada con
amenazas identificadas. representaciones matemáticas del software,
incluyendo la especificación formal de sistemas,
4.5 4. ESPECIFICACIÓN DE LA FIABILIDAD DEL
análisis y demostración de la especificación. el
SOFTWARE
desarrollo transformacional y la verificación de
4.5.1 La fiabilidad es un concepto complejo que programas. Todas estas actividades dependen de
siempre se debería considerar a nivel de sistema en una especificación formal del software
lugar de a nivel de componente individual. Debido a
5.1.3 Existen cuatro razones principales para esto:
que los componentes de un sistema son
interdependientes, un fallo en un componente l. Una ingeniería del software exitosa.
puede propagarse al resto del sistema y afectar al
2. Cambios en el mercado.
funcionamiento de otros componentes. En un
sistema informático. 3. Ámbito limitado de los métodos formales.
4.5.2 se deben considerar tres dimensiones cuando 4. Escalabilidad limitada de los métodos formales.
se especifique la fiabilidad del sistema en su
5.2 1. ESPECIFICACIÓN FORMAL EN EL PROCESO DEL
totalidad:
SOFTWARE
l. Fiabilidad del hardware.
5.2.1
¿Cuál es la probabilidad de que un componente
hardware falle y cuánto tiempo se tarda en reparar
dicho componente?
2. Fiabilidad del software.
¿Cuál es la probabilidad de que un componente
software produzca una salida incorrecta? Los fallos
del software son distintos de los fallos del hardware
en tanto que el software no se desgasta: éste puede
continuar funcionando correctamente después de
que se haya producido un resultado incorrecto.
3. Fiabilidad del operador. 5.2.2

¿Cuál es la probabilidad de que el operador de un

sistema cometa un error?
5 ESPECIFICACIÓN FORMAL
5.1 CONCEPTO
5.1.1 Una especificación formal del software es una
especificación expresada en un lenguaje cuyo
vocabulario, sintaxis y semántica están formalmente
definidos. Esta necesidad de una definición formal
significa que los lenguajes de especificación deben
basarse en conceptos matemáticos cuyas
propiedades se comprendan bien
5.2.3 Una especificación formal del software es una subsistema combinando las especificaciones de los
especificación expresada en un lenguaje cuyo objetos que componen la interfaz.
vocabulario, sintaxis y semántica están formalmente
5.3.4 La estructura de la especificación de un objeto
definidos. Esta necesidad de una definición formal
se muestra en la Figura 10.6. El cuerpo de la
significa que los lenguajes de especificación deben
especificación tiene cuatro componentes:
basarse en conceptos matemáticos cuyas
propiedades se comprendan bien 5.4 3. ESPECIFICACIÓN DEL COMPORTAMIENTO
5.2.4 Si se desarrolla una especificación formal del 5.4.1 Una aproximación alternativa a la
software, ésta normalmente tiene lugar después de especificación formal que se está utilizando cada vez
que se hayan especificado los requerimientos del más en proyectos industriales es la especificación
sistema, pero antes del diseño detallado de dicho basada en modelos. La especificación basada en
sistema. Aquí hay un estrecho bucle de modelos es una aproximación a la especificación
realimentación entre la especificación detallada de formal en la que la especificación del sistema se
los requerimientos y la especificación formal. expresa como un modelo de estados del sistema. Se
pueden especificar las operaciones del sistema
5.3 2. ESPECIFICACIÓN DE INTERFACES DE
definiendo cómo éstas afectan ai estado del modelo
SUBSISTEMAS
del sistema.
5.3.1

5.3.2 Los grandes sistemas se descomponen

normalmente en subsistemas que se desarrollan de
forma independiente. Los subsistemas usan otros
subsistemas; por lo tanto, una parte esencial del
proceso de especificación es la definición de
interfaces de subsistemas. Una vez que los
interfaces se han acordado y definido, los
subsistemas pueden entonces diseñarse e
implementarse de forma independiente.
5.3.3 Los interfaces de subsistemas se definen a
menudo como un conjunto de objetos o
componentes (Figura 10.5). Éstos describen los
datos y operaciones a los que puede acceder a
través de la interfaz del subsistema. Por lo tanto, se
puede definir una especificación de la interfaz de un