requisitos

5/9/2018 requisitos - slidepdf.com

http://slidepdf.com/reader/full/requisitos-559ca1868f712 1/29

ESPECIFICACION DE

REQUISITOS



¿QUÉ SON LOS REQUISITOS O

REQUERIMIENTOS?

Normalmente, un tema de la Ingeniería de Softwaretiene diferentes significados. De las muchasdefiniciones que existen para requerimiento, hacontinuación se presenta la definición que aparece

en el glosario de la IEEE . Una condición o necesidad de un usuario para

resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente

en un sistema o componentes de sistema parasatisfacer un contrato, estándar, especificación uotro documento formal.

Una representación documentada de una condicióno necesidad.



QUE SE CONSIDERA COMO UN REQUISITO

Una facilidad a nivel usuarioEj.: ¶el procesador de palabras debe incluir un

verificador de ortografía y un comando de corrección· Una propiedad muy general del sistema

Ej.: ¶el sistema debe asegurar que la informaciónpersonal nunca se haga disponible sin autorización·

Una restricción específica del sistemaEj.: ¶el sensor debe ser activado 10 veces por

segundo· Una restricción para el desarrollo del sistema

Ej.: ¶el sistema debe ser desarrollado usando Ada· Cómo llevar a cabo algún cálculo

Ej.: ¶la nota final debe ser calculada sumando lasnotas del examen, proyecto y cursada del estudiante basado enla siguiente fórmula nota final = nota_exam + 2 * nota_proy +2/3 * nota_cursada·



QUE SE CONSIDERA COMO UN REQUISITO

Propiedades del dominio: ´Cosasµ en el dominio deaplicación que son verdaderas independientementeque se construya o no el sistema de software

Requisitos: ´Cosasµ en el dominio de aplicación quese desean sean verdaderas mediante la construccióndel sistema de software

Especificación: descripción de comportamiento (ydatos) que el programa tiene que tener para cumplir

los requisitos� Sólo puede ser descrito en términos de losfenómenos compartidos por la máquina y eldominio de aplicación



ACTORES RELACIONADOS CON EL SISTEMA

Llamados Stakeholder. Entidad que será afectadapor el sistema y que tienen una influencia directa oindirecta sobre los requisitos del sistema.

Usuarios finales del sistema Gerentes involucrados en los procesosorganizacionales influenciados o que influencian alsistema Ingenieros responsables por el desarrollo y

mantenimiento del sistema, Clientes de la organización Cuerpos externos tales como autoridadesreguladoras o de certificación.



LEVANTAMIENTO DE REQUISITOS

Definición de requisitosDefinición de requisitos Expresa en lenguaje natural o con diagramas

los servicios y restricciones operacionales delsistema. Se genera con la información

proporcionada por el cliente.Especificación de RequisitosEspecificación de Requisitos Documento estructurado que describe con

detalle los servicios del sistema. A veces llamadoespecificación funcional. Escrito como contrato

con el cliente.Especificación de softwareEspecificación de software Escrito para los diseñadores. Sirve de base

para el diseño y desarrollo del sistema.



DOCUMENTO DE REQUISITOS

El documento de requisitos es un escrito oficial delos requisitos del sistema para los clientes, usuariosfinales y desarrolladores de software.

Nombres:y Especificación funcional,y Definición de requisitos,y Especificación de los requisitos de software



DOCUMENTO DE REQUISITOS

El documento describe: Los servicios y funciones que el sistema debería

proveer. Las restricciones bajo las cuales el sistema debe

operar Las propiedades generales del sistema, es decir,restricciones sobre las propiedades emergentes del

sistema Definiciones de otros sistemas con los cuales el

sistema se debe integrar. Información acerca del dominio de aplicación del

sistema, por ej. cómo llevar a cabo tiposparticulares de cálculos. Restricciones sobre el proceso usado para

desarrollar el sistema glosario



USUARIOS DEL DOCUMENTO DE REQUISITOS

Clientes del sistema Especifican los requisitos y los leen parachequear que atienden sus necesidades.

Especifican cambios en los requisitos.

GerentesUsan los documentos de requisitos para

planificar una propuesta (oferta) para el sistema

