requerimientos

Facultad de Ingeniería Informática Segundo semestre – 2011 - Elkin Alfredo Albarracin N.

Universidad Pontificia Bolivariana

Seccional Bucaramanga FACULTAD DE INGENIERÍA INFORMATICA

Curso : Ingeniería de Software

03 – INGENIERIA DE REQUERIMIENTOS


Objetivos

• Entender los conceptos de requerimientos de usuario y

requerimientos del sistema.

• Entender las diferencias entre requerimientos funcionales y no

funcionales del sistema.

• Como se pueden organizar los requerimientos en un documento de

requerimientos de software


Conceptos Básicos

• Los requerimientos para un sistema son la descripción de los

servicios proporcionados por el sistema y sus restricciones

operativas

• Los requerimientos reflejan las necesidades de los clientes de tener

un sistema que ayude a resolver algún problema en su

organización.

• En algunos casos no se utiliza el termino requerimiento,

simplemente es una abstracción de alto nivel de un servicio que

debe proporcionar el sistema o de una restricción del mismo.


Según Frederick P. Brooks

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

•Ninguna otra parte del trabajo conceptual es tan difícil como establecer los

requerimientos técnicos detallados, incluyendo todas las interfaces con gente,

máquinas y otros sistemas.

•Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es

tan difícil de corregir más adelante...

Entonces, la tarea más importante que el ingeniero de software hace

para el cliente es la extracción iterativa y el refinamiento de los

requerimientos del producto.

Conceptos Básicos


Si no se tienen los requerimientos correctos, no se puede

diseñar o construir el producto correcto y, consecuentemente,

el producto no permitirá a los usuarios finales realizar su

trabajo. Y esto está confirmado por estudios que demuestran

que más del 60% de los errores de diseño se originan durante

las etapas de requerimientos y análisis.

Conceptos Básicos


Los requerimientos se pueden dividir en :

• Requerimientos Funcionales: que son aquellos que

definen qué hace el sistema (describen todas las entradas

y salidas), es decir, las funciones del sistema.

• Requerimientos no-funcionales: definen los atributos

que le indican al sistema cómo realizar su trabajo

(eficiencia, hardware, software, interface, usabilidad, etc.);

es el cómo, cuándo y cuánto.

Conceptos Básicos


Conceptos Básicos Ingeniería de Requerimientos

La Ingeniería de Requerimientos se define, como

un "conjunto de actividades en las cuales,

utilizando técnicas y herramientas, se analiza un

problema y se concluye con la especificación de

una solución (a veces más de una)."

¿Qué es la Ingeniería de Requerimientos (IR)?


Conceptos Básicos

Ingeniería de Requerimientos

Modelo del Proceso de la Ingeniería de Requerimientos (IR)

Extracción de

Requerimientos

Análisis de

Requerimientos

Documentación

de

Requerimientos

Validación de

Requerimientos

Documentación de

Requerimientos

Especificación del

Sistema

Necesidades de los

usuarios, Información

de Sistemas existentes,

estándares , etc.

Requerimientos

Acordados


Conceptos Básicos



MODELO EN CASCADA

Este modelo sugiere que los resultados de una tarea del proceso llevan a la siguiente, y así

sucesivamente.

EXTRACCION

ANALISIS

ESPECIFICACION

VALIDACION


Conceptos Básicos



MODELO EN ESPIRAL Un modo alternativo de presentar modelos de actividad que toma en cuenta la retroalimentación entre

etapas y la repetición de tareas.


Conceptos Básicos


Actividades de la Ingeniería de Requerimientos (IR)

EXTRACCION

• Esta fase representa el comienzo de cada ciclo.

• Extracción es el nombre comúnmente dado a las actividades involucradas en el

descubrimiento de los requerimientos del sistema.

• Los Analistas deben trabajar junto al cliente para descubrir el problema que el sistema

debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que

se pueden presentar, etc.

