Ingeniería de Software

Ing. De requerimientos / SRS

Es la disciplina de establecer los servicios requeridos por el cliente para un sistema y las restricciones en las cuales el mismo va a operar y en las cuales va a ser desarrollado, buscando cumplir los objetivos esperados por el cliente.

¿Qué es la ing. de requerimientos?

“La tarea más difícil de construir un sistema de software es precisamente decidir qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requisitos, incluyendo todas las interfaces a las personas, a las máquinas, y otros sistemas del software. Ninguna parte del trabajo lesiona tanto al sistema resultante si hace mal. Ninguna otra parte es más difícil de rectificar después."[Brooks, No Silver Bullets, 1987].

Su importancia

El requerimiento puede variar desde una sentencia abstracta de un servicio o restricción a una función matemática detallada.Un mismo requerimiento puede ser dado como fuente para realizar el relevamiento o directamente como un contrato que debe ser respetado. En casos de licitación, una especificación de requerimientos de alto nivel sin detalles se utiliza para que distintos interesados puedan licitar.

A partir de cada objetivo es la explicitación de una intención que el cliente requiere para el sistema. De estos objetivos salen los requerimientos. A veces el cliente especifica los requerimientos sin tener en cuenta los objetivos que busca.

¿Qué es un requerimiento?

Según punto de vista:◦ Requerimientos de usuario: Sentencias en lenguaje natural o en poco

detalle especificando a alto nivel el servicio provisto. ◦ Requerimientos de sistema: Documento estructurado, especificando en

detalle y en lenguaje formal, especificando las acciones que hará el sistema para proveer dicho requerimiento

Según funcionalidad:◦ Requerimientos funcionales: se ven servicios y funcionalidades

individuales que el sistema debe proveer. En general actúan como respuesta a estímulos específicos. En la mayoría de los casos relacionan con el atributo de calidad funcionalidad.

◦ Requerimientos no funcionales y restricciones: Se ven servicios y funcionalidades que el sistema debe proveer como un todo. Incluye además requerimientos de tecnologías específicas, estándares de calidad, y restricciones por parte del proceso y la organización. En general pueden ser mas importantes que los funcionales ya que delimitan el accionar de los desarrolladores.

Clasficación

En la práctica los requerimientos no funcionales ponen cotas de aceptación a los atributos de calidad. Partiendo de los requerimientos no funcionales, se crean requerimientos funcionales.

Requerimientos no funcionales

Imprecisión◦ Es difícil lograr requerimientos específicos.

Coherencia◦ Entre los diferentes requerimientos

Ambigüedad◦ Sobre todo en el lenguaje

Abstracción◦ Solo se debe tener en cuenta lo relevante para el

sistema.

Complejidades especificando

Esta fase consiste en realizar un relevamiento inicial de los requerimientos principales del proyecto◦ No se puede avanzar en las tareas de planificación sin tener una

conocimiento global de lo que hay que hacer.◦ No siempre se cuenta con mucho tiempo para realizar esta tarea en

detalle, se debe realizar a un alto nivel.

Tiene por objetivo:◦ Especificar el objetivo del proyecto y alcance◦ Identificar los roles del cliente◦ Establecer los drivers del proyecto◦ Definir los requerimientos mas importantes del proyecto (“Wish

List”) Funcionales No Funcionales Restricciones

Identificación de requerimientos

Describe los resultados de negocio esperados a los cuales contribuye la concreción del proyecto

El éxito del proyecto deberá medirse en el grado de cumplimiento de dichos objetivos

Los objetivos deben ser precisos (de lo contrario no se podrá corroborar si se alcanzaron)

Recordar no confundir la solución con el objetivo del proyecto

La solución es el curso de acción para alcanzar el objetivo

El objetivo no es la forma en que vamos a hacer algo sino el resultado que esperamos

Identificación de requerimientos

Alcance◦ Define los límites del sistema◦ Lo que incluye◦ Si es necesario, se aclaran especialmente que “no” incluye (con el

objetivo de despejar dudas)

La lista de requerimientos debe incluir:◦ Requerimientos Funcionales

