tema 2 - ingenieria de requisitos

8/19/2019 Tema 2 - Ingenieria de Requisitos

1/30

Ingeniería de Requisitos

Ing. de los Requerimientos y

Modelado del Software

Juan Pablo Rodriguez B.

www.aulaweb.net


2/30

Ingeniería

La ingeniería es el conjunto de conocimientosy técnicas científicas aplicadas, que sededica a la resolución u optimización de los

problemas que afectan directamente a lahumanidad.


3/30

Ingeniería del Software

Disciplina o área de la informática que ofrecemétodos y técnicas para desarrollar ymantener software de calidad.


4/30

Requisito

Una condición o necesidad de un usuario pararesolver un problema o alcanzar un objetivo.

Una condición o capacidad que debe estar presente en un sistema o componentes de sistemapara satisfacer un contrato, estándar, especificaciónu otro documento formal.


5/30


Es proceso de recopilar, analizar y verificar lasnecesidades del cliente o usuario para un sistema.

La meta de la ingeniería de requerimientos (IR) esentregar una especificación de requisitos de softwarecorrecta y completa.


6/30


Comprende todas las tareas relacionadas con ladeterminación de las necesidades o de lascondiciones a satisfacer para un software nuevo o

modificado, tomando en cuenta los diversosrequisitos de las partes interesadas, que puedenentrar en conflicto entre ellos.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes dealcanzar la fase de diseño en el proyecto. Losbuenos requisitos deben ser medibles, comprobables,

sin ambigüedades o contradicciones.


7/30


La parte más difícil de construir un sistema esprecisamente saber qué construir.

Es la parte mas difícil.

Es la que mas afecta los sistemas si es hecha mal.

Es la mas difícil de corregir.


8/30

Tipos de Requisitos

Funcionales:

Son los que definen las funciones que el sistema serácapaz de realizar, describen las transformacionesque el sistema realiza sobre las entradas paraproducir salidas.


9/30

Tipos de Requisitos

No funcionales:

Tienen que ver con características que de una u otraforma puedan limitar el sistema, como por ejemplo,el rendimiento (en tiempo y espacio), interfaces deusuario, fiabilidad (robustez del sistema, disponibilidadde equipo), mantenimiento, seguridad, portabilidad,

estándares, etc.


10/30

Características de un Requisitos

Especificado por escrito: Como todo contrato oacuerdo entre dos partes.

Posible de probar o verificar: Si un requerimiento nose puede comprobar, entonces ¿cómo se sabe si secumplió con él o no?

Conciso: Un requerimiento es conciso si es fácil deleer y entender. Su redacción debe ser simple y clarapara aquellos que vayan a consultarlo en un futuro.


11/30

Características de un Requisitos

Completo: Un requerimiento está completo si nonecesita ampliar detalles en su redacción, es decir, sise proporciona la información suficiente para su

comprensión.

Consistente: Un requerimiento es consistente si no escontradictorio con otro requerimiento.

No ambiguo: Un requerimiento no es ambiguocuando tiene una sola interpretación. El lenguajeusado en su definición, no debe causar confusiones

al lector.


12/30

Tareas de la ingeniería de

RequisitosInicio:

Tiene por objetivo identificar el ámbito del proyectogeneral.

Comienza con conversaciones informales entre losparticipantes. Suele ser acompañada de losdocumentos de definición de la visión global y lavisión del dominio del sistema.

Se inicia muchas veces porque: se descubre un

nuevo mercado y se descubre un nuevo servicio.


13/30


RequisitosObtención:

Se sugiere a los ingenieros recopilar requisitos demanera organizada, preguntando a los usuarios y

otros interesados cuales son los objetivos para elsistema o producto, que es lo que se debe lograr, deque forma el producto satisface las necesidades delnegocio y como se utilizara el producto día d día.


14/30


RequisitosElaboración:

Se crea un modelo de análisis con la informaciónobtenida del cliente en las fases de inicio y

obtención, esta información se expande y se refinadurante la elaboración.

Se enfoca en el desarrollo de un modelo técnicorefinado de las funciones, características y

restricciones del software.La elaboración se conduce mediante la creación yrefinamiento de escenarios del usuario que describanla forma en que el usuario final y otros actores

interactúan con el sistema.


15/30


RequisitosNegociación:

En esta etapa el ingeniero de requisitos debenegociar con el cliente los alcances y límites del

sistema.De forma iterativa los requisitos se priorizan,modifican, combinan o eliminan buscando acuerdosque beneficien a todas las partes. Se identifican y

analizan los riesgos asociados con cada requisito.


16/30


RequisitosEspecificación:

Es el producto final de la ingeniería de requisitos, y seconvierte en la materia prima para las actividades

posteriores en el proceso de desarrollo del sistema.

Una especificación puede ser un documento escrito,un conjunto de modelos gráficos, un modelomatemático formal, una colección de escenarios deuso, un prototipo o cualquier combinación de estos.


17/30


RequisitosValidación:

Un equipo de validación toma el producto de la fasede especialización, lo revisa para detectar errores,

conflictos u omisiones y los corrige con el fin degarantizar la consistencia de requisitos.

La validación de requisitos examina la especificaciónpara asegurar que todos los requisitos de software se

