Proceso de descubrir, analizar, documentar y verificar los servicios y restricciones del sistema

Este subproceso, probablemente el más crítico y el más difícil de realizar, tiene como objetivos buscar, investigar y ayudar a los clientes y usuarios a documentar sus necesidades

Esta actividad es parte del subproceso de aseguramiento de la calidad, tiene como objetivo principal detectar conflictos en los requisitos obtenidos, normalmente mediante técnicas de modelado conceptual y de prototipado de interfaz de usuario.

Esta actividad de calidad tiene como objetivo detectar defectos en los requisitos previamente analizados, normalmente mediante técnicas como revisiones formales, listas de comprobación (checklists).

Esta tercera actividad de calidad intenta asegurar que los requisitos verificados reflejan realmente las necesidades de clientes y usuarios

El objetivo de este subproceso es buscar soluciones a los conflictos detectados que satisfagan a los distintos stakeholders

Este subproceso gestiona todo el proceso, en especial las peticiones de cambios en los requisitos, el impacto de dichas peticiones, las distintas versiones de los requisitos.

Es uno de los aspectos más destacables en la ingeniería de requisitos, esta característica hace de la ingeniería de requisitos una disciplina especialmente compleja al intervenir el factor humano

Es una restricción general del sistema

Es una propiedad general del sistema

Es una utilidad para el usuario

Condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado

Indica en qué contexto se debe entender el requisito: Sistema, Software, Hardware

Los requisitos se clasifican en función de la naturaleza de la característica del sistema que se especifica: Requisitos funcionales, Requisitos no funcionales

Indica a quién está dirigido el requisito, es decir, las personas que deben ser capaces de entenderlo.

Establece la forma cómo se definen los requisitos: Formal, Semiformal, No formal

El software debe proporcionar un medio para la representación y acceso a ficheros externos creados por otras herramientas

Describen la funcionalidad o los servicios que se espera que este proveerá

¿Cuál es la clasificación de requisitos?

Ejemplo de un requisito general

Ejemplo de un requisito funcional

Ejemplo de un requisito de implementación

Ejemplo de un requisito de rendimiento

¿Cuáles son los problemas habituales de los requisitos?

Aquello que es tangible o visible para el usuario es normalmente un requisito

Requisitos no relacionados directamente con la funcionalidad del sistema

Especifican el comportamiento del producto:

Tiempo de respuesta, memoria requerida, fiabilidad, portabilidad, usabilidad

Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador:

Estándares de proceso, lenguajes de programación, métodos de diseño, estándares de documentación.

Factores externos al sistema y de su proceso de desarrollo:

Interoperabilidad, éticos, legislativos, privacidad, seguridad.

Los requisitos se recogen en documentos técnicos que reciben el nombre genérico de ERS

Que significan las siglas ERS

Es la documentación de requisitos esenciales (funciones, rendimiento, diseño, restricciones y atributos) del software y de sus interfaces

Una especificación debe servir como canal de comunicación entre los participantes en el proceso de ingeniería de requisitos

Cada requisito solo tiene una interpretación

Incluye todos los requisitos significativos y define la respuesta a todo tipos de entradas

No hay conflictos ni contradicciones

Dos o más requisitos especifican conductas distintas del sistema para las mismas condiciones y el mismo estímulo externo

Se utilizan términos distintos para referirse al mismo concepto

Dos o más requisitos especifican aspectos contradictorios para la misma característica del sistema

Dos o más requisitos exigen características temporales contradictorias al sistema

Los procedimientos de observación para comprobar que el sistema cumple los requisitos son la base para las pruebas de aceptación por parte del cliente

Su estructura y estilo de redacción permiten que los cambios se puedan realizar fácil, completa y consistentemente

Para cada requisito contenido en ella se conoce su origen y puede referenciarse como origen en posteriores documentos

Cada requisito contenido en ella está anotado con la importancia que tiene su cumplimiento para clientes y usuarios y la estabilidad que se espera del requisito, es decir, la probabilidad de que cambie durante el desarrollo

No especifica una determinada descomposición del sistema (arquitectura) ni ningún aspecto de su posible implementación

Especifican los requisitos y los leen para comprobar que estos satisfacen sus necesidades. También especifican los cambios en los requisitos

Utilizan el documento de requisitos para planificar una oferta por el sistema y para planificar el proceso de desarrollo del sistema

Usan los requisitos para entender qué es lo que hay que desarrollar

Se basan en los requisitos para desarrollar tests para la validación del sistema

Utilizan los requisitos como ayuda para comprender el sistema y las relaciones entre sus partes

Captura la funcionalidad de un sistema, de un subsistema, o de una clase, tal como se muestra a un usuario exterior

Es una declaración de un servicio o una restricción de un sistema

Es la declaración formalizada de los requisitos de un sistema

Es cualquier persona afectada o involucrada en el sistema de alguna forma

Es el “sistema” a “entregar”

Es el producto, sus usuarios directos y otros “elementos” del entorno

Es el que hace una empresa para determinar la posibilidad de poder desarrollar un negocio o un proyecto que espera implementar.

Se relaciona con el personal que tiene que realizar el proyecto. Por eso se analiza si el personal posee las competencias laborales necesarias para desarrollarlo y llevarlo a cabo.

Evalúa si la infraestructura técnica que posee la empresa puede responder de manera favorable y eficiente para desarrollar el proyecto o negocio que se tiene panificado.

Se debe realizar un análisis exhaustivo de la relación costo beneficio del negocio o del proyecto y sopesar ambos aspectos.

Determina si existe una potencial posibilidad que exista un número adecuado de clientes.

Verifica si el tipo de negocio o de proyecto por desarrollar, no atenta o incumple alguna ley o norma de carácter municipal, estatal o mundial.

Permite conocer si el tiempo que se tiene planificado para llevar a cabo el proyecto coincide con el tiempo real que se necesita para poderlo implementar