y planificar el proceso de desarrollo.

Ingenieros de sistemas Usan los requisitos para entender qué sistema

tiene que ser desarrollado.

Ingenieros de prueba de

sistemasUsan los requisitos para desarrollar pruebas de

validación para el sistema.

Ing. de mantenimiento

de sistemas

Usan los requisitos para ayudar a entender los

sistemas y las relaciones entre sus partes.



MODELO IEEE/ANSI 830-1998 Introducción

� 1.1.Propósito del documento de requisitos

� 1.2.Alcance del proyecto

� 1.3.Definiciones, acrónimos y abreviaturas

� 1.4.Resumen del resto del documento

Descripción General

� 2.1.Perspectiva del producto

� 2.2.Funciones del producto

� 2.3.Características de los usuarios

� 2.4.Limitaciones generales

�

2.5.Suposiciones y dependencias R equisitos Específicos

� 3.1.Requisitos funcionales, no funcionales

Apéndices

Índice



INGENIERÍA DE REQUISITOS (RE)

RE trata la identificación del propósito de unsistema de software y el contexto en el cual seráusado.

RE actúa como un puente entre las necesidadesdel mundo real de los clientes y otros actoresafectados

Trata sobre los objetivos del mundo real para lossistemas de software, servicios provistos yrestricciones.

Trata sobre el comportamiento del sistema y suevolución a través del tiempo.



IMPORTANCIA DE LA RE EN EL

DESARROLLO DE SOFTWARE

Cuanto más tarde en el ciclo de vida se detecta unerror, más cuesta repararlo.

Muchos errores permanecen latentes y no sondetectados hasta bastante después de la etapa en quese cometieron. Muchos podrían detectarse

tempranamente Se cometen muchos errores de requisitos

Impacto de los errores en la etapa de requisitos El software resultante puede no satisfacer a los

usuarios.

Las interpretaciones múltiples de los requisitospueden causar desacuerdos entre clientes ydesarrolladores.

Es imposible que a través del testeo el softwaresatisfaga sus requisitos.

Puede gastarse tiempo y dinero construyendo elsistema erróneo.



ACTIVIDADES DEL PROCESO DE LA RE

Elicitación Modelado Análisis Gestión

Identificación de

Fuentes Inform.

Representación Verificación Identificación de

cambios

Recolección de

hechos

Organización Validación Análisis de

cambios

Comunicación Almacenamiento

(registración)

Negociación Realización de

cambios



TÉCNICA JAD (JOINT APLICATION

DESIGNER)

Permite a los usuarios, diseñar sistemas en

forma conjunta, en sesiones grupales. Gibson y Jackson afirman que los resultados

aumentan de un 20% a un 60%. Promueve la cooperación, el entendimiento y el

trabajo grupal entre distintos grupos de usuarios.



ROLES DEL JAD

Líder de la sesión. Representante de los usuarios. Especialista. Analista. Representante de SS. Patrocinador (sponsor) ejecutivo o dueño del

sistema.



LÍDER DE SESIÓN

Facilitador de JAD. Dirige el proceso. Facilita el debate y la preparación de

documentos. Trata con el sponsor de JAD para acordar quién

debe asistir las reuniones. Acordar la agenda con los participantes.



PLAN JAD

Dura entre uno y cinco días. El líder de la sesión guía a los participantes a lo

largo de ocho tareas predefinidas. Ellas son:y

Orientación.y Definición de requerimientos de alto nivel .y Límites y alcances del sistema .y Identificar y estimar tiempos de los Diseños JAD.y Identificar los participantes de los Diseños JAD.y Programar días y horarios para los Diseños JAD.y Acordar los puntos y consideraciones de la

documentación a generar del Plan JAD.y Concluir la sesión.



DISEÑO JAD. SESIÓN DE DISEÑO

Dura aproximadamente entre tres y diez días. El líder de la sesión guía a los participantes a lo

largo de las siguientes tareas:y Orientación.y Revisión y refinación de los requerimientos y alcance

del Plan JAD.y Desarrollar diagrama de flujo del trabajo.y Desarrollar descripción del flujo de trabajo.y Identificar funciones y grupos de datos del sistema.y Especificar los requerimientos de procesamiento.y Acordar los puntos y consideraciones de la

