Está en la página 1de 9

TUCUPITA, 22-2-2020

RODRIGUEZ, ROGELIO

SANZ, MOISES

ESTEVES, IVANNA

INGENIERIA DE REQUISITOS

¿Qué son requisitos?

Los requerimientos para un sistema son descripciones de lo que el sistema debe


hacer: el servicio que ofrece y las restricciones en su operación. Tales requerimientos
reflejan las necesidades de los clientes por un sistema que atienda cierto propósito, como
sería controlar un dispositivo, colocar un pedido o buscar información, etc.

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 restricciones
con las cuales éste debe operar.

Los requerimientos del sistema son descripciones más detalladas de las funciones,
los servicios y las restricciones operacionales del sistema de software.

Tipos de requisitos

Los requerimientos funcionales definen las funciones  que el sistema será capaz


de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para
producir salidas.
Tales requerimientos dependen del tipo de software que se esté desarrollando, de los
usuarios esperados del software y del enfoque general que adopta la organización cuando se
escriben los requerimientos. Al expresarse como requerimientos del usuario, los
requerimientos funcionales se describen por lo general de forma abstracta que entiendan los
usuarios del sistema. Sin embargo, requerimientos funcionales más específicos del sistema
detallan las funciones del sistema, sus entradas y salidas, sus excepciones,etcétera.
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.
Los requerimientos no funcionales tienen que ver con características que de una u
otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y
espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo),
mantenimiento, seguridad, portabilidad, estándares, y otros.
Los requerimientos no funcionales, como indica su nombre, 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. De forma alternativa, pueden definir
restricciones sobre la implementación del sistema, como las capacidades de los dispositivos
de entrada y salida o las representaciones de datos usados en las interfaces con otros
sistemas.
Los requerimientos no funcionales a menudo son más significativos que los
requerimientos funcionales individuales. Es común que los usuarios del sistema encuentren
formas para trabajar en torno a una función del sistema que realmente no cubre sus
necesidades. No obstante, el fracaso para cubrir los requerimientos no funcionales haría que
todo el sistema fuera inútil.

 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, requerimientos de fiabilidad que establecen la tasa
aceptable de fallas, requerimientos de seguridad y requerimientos de
usabilidad.
 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.
 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.
Atributos de calidad

También llamada cualidades del software son características no funcionales que se


consideran deseables en un sistema de software. Sin embargo, no todos los sistemas de
software deben tener en cuenta todos estos atributos o cualidades, algunas serán más
importantes que otras dependiendo del sistema, y ciertamente no se pueden maximizar
todas a la vez.

Se establece una diferencia entre cualidades y requerimientos, porque algunas de


ellas pueden incorporarse como entrada al diseño por un camino distinto al del análisis (por
ejemplo, como restricciones de arquitectura o influencias del entorno).

1. Simplicidad

Simplicidad es la ausencia de complejidad o dificultades. En el desarrollo de


software puede resultar de interés diferenciar entre complejidades esenciales y accidentales.

Complejidad esencial: las que son propias o intrínsecas al problema que se desea
solucionar. Es natural que un problema complejo tenga soluciones con algún grado de
complejidad.

Complejidades accidentales: aquellas que surgen por malas decisiones de diseño.

Naturalmente, se intentará evitar diseñar soluciones que sean más complejas de lo


que el problema requiere.

Determinar si una dificultad en un diseño o programa es esencial o accidental, nos


permite atacar las dificultades accidentales, buscando soluciones más simples.

2. Correctitud, consistencia, completitud

Correctitud: Ausencia de errores.

Consistencia: Coherencia entre las operaciones que realiza el usuario.

Completitud: Capacidad del sistema para realizar todas las operaciones que usuario
podría requerir.

3. Robustez

Robusto es un sistema que goza de buena salud y que brinda garantías de que va a
continuar teniendo buena salud. Algunos síntomas de un sistema robusto son:
La capacidad de ser modificado sin introducir errores, durabilidad del sistema
funcionando correctamente (no aparecen errores aleatorios)

4. Flexibilidad

Es la capacidad para admitir cambios que pueden ser necesarios tanto por un
cambio de requerimientos como por la detección de un error que debe ser corregido. Una
variante de flexibilidad es la extensibilidad, es decir, la posibilidad de agregar nuevos
requerimientos.

