Proceso de la ingeniería de requerimientos

DATOS

SOFTWARE

PROCESOS

TIEMPO

  El proceso de establecer los servicios que el cliente requiere de un sistema y las restricciones sobre las cuales opera y es desarrollado Los requerimientos son descriptivos de los servicios del sistema y las restricciones que son generadas durante el proceso de requerimientos de ingeniería .

que contribuye a la solución de un problema del “mundo real”.   Expresa las necesidades y restricciones sobre un producto de software. Propiedad que debe exhibir un producto de software para resolver un problema del mundo real”. Tiene distintas fuentes. . de diferentes personas y niveles de la organización.

 Los requerimientos podrían tener una doble función  Podría ser la base de una propuesta de contrato – además debe ser abierta a la interpretación  Podría ser la base para el contrato – además tiene que ser definida a detalle  Ambos enunciados podrían ser llamados requerimientos .

.

.

 Necesario:  Conciso.  Completo  Consistente  No ambiguo  Verificable .

  Requerimientos no están definidos de forma precisa Requerimientos ambiguos podrían ser interpretados de diferentes formas por desarrolladores y usuarios .

  En principio los requerimientos deben ser ambos. completos y consistentes Completos  Deben incluir descripciones de todas facilitadores requeridos los  Consistentes  No deben tener conflictos ni contradicciones en la descripción de las facilidades del sistema .

 Por su procedencia o utilización se clasifican en:  Requerimientos de proceso  Requerimientos  De usuario (acores involucrados)  Requerimientos para análisis y gestión  Requerimientos para gestión .

describen los procedimientos y políticas que las organizaciones deben seguir así como las restricciones que deben obedecer. un requerimiento del costo máximo del desarrollo (requerimiento de proceso) se puede imponer para ayudar a alcanzar un requerimiento del precio máximo de venta (requerimiento del producto).   Son a nivel organizacional Describen “el cómo”. es decir. Se imponen como la manera de alcanzar un cierto requerimiento de alto nivel del producto. . Por ejemplo.

   Estándares usados en los procesos Requerimientos de implementación Políticas de la empresa .

 Son todas sus necesidades. . las cuales se traducen a los requerimientos. de lo que esperan que un nuevo sistema realice y de las restricciones que lleva consigo.

 Pueden plantearse en los siguientes tres campos Ejemplo: Las condiciones y formas de uso La eficiencia en relación con el aprovechamiento de recursos para su empleo La confianza de su vigencia o fallas Relativos al producto : incluyen la finalidad del producto o servicio que pretende el cliente Respecto a la organización Condiciones de entrega Exigencias de espacio y acomodo Cumplimiento con estándares Relación con otros servicios o productos Restricciones morales Exigencias legislativas o de justicia Aportes de la organización al mejoramiento ambiental Relativos al ambiente o externos .

. completitud y ambigüedad  Clasificar en base a las necesidades de los clientes/usuarios. Una vez recabados los requerimientos:  Agrupar por categorías  Organizar en sub conjuntos  Estudiar cada requisito en relación con el resto  Examinar los requisitos en su consistencia.

. consumiendo recursos de negocios limitados. cómo sería el sobrepasar el presupuesto y el tiempo requerido para el desarrollo del sistema. Definir si un requerimiento es necesario:  Razón: es común en clientes y usuarios solicitar más de lo que puede realizarse.

 Para la gestión y negociación es útil saber si los requerimientos son:  Esenciales (deben ser absolutamente satisfechos)  Deseables (son importantes pero no indispensables)  Opcionales (son posibles pero que podrían eliminarse) .

 Requerimientos que permiten administrar los datos que se requieren para poder implementar la funcionalidad de manera adecuada. .

   Primero se deben determinar los actores involucrados Deben describir requerimientos funcionales y no funcionales que sean entendibles por los usuarios del sistema aunque no tenga el conocimiento técnico detallado Los requerimientos de usuario son definidos usando lenguaje natural. tablas y diagramas .

    Especificaciones más detalladas de los requerimientos de usuario Servir como base para el diseño del sistema Podría ser usado como parte del contrato del sistema Los requerimientos del sistema podrían ser expresados usando modelos de sistema definidos .

Requerimientos del usuario Administradores clientes Usuarios finales del sistema Ingenieros clientes Administradores contratistas Arquitectos del sistema Requerimientos del sistema Usuarios finales del sistema Ingenieros clientes Arquitectos del sistema Desarrolladores del software Ingenieros clientes (quizás) Arquitectos del sistema Desarrolladores del software Especificación del diseño del sw .

