Volver a Ingeniería en Software
UNIDAD 4 - INGENIERÍA DE REQUERIMIENTO
Se distinguen con el uso del término “requerimientos del usuario” para representar los
requerimientos abstractos de alto nivel; y “requerimientos del sistema” para caracterizar la
descripción detallada de lo que el sistema debe hacer.
Los requerimientos del usuario y los requerimientos del sistema se definen del siguiente
modo:
1. Los requerimientos del usuario son enunciados, en un lenguaje natural junto con
diagramas, acerca de qué servicios esperan los usuarios del sistema, y de las
restric-ciones con las cuales éste debe operar.
2. Los requerimientos del sistema son descripciones más detalladas de las funciones,
los servicios y las restricciones operacionales del sistema de software. El documento
de requerimientos del sistema (llamado en ocasiones especificación funcional) tiene
que definir con exactitud lo que se implementará. Puede formar parte del contrato
entre el comprador del sistema y los desarrolladores del software.
Requerimientos funcionales y no funcionales
● Requerimientos funcionales Son enunciados acerca de servicios que el sistema
debe proveer, de cómo debería reaccionar el sistema a entradas particulares y de
cómo debería comportarse el sistema en situaciones específicas. En algunos casos,
los requerimientos funcionales también explican lo que no debe hacer el sistema.
● Requerimientos no funcionales Son limitaciones sobre servicios o funciones que
ofrece el sistema. Incluyen restricciones tanto de temporización y del proceso de
desarrollo, como impuestas por los estándares. Los requerimientos no funcionales
se suelen aplicar al sistema como un todo, más que a características o a servicios
individuales del sistema.
FUNCIONALES: Los requerimientos funcionales para un sistema refieren lo que el sistema
debe hacer. Los requerimientos funcionales del sistema varían desde requerimientos
generales que cubren lo que tiene que hacer el sistema, hasta requerimientos muy
específicos que reflejan maneras locales de trabajar o los sistemas existentes de una
organización.
NO FUNCIONALES: son requerimientos que no se relacionan directamente con los
servicios específicos que el sistema entrega a sus usuarios. Pueden relacionarse con
propiedades emergentes del sistema, como fiabilidad, tiempo de respuesta y uso de
almacenamiento. Los requerimientos no funcionales a menudo son más significativos que
los requerimientos funcionales individuales. Los requerimientos no funcionales surgen a
través de necesidades del usuario, debido a restricciones presupuestales, políticas de la
organización, necesidad de interoperabilidad con otro software o sistemas de hardware, o
factores externos como regulaciones de seguridad o legislación sobre privacidad.
Tipos:
1. Requerimientos del producto Estos requerimientos especifican o restringen el
comportamiento del software. Los ejemplos incluyen requerimientos de rendimiento sobre
qué tan rápido se debe ejecutar el sistema y cuánta memoria requiere, reque-
rimientos de fiabilidad que establecen la tasa aceptable de fallas, requerimientos de
seguridad y requerimientos de usabilidad.
2. Requerimientos de la organización Son requerimientos de sistemas amplios, derivados
de políticas y procedimientos en la organización del cliente y del desarrollador.
Los ejemplos incluyen requerimientos del proceso operacional que definen cómo se usará el
sistema, requerimientos del proceso de desarrollo que especifican el lenguaje de
programación, estándares del entorno o el proceso de desarrollo a utilizar, y requerimientos
ambientales que definen el entorno de operación del sistema.
3. Requerimientos externos Este término cubre todos los requerimientos derivados de
factores externos al sistema y su proceso de desarrollo. En ellos se incluyen requerimientos
regulatorios que establecen lo que debe hacer el sistema para ser aprobado en su uso por
un regulador, como sería un banco central; requerimientos legislativos que tienen que
seguirse para garantizar que el sistema opere conforme a la ley, y requerimientos éticos que
garanticen que el sistema será aceptable para sus usuarios y el público en general.
El documento de requerimientos de software
El documento de requerimientos de software (especificación de requerimientos de software
o SRS) es un comunicado oficial de lo que deben implementar los desarrolladores del
sistema. Incluye tanto los requerimientos del usuario para un sistema, como una
especificación detallada de los requerimientos del sistema.
Especificación de requerimientos
La especificación de requerimientos es el proceso de escribir en un documento los
requerimientos del usuario y del sistema.
De manera ideal deben:
● ser claros
● sin ambigüedades
● fáciles de entender
● completos
● consistentes
● describir los requerimientos
funcionales y no funcionales
● especificar sólo el comportamiento
externo del sistema.
● se escriben en lenguaje natural,
complementado con diagramas y
tablas adecuado
El documento de requerimientos no debe incluir detalles de la arquitectura o el diseño del
sistema.
Especificación en lenguaje natural
Desde los albores de la ingeniería de software, el lenguaje natural se usa para escribir los
requerimientos de software. Es expresivo, intuitivo y universal. También es vago, ambiguo y
su significado depende de los antecedentes del lector.
Especificaciones estructuradas
El lenguaje natural estructurado es una manera de escribir requerimientos del sistema,
donde está limitada la libertad del escritor de requerimientos y todos éstos se anotan en una
forma estándar.
Cuando se use una forma estándar para especificar requerimientos funcionales, debe
incluirse la siguiente información:
1. Una descripción de la función a especificar.
2. Una descripción de sus entradas y sus procedencias.
3. Una descripción de sus salidas y a dónde se dirigen.
4. Información sobre los datos requeridos para el cálculo u otras entidades en el sistema
que se utilizan (la parte “requiere”).
5. Una descripción de la acción que se va a tomar.
6. Si se usa un enfoque funcional, una precondición establece lo que debe ser verdadero
antes de llamar a la función, y una postcondición especifica lo que es verdadero después de
llamar a la función.
7. Una descripción de los efectos colaterales (si acaso hay alguno) de la operación.
Procesos de ingeniería de requerimientos
Los procesos de ingeniería de requerimientos incluyen cuatro actividades de alto nivel.
Éstas se enfocan en valorar si el sistema es útil para la empresa (estudio de factibilidad),
descubrir requerimientos (adquisición y análisis), convertir dichos requerimientos en alguna
forma estándar (especificación) y comprobar que los requerimientos definan realmente el
sistema que quiere el cliente (validación).
Adquisición y análisis de requerimientos
1. Descubrimiento de requerimientos: Éste es el proceso de interactuar con los
participantes del sistema para descubrir sus requerimientos; la documentación se
comienza. Existen numerosas técnicas complementarias que pueden usarse.
2. Clasificación y organización de requerimientos: toma la compilación no estructurada
de requerimientos, agrupa requerimientos relacionados y los organiza en grupos
coherentes.
3. Priorización y negociación de requerimientos: cuando intervienen diversos
participantes, los requerimientos entrarán en conflicto. Esta actividad se preocupa
por priorizar los requerimientos, así como por encontrar y resolver conflictos de
requerimientos mediante la negociación. Por lo general, los participantes tienen que
reunirse para resolver las diferencias y estar de acuerdo con el compromiso de los
requerimientos.
4. Especificación de requerimientos: Los requerimientos se documentan e ingresan en
la siguiente ronda de la espiral. Pueden producirse documentos de requerimientos
formales o informales.
Descubrimiento de requerimientos: es el proceso de recopilar información sobre el
sistema requerido y los sistemas existentes, así como de separar, a partir de esta
información, los requerimientos del usuario y del sistema.
Las fuentes de información durante la fase de descubrimiento de requerimientos incluyen
documentación, participantes del sistema y especificaciones de sistemas similares. La
interacción con los participantes es a través de entrevistas y observaciones, y pueden
usarse escenarios y prototipos para ayudar a los participantes a entender cómo será el
sistema.
Los participantes varían desde administradores y usuarios finales de un sistema hasta
participantes externos como los reguladores, quienes certifican la aceptabilidad del sistema.
Entrevistas: aqui, el equipo formula preguntas a los participantes sobre el sistema que
actualmente usan y el sistema que se va a desarrollar. Los requerimientos se derivan de las
respuestas a dichas preguntas. Las entrevistas pueden ser:
❖ cerradas, donde los participantes responden a un conjunto de preguntas
preestablecidas.
❖ abiertas, en las cuales no hay agenda predefinida. El equipo de ingeniería de
requerimientos explora un rango de conflictos con los participantes del sistema y,
como resultado, desarrolla una mejor comprensión de sus necesidades.
En la práctica, las entrevistas con los participantes son por lo general una combinación de
ambas.
Las entrevistas son valiosas para lograr una comprensión global sobre qué hacen los
participantes, cómo pueden interactuar con el nuevo sistema y las dificultades que enfren-
tan con los sistemas actuales. Sin embargo, las entrevistas no son tan útiles para
comprender los requerimientos desde el dominio de la aplicación.
Escenarios: Por lo general, las personas encuentran más sencillo vincularse con ejemplos
reales que con descripciones abstractas. Los ingenieros de requerimientos usan la
información obtenida de esta discusión para formular los verdaderos requerimientos del
sistema.
Los escenarios son particularmente útiles para detallar un bosquejo de descripción de
requerimientos. Se trata de ejemplos sobre descripciones de sesiones de interacción. Cada
escenario abarca comúnmente una interacción o un número pequeño de interacciones posi-
bles.
Un escenario comienza con un bosquejo de la interacción. Durante el proceso de
adquisición, se suman detalles a éste para crear una representación completa de dicha
interacción.
Casos de uso: un caso de uso identifica a los actores implicados en una interacción, y
nombra el tipo de interacción; se complementa con información adicional (puede ser una
descripción textual, o bien, uno o más modelos gráficos) que describe la interacción con el
sistema.
Etnografía: es una técnica de observación que se usa para entender los procesos
operacionales y ayudar a derivar requerimientos de apoyo para dichos procesos. Un
analista se adentra en el ambiente laboral donde se usará el sistema, observa el trabajo
diario y toma notas acerca de las tareas existentes en que intervienen los participantes. El
valor de la etnografía es que ayuda a descubrir requerimientos implícitos del sistema que
reflejan las formas actuales en que trabaja la gente, en vez de los procesos formales
definidos por la organización.
Es muy efectiva para descubrir dos tipos de requerimientos:
● los que se derivan de la forma en que realmente trabaja la gente;
● los que se derivan de la cooperación y el conocimiento de las actividades de otras
personas.
La etnografía puede combinarse con la creación de prototipos.
Los estudios etnográficos pueden revelar detalles críticos de procesos, que se suelen
perder con otras técnicas de adquisición de requerimientos. Sin embargo,
debido a su enfoque en el usuario final, no siempre es adecuado para descubrir
requerimientos de la organización o de dominio. En consecuencia, la etnografía no es
un enfoque completo para la adquisición por sí misma, y debe usarse para complementar
otros enfoques, como el análisis de casos de uso.
Validación de requerimientos
Es el proceso de verificar que los requerimientos definan realmente el sistema que en
verdad quiere el cliente. Se traslapa con el análisis, ya que se interesa por encontrar
problemas con los requerimientos; los errores en un documento de requerimientos pueden
conducir a grandes costos por tener que rehacer, cuando dichos problemas se descubren
durante el desarrollo del sistema o después de que éste se halla en servicio.
En general, el costo por corregir un problema de requerimientos es mucho mayor que
reparar los errores de diseño o codificación ya que un cambio a los requerimientos significa
que también deben cambiar el diseño y la implementación del sistema, además el sistema
debe probarse nuevamente.
Durante el proceso de validación de requerimientos, tienen que realizarse diferentes
comprobaciones sobre los requerimientos, que incluyen:
1. Comprobaciones de validez Un usuario quizá crea que necesita un sistema para
realizar ciertas funciones. Sin embargo, con mayor consideración y análisis se logra
identificar las funciones adicionales o diferentes que se requieran.
2. Comprobaciones de consistencia Los requerimientos en el documento no debe
haber restricciones contradictorias o descripciones diferentes de la misma función
del sistema.
3. Comprobaciones de totalidad El documento de requerimientos debe incluir
requerimientos que definan todas las funciones y las restricciones pretendidas por el
usuario del sistema.
4. Comprobaciones de realismo los requerimientos deben comprobarse para garantizar
que en realidad pueden implementarse. Dichas comprobaciones también tienen que
considerar el presupuesto y la fecha para el desarrollo del sistema.
5. Verificabilidad Para reducir las disputas entre cliente y contratista, los requerimientos
del sistema deben escribirse siempre de manera que sean verificables.
Técnicas de validación de requerimientos que se usan individualmente o en conjunto con
otras:
➔ Revisiones de requerimientos Los requerimientos se analizan sistemáticamente
usando un equipo que verifican errores e inconsistencias.
➔ Creación de prototipos se muestra un modelo ejecutable del sistema en cuestión a
los usuarios finales y clientes. Así, ellos podrán experimentar con este modelo para
constatar si cubre sus necesidades reales.
➔ Generación de casos de prueba Los requerimientos deben ser comprobables.
Administración de requerimientos
Los requerimientos para los grandes sistemas de software siempre cambian. Una razón es
que dichos sistemas se desarrollaron para resolver problemas que no se pueden definir por
completo, por eso los requerimientos tienden a estar incompletos. Entonces, los
requerimientos deben evolucionar.
Una vez que se instala un sistema, y se utiliza con regularidad, surgirán nuevos
requerimientos. Razones por las que es inevitable el cambio:
1. Los ambientes empresarial y técnico del sistema siempre cambian después de la
instalación. Puede por ejemplo cambiar las prioridades de la empresa;
2. Los individuos que pagan por un sistema y los usuarios de dicho sistema, no son los
mismos. Los clientes imponen requerimientos debido a restricciones organizativas y
presupuestales, es muy probable que se deban agregar nuevas características para
apoyar al usuario;
3. Los sistemas grandes tienen una comunidad de usuarios diversa, en la cual muchos
individuos tienen diferentes requerimientos y prioridades que quizás estén en
conflicto o sean contradictorios.
La administración de requerimientos es el proceso de comprender y controlar los cambios
en los requerimientos del sistema. Es necesario seguir los requerimientos individuales y
mantener los vínculos entre los requerimientos dependientes, de manera que pueda
valorarse el efecto del cambio en los requerimientos. También es preciso establecer un
proceso formal para hacer cambios a las propuestas y vincular éstos con los requerimientos
del sistema.
Planeación de la administración de requerimientos
La planeación es una primera etapa esencial en el proceso de administración de
requerimientos. Esta etapa establece el nivel de detalle que se requiere. Durante la etapa
de administración de requerimientos, hay que decidir sobre:
1. Identificación de requerimientos Cada requerimiento debe identificarse de manera
exclusiva, de forma que pueda tener referencia cruzada con otros requerimientos y
usarse en las evaluaciones de seguimiento.
2. Un proceso de administración del cambio Éste es el conjunto de actividades que
valoran el efecto y costo de los cambios.
3. Políticas de seguimiento Dichas políticas definen las relaciones entre cada
requerimiento, así como entre los requerimientos y el diseño del sistema que debe
registrarse. La política de seguimiento también tiene que definir cómo mantener
dichos registros.
4. Herramientas de apoyo La administración de requerimientos incluye el
procesamiento de grandes cantidades de información acerca de los requerimientos.
La administración de requerimientos necesita apoyo automatizado y herramientas de
software, para lo cual deben seleccionarse durante la fase de planeación. Se necesitan
herramientas de apoyo para:
➢ Almacenamiento de requerimientos tienen que mantenerse en un almacén de datos
administrado y seguro, que sea accesible para los que intervienen en el proceso
➢ Administración del cambio se simplifica si está disponible la herramienta de apoyo
activa.
➢ Administración del seguimiento la herramienta de apoyo para el seguimiento permite
la identificación de requerimientos relacionados.
Administración del cambio en los requerimientos
La ventaja de usar un proceso formal para la administración del cambio es que todas las
propuestas de cambio se tratan de manera consistente y los cambios al documento de
requerimientos se realizan en una forma controlada.
Etapas principales de un proceso de administración del cambio:
1) Análisis del problema y especificación del cambio se comienza con la identificación
de un problema en los requerimientos o con una propuesta de cambio específica.
Durante esta etapa, el problema o la propuesta de cambio se analizan para
comprobar que es válida. Este análisis retroalimenta al solicitante del cambio, quien
tomará la decision.
2) Análisis del cambio y estimación del costo El efecto del cambio propuesto se valora
usando información de seguimiento y conocimiento general de los requerimientos
del sistema. El costo por realizar el cambio se estim y se toma una decisión si se
procede o no con el cambio de requerimientos.
3) Implementación del cambio Se modifican el documento de requerimientos y el
diseño y la implementación del sistema.
Los procesos de desarrollo ágil, como la programación extrema, se diseñaron para
enfrentar los requerimientos que cambian durante el proceso de desarrollo. En dichos
procesos, cuando un usuario propone un cambio de requerimientos, éste no pasa por
un proceso de administración del cambio formal. En vez de ello, el usuario tiene que
priorizar dicho cambio y, si es de alta prioridad, decidir qué características del sistema
planeadas para la siguiente iteración pueden eliminarse.
CAP 4 - Ingeniería de requerimientos .docx
browser_emoji Estamos procesando este archivo...
browser_emoji Lamentablemente la previsualización de este archivo no está disponible. De todas maneras puedes descargarlo y ver si te es útil.
Descargar
. . . . .