Unidad IV. Requerimientos del software
9:50 | Publicado por
Rosemary Samaniego |
Editar página
Requerimientos
Según Rational. Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar.
Según IEEE un Requerimiento es “1) La condición o idoneidad necesitada por un usuario para resolver un problema o para lograr un objetivo. 2). Condición o idoneidad que debe ser lograda o que debe poseer un sistema o componente del sistema para satisfacer un acuerdo, estándar, especificación u otro documento formal aceptado. El conjunto de requerimientos forman la base para el subsecuente desarrollo de un sistema o componente de sistema”
Los requerimientos son una descripción de las necesidades a las que debe responder el producto a desarrollar.
Para extraer los requerimientos correctamente, el equipo de analistas debe estar familiarizado con el dominio de la aplicación (área en el cuál se usará el producto). Por ejm. Si vamos a recolectar la información para el desarrollo de un sistema de puentes, es necesario familiarizarnos con esa área, de lo contrario podemos entender que abrazadera, traba, barra son palabras sinónimas y los podría tratar para el desarrollo del sistema como equivalentes, pero en ésta área son totalmente diferentes, al ejecutar el sistema existiría un colapso del puente, de tal manera que podríamos ser demandados por negligencia.
Por ello es útil, construir un glosario que contenga una lista de palabras técnicas utilizadas en el dominio, junto con sus significados.
Sólo después de que se ha obtenido una imagen clara de la situación presente, el equipo puede intentar contestar una pregunta importante: ¿Qué debe ser capaz de realizar el producto nuevo?
El proceso de descubrir los requerimientos del cliente se denomina extracción de requerimientos (ó captura de requerimientos). Una vez que se traza el conjunto inicial de requerimientos, el proceso de detallarlos y extenderlos se denomina análisis de requerimientos.
Algunos de los problemas surgen al no hacer una separación entre los difenrentes niveles de descripción así:
Algunos de los problemas surgen al no hacer una separación entre los difenrentes niveles de descripción así:
Requerimientos funcionales y no funcionales
Requerimientos de usuario: Representan el conjunto completo de resultados a ser obtenidos utilizando el sistema.
Ejm. El sistema controlará los datos requeridos por las agencias que licencian los derechos de autor en Europa y en otra parte.
Requerimientos del sistema: Establecen con detalle las funciones, servicios y restricciones operativas del sistema. Debe definir exactamente que es lo que se va a implementar.
Ejm. Al hacer una petición de un documento del sistema se presentará un formulario que registre los detalles de usuario y de la petición hecha.
A menudo, los requerimientos de sistemas software se clasifican en funcionales y no funcionales, o como requerimientos del dominio:
1. Requerimientos funcionales. Describen las tareas que el sistema debe realizar.
2. Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican características o servicios individuales del sistema.
3. Requerimientos del dominio. Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y restricciones de ese dominio. Pueden ser funcionales o no funcionales.
Existen otros como
Lecturas
Análisis de Factibilidad www.cid.uc.edu.ve/fponte/ejemplo/factib.pdf
IEEE 830 http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
UML recomendado: www.vico.org/aRecursosPrivats/TRAD_introUML.pdf
Tareas Grupales
Estudio de Factibilidad
1. Introducción
1.1 Propósito
1.2 Visión general
2. Descripción General
3. Estudio de Factibilidad
3.1 Factibilidad Operativa
3.2 Factibilida Técnica
3.3 Factibilidad Económica
3.3.1 Análisis Costo-Beneficio
3.4 Factibilidad legal
3.5 Conclusiones y Recomendaciones
Especificación de Requisitos del software
Plan general del Proyecto de Software
Existen otros como
R. de Interfaz: Definen las interacciones del sistema con su entorno:
§Usuarios
§Otros sistemas
RecursosLecturas
Análisis de Factibilidad www.cid.uc.edu.ve/fponte/ejemplo/factib.pdf
IEEE 830 http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
UML recomendado: www.vico.org/aRecursosPrivats/TRAD_introUML.pdf
Tareas Grupales
Estudio de Factibilidad
1. Introducción
1.1 Propósito
1.2 Visión general
2. Descripción General
3. Estudio de Factibilidad
3.1 Factibilidad Operativa
3.2 Factibilida Técnica
3.3 Factibilidad Económica
3.3.1 Análisis Costo-Beneficio
3.4 Factibilidad legal
3.5 Conclusiones y Recomendaciones
Especificación de Requisitos del software
Plan general del Proyecto de Software
Suscribirse a:
Entradas (Atom)
Perfil
Desarrollo de Unidades
Rosemary Samaniego. Con la tecnología de Blogger.