Escrito como un contrato entre el cliente y el proveedor  Especificación de software  Una descripción detallada del software que pueda servir como base para el diseño o implementación. Requerimientos de usuario  Enunciados en un lenguaje natural además de diagramas de los servicios que el sistema provee y sus restricciones operacionales.  Requerimientos del sistema  Un documento estructurado estableciendo descripciones detalladas de los servicios del sistema. Escrito por desarrolladores . Escrito por los clientes.

 Requerimientos funcionales  Servicios que el sistema debe proveer.  Requerimientos de dominio  Requerimientos que vienen del dominio de aplicación del sistema y reflejan características de ese dominio . del proceso del desarrollo. como restricciones tiempo.  Requerimientos no funcionales  Restricciones en los servicios o funciones ofrecidos por el sistema. estándares. etc. cómo debe reaccionar el sistema a entradas particulares y cómo se debe comportar en situaciones particulares.

Describe la funcionalidad o servicios del sistema Depende del tipo de software. usuarios y el tipo de sistema donde el software es utilizado  Los requerimientos funcionales del usuario podrían ser enunciados complejos de lo que el sistema debe hacer. pero los requerimientos funcionales del sistema deben describir los servicios del sistema a detalle   .

representaciones del sistema. etc. el sistema no es útil .     Define las propiedades y restricciones del sistema. Las restricciones son capacidades de los dispositivos de entrada/salida. Si no son alcanzados. Los requerimientos de procesos Los requerimientos no funcionales podrían ser más críticos que los requerimientos funcionales.

 Requerimientos externos  Requerimientos que surgen de factores externos al sistema y su proceso de desarrollo. Requerimientos de producto  Requerimientos que especifican lo que el producto liberado tiene que alcanzar en puntos particulares.  Requerimientos organizacionales  Requerimientos que son consecuencia de políticas organizacionales y procedimientos. .

Requerimientos no funcionales Requerimientos del producto Requerimientos organizacionales Requerimientos externos Requerimientos de eficiencia Requerimientos de fiabilidad Requerimientos de portabilidad Requerimientos de interoperabilidad Requerimientos éticos Requerimientos de usabiliad Requerimientos de entrega Requerimientos de implementación Requerimientos de estándares Requerimientos legislativos Requerimientos de desempeño Requerimientos de espacio Requerimientos de privacidad Requerimientos de seguridad .

  Objetivo  Es una intención general del usuario Requerimientos no funcionales verificables  Un enunciado usando alguna medida que pueda ser probada objetivamente  Los objetivos son útiles a los desarrolladores cuando dan a conocer las intenciones de los usuarios del sistema .

Propiedad Rapidez Ejemplo de Medida Transacciones procesadas por segundo Tiempo de respuesta al usuario y a eventos Tiempo de actualización de la pantalla Tamaño Facilidad de uso Fiabilidad KB Número de chips de RAM Tiempo de capacitación Número de cuadros de ayuda Tiempo promedio entre fallas Probabilidad de no disponibilidad Tasa de ocurrencia de las fallas Disponibilidad Tiempo de reinicio después de fallas Porcentaje de eventos que provocan las fallas Probabilidad de corrupción de datos % de declaraciones dependientes del objetivo Número de sistemas objetivo Robustez Portabilidad .

restricciones en requerimientos existentes o definición de cálculos específicos  Si los requerimientos de dominio no son satisfechos.Derivado del dominio de la aplicación. describe las características del sistema y aspectos que reflejen el dominio  Podrían existir nuevos requerimientos funcionales. el sistema no será utilizable  .

Literatura técnica Aplicaciones existentes Taxonomía de clases Estándar de reusabilidad Fuentes de dominio del conocimiento Recursos del cliente Consejo de experto Requisitos actuales/futuros Análisis del dominio Modelos funcionales Lenguajes del dominio Modelo del análisis del dominio .

 Comprensibilidad  Los requerimientos son expresados en el lenguaje del dominio de la aplicación  Esto no es entendido frecuentemente por ingenieros de software que desarrollan el sistema  Implicación  Especialistas de dominio entienden el área tan bien que no piensan establecer requerimientos de dominio explícitos .

   El documento de requerimientos es la definición oficial de lo que es requerido por los desarrolladores de sistemas Deben incluir una definición y una especificación de los requerimientos No es un documento de diseño. Debe especificar lo que el sistema debe hacer en vez del cómo lo debe hacer .

Clientes del sistema Especifican los requerimientos y los lee para verificar que cumplen sus necesidades. Especifican los cambios en los requerimientos Utilizan el documento de requerimientos para planear el proceso de desarrollo del sistema Utilizan los requerimientos para comprender por qué se desarrollará el sistema Administradores Ingenieros de sistemas Ingenieros que prueban el sistema Utiliza los requerimientos para desarrollar las pruebas de validación para el sistema Utilizan los requerimientos para ayudar a comprender el sistema y las relaciones entre las partes Ingenieros de mantenimiento del sistema .

predice cambios  Caracteriza respuestas a eventos inesperados     Formato de Requerimientos IEEE830 .Especifica el comportamiento externo del sistema Especifica las restricciones de implementación Fácil de modificar Sirve como herramienta de referencia para mantenimiento  Registra la disposición acerca del ciclo de vida del sistema ej.

Sign up to vote on this title
UsefulNot useful