documentación a generar del Diseño JAD.y Concluir la fase de sesión.



LIBROS DE TRABAJO

Formas predefinidas para los grupos, para quesean completadas durante la sesión.

Formularios de participantes.

Formularios de resultados. Formularios de estimaciones. Formularios de salidas por pantalla. Formularios de reportes. Formularios de descripción de interfaces y de

descripción de funciones.



JAD Y EL PROCESO DE REQUERIMIENTOS

La articulación del concepto de producto,requerimientos, medición de resultados.

Análisis de problemas. Estudios de factibilidad y análisis de opciones de

costo-beneficio. Análisis y modelado.

La documentación de requerimientos.



JAD Y LA COMUNICACIÓN HUMANA

La identificación de varios puntos de vista. La conciliación de los puntos de vista. La revisión por parte del usuario de los modelos

desarrollados. El análisis de los propios problemas del usuario y

la identificación de la necesidad de cambio.



ANÁLISIS DE PUNTOS DE FUNCIÓN (FPA)

Mide el tamaño del software desde el punto devista del usuario. Medir la funcionalidad delproducto.

Es independiente de la tecnología usada para el

desarrollo e implementación. Se aplica a partir de los documentos de

requerimientos y a lo largo del ciclo de vida delsoftware.

Los enfoques para estimar Puntos Función(Function Points - FP) facilitan la estimacióntemprana de un proyecto de software (costo,esfuerzo, cronograma) cuando los requerimientosno están completamente definidos.



MEDICIÓN

Es una práctica de administración Probada en eltiempo.

No se puede administrar lo que no se puede

medir. Un 40% de proyectos fracasan por falta de

administración, Herramienta para determinar el tamaño del

requerimiento, extrapolar la productividad y lacalidad.

Se mide para entender y mejorar procesos.



CLASES DE MEDICIÓN

Medición: Cuantificación directa.y Estatura de una persona.

Cálculo: Cuantificación indirecta.y A partir de la combinación de medidas se obtiene el

valor del atributo de interés.y Ejemplo: medir la velocidad a partir de la distancia y

el tiempo.



MEDICIÓN DEL SOFTWARE

Se miden las características para saber si losrequerimientos son consistentes y completos.

Los administradores de proyectos miden procesosy productos para determinar tiempos de entrega

y costos. Incluyen las siguientes actividades:

y Estimación de costo y esfuerzo.y Medidas de productividad.y

Recolección de datos.y Medidas de calidad y confiabilidad.y Performance.y Complejidad.y Métodos y herramientas.



BENEFICIOS DE LA MEDICIÓN

Entender que está ocurriendo en el desarrollo ymantenimiento para mejorar las relaciones entre

actividades. Control de lo que ocurre en el proyecto, para

predecir lo que ocurrirá y los cambios a realizar. Mejorar los procesos y productos, aumentando las

revisiones del diseño se incrementa la calidad.



MEDICIÓN DEL TAMAÑO DEL SISTEMA

Tamaño delprocesamiento deinformación�

Entradas� Salidas.� Otros

Tamaño delprocesamiento deinformación�

Entradas� Salidas.� Otros

Tamaño del sistema desde

los requerimientos delusuario

Requerimientostécnicos.� Performance.�

Facilidad deuso.� otros

Requerimientostécnicos.� Performance.�

Facilidad deuso.� otros



BENEFICIOS DEL FPA

Mejorará la definición de los requerimientos. Comunicar requerimientos funcionales. Estimar esfuerzo, agenda y costos basado en

requerimientos. Evaluar la factibilidad de un proyecto. Administrar los cambios. Mejorará el mantenimiento y soporte.

Medir la productividad. Verificar la completitud.



RESUMEN DE OBJETIVOS

¿Qué son los requerimientos o Requisitos? Necesidades, objetivos y actores relacionados con

los requerimientos

Importancia de la Ingeniería de Requisitos en lapráctica Levantamiento y Recolección de Requerimientos. Técnicas más usadas: Método JAD y FPA

requisitos

Documents