La extracción debe ser efectiva, ya que la aceptación del sistema dependerá de cuan bien

éste satisfaga las necesidades del cliente y de cuan bien asista a la automatización del

trabajo.


Conceptos Básicos



ANALISIS

Una vez Finalizada la extracción, inicia esta fase que puede ser compleja si el proyecto es y su

funcionalidad son desconocidos, generalmente se apunta a descubrir problemas con los

requerimientos del sistema identificados hasta el momento.

Se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos;

en esta fase :

•Se leen los requerimientos

•Se conceptúan

•Se investigan

•Se intercambian ideas con el resto del equipo

•Se resaltan los problemas

•Se buscan alternativas y soluciones

Finalmente se van fijando reuniones con el cliente para discutir los requerimientos.


Conceptos Básicos



ESPECIFICACION

En esta fase se documentan los

requerimientos acordados con el cliente,

en un nivel apropiado de detalle.

En la práctica, esta etapa se va

realizando conjuntamente con el análisis,

pero podríamos decir que la

Especificación es el "pasar en limpio" el

análisis realizado previamente aplicando

técnicas y/o estándares de

documentación, como la notación UML.


Conceptos Básicos



VALIDACION

La validación es la etapa final de la IR. Su objetivo es validar los

requerimientos, es decir, verificar todos los requerimientos que

aparecen en el documento especificado para asegurarse que

representan una descripción, por lo menos, aceptable del sistema

que se debe implementar. Esto implica verificar que los

requerimientos sean consistentes y que estén completos.

En definitiva, realmente significa asegurarse de que el documento

de requerimientos represente una descripción clara del sistema, y es

una verificación final de que los requerimientos cubren las

necesidades de los usuarios.


Conceptos Básicos


Estructura Sugerida para un Documento de

Especificación de Requerimientos NORMA IEEE/ANSI 830-1998

1. INTRODUCCION Propósito del Documento de Requerimientos

Alcance del producto

Definiciones, Acrónimos y Abreviaturas

Referencias

Descripción del Resto del Documento

2. DESCRIPCION GENERAL Perspectiva del Producto

Funciones del Producto

Características del Usuario

Restricciones Generales

Suposiciones y Dependencias

3. REQUERIMIENTOS ESPECIFICOS Incluyen los requerimientos funcionales y no funcionales, Generalmente debe incluir

las interfaces externas, describir la funcionalidad y rendimiento del sistema,

especificar los requerimientos lógicos de la base de datos, las restricciones de diseño

y características de calidad.

4. APENDICES

5. INDICE


Conceptos Básicos


Especificación de los Requisitos de Software (SRS) NORMA IEEE/ANSI 830-1998

Contrato: Un documento es legalmente obligatorio y en el estarán de acuerdo las partes del cliente y proveedor.

Esto incluye los requisitos técnicos y requerimientos de la organización, costo y tiempo para un producto. Un

contrato también puede contener la información informal pero útil como los compromisos o expectativas de las

partes involucradas.

Cliente: La persona (s) que pagan por el producto y normalmente (pero no necesariamente) definen los requisitos.

En la práctica el cliente y el proveedor pueden ser miembros de la misma organización.

Proveedor: La persona (s) que producen un producto para un cliente.

Usuario: La persona (s) que operan o actúan recíprocamente directamente con el producto. El usuario (s) y el

cliente (s) no es (son) a menudo las mismas persona(s).

DEFINICIONES


Conceptos Básicos



CONSIDERACIONES

Existen básicamente ocho(8) consideraciones a tener en cuenta para la elaboración de un buen documento de

SRS

1. La Naturaleza del SRS

2. El Ambiente del SRS

3. Las Características de un buen SRS

4. La preparación de los acuerdos del SRS

5. La evolución de SRS

6. Prototipos

7. Generando el diseño en el SRS

8. Generando los requisitos del proyecto en el SRS


Conceptos Básicos



NATURALEZA DEL SRS

Representa para que fue creado el Documento SRS, quien lo creo y detalla problemas

