TALLER DE REQUERIMIENTOS

1.
Los requisitos de software expresan las necesidades y limitaciones impuestas a un
producto de software que contribuyen a la solución de algún problema del mundo
real.
2.
Un requisito de software es una propiedad que debe ser exhibida por algo para
resolver algún problema en el mundo real. Puede tener como objetivo automatizar
parte de una tarea para que alguien apoye los procesos comerciales de una
organización, corrija las deficiencias del software existente o controle un
dispositivo.
3.
Una propiedad esencial de todos los requisitos de software es que sean
verificables como una característica individual como un requisito funcional o al nivel
del sistema como un requisito no funcional.
4.
Un requisito de producto es una necesidad o restricción en el software a
desarrollar.
Un requisito de proceso es esencialmente una restricción en el desarrollo del
software.
5.
Requisitos funcionales: describen las funciones que debe ejecutar el software; A
veces se les conoce como capacidades o características. Un requisito funcional
también se puede describir como declaraciones de los servicios que prestará el
sistema, en la forma en que reaccionará a determinadas situaciones.
6.
Requisitos no funcionales: Se trata de requisitos que no se refieren directamente
a las funciones específicas suministradas por el sistema, sino a las propiedades del
sistema: rendimiento, seguridad, disponibilidad.
7.
Los requisitos de software deben establecerse de la manera más clara e
inequívoca posible y, cuando corresponda, cuantitativamente. Es importante evitar
requisitos vagos y no verificables que dependen para su interpretación del juicio
subjetivo.
8.
Los requisitos del sistema son los requisitos del sistema en su totalidad (sistema
significa “Una combinación interactiva de elementos para lograr un objetivo
definido. Estos incluyen hardware, software, firmware, personas, información,
técnicas, instalaciones, servicios y otros elementos de soporte”).
9.
En un sistema que contiene componentes de software, los requisitos de software
se derivan de los requisitos del sistema.
10.
Modelos de proceso: En particular, el tema se refiere a cómo se configuran las
actividades de obtención, análisis, especificación y validación para diferentes tipos
de proyectos y restricciones. El tema también incluye actividades que brindan
información sobre el proceso de requisitos, como estudios de mercadeo y
factibilidad.
Actores de proceso: Existen a menudo muchas personas involucradas además
del especialista en requisitos, cada una de las cuales tiene una participación en el
software.
• Usuarios: Este grupo está compuesto por aquellos que operarán el software.
• Clientes: este grupo comprende aquellos que han encargado el software o que
representan el mercado objetivo del software.
• Analistas de mercado: un producto de mercado masivo no tendrá un cliente que
comisione, por lo que a menudo se necesita personal de marketing para
establecer lo que el mercado necesita y actuar como clientes sustitutos.
• Reguladores: muchos dominios de aplicaciones, como el banco y el transporte
público, están regulados. El software en estos dominios debe cumplir con los
requisitos de las autoridades reguladoras.
• Ingenieros de software: Un cliente de un producto en particular tiene requisitos
específicos que comprometen el potencial para la reutilización de componentes,
los ingenieros de software deben equilibrar cuidadosamente su propia
participación con la del cliente.
Apoyo y gestión de procesos: Esta sección presenta los recursos de gestión de
proyectos requeridos y consumidos por el proceso de requisitos.
Calidad y mejora de procesos: Este tema se refiere a la evaluación de la calidad
y la mejora del proceso de requisitos. Su propósito es enfatizar el papel clave que
desempeña el proceso de requisitos en términos del costo y la oportunidad de un
producto de software y de la satisfacción del cliente con él.
11.
La elicitation de requisitos se refiere a los orígenes de los requisitos de software y
cómo el ingeniero de software puede recopilarlos. Es la primera etapa en la
construcción de una comprensión del problema que el software debe resolver. Es
fundamentalmente una actividad humana y es donde se identifican los
stakeholders y se establecen relaciones entre el equipo de desarrollo y el cliente.
12.
• Metas. El término "goal" se refiere a los objetivos generales de alto nivel del
software.
• Conocimiento del dominio. El ingeniero de software necesita adquirir o tener
conocimiento disponible sobre el dominio de la aplicación. El conocimiento del
dominio proporciona el trasfondo sobre el cual se deben establecer todos los
requisitos de conocimiento para comprenderlo.
• Stakeholders. El ingeniero de software necesita identificar, representar y
administrar los "puntos de vista" de muchos tipos diferentes de partes interesadas.
• Reglas del negocio. Estas son declaraciones que definen o restringen algún
aspecto de la estructura o el comportamiento del negocio en sí.
• El entorno operativo. Los requisitos se derivarán del entorno en el que se
ejecutará el software.
• El ambiente organizacional. El software a menudo se requiere para soportar un
proceso de negocio, cuya selección puede estar condicionada por la estructura,
cultura y política interna de la organización.
13.
• detectar y resolver conflictos entre requisitos;
• descubrir los límites del software y cómo debe interactuar con su entorno
organizacional y operativo;
• elaborar requisitos del sistema para derivar los requisitos de software.
14.
• Si el requisito es funcional o no funcional
• Si el requisito se deriva de uno o más requisitos de alto nivel o de una propiedad
emergente
• Si el requisito es sobre el producto o el proceso
• La prioridad del requisito. Cuanto mayor sea la prioridad, más esencial será el
requisito para cumplir con los objetivos generales del software.
• El alcance del requisito. El alcance se refiere a la medida en que un requisito
afecta el software y los componentes del software.
• Volatilidad / estabilidad. Algunos requisitos cambiarán durante el ciclo de vida del
software, e incluso durante el proceso de desarrollo en sí.
15.
Es útil crear un modelo del contexto del software. El contexto del software
proporciona una conexión entre el software previsto y su entorno externo. Esto es
crucial para comprender el contexto del software en su entorno operativo y para
identificar sus interfaces con el entorno.
16.
El diseño arquitectónico es el punto en el que el proceso de requisitos se
superpone con el diseño de software o sistemas e ilustra cuán imposible es
desacoplar limpiamente las dos tareas. En muchos casos, el ingeniero de software
actúa como arquitecto de software porque el proceso de análisis y elaboración de
los requisitos exige que se identifiquen los componentes de arquitectura / diseño
que serán responsables de satisfacer los requisitos. Esta es la asignación de
requisitos: la asignación a los componentes de arquitectura responsables de
satisfacer los requisitos.
17.
“Requirements Negotiation” se refiere a la resolución de problemas con
requisitos donde se producen conflictos entre dos stakeholders que requieren
características mutuamente incompatibles, entre requisitos y recursos, o entre
requisitos funcionales y no funcionales, por ejemplo. En la mayoría de los casos,
no es aconsejable que el ingeniero de software tome una decisión unilateral, por lo
que se hace necesario consultar con las partes interesadas para llegar a un
consenso sobre una compensación adecuada.
18.
Documento de definición del sistema
Este documento registra los requisitos del sistema. Define los requisitos del
sistema de alto nivel desde la perspectiva del dominio.
Especificación de requisitos del sistema
Los desarrolladores de sistemas con componentes importantes de software y no
software a menudo separan la descripción de los requisitos del sistema de la
descripción de los requisitos del software. Se especifican los requisitos del
sistema, los requisitos del software se derivan de los requisitos del sistema y luego
se especifican los requisitos para los componentes del software.
Especificación de Requerimientos de Software
La especificación de requisitos de software establece la base para un acuerdo
entre clientes y contratistas o proveedores sobre lo que debe hacer el producto de
software y lo que no se espera que haga.
19.
IEEE Std. 830-1998
20.
Los documentos de requisitos pueden estar sujetos a procedimientos de
validación y verificación. Los requisitos pueden validarse para garantizar que el
ingeniero de software haya entendido los requisitos; También es importante
verificar que un documento de requisitos cumpla con los estándares de la
compañía y que sea comprensible, consistente y completo.