El documento describe la importancia de la ingeniería de requerimientos en el desarrollo de software. Explica que los requerimientos deben ser especificados por escrito, posibles de probar o verificar, concisos, completos, consistentes y no ambiguos. También menciona algunas técnicas para obtener requerimientos como entrevistas, cuestionarios y casos de uso.

1. Autor: Luis Cabello
*
REPÚBLICA BOLIVARIANA DE VENEZUELA
INSTITUTO UNIVERSITARIO POLITÉCNICO
“SANTIAGO MARIÑO”
EXTENSIÓN PORLAMAR
ESCUELA DE INGENIERÍA DE SISTEMAS

2. *
*Un requerimiento en términos de implementación
tiene un nivel de importancia demasiado grande,
esta característica se le conoce como prioridad y
debe ser usada para establecer la secuencia en que
ocurrirán las actividades de diseño y prueba de cada
requisito.
*La prioridad de cada requerimiento dependerá de
las necesidades que tenga el negocio.

3. *
* La ingeniería de requerimientos sirve como una
base sólida en el proceso de desarrollo de software,
por lo que antes de pasar a tratar los aspectos
referentes a la administración adecuada de los
requerimientos, es importante primero definir lo
que es un requerimiento y cuales serían las
características deseables que deberían de tener.

4. *
*1. “Una condición o necesidad de un usuario para
resolver un problema o alcanzar un objetivo”. (Std
610.12-1900, IEEE: 62)
*2. “Una condición o capacidad que debe estar
presente en un sistema o componentes de sistema
para satisfacer un contrato, estándar, especificación
u otro documento formal”.
(Std 610.12-1900, IEEE: 62)

5. *“Un requerimiento es simplemente una declaración
abstracta de alto nivel de un servicio que debe
proporcionar el sistema o una restricción de éste”.
(Sommerville, 2005: 108)
*

6. *Es importante no perder de vista que
un requerimiento debe ser:
* Especificado por escrito
* Posible de probar o verificar
* Conciso
*Completo
*Consistente
*No ambiguo
*

7. *
* Cumple con un papel primordial en el proceso
de producción de software, ya que enfoca un
área fundamental:
La definición de lo que se desea producir.

8. *
*Los requerimientos deben ser:
*Especificados por escrito. Como todo contrato o
acuerdo entre dos partes
*Posibles de probar o verificar. Si un requerimiento no
se puede comprobar, entonces ¿cómo sabemos si
cumplimos con él o no?
Descritos como una característica del sistema a
entregar. Esto es: que es lo que el sistema debe de
hacer (y no como debe de hacerlo)
* Lo más abstracto y conciso posible. Para evitar malas
interpretaciones.

9. *
*Los requerimientos deben ser:
*Especificados por escrito. Como todo contrato o
acuerdo entre dos partes
*Posibles de probar o verificar. Si un requerimiento no
se puede comprobar, entonces ¿cómo sabemos si
cumplimos con él o no?
Descritos como una característica del sistema a
entregar. Esto es: que es lo que el sistema debe de
hacer (y no como debe de hacerlo)
* Lo más abstracto y conciso posible. Para evitar malas
interpretaciones.

10. *
*En la actualidad las técnicas modernas están siendo
fusionadas, para así lograr un mejor método que pueda
hacerle frente a las necesidades de las diferentes fases
del ciclo de vida del sistema, incluyendo a la fase de
análisis. Obteniendo de está manera mejores resultados
que pueda interpretar el analista en forma rápida y
precisa.

11. *
*Entrevistas y Cuestionarios
*Sistemas existentes
*Lluvia de ideas (Brainstorm)
*Prototipos
*Casos de Uso

12. *
Desde un punto de vista conceptual, las actividades
son de cinco clases.
*Obtener requisitos: a través de entrevistas o
comunicación con clientes o futuros usuarios, para
saber cuáles son sus expectativas.
*Analizar requisitos: detectar y corregir las carencias o
falencias comunicativas, transformando los requisitos
obtenidos de entrevistas y requisitos, en condiciones
apropiadas para ser tratados en el diseño.

13. *
*Documentar requisitos: igual que todas las etapas, los
requisitos deben estar debidamente documentados.
*Verificar los requisitos: consiste en comprobar la
implementación de los requerimientos.
*Validar los requisitos: comprobar que los requisitos
implementados sean funcionales para lo que
inicialmente se construyó el producto.

14. *
*Dentro del mismo documento mencionado anteriormente
(Herrera, 2003: 6), se dice que dentro de la IR (ingeniería de
software) existen cuatro actividades básicas que se tienen
que llevar a cabo para completar el proceso. Estas
actividades ayudan a reconocer la importancia que tiene
para el desarrollo de un proyecto de software realizar una
especificación y administración adecuada de los
requerimientos de los clientes

15. *
*Extracción
*Análisis
*Especificación
*Especificación

16. *
*Los requerimientos no son obvios y vienen de
muchas fuentes.
Son difíciles de expresar en palabras (el lenguaje es
ambiguo).
Existen muchos tipos de requerimientos y diferentes
niveles de detalle.
La cantidad de requerimientos en un proyecto puede ser
difícil de manejar. Nunca son iguales. Algunos son más
difíciles, más riesgosos, más importantes o más estables
que otros.

17. *
*Los requerimientos están relacionados unos con otros,
y a su vez se relacionan con otras partes del proceso.
*Cada requerimiento tiene propiedades únicas y abarcan
áreas funcionales específicas.
*Un requerimiento puede cambiar a lo largo del ciclo de
desarrollo.
*Son difíciles de cuantificar, ya que cada conjunto de
requerimientos es particular para cada proyecto.

18. *
* Cada requerimiento puede ser clasificados como
mandatorio, deseables o innecesarios.
* Las soluciones iniciales, deben ser definidas
tomando en cuanta tanto la perspectiva técnica
como la del negocio.
* Es importante determinar quién tiene el problema
realmente, considerar dicho problema desde una
variedad de perspectivas y explorar muchas
soluciones desde diferentes puntos de vista.

19. *