Upload
inez-jasmin
View
216
Download
0
Embed Size (px)
Citation preview
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