1. INGENIERÍA DE REQUERIMIENTOS
cliente para un sistema de software
poseer un sistema o una componente de un sistema para satisfacer un contrato, un standard, una
especificación u otro documento formalmente impuestos. Según Zave, Rama de la ingeniería del
software que trata con el establecimiento de los objetivos, funciones y restricciones de los sistemas
software. Así mismo, se ocupa de la relación entre factores con el objeto de establecer
especificaciones precisas. Según Boehm, Ingeniería de Requerimientos es la disciplina para
desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para
acuerdos comunes entre todas las partes involucradas y en donde se describen las funciones que
realizara los sistemas. Según Leite: Es el proceso mediante el cual se intercambian diferentes puntos
de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación
de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento
de requerimientos.
NIVELES DE DESCRIPCIÓN DE REQUERIMIENTOS UTILIZADOS EN LAS DIFERENTES FASES DEL
PROCESO DE INGENIERÍA DE REQUERIMIENTOS. Una vez recopilados, los requisitos se agrupan por
Utilizando un proceso iterativo, se irán eliminando requisitos, se irán combinando y/o modificando
para conseguir satisfacer los objetivos planteados. EL documento de Requerimientos: En la práctica
es común describir los requerimientos en un documento llamado especificación de Requerimientos
del Software (SRS -Software Requirements Specification) ¿Para qué sirve un SRS? Comunicar de
manera precisa los requerimientos, objetivos y presunciones del dominio Contrato legal,
documento interno o a modo de memorando Base para estimación (tamaño, costo, tiempo) y
planificación del proyecto Base para evaluación de producto final Debería tener suficiente
información para decidir si el producto final es aceptable (Satisface los requerimientos) Base para
el control de cambios Un SRS deberá abarcar: Funcionalidad. Que es lo que el software hace?
Interfases externas. Como debe interactuar con gente, con el Hardware del sistema, con demás
hardware y con demás Software? Atributos de Calidad. Disponibilidad, tiempo de respuesta, tiempo
de recuperación Después de fallas, etc... Consideraciones de portabilidad, co rectitud, precisión,
mantenibilidad, seguridad. Restricciones de diseño. Existen estándares a cumplir, lenguaje de
programación, recursos, sistemas operativos, etc.

2. Demostración de que los requerimientos que definen el sistema son lo que el cliente realmente
quiere. Los costos de errores en los requerimientos son altos, por lo cual, la validación es muy
importante. Fijar un error de requerimiento después del desarrollo puede resultar en un costo 100
veces mayor que fijar un error en la implementación. El Prototipado es una técnica importante de
la validación de requerimientos.
ESTRUCTURA DEL DOCUMENTO DE REQUERIMIENTOS. Describe la necesidad de crear el sistema y
cuáles son sus objetivos. Modelos del Sistema. Define los modelos que muestran los componentes
del sistema y las relaciones e
servicios que serán proporcionados.
ESTRUCTURA DEL DOCUMENTO DE REQUERIMIENTOS. Definición de Requerimientos No-
funcionales. Definir las limitantes del sistema y el proceso de desarrollo. Evolución del Sistema.
Definir las suposiciones fundamentales en las cuales el sistema se basa y se anticipan los cambios.
Especificación de Requerimientos. Especificación detallada de los requerimientos funcionales del
sistema. Apéndices. Descripción de la plataforma de Hardware del Sistema. Requerimientos de la
base de Datos (quizá como un modelo ER). Es muy difícil formular una especificación de
requerimientos completa y consistente. Una definición de requerimientos, una especificación de
requerimientos y una especificación de Software son una manera de especificar el Software para
diferentes tipos de lectores. El Documento de Requerimientos es una descripción para clientes y
desarrolladores.
RESUMEN. Los errores en los requerimientos son usualmente muy caros de corregir una vez
desarrollado el sistema. La revisión debe involucrar al cliente y al staff de contratistas para validar
del cliente pa e se use el
sistema.
INSTRUCCIONES PARA EL USO DE ESTE FORMATO. Este formato es una plantilla tipo para
documentos de requisitos del software. Está basado y es conforme con el estándar IEEE Std 830-
1998. Las secciones que no se consideren aplicables al sistema descrito podrán de forma justificada
indicarse como no aplicables (NA). Notas: Los textos en color azul son indicaciones que deben
eliminarse y, en su caso, sustituirse por los contenidos descritos en cada apartado. 08/06/14 25De
la plantilla de formato del documento © & Coloriuris http://www.qualitatis.org
Los textos entre corchetes del tipo “” permiten la inclusión directa de texto con el color y estilo
adecuado a la sección, al pulsar sobre ellos con el puntero del ratón. Los títulos y subtítulos de cada
apartado están definidos como estilos de MS Word, de forma que su numeración consecutiva se
genera automáticamente según se trate de estilos “Titulo1, Titulo2 y Titulo3”. La sangría de los
textos dentro de cada apartado se genera automáticamente al pulsar Intro al final de la línea de

3. título. (Estilos Normal indentado1, Normal indentado 2 y Normal indentado 3). El índice del
documento es una tabla de contenido que MS Word actualiza tomando como criterio los títulos del
documento. Una vez terminada su redacción debe indicarse a Word que actualice todo su
contenido para reflejar el contenido definitivo. Plantilla de formato del documento © & Coloriuris
http://www.qualitatis.org.