Ingenieria de requerimientos y modelo para identificar los requerimientos. Parte # 3
Siguiendo con la serie de post sobre la ingeniería de requerimientos y es este post donde se hablara sobre la siguiente etapa del modelo de ingeniería de requerimientos. Esta etapa es llamada:
Análisis
El análisis de los requerimientos consiste en estudiar las necesidades de los clientes para plantearlas en términos de un sistema de software. Para lograr esto, existen diferentes técnicas como diagramas de contexto, diagramas de flujo o diagramas de estado. UML utiliza la técnica de Casos de Uso para analizar las necesidades de los usuarios y estructurarlas a manera de servicios que el sistema debe proveer.
Casos de uso
Son historias del uso de un sistema para alcanzar sus objetivos. Especifica todos los posibles escenarios para una funcionalidad. Representa una colección de escenarios con éxito y fracaso relacionados, que describen los actores utilizano un sistema para satisfacer un objetivo Los casos de uso describen lo siguiente:
- División del trabajo: Describen procesos de trabajo de los usuario relevantes para el sistema. Definición de las fronteras entre el usuarios y sistema.
- Funciones principales del sistema
- Funciones de apoyo del sistema
- Dialogo: describen las interacciones entre usuarios e interfaz de usuario del sistema.
Ejemplo de la estrategia del producto Unificado sobre el desarrollo de requisitos.
Utilizando terminología orientada a objetos, cada caso de uso define una clase o forma particular de usar el sistema mientras que cada ejecución del caso de uso se puede ver como una instancia del caso de uso, o sea, un objeto, con estado y comportamiento.
El actor primario es encargado de dar inicio a esta interacción, mientras que los casos de uso son instanciados como respuesta al evento anterior. Una instancia de un actor puede ejecutar varias de estas secuencias, consistiendo de diferentes acciones que a su vez deben llevarse a cabo.
La instancia del caso de uso existe mientras el caso de uso siga ejecutando. La ejecución del caso de uso termina cuando el actor genere un evento que requiera un caso de uso nuevo. Las diferentes instancias de los casos de uso se conocen como escenarios.
Tecnicas
Para identificar los casos de uso, se puede leer la descripción del problema y discutirlo con aquellos que actuarán como actores, haciendo preguntas como:
- ¿Cuales son las tareas principales de cada actor?
- ¿Tendrá el actor que consultar y modificar información del sistema?
- ¿Tendrá el actor que informar al sistema sobre cambios externos?
- ¿Desea el actor ser informado sobre cambios inesperados?
Los nombres de los casos de uso deben corresponder a acciones y no tanto a sustantivos.
La identificación de casos de uso y de los aspectos anteriores, es a menudo un proceso muy iterativo donde varios intentos se hacen hasta llegar a una solución final estable. Cuando esto ocurre, cada caso de uso debe ser descrito con más detalle.
Tipicos errores que se comenten en la especificacion de casos de uso
10. No escriba los requisitos funcionales en vez del texto del escenario de uso.
Los requisitos se expresan generalmente en términos de lo que el sistema hará, mientras los escenarios de uso describen las acciones que los usuarios toman y las respuestas que el sistema genera
9. No describa los atributos y los métodos antes que el uso.
El texto del caso del uso no debe incluir demasiados detalles de presentación, los métodos no deberán ser nombrados y descritos en el texto del caso de uso porque ellos representan cómo el sistema hará las cosas, en comparación con lo que el sistema hará.
8. No escriba los casos de uso de modo muy cortante.
Cuando se trata de escribir texto para el caso de uso, entre mas detallado mejor. Uno debe de dirigir todos los detalles de las acciones del usuario , así como las respuestas del sistema, porque nuestro caso de uso será la base para el manual del usuario.
7. Diseñe detalladamente la interfaz de usuario
Es la base indispensable para el entendimiento tanto del usuario final como del programador quien desarrollará el caso de uso.
6. No evite nombres explícitos para sus objetos frontera.
Los objetos frontera son los objetos con los que el actor interactúa (ventanas, menús, etc.) Entonces será necesario nombrar a los objetos frontera de forma explícita en el texto del caso de uso.
Los requisitos se expresan generalmente en términos de lo que el sistema hará, mientras los escenarios de uso describen las acciones que los usuarios toman y las respuestas que el sistema genera
9. No describa los atributos y los métodos antes que el uso.
El texto del caso del uso no debe incluir demasiados detalles de presentación, los métodos no deberán ser nombrados y descritos en el texto del caso de uso porque ellos representan cómo el sistema hará las cosas, en comparación con lo que el sistema hará.
8. No escriba los casos de uso de modo muy cortante.
Cuando se trata de escribir texto para el caso de uso, entre mas detallado mejor. Uno debe de dirigir todos los detalles de las acciones del usuario , así como las respuestas del sistema, porque nuestro caso de uso será la base para el manual del usuario.
7. Diseñe detalladamente la interfaz de usuario
Es la base indispensable para el entendimiento tanto del usuario final como del programador quien desarrollará el caso de uso.
6. No evite nombres explícitos para sus objetos frontera.
Los objetos frontera son los objetos con los que el actor interactúa (ventanas, menús, etc.) Entonces será necesario nombrar a los objetos frontera de forma explícita en el texto del caso de uso.
5. No escriba en voz pasiva, use la perspectiva del usuario.
El caso de uso es mas efectivamente escrito desde la perspectiva del usuario como un conjunto de verbos en tiempo presente en voz activa. Porque los casos de uso deben expresar las acciones que el usuario realiza, y las respuestas del sistema a esas acciones.
4. No describa únicamente las interacciones con el usuario, ignorando las respuestas del sistema.
La narrativa de un caso de uso debe orientarse a un evento-respuesta, como lo siguiente, "el sistema hace esto cuando el usuario hace aquello" el caso de uso captura que pasa "bajo cubierta" en respuesta a lo que el actor hizo.
3. No omita texto para cursos de acción alternativos.
Los cursos de acción son fáciles de identificar y escribir su texto. Pero se debe de tratar de identificar cursos de acción alternativa lo que evitara problemas al programar al tener que implementar cosas que se omitieron en los casos de uso.
2 No se enfoque en otra cosa que no sea "lo que esta adentro" de un caso de uso, tales como usted llega a allí o lo que acontece después.
Deberá tratar de no usar largas y complejas plantillas para casos de uso, solo porque digan o aparezca en algún libro o revista.
1. No desperdicie un mes decidiendo si usa includes o extends.
Tratar de usar un solo mecanismo para descomponer en factores.
El caso de uso es mas efectivamente escrito desde la perspectiva del usuario como un conjunto de verbos en tiempo presente en voz activa. Porque los casos de uso deben expresar las acciones que el usuario realiza, y las respuestas del sistema a esas acciones.
4. No describa únicamente las interacciones con el usuario, ignorando las respuestas del sistema.
La narrativa de un caso de uso debe orientarse a un evento-respuesta, como lo siguiente, "el sistema hace esto cuando el usuario hace aquello" el caso de uso captura que pasa "bajo cubierta" en respuesta a lo que el actor hizo.
3. No omita texto para cursos de acción alternativos.
Los cursos de acción son fáciles de identificar y escribir su texto. Pero se debe de tratar de identificar cursos de acción alternativa lo que evitara problemas al programar al tener que implementar cosas que se omitieron en los casos de uso.
2 No se enfoque en otra cosa que no sea "lo que esta adentro" de un caso de uso, tales como usted llega a allí o lo que acontece después.
Deberá tratar de no usar largas y complejas plantillas para casos de uso, solo porque digan o aparezca en algún libro o revista.
1. No desperdicie un mes decidiendo si usa includes o extends.
Tratar de usar un solo mecanismo para descomponer en factores.
En este punto teniendo identificados lo casos de uso se puede iniciar la siguiente fase que es la especificación.