5. Performance

La performance es una medida de la eficiencia en el uso de recursos del sistema


ejecutándose, por ejemplo:

Uso de procesador

Memoria

Almacenamiento permanente (discos rígidos, etc).

Uso de redes

… o cualquier otro recurso físico.

6. Escalabilidad

Es la capacidad de un sistema para trabajar con diferentes cantidades de trabajo,


como cambios en el volumen de datos o flujo de pedidos. Con frecuencia se estudia la
escalabilidad de un sistema hacia arriba, es decir, se mide la capacidad del sistema para
manejar, por ejemplo, un mayor volumen de datos. La medida de escalabilidad no requiere
que el sistema funcione intacto en las nuevas condiciones, en cambio es una medida de la
facilidad con la que se lo puede adaptar al nuevo entorno, por ejemplo, si está preparado
para que yo agregue un servidor más a un clúster eso se podría considerar escalable.

7. Seguridad

Algunas visiones de la seguridad son:

Comprobar la identidad de las personas que intentan acceder al sistema.

Garantizar que sólo las personas específicamente autorizadas pueden ver


determinada porción de la información del sistema
Garantizar que sólo las personas específicamente autorizadas pueden modificar
determinada porción de la información del sistema o bien realizar determinadas acciones.

8. Usabilidad

La facilidad con la que el sistema o componente se puede utilizar o bien aprender a


utilizar.

9. Constructibilidad

La constructibilidad es una medida inversa a la complejidad de la construcción del


sistema. Las decisiones de diseño pueden afectar severamente la dificultad para construir
ese sistema.

Objetivos de la Ingeniería de Requisitos:

• El objetivo del proceso de la ingeniería de requisitos es darle a todas las


partes una explicación escrita del problema.

• Es esencial que se haga un esfuerzo real por entender los requisitos de un


problema antes de intentar resolverlo.

Personal involucrado en la Ingeniería de Requerimientos:

Los roles más importantes pueden clasificarse como sigue:

• Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están
relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; están
familiarizados con los procesos específicos que debe realizar el software, dentro de los
parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de
usuario.

• Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el
dominio del problema en donde será empleado el software desarrollado. Ellos proporcionan
al equipo técnico los detalles y requerimientos de las interfaces del sistema.

• Personal de Mantenimiento: Para proyectos que requieran un mantenimiento


eventual, estas personas son las responsables de la administración de cambios, de la
implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los
procesos del producto ya finalizado.
• Analistas y programadores: Son los responsables del desarrollo del producto en sí;
ellos interactúan directamente con el cliente.

• Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para


asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van
a validar si los requerimientos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del


proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores de base
de datos, entre otros.

Fases de la ingeniería de requisitos

1. Elicitación de requisitos.

Elicitación (o extracción o determinación) de requisitos, es el proceso mediante el


cual los usuarios descubren, revelan, articulan y comprenden los requisitos que desean. En
esta etapa, se trata de descubrir los requisitos y personal técnico trabaja con los clientes y
usuarios para descubrir el dominio de la aplicación, los servicios que se deben proporcionar
y las restricciones. Puede implicar a usuarios finales, encargados, ingenieros implicados en
el mantenimiento, expertos del dominio, etc.

2. Modelado

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la


funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede
funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo
tanto proyecta lo que el cliente desea según la percepción del desarrollador. Es esencial que
los clientes puedan comprender este modelo.

El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para


la formación de todos los demás modelos en el desarrollo de software. En general, el
cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores
consecuencias, a este nivel que posteriormente.

3. Analisis

Se define el análisis de requisitos como “el proceso del estudio de las necesidades
de los usuarios para llegar a una definición de los requisitos del sistema, de
hardware o de software, así como el proceso de estudio y refinamiento de dichos
requisitos”

La fase de análisis de requisitos, según el estándar IEEE 1074 [IEEE, 1991] se


desglosa en tres grandes actividades:
•Definir los requisitos de software. Tarea iterativa para crear una definición
o especificación preliminar de los requisitos que debe cumplir el software a partir de la
información obtenida mediante técnicas de recogida de información analizadas en el
capítulo anterior.

