Según la IEEE un requerimiento es la condición o capacidad que debe poseer un sistema o un componente de un sistema para satisfacer un contrato, un estándar, una especificación u otro documento formalmente impuesto.

 Requerimientos de proceso

En principio, los requerimientos deben establecer lo que el sistema debe hacer y el diseño debe describir como hacerlo, pero en la practica requerimientos y diseño son inseparables

Los requerimientos del proceso son a nivel organizacional, describen “el cómo”, es decir, describen los procedimientos y políticas que las organizaciones deben seguir así como las restricciones que deben obedecer, por ejemplo, estándares usados en los procesos, los requerimientos de implementación, etc.

Los requerimientos de proceso se imponen a menudo como la manera de alcanzar un cierto requerimiento de alto nivel del producto. Por ejemplo, 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).

Requerimientos de los usuarios (actores involucrados)

Los requerimientos de los usuarios 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.

Los requerimientos del sistema son los mismos que los requerimientos de los usuarios, pero son descritos en lenguaje técnico y de manera más detallada a diferencia de los requerimientos de los usuarios, que se describen en el lenguaje cotidiano de ellos, para su mayor comprensión por parte de los usuarios.

Requerimientos para el análisis y negociación

Una vez recopilados los requerimientos el producto obtenido configura la base del análisis de requerimientos. De manera general en la actividad del análisis y negociación los requerimientos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requerimiento en relación con el resto, se examinan los requerimientos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes y/o usuarios y del negocio, y considerando también costo tiempo y esfuerzo que se llevará en realizar cada uno de los requerimientos.

Requerimientos para la gestión

La gestión de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del sistema y se lleva a cabo junto con el proceso de ingeniería de requerimientos. La planeación comienza al mismo tiempo que la obtención inicial de requerimientos y la administración activa debe iniciar tan pronto esté lista la primera versión del documento de requerimientos.

Antes de definir las etapas de la administración de requerimientos se discute porque los requerimientos inevitablemente cambian.

Desde una perspectiva evolutiva los requerimientos se dividen en dos clases:

• Requerimientos duraderos: son aquellos relativamente estables, resultan de la actividad principal de la organización y están relacionados directamente con el dominio del sistema.
• Requerimientos volátiles: son aquellos que cambiarán probablemente durante el desarrollo del sistema o después de que éste ya se haya puesto en operación. Además se clasifican en los siguientes:

• Requerimientos mutantes: cambian debido a los cambios en el ambiente en el que opera la organización.
• Requerimientos emergentes: resultan al incrementarse la comprensión del cliente en el desarrollo del sistema.
• Requerimientos consecutivos: resultan de la introducción del sistema de cómputo, la cual puede cambiar los procesos de la organización.
• Requerimientos de compatibilidad: dependen de sistemas particulares o procesos de negocios dentro de la organización.

Las caracteristicas que debe de culplir un requerimientos son las siguientes:

• validez
• consistencia
• integridad
• realismo
• verificabilidad

Queremos modelar el sistema de pago de una tienda web.

El cliente debe identificarse mediante su dirección de correo. Si es un nuevo cliente se le debe registrar en el sistema previamente, pidiéndole los datos personales. Una vez identificado el cliente, éste podrá elegir el medio de pago: por transferencia bancaria o con tarjeta de crédito.  Según el medio de pago se le solicitarán unos datos u otros.El cliente también deberá elegir el método de envío.Finalmente se le mostrarán todos los datos del pedido para pedirle que lo confirmen.

Supongamos que se desea desarrollar el control de una máquina de entrega de café automática.

La máquina debe permitir a una persona introducir dinero, escoger uno de los productos de acuerdo a su precio, escoger un nivel de azúcar y entregar el producto y el cambio.El usuario puede en cualquier momento antes de escoger el azúcar cancelar la operación, mediante un botón existente para este objetivo.

Este es un diagrama básico pero esencial  en la programación , ya que este diagrama representa los diferentes «Usos » que nuestro software tendrá. Dicho esto ,este diagrama se representa de una forma   muy simple, como en las pinturas de la prehistoria con monos de palitos y teniendo ligado a él círculos que representas dichos usos que tendrá cada sección ( representado con el muñeco de palitos ). Y un flujo o asociación representado con una línea y por ultimo extensa o incluye representando si el siguiente te uso es una extensión o involución del uso al que se asocia.

En los diagramas de casos de uso tenemos varios elementos, como lo son :

Casos de uso:

Representan en forma básica un situación o caso en la que el actor utilizara alguna característica o acción en el sistema.

Actores

Se utilizan para representar el usuario directo que va a desempeñar un papel importante dentro del sistema y los cuales lleva a cabo casos de uso y un mismo actor puede realizar varios casos de uso ,pero a si mismo un caso de uso puede ser realizado por varios actores.

Extends

Se usa en el vinculo entre actor y caso de uso , para representar que se tiene un caso de uso que es similar al otro, pero que hace un poco más.

Uses

Se emplea para repetir cuando se trata de uno o varios casos de uso y desee evitar repeticiones.

Ejemplos :

Diagrama de casos de uso de una biblioteca :

Diagrama de casos de uso de una tienda simple:

Diagrama de caso de usos de una pagina de consulta de calificaciones :