Describen como debe comportarse el sistema ante determinado estímulo Describen la interacción entre sistema y ambiente (describen los servicios que

el sistema proveerá)◦ Requerimientos No Funcionales

Describen bajo qué condiciones debe darse el comportamiento del sistema◦ Restricciones

Describen limitaciones a la que debe estar sujeta la solución que se diseñe y por lo general tienen poca flexibilidad (no están bajo control directo) Ej.: cumplimiento de estándares / ejecutar sobre cierta plataforma específica / legislación

Identificación de requerimientos

Etapas en la ing. de req.

La lista debe estar priorizada◦ Esenciales (“Must Have”)◦ Importantes (“Should Have”)◦ Deseables (“Nice to Have”)

Priorización de requerimientos

Validez: El sistema provee la funcionalidad que mejor atiende las necesidades del cliente?

Consistencia: Hay algún conflicto entre los requerimientos?

Completitud: Están incluidas todas las funciones requeridas por el cliente?

Realismo: Se pueden implementar los requerimientos con el presupuesto y la tecnología disponible?

Verificabilidad: Se pueden verificar los requerimientos?

Chequeo interno de los requerimientos

Comprensibilidad: Se entienden? Trazabilidad: Se puede identificar

claramente el origen de los requerimientos? Adaptabilidad: Se pueden cambiar sin tener

un gran impacto en los otros requerimientos?

Chequeo externo de los requerimientos (con los clientes)

Sponsor◦ Es el “owner” del proyecto◦ Es el que tiene la autoridad para llevar adelante el proyecto

Usuario Campeón◦ Experto en el dominio del problema del proyecto◦ Asegurar su capacidad para la función y su disponibilidad (son

muy demandados) Stakeholders

◦ Los que tienen el poder de decisión para con capacidad de influir en la marcha del proyecto

Usuarios Directos◦ Interactuan directamente con el sistema

Usuario Indirectos◦ Hacen uso del sistema, aunque no necesariamente lo operan

Roles a tener en cuenta

Se identifican 5 dimensiones en un Proyecto de SW:◦ Funcionalidad◦ Calidad◦ Recursos◦ Costo◦ Plazo

No se puede cumplir con todas a la vez !! Cada dimensión puede ser

◦ Driver: objetivo vital a lograr (tiene poco/nada de flexibilidad)

◦ Restricción: no está bajo nuestro control directo y también tiene poco/nada de flexibilidad

◦ Grados de Libertad: Libertad para fijar objetivos en alguna dimensión

Dimensiones

Es una conversacion, no un interrogatorio Se puede hacer con una o mas personas Se pueden utilizar preguntas abiertas (para obtener

información cualitativa) o cerrada (determinísticas, por ej cantidades)

Pasos para armarla: lectura previa, establecer objetivos, decidir a quienes entrevistar, preparar al entrevistado, decidir estructura y tipo de preguntas, armar entrevista

Ventajas: no hay intermediarios, se puede preguntar sobre temas que surgen en el momento, mejora relación con usuario, aporta calidad porque permite hallar opiniones, problemas, políticas, etc.

Desventajas: mucho tiempo en planificación, mucho tiempo en entrevistar, poca “cantidad” de información obtenida, mucho tiempo para analizar resultados

Técnicas de relevamiento: Entrevista

Se busca obtener una percepción de lo que realmente sucede, no solo de lo documentado

Se puede utilizar para verificar lo relevado con otras técnicas

Permite obtener información directa sobre qué, cómo, quién, cuándo se hace, cuánto tarda, dónde se hace y para qué se hace la tarea observada.

Puede ser participativa (incluye al observador, se interrumpe la tarea), o no participativa (atención: LA OBSERVACIÓN MODIFICA EL EXPERIMENTO)

Observación

Generalmente las respuestas son “multiple choice” (cerrado), también se pueden hacer para recabar información en general (abirto)

Se puede utilizar para cuantificar lo hallado en las entrevistas

Antes de distribuir masivamente se recomienda hacer un pequeño test para retocar el cuestionario si hace falta

Ventajas: se puede automatizar el análisis, es relativamente barato en comparación a la información obtenida, si son anónimos se puede obtener información sincera