•Definir los requisitos de las interfaces del software con el resto del sistema y con
el exterior. Deben definirse las propiedades que se deben satisfacer para obtener una
interacción eficaz con otros elementos del sistema (el usuario, el hardware, otras
aplicaciones software, ...).En particular la interfaz con el usuario es crítica para la
facilidad de uso (y por tanto el éxito) del software.

Los requisitos de interfaz con otras aplicaciones deben describir las


características para que el software se relacione con ellas, las cuales pueden estar muy
influenciadas por restricciones de trabajo del sistema (S.O. utilizado, SGBD empleado,
Compiladores, controladores de red, etc.).

Así mismo deben definirse las características de las interrelaciones con


elementos hardware.

•Integrar los requisitos en un documento de especificación y asignarles


prioridades. La asignación de prioridades debe hacerse en función de su
importancia o los beneficios que puede aportar su cumplimiento.

4. Gestión

La administración de requerimientos es el proceso de comprender y controlar los


cambios en los requerimientos del sistema. Es necesario seguir la pista de 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. El proceso formal de la administración de requerimientos debe
comenzar tan pronto como esté disponible un borrador del documento de requerimientos.
Sin embargo, hay que empezar a planear cómo administrar el cambio en los requerimientos
durante el proceso de adquisición de los mismos.

Técnicas para el levantamiento y recolección de requisitos

1. Entrevistas

Las entrevistas formales o informales con participantes del sistema son una parte de
la mayoría de los procesos de ingeniería de requerimientos. En estas entrevistas, el equipo
de ingeniería de requerimientos 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


son de dos tipos:

1. Entrevistas cerradas, donde los participantes responden a un conjunto de


preguntas preestablecidas.

2. Entrevistas 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.

Las entrevistas tampoco son una técnica efectiva para adquirir conocimiento sobre
los requerimientos y las restricciones de la organización, porque existen relaciones sutiles
de poder entre los diferentes miembros en la organización. Las estructuras publicadas de la
organización rara vez coinciden con la realidad de la toma de decisiones en una
organización, pero los entrevistados quizá no deseen revelar a un extraño la estructura real,
sino la teórica. En general, la mayoría de las personas se muestran renuentes a discutir los
conflictos políticos y organizacionales que afecten los requerimientos.

2. Escenarios

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 posibles. Se
desarrollan diferentes formas de escenarios y se ofrecen varios tipos de información con
diversos niveles de detalle acerca del sistema.

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. En su forma más general, un escenario puede incluir:

1. Una descripción de qué esperan el sistema y los usuarios cuando inicia el


escenario.

2. Una descripción en el escenario del flujo normal de los eventos.

3. Una descripción de qué puede salir mal y cómo se manejaría.

4. Información de otras actividades que estén en marcha al mismo tiempo.

5. Una descripción del estado del sistema cuando termina el escenario.

La adquisición basada en escenario implica trabajar con los participantes para


identificar escenarios y captar detalles a incluir en dichos escenarios. Estos últimos pueden
escribirse como texto, complementarse con diagramas, tomas de pantallas, etcétera. De
forma alternativa, es posible usar un enfoque más estructurado, como los escenarios de
evento o casos de uso.

3. Casos de uso

Un caso de uso es una técnica para documentar posibles requisitos, graficando la


relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece
como una caja negra, y sólo se representa su interacción con entidades externas, permite
omitir dichos aspectos y determinar los que realmente corresponden a las entidades
externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los
desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia
el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes
peligros potenciales.

Los casos de uso se documentan con el empleo de un diagrama de caso de uso de


alto nivel. El conjunto de casos de uso representa todas las interacciones posibles que se
describirán en los requerimientos del sistema. Los actores en el proceso, que pueden ser
individuos u otros sistemas, se representan como figuras sencillas. Cada clase de
interacción se constituye como una elipse con etiqueta. Líneas vinculan a los actores con la
interacción. De manera opcional, se agregan puntas de flecha a las líneas para mostrar
cómo se inicia la interacción.

4. Etnografia

La 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.

La etnografía es muy efectiva para descubrir dos tipos de requerimientos:

1. Requerimientos que se derivan de la forma en que realmente trabaja la gente, en vez


de la forma en la cual las definiciones del proceso indican que debería trabajar.
2. Requerimientos que se derivan de la cooperación y el conocimiento de las
actividades de otras personas.

También podría gustarte