como :

• Funcionalidad del Sistema : Que hace el sistema

• Interfaces Externas : Interacción del sistema con personas, otras sistemas y

hardware.

• Actuación : Velocidad, Disponibilidad, Transaccionalidad, etc.

• Atributos: Portabilidad del Sistema, mantenimiento, seguridad.

• Restricciones de Diseño en la aplicación: Restricciones de Idioma, manejo de

datos, limites de recursos, etc.


Conceptos Básicos



AMBIENTE DEL SRS

Define los alcances y hasta donde debe ir el documento SRS, generalmente debe definir todos los

requisitos del software correctamente. Un requisito del software puede existir debido a la

naturaleza de la tarea a ser resuelta o debido a una característica especial del proyecto.

NO DEBE

• Describir cualquier plan o detalles de aplicación. Éstos deben describirse en la fase del diseño

del proyecto.

• Imponer las restricciones adicionales en el software. Éstos se especifican propiamente en otros

documentos.


Conceptos Básicos



CARACTERISTICAS DEL SRS

1. Correcto (Cada Requisito se encuentra en el software)

2. Inequívoco (Cada Requisito tiene una sola interpretación)

3. Completo (todas las Entradas y Salidas del sistema están validadas)

4. Consistente (Consistencia con documentos relacionados)

5. Delinear que tiene importancia y/o estabilidad ( Cada requisito debe tener un

indicador de importancia y estabilidad)

6. Comprobable (Procesos Finitos que lo puedan validar)

7. Modificable (Realizar cambios de manera fácil, completa y consistente)

8. Identificable (Origen Claro)


Conceptos Básicos



PREPARACION DE ACUERDOS DEL SRS

Generación de un documento entre el cliente y el proveedor

completo y entendible.


Conceptos Básicos



EVOLUCION DEL SRS

El documento de SRS debe evolucionar asi como evolucionan cada una de las

actualizaciones de software. Se debe tener en cuenta :

• Debe especificarse los requerimientos completamente y anotar que se encuentran

incompletos.

• Debe existir una documentación de la proyección de los cambios.


Conceptos Básicos



PROTOTIPOS DEL SRS

La generación de prototipos es util por :

• El cliente puede leer el prototipo de SRS y retroalimentar el mismo.

• El prototipo aparte de generar respuestas también trae consigo nuevas preguntas acerca del

documento de SRS.

• Un SRS basado en un prototipo tiende a sufrir menos cambios durante el desarrollo, así se acorta

el tiempo de desarrollo.

Un prototipo debe usarse como una manera de sacar los requisitos del software.

Se pueden extraer algunas características como pantalla o formatos del reporte directamente del

prototipo.


Conceptos Básicos



GENERANDO EL DISEÑO DEL SRS

El SRS debe especificar qué funciones serán realizadas, con qué datos,

para producir qué resultados, en qué situación y para quien.

Los ejemplos de restricciones del diseño válidos son requisitos físicos,

requisitos del desarrollo, normas de desarrollo de software y software

de calidad según los estándares.


Conceptos Básicos



GENERANDO LOS REQUISITOS DEL PROYECTO EN EL SRS

Los requisitos del proyecto representan una comprensión entre el cliente y el proveedor sobre

materias contractuales que pertenecen a la producción de software y así no deben ser incluidos

en el SRS. Éstos normalmente incluyen los puntos como:

- El Costo

- Los tiempos de la entrega

- Informando los procedimientos

- Los métodos de desarrollo de Software

- La convicción de Calidad

- La Aprobación y criterio de la comprobación

- Los procedimientos de aceptación


Investigar sobre las distintas

técnicas y herramientas que se

utilizan para especificar

requerimientos.

requerimientos

Documents

conceptos de requerimientos

requerimientos funcionales

documento de requerimientos

etapas de requerimientos

requerimientos correctos

ingeniera de software

elkin alfredo albarracin

sistema cmo