Desventajas: suele haber problemas de interpretación, se debe articular para que TODOS los respondan, es poco flexible ya que no se hace en presencia del analista y no permite profundizar en caso de ser necesario

Cuestionario

Muy ùtil a la hora de rehacer un sistema existente

Problemas: la falta de documentación atenta contra esta técnica de relevamiento

Ventaja: se puede hacer búsqueda de patrones en datos, se puede analizar volúmenes y performance esperados

Revisión de registros

El documento de requisitos es un escrito oficial de los requisitos del sistema para los clientes, usuarios finales y desarrolladores de software.

Se lo conoce por diferentes nombres:◦ especificación funcional,◦ definición de requisitos,◦ especificación de los requisitos de software (SRS)

SRS

El documento describe:◦ Los servicios y funciones que el sistema debería proveer.◦ Las restricciones bajo las cuales el sistema debe operar ◦ Las propiedades generales del sistema, entre otras cosas,

restricciones sobre las propiedades emergentes del sistema

◦ Definiciones de otros sistemas con los cuales el sistema se debe integrar.

◦ Información acerca del dominio de aplicación del sistema, por ej. cómo llevar a cabo tipos particulares de cálculos.

◦ Restricciones sobre el proceso usado para desarrollar el sistema

SRS

Un SRS es correcto si, y sólo si, cada requerimiento incluido es uno de los que el software debe cumplir. No hay ninguna herramienta o procedimiento que aseguran la exactitud. Alternativamente el cliente o el usuario pueden determinar si el SRS refleja las necesidades reales correctamente.

Caract. de la SRS: Correcto

Un SRS es inequívoco si, y sólo si, cada requisito declarado tiene sólo unainterpretación. Es aconsejable el uso de un glosario. Hay que tener cuidado con las trampas del idioma natural, se puede apelar a lenguajes de especificación o al uso de herramientas CASE.

Caract. de la SRS: Inequívoco

Caract. de la SRS: Inequívoco

Los requerimientos deben estar relacionados con la funcionalidad, el desarrollo, las restricciones del diseño, los atributos y las interfaces externas.

Se debe incluir la definición de las respuestas del software a todos los posibles datos de la entrada del sistema y a toda clase de situaciones.

Caract. de la SRS: Completo

La consistencia se refiere a la consistencia interior. Si un SRS no está de acuerdo conalgún documento del superior-nivel, como una especificación de requisitos de sistema,entonces no es correcto.

Caract. de la SRS: Consistente

Un SRS debe delinear la importancia y/o estabilidad si cada requisito en él tiene unidentificador para indicar la importancia o estabilidad de ese requisito en particular.Típicamente, todos los requisitos que relacionan a un producto del software no sonigualmente importantes.

Caract. de la SRS: Delinear que tiene importancia y/o estabilidad

Un SRS es comprobable si, y sólo si, cada requisito declarado es comprobable. Unrequisito es comprobable si, y sólo si, allí existe algún proceso rentable finito con queuna persona o la máquina puede verificar que el producto del software reúne elrequisito.

Caract. de la SRS: Comprobable

Un SRS es modificable si, y sólo si, su estructura y estilo son tales que puede hacerse cualquier cambio a los requisitos fácilmente, completamente y de forma consistente mientras conserva la estructura y estilo.

Caract. de la SRS: Modificable

Un SRS es identificable si el origen de cada uno de sus requisitos está claro (hacia atrás) y si facilita las referencias de cada requisito en el desarrollo futuro o documentación del mismo (hacia adelante).

Caract. de la SRS: Identificable

Introducción◦ Propósito del documento de requisitos◦ Alcance del proyecto◦ Definiciones, acrónimos y abreviaturas◦ Resumen del resto del documento

Descripción General◦ Perspectiva del producto◦ Funciones del producto◦ Características de los usuarios◦ Limitaciones generales◦ Suposiciones y dependencias

Requisitos Específicos◦ Requisitos funcionales, no funcionales

Apéndices Índice

SRS: Estructura básica

Preguntas

Sugerencias

Aplausos