han establecidos de manera precisa; que se handetectado las inconsistencias omisiones y errores yque estos han sido corregidos y que el producto detrabajo cumple con los estándares establecidos para

el proceso, proyecto y producto.


18/30


RequisitosGestión de requisitos:

Ayuda a rastrear los requisitos según lascaracterísticas de los mismos, el código fuente

relacionado, dependencia entre requisitos,subsistemas e interfaces internas y externas de formaque pueda identificarse con rapidez para entender como afectara una modificación diferentes aspectos

del sistema a construir. Es un conjunto de actividadesque ayudan al equipo de proyecto a identificar,controlar y rastrear los requisitos y los cambios a estosen cualquier momento mientras se desarrolla elproyecto.


19/30

Técnicas de la ingeniería de

RequisitosEntrevistas y Cuestionarios:

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos.

Durante la entrevista, el analista conversa con elencuestado; el cuestionario consiste en una serie depreguntas relacionadas con varios aspectos de un

sistema.


20/30

Técnicas de la ingeniería de

RequisitosEntrevistas y Cuestionarios:Por lo común, los encuestados son usuarios de lossistemas existentes o usuarios en potencia del sistema

propuesto. En algunos casos, son gerentes oempleados que proporcionan datos para el sistemapropuesto o que serán afectados por él. El éxito deesta técnica, depende de la habilidad del

entrevistador y de su preparación para la misma.


21/30

Técnicas de la ingeniería deRequisitos

Sistemas existentes:

Esta técnica consiste en analizar distintos sistemas yadesarrollados que estén relacionados con el sistema

a ser construido. Por un lado, podemos analizar lasinterfaces de usuario, observando el tipo deinformación que se maneja y cómo es manejada,por otro lado también es útil analizar las distintas

salidas que los sistemas producen (listados, consultas,etc.), porque siempre pueden surgir nuevas ideassobre la base de estas.


22/30


Lluvia de ideas:

Este es un modelo que se usa para generar ideas. Laintención en su aplicación es la de generar la

máxima cantidad posible de requerimientos para elsistema. No hay que detenerse en pensar si la ideaeso no del todo utilizable. La intención de esteejercicio es generar, en una primera instancia,

muchas ideas.


23/30


Prototipos:

Para validar los requerimientos hallados, seconstruyen prototipos. Los prototipos son

Simulaciones del posible producto, que luego sonutilizados por el usuario final, permitiéndonosconseguir una importante retroalimentación encuanto a si el sistema diseñado con base a los

requerimientos recolectados le permite al usuariorealizar su trabajo de manera eficiente y efectiva.


24/30


Prototipos:

El desarrollo del prototipo comienza con la capturade requerimientos. Desarrolladores y clientes se

reúnen y definen los objetivos globales del software,identifican todos los requerimientos que sonconocidos, y señalan áreas en las que será necesariala profundización en las definiciones.

Luego de esto, tiene lugar un “diseño rápido”. Eldiseño rápido se centra en una representación deaquellos aspectos del software que serán visibles alusuario (por ejemplo, entradas y formatos de las

salidas).


25/30


Casos de Uso:

Los casos de uso son una técnica para especificar elcomportamiento de un sistema.

“Un caso de uso es una secuencia de transaccionesque son desarrolladas por un Sistema en respuesta aun evento que inicia un actor sobre el propio sistema.

Los diagramas de casos de uso sirven paraespecificar la funcionalidad y el comportamiento deun sistema mediante su interacción con los usuariosy/o otros sistemas”


26/30


Casos de Uso:

Los casos de uso permiten entonces describir laposible secuencia de interacciones entre el sistema y

uno o más actores, en respuesta a un estímulo inicialproveniente de un actor, es una descripción de unconjunto de escenarios, cada uno de elloscomenzado con un evento inicial desde un actor

hacia el sistema.


27/30

Proceso de la Ingeniería deRequisitos


28/30


Estudio de viabilidad: Este permitirá rendir un informetanto al equipo de desarrollo del proyecto como alusuario o cliente, donde se verificará si el proyecto

vale la pena desarrollarlo. Es de vital importanciapara la satisfacción de los objetivos del negocio.

Captura y Análisis: En esta fase el equipo de

desarrollo entra en contacto con el usuario final ocon el cliente para determinar el alcance delproyecto o del sistema, además, se debe identificar cuáles son los servicios que prestará el sistema, surendimiento, sus necesidades y restricciones, y cuálesson los objetivos esperados.


29/30


Especificación: Aquí se debe obtener un documentode especificación de requisitos, en cual se llega adefinir de una forma completa, precisa y verificable

cada uno de los requerimientos o necesidades quedebe satisfacer el sistema a desarrollar, además desus respectivas restricciones (software, hardware).

Validación: Consiste en mostrar o comprobar quecada uno de los requisitos obtenidos definen elsistema o proyecto. En esta etapa solamente entranaquellos requisitos que se mencionaron ya en laespecificación.


30/30


Gestión: Se realiza la comprensión y control de loscambios de cada una de los requisitos, sean estosrequisitos estables (corresponden al estado del

sistema) o volátiles (representan eventos que hacenque el sistema realice una función dada).

tema 2 - ingenieria de requisitos

Documents