Este documento presenta un resumen del capítulo 1 sobre los requerimientos de software. Explica los conceptos básicos de los requerimientos, incluyendo su definición, los requerimientos funcionales y no funcionales, y los requerimientos de procesos y productos. También describe el proceso de requerimientos, incluyendo las actividades de elicitación, análisis, especificación y validación de requerimientos. Finalmente, identifica a los actores clave en el proceso de requerimientos como usuarios, clientes, ingenieros de
1. TRADUCCIÓN DEL CAPITULO 1
REQUERIMIENTOS DE SOFTWARE
PRESENTADO POR:
JESUS ANDRES MORALES RODRIGUEZ
CODIGO:
1090423748
PRESENTADO A:
DOCENTE. JOHANN LATORRE
FACULTA DE CIENCIAS ECONOMICAS Y EMPRESARIALES
UNIVERSIDAD DE PAMPLONA
SEDE DE VILLLA DEL ROSARIO
SAN JOSE DE CUCUTA 21 DE ABRIL DEL 2014
2. Capitulo 1
REQUERIMIENTOS DE SOFTWARE
SIGLAS
INTRODUCCION
El Área de Conocimiento de Exigencias de Software el (AC) está preocupado por
el análisis, la especificación, y la validación de exigencias de software.
Extensamente es reconocido dentro de la industria que el software que traza
proyectos es críticamente vulnerable cuando estas actividades son realizadas mal.
Las exigencias de software expresan las necesidades y coacciones colocadas
sobre un producto de software que contribuye a la solución de algún problema
mundial verdadero.
El término " exigencias de la ingeniería" es extensamente usado en el campo para
denotar el manejo sistemático de exigencias. Por motivos de consistencia, el
término "ingeniería" no será usado en la Guía sino para otra cosa que el software
que trama en sí.
Por la misma razón, "las exigencias del ingeniero," un término que aparece en un
poco de la literatura, no será usado tampoco. En cambio, el término "el ingeniero
de software" o, en algunos casos específicos, " el especialista de exigencias " será
usado, éste el donde el papel en cuestión por lo general es realizado por un
individuo otro que un ingeniero de software. Esto no implica, sin embargo, que un
ingeniero de software no pueda realizar la función.
Un riesgo inherente en la interrupción propuesta consiste en que un proceso
parecido a una cascada puede ser deducido. Para protegerse contra esto, el
subárea 2 Proceso de Exigencias, es diseñado para proporcionar una descripción
de alto nivel del proceso de exigencias disponiendo de los recursos y coacciones
bajo las cuales el proceso funciona y que actúan para configurarlo.
Una descomposición alterna podría usar una estructura a base de producto
(exigencias de sistema, exigencias de software, prototipos, casos de empleo,
etcétera). La interrupción a base del proceso refleja el hecho que el proceso de
exigencias, si debe ser acertado, debe ser considerado como un proceso que
implica el complejo, actividades
GDA: Gráfico Dirigido A cíclico
MTF: Medida de Tamaño Funcional.
COINSIS: Consejo internacional sobre Ingeniería de sistemas.
LUM: Lengua Unificada de Modelaje.
SML: Sistemas que Modelan el Lenguaje.
3. Figura 1: Interrupción de Asuntos para las Exigencias de Software
Requerimientos del
Software
Requerimientos del
software
fundamentales
Definicion de
Requerimientos del
Software
Requerimientos del
producto y los
procesos.
Requerimientos
funcionales y no
funcionales
Propiedades
Emergentes
Requerimientos
cuantificables
Requerimientos de
Software y
Requerimientos de
sistemas
Proceso de
Requerimientos
Modelo de Procesos
Actores de Procesos
Apoyo y Gestion de
Procesos
Proceso de Calidad y
Mejora.
Elicitación de
Requerimientos
Fuentes de
Requerimientos
Tecnicas de Elicitacion
Análisis de
Requerimientos
Clasificacion de
Requerimientos
Modelado Conceptual
Diseño Arquitectónico
y Asignación de
Requerimientos
Negociacion de
Requerimientos
Analisis Formal
Especificación de
Requerimientos
Documento de
Definicion de Sistema
Especificacion de los
Requerimientos del
Sistema
Especificacion de los
Requerimientos del
Software
Validación de
Requerimientos
Revisiones de
Requerimientos
Creacion de Prototipos
Validacion del Modelo
Pruebas de Aceptacion
Consideración Practica
Naturaleza Interactiva
del proceso de
requerimientos
Gestion del Cambio
Atributos de los
Requerimientos
Rastreo de los
Requerimientos
Medicion de los
Requerimientos
Herramientas de los
Requerimientos del
Software
4. Fuerte acopladas (tanto secuencial como simultáneo), más bien como una
actividad discreta, única realizada a comienzos de un proyecto de desarrollo de
software.
Las Exigencias de Software son relacionadas estrechamente con el Diseño de
Software, Pruebas de Software, el Mantenimiento de Software, la Dirección de
Configuración de Software, Ingeniería del mantenimiento de software, el Proceso
de Ingeniería de Software, Ingeniería de los Modelos y Métodos de Software, y la
Calidad de Software.
1. Requerimientos del Software fundamentales
1.1. Definición de un Software de requisito.
En su forma más básica, un requisito de software es una propiedad que debe ser
exhibida para solucionar algún problema en el mundo real. La guía se refiere a los
requisitos en "software" porque se refiere a los problemas a ser abordados por el
software. Por lo tanto, un requisito de software es una propiedad que debe ser
exhibida por el software desarrollado o adaptado para resolver un problema
particular. Dicho software puede apuntar para automatizar parte de una tarea de
quien usará el software, para apoyar los procesos de negocio de las organización
que ha encargado el software, las deficiencias correcta del software existente, o
para controlar un dispositivo — por nombrar solo algunos de los muchos
problemas para que el software soluciones son posibles. Las formas en que los
usuarios, los procesos de negocio y dispositivos función son típicamente
complejos. Por extensión, por lo tanto, los requisitos de software en particular son
típicamente una combinación compleja de los requisitos de diferentes personas en
diferentes niveles de organización y del ambiente en el que el software funcionará.
Una característica esencial de todos los requisitos de software es que sean
comprobables. Puede ser difícil o costoso para verificar ciertos requisitos de
software. Por ejemplo, verificación de los requisitos de rendimiento en un centro
de llamadas puede requerir el desarrollo de software de simulación. Tanto los
requisitos de software y calidad personal debe asegurarse de que los requisitos
pueden verificarse dentro de las limitaciones de recursos disponibles.
Los Requisitos tienen otros atributos además de las propiedades del
comportamiento que expresan. Los ejemplos más comunes incluyen un grado de
prioridad a permitir compensaciones ante recursos finitos y un valor de estado
para permitir el avance del proyecto a ser monitoreados. Por lo general, requisitos
de software únicamente son identificados para que ellos puedan ser sometidos a
control de la configuración del software y gestionados por el software todo el ciclo
de vida.
1.2. Requerimientos de proceso y producto
Se puede distinguir entre parámetros de producto y proceso. Parámetros del
producto son requisitos de software a desarrollarse (por ejemplo, "el software
5. verificará que un estudiante cumple con todos los requisitos antes de que él o ella
se registra para un curso").
Un parámetro de proceso es esencialmente una restricción en el desarrollo del
software (por ejemplo, "el software deberá estar escrito en Java"). Estos son a
veces conocidos como requisitos del proceso.
Algunos requisitos de software generan requisitos de proceso implícito. La
elección de la técnica de verificación es un ejemplo. Otro podría ser el uso de
técnicas de análisis particularmente riguroso (como los métodos de especificación
formal) para reducir fallas que pueden conducir a la insuficiente fiabilidad. También
podrán imponer requisitos de proceso directamente por la organización de
desarrollo, sus clientes, o terceros como un regulador de seguridad.
1.3. Funcionales y los requisitos no funcionales
Los requisitos funcionales describen las funciones que el software se va a
ejecutar; por ejemplo, formato de texto o una señal de modulación. Se conocen a
veces como capacidades. Los requisitos no funcionales son los que actúan para
restringir la solución.
Los requisitos no funcionales son a veces conocidos como restricciones o
requisitos de calidad. Se pueden clasificar más lejos según sean los requisitos de
rendimiento, requisitos de mantenimiento, los requisitos de seguridad, requisitos
de fiabilidad o uno de muchos otros tipos de requisitos de software (véase también
"Características de los modelos y calidad" en el Software de calidad KA)
1.4. Propiedades emergentes
Algunos requisitos representan propiedades emergentes de software — es decir,
requisitos que no puede ser tratado por un solo componente, pero que dependen
para su satisfacción sobre cómo inter operan todos los componentes de software.
El requisito de rendimiento para un centro de llamadas, por ejemplo, depende
cómo el sistema telefónico, el sistema de información y los operadores
interactuaban bajo condiciones de funcionamiento reales. Propiedades
emergentes dependen crucialmente de la arquitectura del sistema.
.5. Requisitos Cuantificables
Los requisitos de Software, deberían indicarse claramente y sin ambigüedad
posible y, cuando proceda, cuantitativamente. Es importante evitar los
requerimientos de vagos y no se puede comprobar que dependen para su
interpretación en juicio subjetivo ("el software será confiable"; "el software es fácil
de usar"). Esto es particularmente importante para los requisitos no funcionales.
Dos ejemplos de requisitos cuantificados son los siguientes: software de un centro
de llamadas debe aumentar el rendimiento del centro en un 20%; y un sistema
tendrá una probabilidad de generar un error fatal durante cualquier hora de
operación de menos de 1 * 10−188 8. El requisito de rendimiento es a un nivel
6. muy alto y es necesario utilizar para derivar una serie de requisitos detallados. El
requisito de confiabilidad limitará fuertemente la arquitectura del sistema.
1.6. Requisitos del sistema y los requisitos de Software
En este tema, "sistema" significa "una interacción combinación de elementos para
lograr un objetivo definido. Estos incluyen hardware, software, firmware, gente,
información, técnicas, instalaciones, servicios y otros elementos de apoyo”.
Requisitos del sistema son los requisitos para el sistema como un todo. En un
sistema que contiene componentes de software, requisitos de software se derivan
de los requisitos del sistema. La literatura sobre los requisitos a veces llama
requisitos del sistema "requisitos de usuario". La guía define "necesidades de los
usuarios" de manera restringida como los requisitos de los clientes o usuarios
finales del sistema. Requisitos del sistema, por el contrario, abarcan los
requerimientos del usuario, requisitos de otras partes interesadas (por ejemplo, las
autoridades reguladoras) y requisitos sin un origen humano identificable.
2. Proceso de Requisitos
Esta sección presenta el proceso de los requisitos del software, orientando las
restantes cinco subareas y mostrando cómo los requisitos concuerdan con el
proceso general de ingeniería de software.
2.1 Modelos de procesos.
El objetivo de este tema es proporcionar un entendimiento de que los requisitos
del proceso:
No son una actividad de principio a fin discreta, del ciclo de vida del
software, sino más bien un proceso iniciado al principio de un proyecto que
sigue siendo refinado durante todo el ciclo de vida.
Identifica los requerimientos de software como elementos de configuración
y los administra utilizando las mismas prácticas de gestión de configuración
del software como otro producto de los procesos de ciclo de vida del
software.
Debe ser adaptada al contexto y organización del proyecto.
En particular, el tema se refiere a cómo se configuran las actividades de
obtención, análisis, especificación y validación para los diferentes tipos de
proyectos y limitaciones. El tema también incluye actividades que proporcionan
insumos en el proceso de requisitos, tales como los estudios de Marketing y
viabilidad.
2.2 Actores del Proceso
Este tema presenta los roles de las personas que participan en el proceso de
requisitos.
7. Este proceso es fundamentalmente interdisciplinario, y el especialista en requisitos
necesita mediar entre el dominio de la parte interesada y la ingeniería de software.
A menudo hay muchas personas involucradas además del especialista de
requerimientos, cada uno de los cuales tiene una participación en el software. Las
partes interesadas variarán a través de proyectos pero siempre incluirá los
usuarios y operadores y clientes (que no tiene que ser el mismo).
Los ejemplos típicos de los actores de software incluyen (pero no están limitados
a):
Usuarios: Este grupo comprende aquellos que operarán el software. A
menudo es un grupo heterogéneo formado por personas con diferentes
funciones y requisitos.
Clientes: este grupo está conformado por aquellos que han encargado el
software o que representan el mercado objetivo del software.
Los analistas del mercado: un producto de Mercado masivo no tendrá una
puesta en servicio al cliente, así que a menudo se necesitan personas de
marketing para establecer lo que necesita el mercado y para actuar como
clientes.
Reguladores: muchos dominios de aplicación, como lo bancario y el
transporte público, se encuentran regulados. El software en estos dominios
debe cumplir con los requisitos de las autoridades reguladoras.
Ingenieros de Software: estos individuos tienen un interés legítimo en el
beneficio de desarrollar un software, por ejemplo, reutilizando los
componentes en otros productos. Si en este escenario, un cliente de un
producto en particular tiene necesidades específicas que comprometen las
posibilidades de reutilización de componentes, los ingenieros de software
deben pensar cuidadosamente su propio juego contra ésos del cliente.
No será posible satisfacer perfectamente las necesidades de todos los
interesados, y es trabajo del ingeniero software negociar las compensaciones
que sean aceptables a las principales partes interesadas y dentro del
presupuesto, técnicas regulatorias y otras restricciones. Un requisito previo
para esto es que todas las partes interesadas sean identificadas, la naturaleza
de su "inversión" analizadas y sus requerimientos sacados.
2.3. Apoyo y Gestión de Procesos.
Este tema presenta los recursos de gestión de proyectos requeridos y consumidos
por el proceso de requisitos. Establece el contexto para la primera subárea
(definición de iniciación y alcance) de la Gestión de Ingeniería de Software. Su
propósito principal es hacer el vínculo entre las actividades de proceso
identificadas en el punto 2.1 y las cuestiones de costo, recursos humanos,
capacitación y herramientas.
2.4. Proceso de calidad y mejora.
Este tema se refiere a la evaluación de la calidad y la mejora del proceso de
requisitos. Su propósito es hacer hincapié en el papel clave que juega el proceso
8. de requisitos en términos de costo y puntualidad de un producto de software y de
la satisfacción del cliente con él. Ayudará a orientar el proceso de requisitos con
estándares de calidad y modelos de mejora de procesos de software y sistemas.
Calidad del proceso y mejora se relaciona estrechamente tanto el Software calidad
KA y KA proceso de ingeniería del Software. Este tema se trata:
Requisitos de proceso, cobertura por estándares de mejora de procesos y
modelos;
Requisitos de proceso de medidas y benchmarking (proceso sistemático y
continuo para evaluar los productos, servicios y procesos de trabajo de las
organizaciones);
Planificación de la mejora e implementación.
3. Licitación de Requerimientos
La licitación de requisitos se refiere a la procedencia de requisitos de software y
cómo el ingeniero de software puede juntarlos. Es la primera etapa en la
construcción de una comprensión del problema del software que es necesaria
para resolver. Es fundamentalmente una actividad humana y es donde se
identifican los actores y las relaciones establecidas entre el equipo de desarrollo y
el cliente. Varios la denominan "captura de requisitos", "descubrimiento de
requisitos" y "adquisición de requisitos".
Uno de los principios fundamentales de la buena Ingeniería de software es que
hay buena comunicación entre los actores del software e ingenieros de software.
Antes de que comience el desarrollo, especialistas en requisitos pueden formar el
conducto para la comunicación. Deben mediar entre el dominio de los usuarios del
software (y otras partes interesadas) y el mundo técnico del ingeniero de software.
Un elemento crítico de la e licitación de requisitos es informar el alcance del
proyecto. Se trata de proporcionar una descripción del software a ser especificado
y su propósito, priorizando las entregas para garantizar que se satisfacen las
necesidades del cliente más importantes del negocio, primero. Esto reduce el
riesgo de que los especialistas de requisitos demoren más tiempo e licitando
requisitos que son de poca importancia o aquellos que resultan ya no ser
relevantes cuando el software se es entregado.
3.1. Fuentes de Requisitos.
Los requisitos tienen muchas fuentes en el software típico, y es esencial que todas
las fuentes potenciales sean identificadas y evaluadas. Este tema está diseñado
para promover el conocimiento de las distintas fuentes de requisitos de software y
de los marcos para gestionarlos. Son los puntos principales cubiertos:
Objetivos. El término "objetivo" (a veces llamado "la preocupación de
negocio" o "factor crítico de éxito") se refiere a los objetivos generales de
alto nivel del software. Los objetivos proporcionan la motivación para el
software pero son a menudo vagamente formulados. Los Ingenieros de
software necesitan prestar especial atención a la evaluación del valor (en
9. relación con prioridad) y costo de las metas. Un estudio de viabilidad es una
forma relativamente barata de hacer esto.
Conocimiento de dominio. El ingeniero de software necesita adquirir o
disponer, conocimiento sobre el dominio de aplicación. El conocimiento del
dominio proporciona el fondo contra el cual deben establecerse requisitos
sacando todos los conocimientos para entenderlo.
Partes interesadas (véase tema 2.2 actores del proceso). Muchos software
han demostrado ser satisfactorios porque lo han subrayado las necesidades
de un grupo de partes interesadas a expensas de los demás. Por lo tanto,
el software suministrado es difícil de usar o subvierte las estructuras
culturales o políticas de la organización del cliente. El ingeniero de software
debe identificar, representar y administrar los "miradores" de muchos tipos
diferentes de las partes interesadas.
Reglas del negocio. Estas son declaraciones que definen o limitan algunos
aspectos de la estructura o el comportamiento del negocio propio. "Un
estudiante no puede registrarse en cursos del próximo semestre si quedan
algunos sin pagar la matrícula" sería un ejemplo de una regla de negocio
que sería una fuente de requisito para el software de registro de curso de
una universidad.
El entorno operativo. Los requisitos se derivarán del ambiente en el cual se
ejecutará el software. Estos pueden ser, por ejemplo, restricciones de
sincronización en tiempo real del software o interoperabilidad restricciones
en un ambiente de negocios. Estos deben ser activamente buscados
porque pueden en grandes proporciones afectar la factibilidad y costo del
software así como restringir las opciones de diseño.
El clima organizacional. Un software es a menudo necesario para apoyar un
proceso de negocio, la selección de los cuales puede estar condicionada
por la estructura, la cultura y la política interna de la organización. Las
necesidades del ingeniero de software deben ser sensibles a estos ya que,
en general, un nuevo software no debería obligar a un cambio imprevisto en
los procesos de negocio.
3.2. Técnicas de E licitación.
Una vez que se han identificado las fuentes de requisitos, el ingeniero de software
puede empezar a obtener la información de requisitos de ellos. Tenga en cuenta
que los requisitos son rara vez sacados o confeccionados. Por el contrario, el
ingeniero de software provoca que se formulen los requerimientos de información.
Este tema se centra en las técnicas para conseguir actores humanos para articular
la información relacionada con los requisitos. Es una tarea muy difícil y el
ingeniero de software debe sensibilizarse al hecho de que los usuarios (por
ejemplo) pueden tener dificultades para describir sus tareas, pueden dejar
importante información que no se expresa o pueden ser incapaces de cooperar.
Es particularmente importante entender que la e licitación no es una actividad
pasiva y que, incluso si actores cooperativos y articulados están disponibles, el
ingeniero de software tiene que trabajar duro para obtener la información correcta.
Gran parte de los negocios o los requerimientos técnicos es tácito o en
10. comentarios que aún debe obtenerse de los usuarios finales. No puede
exagerarse la importancia de la planificación, verificación y validación en toma de
requerimientos. Existe un número de técnicas para la toma de requerimientos,
siendo los principales:
Entrevistas. un medio "tradicional" de obtención de requisitos. Es
importante comprender las ventajas y limitaciones de las entrevistas y cómo
debe realizarse.
Escenarios, significa un valioso contexto para proporcionar la e licitación de
requisitos de usuario. Permiten al ingeniero de software proporcionar un
marco para preguntas acerca de las tareas del usuario permitiendo que "si"
y "Cómo se hace esto" sean preguntas que formular. El tipo más común de
escenario es la descripción de casos de uso. Hay un enlace a topic4.2
(modelado Conceptual) porque las notaciones de escenario como
diagramas de casos de uso son comunes en software de modelado.
Prototipos, una valiosa herramienta para clarificar los requisitos claros.
Pueden actuar de una manera similar a escenarios ofreciendo a los
usuarios un contexto dentro del cual puedan entender mejor qué
información necesitan proporcionar. Hay una amplia gama de técnicas de
prototipos de maquetas de papel, de diseños de pantalla a las versiones
beta-test de productos de software y un fuerte compromiso de su propio uso
por separado para la toma de requerimientos y validación de requisitos (Ver
tema 6.2 Prototipos).
Facilitación de reuniones. El propósito de estos encuentros es tratar de
lograr un efecto sumatorio, por el que un grupo de personas puede aportar
una visión más clara en sus requerimientos de software que al trabajar
individualmente. Pueden pensar y refinar ideas que pueden ser difíciles de
llevar a la superficie mediante entrevistas. Otra ventaja es que los requisitos
de superficie pueden ser contradictorios desde el principio de una manera
que permite a las partes interesadas reconocer donde hay conflicto.
Cuando funciona bien, esta técnica puede resultar en una serie de
requisitos más rica y más consistente de lo contrario podría ser factible. Sin
embargo, las reuniones deben ser manipuladas con cuidado (por lo tanto, la
necesidad de un facilitador) para prevenir una situación en la cual las
capacidades críticas del equipo están erosionadas por lealtad de grupo o en
los requisitos que refleja las preocupaciones de algunas personas
abiertamente (y quizás último) son favorecidas en detrimento de otros.
Observación. La importancia del contexto de software en el entorno
organizacional ha llevado a la adaptación de las técnicas observacionales
como etnografía para toma de requerimientos. Ingenieros de software
aprenden acerca de las tareas del usuario que se sumerge en el ambiente y
observando cómo los usuarios realizan sus tareas al interactuar con los
demás y con herramientas de software y otros recursos. Estas técnicas son
relativamente caras pero también instructivas porque ilustran muchas
tareas de usuario y procesos de negocios que son muy sutiles y complejos
para que sus actores puedan describir fácilmente.
11. Historias de usuario. Esta técnica se utiliza comúnmente en metodologías
ágiles (vea el tema "Métodos ágiles" en el área de conocimiento de
métodos y modelos de ingeniería de Software) y se refiere a las
descripciones cortas de alto nivel de funcionalidad requerida expresada en
términos de atención al cliente. Una historia de usuario está destinada a
contener suficiente información para que los desarrolladores puedan
producir una estimación razonable del esfuerzo para implementarlo. El
objetivo es evitar algunos de los residuos que suceden a menudo en
proyectos donde están reunidos los requisitos detallados anteriormente
pero deben ser válidos antes de que comience el trabajo. Antes de
implementar una historia de usuario, deberá escribirse un procedimiento
apropiado de aceptación por parte del cliente para determinar si se han
cumplido los objetivos de la historia de usuario.
Otras técnicas. Existe una variedad de otras técnicas para apoyar la e
licitación de requisitos de información y van desde análisis de productos de
la competencia a la aplicación de técnicas de minería de datos a utilizar
fuentes de bases de dominio, conocimiento o petición de cliente.
4. Análisis de requerimientos.
Este tema tiene que ver con el proceso de analizar los requisitos para:
Detectar y resolver conflictos entre requisitos.
Descubre los límites del software y de cómo debe interactuar con su
ambiente.
Requisitos del sistema elaborado para derivar requerimientos de software.
La visión tradicional del análisis de requerimientos ha sido que se reduzca el
Modelado conceptual utilizando uno de un número de métodos de análisis, tales
como el método de análisis estructurado. Mientras que el modelado conceptual es
importante, se incluye la clasificación de los requisitos para ayudar a informar
disyuntivas entre requisitos (clasificación de requisitos) y el proceso de establecer
estas disyuntivas (negociación de requisitos).
Debe tenerse cuidado para describir los requisitos precisamente lo suficiente para
permitir que los requisitos sean validados para su aplicación, verificando sus
costos para ser estimados.
4.1. Clasificación de los Requisitos.
Los requisitos se pueden clasificar en varias dimensiones. Los ejemplos incluyen:
Si el requisito es funcional o no funcional (Ver tema 1.3 requisitos
funcionales y no funcionales).
Si el requisito es derivado de uno o más requisitos de alto nivel o de una
propiedad emergente (véase tema 1.4 propiedades emergentes) o está
imponiendo directamente en el software de un participante o de alguna otra
fuente.
12. Si el requisito es sobre el producto o el proceso (véase 1.2 producto y
requisitos de proceso). Los requisitos en el proceso pueden restringir la
elección del contratista, el proceso de ingeniería de software para ser
adoptado o las normas a seguirse.
La prioridad del requisito. Cuanto mayor sea la prioridad, lo más esencial es
el requisito para cumplir los objetivos generales del software. A menudo se
clasifican en una escala de punto fijo como obligatorio, altamente deseable,
deseable, u opcional, la prioridad a menudo tiene que sopesar el costo de
desarrollo e implementación. La priorización de requisitos es necesaria no
sólo como un medio para filtrar requisitos importantes, sino también para
resolver los conflictos y planes de puesta en escena de las entregas, lo que
significa tomar decisiones complejas que requieran dominio detallado de los
conocimientos y habilidades de buena estimación. Sin embargo, a menudo
es difícil obtener información real que puede actuar como una base para
este tipo de decisiones. Además, los requisitos a menudo dependen
mutuamente y sus prioridades son relativas. En la práctica, ingenieros de
software realizan priorización de requerimientos con frecuencia sin conocer
todos los requisitos.
El alcance del requisito. Este ámbito de aplicación se refiere a la medida en
que afecta un requisito del software y componentes de software. Algunos
requisitos, especialmente los no funcionales, tienen un alcance global en
que su satisfacción no puede asignarse a un componente discreto. Por lo
tanto, un requisito con ámbito global afecta fuertemente a la arquitectura de
software y el diseño de muchos componentes, mientras que uno con un
alcance acotado puede ofrecer un número de opciones de diseño y tienen
poco impacto en la satisfacción de otras necesidades.
Volatilidad/estabilidad. Algunos requisitos cambiarán durante el ciclo de
vida del software e incluso durante el proceso de desarrollo propio. Es útil si
se puede hacer una estimación de la probabilidad de que un requisito va a
cambiar. Por ejemplo, en una aplicación bancaria, los requisitos de las
funciones para calcular el interés de crédito de las cuentas de los clientes
serán probablemente más estables que un requisito para apoyar un tipo
particular de cuenta libre de impuestos. Los primeros reflejan una
característica fundamental del dominio bancario (que cuentas pueden ganar
interés), mientras que este último puede ser obsoleta por un cambio en la
legislación del gobierno. Al marcar los requisitos potencialmente volátiles
puede ayudar al ingeniero de software a establecer un diseño que es más
tolerante al cambio.
Otras clasificaciones pueden ser apropiadas, dependiendo de la práctica habitual
de la organización y de la propia aplicación.
Hay una fuerte superposición entre la clasificación de los requisitos y atributos de
requisitos (véase tema 7.3 requisitos atributos).
13. 4.2. Modelado conceptual.
El desarrollo de modelos de un problema del mundo real es clave para el análisis
de requisitos de software. Su propósito es ayudar a comprender el problema, más
que todo para iniciar el diseño de la solución. Por lo tanto, los modelos
conceptuales constituyen modelos de entidades del problema de dominio
configurado para reflejar sus reales relaciones y dependencias. Este tema está
estrechamente relacionado al área de conocimiento de métodos y modelos de
ingeniería de Software.
Se pueden desarrollar varios tipos de modelos. Estos incluyen diagramas de
casos de uso, modelos de flujo de datos, modelos de estado, los modelos basados
en la meta, las interacciones del usuario, modelos de objetos, modelos de datos y
muchos otros. Muchas de estas notaciones de modelado son parte de la Unified
Modeling Language (UML). Diagramas de casos de uso, por ejemplo, se utilizan
habitualmente para proporcionar un medio de representar el límite de software,
una vista de alto nivel de su comportamiento (los casos de uso) y los actores en el
entorno de software.
Los factores que influyen en la elección de la notación de modelado incluyen:
La naturaleza del problema. Algunos tipos de software demandan que
algunos aspectos se analicen rigurosamente. Por ejemplo, los estados y
modelos paramétricos, que forman parte de SysML [2], son propensos a ser
más importante para el software en tiempo real que para los sistemas de
información, mientras que normalmente sería lo contrario para los modelos
de objeto y actividad.
La experiencia del ingeniero de software. Suele ser más productivo de
adoptar la notación de modelado o método con el cual el ingeniero de
software tiene experiencia.
Los requisitos del proceso del cliente (Ver tema 1.2 requerimientos de
proceso y producto). Los clientes pueden imponer su notación favorecida o
método o prohibir que son desconocidos. Este factor puede entrar en
conflicto con el factor anterior.
Tenga en cuenta que, en casi todos los casos, es útil comenzar con la
construcción de un modelo del contexto de software. El contexto de software
proporciona una conexión entre el software previsto y su ambiente externo. Esto
es crucial para entender el contexto del software en su entorno operacional y la
identificación de sus interfaces con el medio ambiente.
Este tema no pretende "enseñar" un estilo particular de modelado o notación pero
proporciona una guía sobre el propósito y la intención de modelado.
4.3. Proyectos arquitectónicos y asignación de requisitos.
En algún momento, la arquitectura de la solución debe ser derivada. El diseño
arquitectónico es el punto en que el proceso de requisitos se superpone con el
diseño de software o sistemas e ilustra lo imposible que es separar limpiamente
14. las dos tareas. Este tema se relaciona estrechamente con la subzona de Software.
En muchos casos, el ingeniero de software actúa como arquitecto de software
porque el proceso de analizar y elaborar los requisitos exige que los componentes
que se encargan de satisfacer los requisitos deban ser identificados. Esta es la
asignación de requisitos, la asignación a los componentes de la responsabilidad
de satisfacer los requisitos.
La asignación es importante para permitir un análisis detallado de los requisitos.
Por lo tanto, por ejemplo, una vez que un conjunto de requisitos ha sido asignado
a un componente, las necesidades individuales pueden ser más analizadas para
descubrir aún más los requisitos de cómo el componente necesita interactuar con
otros componentes con el fin de satisfacer los requisitos asignados. En grandes
proyectos, la asignación estimula una nueva ronda de análisis para cada
subsistema. Por ejemplo, los requisitos para un determinado rendimiento de
frenado para un auto (distancia de frenado, condiciones de seguridad en la
conducción pobre, suavidad de aplicación, presión en el pedal requerida) pueden
asignarse al hardware frenado (Asambleas mecánicas e hidráulicas) y un sistema
de frenos antibloqueo (ABS). Sólo cuando se ha identificado un requisito para un
sistema de frenado antibloqueo, y los requisitos asignados a él, puede las
capacidades del ABS, el frenado hardware y propiedades emergentes (como el
peso del coche) utilizarse para identificar los requisitos detallados del software
ABS.
El diseño arquitectónico está estrechamente identificado con modelado conceptual
(Ver tema 4.2 modelado Conceptual).
4.4. Requisitos de negociación.
Otro término usado comúnmente para este subtema es "resolución de conflictos".
Esto concierne en resolver problemas con requisitos donde se producen conflictos
entre dos actores que requieren características mutuamente incompatibles, entre
recursos y requisitos o entre los requerimientos funcionales y no funcionales, por
ejemplo. En la mayoría de los casos, no es prudente para el ingeniero de software
tomar una decisión unilateral, y entonces se hace necesario consultar con las
partes interesadas para alcanzar un consenso sobre una compensación
adecuada. A menudo es importante, por razones contractuales, que tales
decisiones sean trazables al cliente. Hemos clasificado esto como un tema de
análisis de requisitos de software porque surgen problemas como el resultado del
análisis. Sin embargo, también puede hacerse un fuerte caso por considerarlo un
tema de validación de requisitos.
4.5. Análisis formal.
Las preocupaciones del análisis formal conciernen no sólo a la sección 4, sino
también al inciso 5.3 y 6.3. Este tema también está relacionado con el tema
"Métodos formales" en el área de conocimiento de métodos y modelos de
ingeniería de Software. El análisis formal ha tenido un impacto en algunos
dominios de aplicación, particularmente los de sistemas de alta integridad. La
15. expresión formal de los requisitos requiere un lenguaje con semántica
formalmente definida. El uso de un análisis formal para la expresión de requisitos
tiene dos ventajas. En primer lugar, permite a los requisitos expresados en el
lenguaje especificarse con precisión y sin ambigüedades, por lo tanto (en
principio) evitando la posibilidad de una interpretación errónea. En segundo lugar,
los requisitos se pueden razonar, permitiendo propiedades deseadas del software
especificado que debe ser probado. El razonamiento formal requiere herramientas
de apoyo que sean posible para que no sean sistemas y herramientas triviales que
generalmente caen en dos tipos; Teoremas o damas modelo. En ningún caso
puede probar ser completamente automatizado, y el nivel de competencia en
razonamiento formal necesario para utilizar las herramientas restringe la aplicación
más amplia del análisis formal.
El análisis más formal se centra en etapas relativamente tardías de análisis de
requerimientos. Es generalmente contraproducente aplicar formalización hasta los
objetivos de negocio y las necesidades de los usuarios han entrado bien
enfocadas a través de medios como los que se describe en la sección 4. Sin
embargo, una vez los requisitos se hayan estabilizado y elaborado para
especificar las propiedades concretas del software, puede ser beneficioso
formalizar al menos los requisitos críticos. Esto permite la validación estática del
software especificado por los requisitos; de hecho tiene las propiedades (por
ejemplo, ausencia de bloqueo) que el ingeniero de software, los usuarios y clientes
que esperan.
5. Especificación de los requisitos.
Para las profesiones de ingeniería, el término "especificación" se refiere a la
asignación de valores numéricos o límites objetivos de diseño de un producto. En
la jerga de la ingeniería de software, "especificación de requisitos de software" se
refiere normalmente a la producción de un documento que puede ser
sistemáticamente revisado, evaluado y aprobado. Para los sistemas complejos,
especialmente aquellos que involucran componentes de software no-
substanciales, tantos como tres diferentes tipos de documentos se producen:
definición de sistema, requisitos del sistema y requisitos de software. Para
productos de software simple, sólo la tercera parte de éstos se requiere. Los tres
documentos se describen aquí, con el entendimiento de que se puede combinar
según corresponda. Puede encontrarse una descripción de los sistemas de
ingeniería en las disciplinas relacionadas de Ingeniería de Software.
5.1. Documento de definición del sistema.
Este documento (a veces conocido como el documento de requisitos de usuario o
el concepto de operaciones) registra los requisitos del sistema. Define los
requisitos de alto nivel del sistema desde la perspectiva de dominio. Sus lectores
incluyen representantes de los usuarios/clientes de sistema (marketing puede
desempeñar estas funciones de software orientados al mercado), así que su
contenido debe ser redactado en términos de dominio. El documento enumera los
requisitos del sistema junto con información acerca de los objetivos generales para
16. el sistema, su entorno de destino y una declaración de las limitaciones, supuestos
y los requisitos no funcionales. Puede incluir modelos conceptuales diseñados
para ilustrar el contexto del sistema, los escenarios de uso y las entidades de
dominio principal, así como los flujos de trabajo.
5.2. Sistema de especificación de requisitos.
Los desarrolladores de sistemas con software substancial y componentes de
software — un avión moderno, por ejemplo — a menudo separan la descripción de
los requisitos del sistema de la descripción de requisitos de software. En este
punto de vista, se especifican los requisitos del sistema, los requisitos de software
se derivan de los requisitos del sistema, y luego se especifican los requisitos para
los componentes de software. Estrictamente hablando, especificación de
requisitos de sistema es una actividad de ingeniería de sistemas y cae fuera del
alcance de esta guía.
5.3. Software de especificación de requisitos.
El software de especificación de requisitos establece las bases para el acuerdo
entre clientes y contratistas o proveedores (en proyectos impulsados por el
mercado, estas funciones pueden ser interpretadas por las divisiones de marketing
y desarrollo) en lo que es el producto de software a hacer así como lo que no se
espera que haga.
El software de especificación de requisitos permite una evaluación rigurosa de los
requisitos, antes del diseño se puede comenzar y reducir el rediseño más
adelante. Asimismo deberá aportar una base realista para la estimación de los
horarios, los riesgos y los costos del producto.
Las organizaciones también pueden utilizar un documento de especificación de
requisitos de software para desarrollar sus propios planes de validación y
verificación más productivamente.
El software de especificación de requisitos proporciona una base informada para
transferir un producto de software a nuevos usuarios o plataformas de software.
Por último, puede proporcionar una base para la mejora de software.
Los requisitos de software a menudo están escritos en lenguaje natural, pero en el
software de especificación de requisitos, esto podrá completarse con las
descripciones formales o semi-formales. La selección de notaciones apropiadas
permite requisitos específicos y aspectos de la arquitectura de software que se
describirán más precisa y concisamente ese lenguaje natural. La regla general es
que se deben utilizar notaciones que permiten la mayor precisión posible de los
requisitos para ser descrito. Esto es particularmente crucial para críticos y ciertos
otros tipos de software confiable. Sin embargo, la elección de la notación a
menudo está limitada por la formación, habilidades y preferencias de los lectores y
autores del documento.
17. Una serie de indicadores de calidad han desarrollado, que puede utilizarse para
relacionar la calidad de la especificación de requisitos de software para otras
variables del proyecto como costo, aceptación, rendimiento, horario y
reproducibilidad. Los indicadores de calidad para las declaraciones de
especificación de requisitos software individual son imperativos, directivas, frases
débiles, opciones y aplazamientos. Los indicadores para el documento de
especificación de requisitos software completo incluyen tamaño, legibilidad,
especificación, profundidad y estructura del texto.
6. Validación de requisitos.
Los documentos de los requisitos pueden estar sujetos a procedimientos de
validación y verificación. Los requisitos pueden ser validados para asegurarse de
que el ingeniero de software ha comprendido los requisitos; también es importante
verificar que un documento de requisitos conforme a las normas de la empresa
debe ser entendible, coherente y completo. Notaciones formales ofrecen la ventaja
de permitir que las dos últimas propiedades deban ser probadas (en un sentido
restringido, por lo menos). Diferentes actores, incluyendo a representantes del
cliente y desarrollador, deben revisar los documentos. Los documentos de
requisitos están sujetos a las mismas prácticas de gestión de configuración de
software que las otras entregas de los procesos de ciclo de vida del software.
Es normal programar uno o más puntos en el proceso de requisitos donde se
validan los requisitos. El objetivo es recoger cualquier problema antes de que los
recursos se hayan comprometido a atender los requerimientos. La validación de
requisitos se refiere al proceso de examinar el documento de requisitos para
garantizar que se define el software adecuado (es decir, el software que los
usuarios esperan).
6.1. Comentarios de los requisitos.
Quizás los medios más comunes de validación son por inspección o revisiones del
documento de requisitos. Se asigna un grupo de árbitros para buscar errores,
suposiciones erróneas, falta de claridad y la desviación de la práctica estándar. La
composición del grupo que realiza la revisión es importante (al menos un
representante del cliente debe ser incluido en un proyecto orientado hacia el
cliente, por ejemplo), y puede ayudar a proporcionar orientación sobre lo que debe
buscar en forma de listas.
Los comentarios podrán estar constituidos al finalizar el documento de definición
del sistema, el documento de especificación del sistema, el documento de
especificación de requisitos de software, la especificación de línea de base para
una nueva versión, o en cualquier otro paso en el proceso.
6.2. Creación de un prototipo.
Los prototipos comúnmente son un medio para la validación de interpretación al
ingeniero de software de los requisitos de software, así como para la obtención de
nuevos requerimientos. Como con el desencadenamiento, hay una gama de
18. técnicas de creación de prototipos y una serie de puntos en el proceso donde la
validación del prototipo puede ser apropiado. La ventaja de los prototipos es que
pueden llegar más fácil a interpretar supuestos del ingeniero de software y, donde
sea necesario, dar información útil sobre por qué se equivocan. Por ejemplo, se
puede entender mejor el comportamiento dinámico de una interfaz de usuario a
través de un prototipo animado que a través de la descripción textual o modelos
gráficos. También hay desventajas, estos incluyen el peligro de que la atención de
los usuarios pueda distraerse del núcleo de la funcionalidad subyacente por
cuestiones cosméticas o problemas de calidad con el prototipo. Por esta razón,
algunos abogan por prototipos que eviten el software, tales como maquetas
basados en el portafolio. Los prototipos pueden ser costosos para desarrollar, sin
embargo, si evitan el despilfarro de recursos causado por intentar satisfacer
requisitos erróneos, su costo puede justificarse más fácilmente.
6.3. Modelo de validación.
Es normalmente necesario validar la calidad de los modelos desarrollados durante
el análisis. Por ejemplo, en modelos de objetos, es útil a la colección, un análisis
estático para verificar que existen vías de comunicación entre objetos que, en el
dominio de las partes interesadas, intercambian datos. Si se utilizan las notaciones
de análisis formal, es posible utilizar un razonamiento formal para probar las
propiedades de la especificación. Este tema está estrechamente relacionado con
los métodos y modelos de ingeniería de Software.
6.4. Aceptación de pruebas.
Una característica esencial de un requisito de software es que debe ser posible
validar que satisface el producto terminado. Requisitos que no pueden ser
validados son realmente "deseos". Una tarea importante es estar planeando cómo
comprobar cada requisito. En la mayoría de los casos, diseñar pruebas de
aceptación hace esto.
Identificar y diseñar pruebas de aceptación pueden ser difíciles para los requisitos
no funcionales (Ver tema 1.3 funcionales y los requisitos no funcionales). Para ser
validado, primero deben ser analizados y descompuestos al punto donde ellos
pueden expresarse cuantitativamente.
Información adicional puede encontrarse en el KA de pruebas de Software,
pruebas de aceptación/calificación/pruebas de conformidad.
7. Consideraciones Prácticas.
El primer nivel de descomposición de la subzona presentado puede parecer
describir una secuencia lineal de actividades. Esta es una visión simplificada del
proceso.
El proceso de requisitos extiende el ciclo de vida de todo software. La
administración de cambios y el mantenimiento de los requisitos de un estado que
19. refleja con precisión el software a construir, o que ha sido construido, es clave
para el éxito del proceso de ingeniería del software.
No toda organización tiene una cultura de documentación y gestión de requisitos.
Es común en empresas dinámicas, impulsadas por una fuerte "visión de producto"
y recursos limitados, ver la documentación de los requisitos como una sobrecarga
innecesaria. Más a menudo, sin embargo, a medida que estas empresas
aumentan, como su cliente base crece, y cuando su producto comienza a
evolucionar, descubren que tienen que recuperar los requisitos que motivaron
características del producto con el fin de evaluar el impacto de los cambios
propuestos. Por lo tanto, los requisitos documentación y gestión del cambio son
clave para el éxito de cualquier proceso de requisitos.
7.1. Naturaleza interactiva del proceso de requisitos.
Hay presión general en la industria del software para que haya ciclos de
desarrollos más cortos y esto es particularmente pronunciados en sectores
altamente competitivos, impulsados por el mercado. Además, la mayoría de
proyectos están limitados de alguna manera por su entorno, y muchos son
actualizaciones o revisiones de software existente donde la arquitectura es dada.
Por lo tanto, en la práctica casi siempre resulta poco práctico implementar el
proceso de requisitos como un proceso lineal y determinista en que el software de
requisitos es sacado de las partes interesadas, asignado y entregado al equipo de
desarrollo de software. Ciertamente es un mito que los requisitos para grandes
proyectos de software son siempre perfectamente entendidos o perfectamente
especificados.
En cambio, los requisitos normalmente interactúan hacia un nivel de calidad y
detalle suficiente para permitirle a las decisiones de diseño y aprovisionamiento
realizarse. En algunos proyectos, esto puede resultar ser una base ante todas sus
propiedades que se entienden plenamente en los requisitos. El riesgo es que el
trabajo sea costoso si surgen problemas en el proceso de ingeniería de software.
Sin embargo, los ingenieros de software están necesariamente limitados por
planes de gestión de proyecto y por lo tanto, deben tomar medidas para
asegurarse de que la “calidad” de los requisitos sea lo más alta posible dados los
recursos disponibles. Deberían, por ejemplo, hacer explícitamente las
suposiciones que apuntan los requisitos, así como problemas conocidos.
En casi todos los casos proceden requisitos de comprensión que siguen
evolucionando el diseño y desarrollo. Esto a menudo conduce a la revisión de los
requisitos en el ciclo de vida. Quizás el punto más crucial en el entendimiento de la
ingeniería de requerimientos es que una proporción significativa de los
requerimientos va a cambiar. Esto es a veces debido a errores en el análisis, pero
con frecuencia es una consecuencia inevitable del cambio en el “ambiente”, por
ejemplo, el cliente de funcionamiento, o el ambiente de negocios, o el mercado en
que el software debe vender. Cualquiera que sea la causa, es importante
reconocer la inevitabilidad del cambio y tomar medidas para mitigar sus efectos. El
20. cambio tiene que gestionarse para asegurar que los cambios propuestos pasen
por una revisión definida y un proceso de aprobación y, mediante la aplicación de
requisitos cuidadosos como el seguimiento, análisis y gestión de la configuración
de software de impacto. Por lo tanto, el proceso de requisitos no es simplemente
una tarea de principio a fin en el desarrollo del software sino que se extiende a
todo el ciclo de vida de un software. En un proyecto típico, las actividades de los
requisitos de software evolucionan con el tiempo de estimulación a la gestión del
cambio.
7.2 Gestión del Cambio.
La gestión del cambio es fundamental para la gestión de requisitos. Este tema
describe el papel de la gestión del cambio, los procedimientos que deben estar en
el lugar y el análisis que debe aplicarse a los cambios propuestos.
7.3 Atributos de los Requisitos.
Los requisitos deben consistir solo de una especificación de lo que se necesita,
sino también de información auxiliar, que ayuda a administrar e interpretar los
requisitos. Esto debe incluir las diversas dimensiones de la clasificación de los
requisitos y el método de verificación o aceptación relevante. También puede
incluir información adicional, como una justificación sumaria para cada requisito, la
fuente de cada requisito y un historial de cambios. El atributo más importante, es
un identificador que permite a los requisitos identificarse única e inequívocamente.
7.4 Requisitos de Rastreo.
Los requisitos de seguimiento se refieren a recuperar la fuente de los requisitos y
predecir los efectos de este. Un trazado es fundamental para realizar un análisis
de impacto cuando los requerimientos cambian. Un requisito debe ser trazable al
revés de los requerimientos y las partes interesadas que lo motivaron. Por el
contrario, un requisito debe ser trazable para que remita a las entidades de diseño
que satisfacen.
7.5 Requisitos de Medición.
Como una cuestión practica, es típicamente útil tener algún concepto del
“volumen” de los requisitos para un producto de software en particular. Este
número es útil para evaluar el “tamaño” de un cambio en los requisitos, al estimar
el costo de una tarea de mantenimiento o desarrollo, o simplemente para el uso
como denominador en otras medidas. La medida del tamaño funcional (MTF) es
una técnica para evaluar el tamaño de un cuerpo de requerimientos funcionales.
8. Requisitos de las herramientas del software.
Las herramientas para tratar con requisitos de software en términos generales se
dividen en dos categorías: herramientas de modelado y herramientas para la
gestión de requisitos.
21. Las herramientas para la gestión de requisitos suelen apoyar una gama de
actividades, incluyendo documentación, seguimiento y gestión del cambio y han
tenido un impacto significativo en la práctica. De hecho, gestión de cambio y
seguimiento son realmente factibles si son compatibles con una herramienta.
Puesto que es fundamental para la práctica de los requisitos una buena gerencia
del requisito, muchas organizaciones han invertido en herramientas de gestión de
requisitos, aunque muchos más gestionan sus requerimientos y generalmente de
maneras menos satisfactorias.