Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

REQUERIMIENTOS DE SOFTWARE

No description
by

Gloria Molina

on 24 July 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of REQUERIMIENTOS DE SOFTWARE

REQUERIMIENTOS DE SOFTWARE
Requerimientos No Funcionales
Surgen de:
Las necesidades del usuario (requerimientos del producto)
Características de la organización (requerimientos organizacionales)
Factores externos (requerimientos externos)
Requerimientos Funcionales
Requerimientos de usuario, se describen de una forma bastante abstracta
Requerimientos del sistema, se describen con detalle la función de éste, sus entradas y salidas, excepciones, etcétera.
Requerimientos de Dominio
Derivan del dominio de aplicación del sistema más que de las necesidades específicas de los usuarios.
INGENIERÍA DE REQUERIMIENTOS
Continuará...
Documento de Requerimientos de Software
Usuarios del documento SRS:
REQUERIMIENTOS
Los requerimientos son las descripciones de los servicios proporcionados por el sistema y sus restricciones operativas.
El proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se denomina ingeniería de requerimientos (RE).
Detalle de las funciones, servicios y restricciones operativas del sistema. Debe decir exactamente que es lo que se va a implementar.
Se requiere información a diferentes niveles por que interesa a diferente tipo de lectores.
Provienen del dominio de aplicación del sistema y reflejan las características y restricciones de ese dominio.
Pueden ser funcionales o no funcionales.
Tipos Requerimientos No Funcionales
Este gran apartado incluye todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo.
Métricas
Los requerimientos no funcionales pueden ser difíciles de verificar ya que los usuarios los redactan como metas generales que dejan abierta la posibilidad a interpretación.
Se puede incluir las metas en el documento de requerimientos junto con los requerimientos pero debe advertirse al desarrollador que están abiertas a interpretaciones erróneas y que no se pueden verificar de forma objetiva.
Requerimientos de Usuario
Pautas para Minimizar Malentendidos
Los Robertson (VOLERE), recomiendan redactar inicialmente los requerimientos del usuario en tarjetas con varios campos..
Fundamento de los requerimientos.
Dependencias con otros requerimientos.
Fuente de los requerimientos.
Material de apoyo.
Otros.
Requerimientos del Sistema
Existen varias razones para esto:
Puede tener que diseñar una arquitectura inicial del sistema para ayudar a estructurar la especificación de requerimientos.
En muchos casos, los sistemas deben interoperar con otros ya existentes.
Es necesario el uso de una arquitectura específica para satisfacer los requerimientos no funcionales.
Debido al nivel de detalle de los requerimientos las especificaciones en lenguaje natural pueden ser confusas y difíciles de entender:
Notación para la Especificación de Requerimientos
Se pueden redactar los requerimientos del sistema en unas notaciones más especializada .
Especificaciones en lenguaje estructurado
Cuando se utiliza un formulario estándar se debe incluir la siguiente información:
Descripción de la función o entidad a especificar.
Descripción de sus entradas y de dónde provienen (Fuente).
Descripción de sus salidas y hacia dónde van (Destino).
Indicación de qué otras entidades se utilizan (Requerimientos).
Si se utiliza un enfoque funcional:
Una precondición que indique lo que se debe cumplir antes de invocar a la función.
Una postcondición que especifique lo que será verdad una vez invocada dicha función.
Descripción de los efectos colaterales (si existen) de la operación.
Especificación de la Interfaz
Interfaces de procedimientos: Ofrecen servicios. También denominadas Interfaces de Programación de Aplicaciones (APls).
Estructuras de datos: Que pasan de un subsistema a otro. Los modelos gráficos de datos son las mejores notaciones para este tipo de descripción.
Representaciones de datos: (como el orden de los bits) establecidas para un subsistema existente. Comunes en sistemas de tiempo real embebido. La mejor forma de describir es utilizar un diagrama de la estructura con anotaciones que expliquen la función de cada grupo de bits.
Este estándar IEEE sugiere la siguiente estructura para los documentos de requerimientos:
Introducción
Propósito del documento de requerimientos
Alcance del producto
Definiciones, acrónicos y abreviaturas
Referencias
Descripción del resto del documento
Descripción general
Perspectiva del producto
Funciones del producto
Características del usuario
Restricciones generales
Suposiciones y dependencias
Requerimientos específicos
Requerimientos funcionales, no funcionales y de interfaz.
No es apropiado definir una estructura estándar para esta sección.
Apéndices
Índice
Niveles de Especificación
Requerimientos de Usuario
Requerimientos del Sistema
Lenguaje natural y diagramas de servicio y restricciones.
LECTORES: Administradores clientes, Usuarios finales del sistema, Ingenieros clientes, Administradores contratistas, Arquitectos del sistema.
LECTORES: Usuarios finales del sistema, Ingenieros clientes, Arquitectos del sistema, Desarrolladores del software.
Tipos de Requerimientos
Funcionales
No Funcionales
De Dominio
Declaraciones de los servicios que debe proporcionar el sistema.
Reacción a entradas particulares
Comportamiento en situaciones particulares.
Restricciones del sistema.
Restricciones de los servicios o funciones ofrecidos por el sistema.
Restricciones de tiempo, sobre el proceso de desarrollo y estándares.
Se aplican al sistema en su totalidad.
Describen lo que el sistema debe hacer.
Dependen de:
Tipo de Software que se desarrolle.
Posibles usuarios del sistema.
Enfoques general tomando por la organización al redactar requerimientos.
La especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente.
Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación.
COMPLETITUD: Todos los servicios solicitados por el usuario deben estar definidos..
CONSISTENCIA: No deben tener definiciones contradictorias..
En la práctica, para sistemas grandes y complejos, es prácticamente imposible alcanzar los requerimientos de consistencia y completitud..
No se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes.
Definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema.
Especifican o restringen las propiedades emergentes del sistema.
Más críticos que los requerimientos funcionales particulares.
También pueden restringir el proceso que se debe utilizar para desarrollar el sistema.
Requerimientos del producto
Requerimientos organizacionales
Requerimientos externos
Estos requerimientos especifican el comportamiento del producto.
Estos requerimientos se derivan de políticas y procedimientos existentes en la organización del cliente y en la del desarrollador.
Requerimientos No Funcionales
Siempre que sea posible, se deben redactar los requerimientos de manera cuantitativa para que se puedan probar de un modo objetivo cuando se prueba el sistema.
Tomar en cuenta:
No existe métricas a utilizar para todas las metas.
Aun si existen las métricas puede que el cliente no pueda relacionarlas con sus necesidades.
El coste de verificar de forma objetiva los requerimientos no funcionales cuantitativos puede ser muy alto y los clientes quizás piensen que estos costes no son justificados.
Los requerimientos no funcionales entran en conflicto e interactúan con otros requerimientos funcionales o no funcionales.
Se deben resaltar los requerimientos que claramente se refieran a las propiedades emergentes del sistema.
Incluyen terminología especializada del dominio o referencias a conceptos del dominio.
Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares.
Resulta difícil entender cómo se relacionan con los otros requerimientos del sistema por la especialización.
La importancia se debe a que a menudo reflejan los fundamentos del dominio de aplicación.
Si estos requerimientos no se satisfacen, puede ser imposible hacer que el sistema funcione de forma satisfactoria.
Redactarse en un lenguaje sencillo, con tablas y formularios sencillos y diagramas intuitivos enfocándose simplemente en los recursos principales que debe proporcionar.
Redactar en lenguaje Natural puede presentar problemas:
Falta de claridad: Redacción ambigua, poco conciso o difícil de leer.
Confusión de requerimientos: No se distinguen entre tipos de requerimientos y metas.
Conjunción de requerimientos: Varios requerimientos en uno.
Separar en el documento de requerimientos los requerimientos del usuario de los del sistema ayuda a que los lectores no técnicos no se confundan con detalles solo relevantes para lectores técnicos.
Se debe intentar asociar un fundamento con cada requerimiento del usuario explicando por qué se ha incluido el requerimiento.
Estandarizar el formato de los requerimientos.
Reduce omisiones y facilita la verificación.
Utilizar el lenguaje de forma consistente.
Distinguirse entre requerimientos deseables y obligatorios.
OBLIGATORIOS: El sistema debe contemplar y se redactan en futuro simple.
DESEABLES: No son fundamentales y se redactan en futuro condicional.
Resaltar el texto para distinguir las partes clave del requerimiento
Evitar el uso de jerga informática
Versiones extendidas de los requerimientos del usuario agregando detalle que son utilizados por los ingenieros de software como punto de partida para el diseño del sistema.
Puede ser utilizados como parte del contrato para la implementación del sistema por lo que debe ser una especificación completa y consistente del sistema entero.
Deben describir el comportamiento externo del sistema y sus restricciones operativas sin tomar en cuenta el diseño pero no se puede excluir siempre en sistemas grandes y complejos.
La comprensión depende de que los lectores y redactores de la especificación utilicen las mismas palabras para el mismo concepto.
La especificación de requerimientos es demasiado flexible.
No existe una forma fácil de modularizar los requerimientos.
Los problemas se descubren en fases posteriores del proceso del software, y resolverlas resultar muy costoso.
Forma de redactar los requerimientos del sistema donde la libertad del redactor está limitada y la redacción es estándar limitando la terminología y utilizando plantillas o formularios estándar predefinidos.
VENTAJA: Mantiene la mayor parte de la expresividad y comprensión del lenguaje natural y los requerimientos se organizan de forma más efectiva.
Aun así es difícil redactar requerimientos de forma no ambigua, especialmente cuando se requieren cálculos complejos.
Se puede añadir información adicional utilizando tablas o modelos gráficos del sistema.
Las tablas son especialmente útiles cuando hay varias situaciones alternativas posibles y se necesita describir las acciones a tomar para cada una de ellas.
Los modelos gráficos son los más útiles cuando se necesite mostrar cómo cambia el estado o cuando se necesite describir una secuencia de acciones.
Casi todos los sistemas software deben funcionar con otros sistemas que ya están implementados e instalados en el entorno.
Para que trabajen juntos las interfaces deben explicarse de forma precisa.
Debe incluirse al inicio del proceso en el documento de requerimientos.
Tipos de interfaces a definirse:
Las notaciones formales permiten definir interfaces de una forma no ambigua pero pocas veces se utilizan en la práctica para la especificación de interfaces.
Algunas veces denominado especificación de requerimientos del software o SRS.
Declaración oficial de QUÉ deben implementar los desarrolladores del sistema incluyendo tanto los requerimientos del usuario como una especificación detallada de los requerimientos del sistema.
Nivel de detalle esta en base al tipo de sistema y proceso de desarrollo utilizado.
El estándar más ampliamente conocido es el IEEE/ANSI 830-1998 (IEEE, 1998).
Los métodos de desarrollo ágiles proponen que los requerimientos del usuario deberían ser recogidos incrementalmente y escritos en tarjetas.
Aunque el estándar IEEE no es ideal, contiene muchos consejos sobre cómo redactar los requerimientos y cómo evitar problemas.
El SRS es fundamental cuando un contratista exterior está desarrollando el sistema software.
Full transcript