Requisitos del Software 1 Curso 2024-2025 PDF

Ingeniería del Software 1 Curso 2024-2025 Requisitos del software Proceso y técnicas de requisitos Grupo de Ingeniería del Software Objetivo ▪ Entender qué son los requisitos y por qué son tan importantes en el desarrollo de software. ▪ Entender en el proceso de requisitos y cómo llevarlo a cabo. ▪ Conocer diferentes técnicas de requisitos y saber cómo aplicarlas en el proceso de requisitos. 2 ¿Qué es un requisito? Declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste. Definición detallada y formal de una función del sistema (I. Sommerville, 2005). Condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado (Piattini, 1996) Necesidades provenientes del usuario y otros stakeholders, que deben ser satisfechas (Aurum y Wohlin, 2005). Característica del sistema que es una condición para su aceptación [Norma MIL-STD-498]. 3 IEEE Std. 610 (1990) “Una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo.” “Una condición o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificación u otro documento formal.” “Una representación en forma de documento de una condición o capacidad como las expresadas en 1. o 2.” 4 Software Engineering Coordinating Committee “Propiedad que debe ser exhibida por un software para resolver un problema particular.” 5 ¿Para qué sirven? Para obtener sistemas útiles que contribuyan a la consecución de los objetivos de negocio y satisfagan las expectativas de clientes y usuarios. Para decidir qué tipo de solución software hay que desarrollar y cómo implementarla con las mayores garantías de éxito. 6 Repercusión en el desarrollo Lo más difícil en la construcción de un sistema software es decidir precisamente qué construir. Ninguna otra parte del trabajo afecta más negativamente al sistema final si se realiza de manera incorrecta. Ninguna otra parte es más difícil de rectificar a posteriori. (F. P. Brooks, 1987) 7 Atributos de un requisito Identificador único Tipo de requisito – 9999 Nombre descriptivo Nombre corto Versión y fecha de creación 1.0 – 01/01/2021 Autores (trazabilidad) Personas que lo redactan Fuentes (trazabilidad) Personas que proporcionan la información Dependencias (trazabilidad) Requisitos con los que se relaciona Importancia Relevancia para clientes y usuarios (p.e. Alta, Media, Baja) Estimación de la probabilidad de que el requisito no cambie durante el resto del Estabilidad desarrollo. (p.e. Alta, Media, Baja) Comentarios Otra información no prevista. Situación en la que se encuentra el requisito en el ciclo de vida del requisito (p.e. Estado Borrador, Analizado, Verificado, etc.) Indicador que establece la dirección del proyecto en base a diferentes factores y que Prioridad ayuda a decidir en qué iteración se implementará (p.e. Alta, Media, Baja) Coste estimado Valor calculado en base a la complejidad (p.e. Horas-persona) 8 Características deseables Necesario Verificable Conciso Inequívoco Completo Consistente 9 Ejemplos de requisitos El sistema a desarrollar permitirá emitir diferentes tipos de informes. El sistema debe ser fácil de usar por cualquier tipo de usuario. El sistema proporcionará una respuesta rápida al usuario. La aplicación se debe poder ejecutar en cualquier tipo de dispositivo. El sistema se recuperará automáticamente tras producirse un fallo. Los errores del sistema deben poderse corregir rápidamente. Los cambios en la funcionalidad deben hacerse lo antes posible. El sistema permitirá adjuntar ficheros a los trámites que se presenten. La aplicación deberá ser multiplataforma, encontrándose certificada para plataformas Linux, AIX y Windows. El sistema deberá trabajar en alta disponibilidad. La página web deberá permitir que toda su funcionalidad esté disponible utilizando los principales navegadores del mercado (Explorer, Firefox, Chrome, etc.) 10 Ejemplos de requisitos El sistema deberá poder imprimir un listado de los préstamos cuyo plazo haya expirado hace 5 días o más. El sistema deberá permitir al usuario realizar búsquedas de productos por categoría. El sistema deberá asignar un identificador único de cuatro dígitos numéricos a cada pedido que se registre. El sistema deberá soportar un máximo de 1000 usuarios concurrentes sin que el tiempo de respuesta medio aumente más de un 10%. Un usuario que haya realizado un entrenamiento de 2 horas deberá ser capaz de utilizar todas las funciones del sistema sin cometer más de 3 errores diarios. El sistema deberá volver a estar operativo tras cualquier fallo en un tiempo máximo de 5 minutos. El sistema deberá implementarse para GNU/Linux Ubuntu versión 18.04 en adelante. El sistema deberá utilizar el servicio @firma para todos los aspectos relacionados con validación y firma electrónica. Todas las comunicaciones externas del sistema deben estar encriptadas utilizando el algoritmo RSA. El sistema deberá disponer de un manual de usuario adecuado al IEEE Std 1063-2001. La aplicación debe poseer un diseño responsive a fin de garantizar la adecuada visualización en ordenadores personales, tabletas y teléfonos móviles. 11 Clasificación FURPS FUNCIONALITY (Funcionalidad). Características y capacidades del software y aspectos de seguridad. USABILITY (Usabilidad). Factores humanos Hewlett-Packard (interacción), estética, consistencia, documentación. RELIABILITY (Fiabilidad). Precisión, frecuencia de fallos, capacidad de recuperación. PERFORMANCE (Rendimiento). Velocidad, eficiencia, uso de recursos y el tiempo de respuesta. SUPPORTABILITY (Capacidad de mantenimiento o de soporte técnico). Extensibilidad, adaptabilidad, compatibilidad, mantenibilidad, configurabilidad. FURPS+ (Implementación, Interoperabilidad, Legales, etc.) 12 Clasificación Según la audiencia Requisitos del usuario. Descripción general, fácilmente comprensible, de los servicios que se esperan del sistema y de las restricciones bajo las cuales debe operar, dirigida al usuario final. Requisitos del sistema. Descripción detallada, lo más precisa posible, de los servicios que deberá proveer el sistema y las restricciones de su operación e implementación, dirigida a los diseñadores. 13 Clasificación Según su naturaleza Requisitos funcionales. Capacidades o servicios que deberá proporcionar el sistema para alcanzar los objetivos del usuario, cómo debe reaccionar a una entrada particular y qué comportamiento debe tener en determinadas circunstancias. Requisitos no funcionales. Cualidades de ejecución y evolución que debe tener el sistema, restricciones que afectan a los servicios que debe ofrecer y condiciones que ponen límites, tanto al sistema como al proceso de desarrollo. 14 Audiencia versus Naturaleza Según la naturaleza Funcionales No funcionales Del usuario – Del usuario – No Del usuario audiencia Según la funcionales funcionales Del sistema – Del sistema – No Del sistema funcionales funcionales 15 Conceptos básicos Definiciones (R.A.E.) Función 1. f. Capacidad de actuar propia de los seres vivos y de sus órganos, y de las máquinas o instrumentos. 2. f. Tarea que corresponde realizar a una institución o entidad, o a sus órganos o personas. Funcional 1. adj. Perteneciente o relativo a la función o a las funciones. 2. adj. Dicho de una cosa: Diseñada u organizada atendiendo, sobre todo, a la facilidad, utilidad y comodidad de su empleo. Funcionalidad f. Cualidad de funcional. 16 Functionality Oxford Dictionary: 1. [ uncountable]thequalityinsomethingofbeingverysuitableforthepurposeitwas designedfor. 2. [uncountable]thepurposethatsomethingisdesignedfororexpectedtoperform. 3. [ uncountable,countable](computing)the range of functions that a computer or other electronic system can perform. Cambridge Dictionary: 1. anyoralloftheoperationsperformedbyapieceofequipmentorasoftwareprogram. 2. the tasks that a computer, software program, or piece of electronic equipment is able to do. 3. thequalityofbeinguseful,practical,andrightforthepurposeforwhichsomething wasmade. 17 Requisitos funcionales (RF) Se refieren a la funcionalidad necesaria o conjunto de funciones que deberá tener el software para satisfacer las expectativas del cliente. Normalmente se afrontan en positivo aunque también pueden referirse a lo que el software no debe hacer: requisitos en negativo. Es importante indicar los datos de entrada que requiere cada función así como los datos de salida que se esperan. También deben incluirse las reglas de negocio que afectan a la funcionalidad así como la información que deberá estar almacenada en el sistema. Con los requisitos funcionales debemos poder dar respuesta a las siguientes preguntas: ¿Qué software queremos construir? ¿Para qué debe servir el software que vamos a desarrollar? ¿Qué servicios debe proporcionar? ¿Qué operaciones debe llevar acabo?. 18 Requisitos funcionales Requisitos de información Los requisitos de información son parte de los requisitos funcionales. Describen toda la información necesaria para poder ofrecer los servicios requeridos: qué datos de entrada hay que proporcionar al sistema, qué datos de salida debe proporcionar el sistema y qué datos debe almacenar el sistema. Elsistemadeberáalmacenarlasiguienteinformaciónsobrelosestudiantes: NIF/NIE,nombreyapellidos,domicilio,teléfonodecontactoycorreo electrónico. 19 Requisitos funcionales Reglas de negocio Las reglas de negocio también son parte de los requisitos funcionales. Describen restricciones y políticas del negocio que afectan a la funcionalidad y que deben ser respetadas por el sistema a desarrollar. El sistema deberá respetar la siguiente regla de negocio: un paciente sólo podrá pedir una cita para ser atendido por su médico de cabecera si no tiene otra pendiente. 20 Requisitos no funcionales (RNF) Requisitos del producto RNF Requisitos Requisitos organizacionales externos (Sommerville, 2011) 21 Requisitos no funcionales Requisitos del producto Se refieren a límites o restricciones sobre el comportamiento del sistema: Requisitos de usabilidad. Esfuerzo necesario para aprender y usar el software. Requisitos de eficiencia. Rendimiento en cuanto a tiempo de respuesta, número de operaciones por segundo, uso de recursos (memoria, procesador, espacio en disco o red). Requisitos de fiabilidad. Engloba la disponibilidad, confiabilidad, seguridad industrial, integridad y mantenibilidad. Requisitos de seguridad: Seguridad lógica, de datos, restricciones de acceso, autenticidad de la información y privacidad. La aplicación deberá consumir menos de 500 Mb de memoria RAM. 22 Requisitos no funcionales Requisitos organizacionales Se derivan de las políticas y procedimientos en la organización del cliente y del desarrollador: Requisitos de entorno. Factores que condicionan la operación o funcionamiento del sistema. Requisitos operacionales. Procedimientos operativos que describen cómo se hará uso del sistema. Requisitos de desarrollo. Lenguaje de programación a utilizar, estándares de codificación, patrones de diseño y programación, herramientas para gestionar el desarrollo de software, entorno de desarrollo de software, entorno de pruebas de software. La interfaz de usuario deberá implementarse para navegadores web únicamente con HTML5 y JavaScript. 23 Requisitos no funcionales Requisitos externos Se derivan de factores externos al sistema y a su desarrollo: Requisitos regulatorios. Características que debe cumplir el software para su aceptación por una entidad u órgano regulador. Requisitos legislativos. Características del sistema para cumplir con la legislación. Requisitos éticos. Características del sistema para adaptarse a la sociedad a la que presta servicio, usuarios y público en general. El sistema deben cumplir con las leyes y reglamentos de protección de datos médicos. 24 Proceso de requisitos Proceso de Ingeniería de Requisitos (Ian Sommerville, 2016) 25 Actividades del proceso Adquisición y análisis de requisitos: Descubrir los requisitos con los stakeholders. Especificación de requisitos: Convertir los requisitos a un formato estándar. Validación de requisitos: Comprobar que los requisitos definen realmente el sistema que desea el cliente. 26 Adquisición y análisis 1. Descubrir y comprender La adquisición y análisis El ciclo comienza con el es un proceso iterativo descubrimiento de con retroalimentación requisitos y termina 2. Clasificar y 4. Documentar continua. con su documentación. organizar La comprensión de los 3. Priorizar y requisitos mejora con negociar cada vuelta del ciclo. Modelo del proceso de adquisición y análisis (Ian Sommerville, 2016) 27 Adquisición y análisis Fuentes de requisitos Metas de la organización Conocimiento del dominio Stakeholders Entorno operacional Entorno de la organización 28 Adquisición y análisis Stakeholders Entidades afectadas por el desarrollo del sistema que deben participar en el proceso o tenerse en cuenta: usuarios finales, desarrolladores de otros sistemas relacionados, responsables de negocio, expertos de dominio, asociaciones sindicales, otros sistemas, etc. Tienen influencia directa o indirecta sobre los requisitos del sistema y ayudan a descubrir el dominio de aplicación: qué servicios debe proporcionar, el rendimiento esperado, las restricciones de hardware, etc. 29 Adquisición y análisis Tareas principales Descubrimiento de requisitos. Se trabaja con los stakeholders del sistema para descubrir cuáles son sus requisitos. Clasificación y organización de requisitos. Se agrupan requisitos relacionados siguiendo criterios coherentes. Priorización y negociación de requisitos. Se indica el orden de preferencia y se resuelven los conflictos identificados. Documentación de requisitos. Se escriben los requisitos (p.e. en tarjetas) para ayudar a descubrir nuevos requisitos en la siguiente vuelta de la espiral. 30 Adquisición y análisis Principales dificultades Los stakeholders pueden tener problemas a la hora de verbalizar qué es lo que esperan del sistema. También pueden hacer peticiones inviables porque no saben qué es factible y qué no. Los analistas pueden no entender los requisitos ya que los stakeholders los expresan en su jerga y parten del conocimiento implícito que tienen de su negocio. Hay que descubrir todas las fuentes potenciales de requisitos e identificar similitudes y conflictos. También la política y los mercados pueden influir en los requisitos del sistema. 31 Especificación de requisitos Consiste en documentar los requisitos del usuario y del sistema de forma clara, sin ambigüedades, comprensible, completos y consistentes. Los requisitos del usuario deben describir los requisitos funcionales y no funcionales, de forma que sean comprensibles para los usuarios del sistema. Deben escribirse en lenguaje natural, con tablas y formas sencillas, así como diagramas intuitivos. Los requisitos del sistema son versiones extendidas de los requisitos del usuario que los ingenieros de software usan como punto de partida para el diseño del sistema. Añaden detalles y explican cómo el sistema debe dar soporte a los requisitos del usuario. Deben ser una especificación completa y detallada de todo el sistema. 32 Validación de requisitos Consiste en comprobar que los requisitos definan realmente el sistema que quiere el cliente. Durante el proceso se realizan diferentes tipos de comprobaciones sobre los requisitos contenidos en el documento de requisitos. Los errores en el documento de requisitos pueden aumentar los costes si se descubren durante el desarrollo del sistema o después de que entre en explotación. 33 Validación de requisitos Comprobaciones a realizar Validez. Los requisitos reflejan las necesidades reales de los usuarios del sistema incluso tras posibles cambios. Consistencia. Los requisitos no se contradicen entre sí. Completitud. Los requisitos definen todas las funciones y restricciones que demanda el usuario del sistema. Viabilidad. Los requisitos se pueden implementar con la tecnología existente considerando el presupuesto y los plazos de desarrollo del sistema. Verificabilidad. Los requisitos del sistema están escritos de forma que pueden comprobarse mediante un conjunto de pruebas que demuestren que el sistema final satisface los requisitos especificados. 34 Técnicas de requisitos 35 Técnicas de requisitos Clasificación según su uso Técnicas para identificar y analizar Clasificación según el uso Técnicas para especificar Técnicas para validar 36 Entrevista Permite conocer el problema de una forma natural y comprender los objetivos de la solución buscada. Los pasos de la entrevista son: identificación de los entrevistados, preparación de la entrevista, realización de la entrevista y documentación de los resultados. Se formulan preguntas sobre el sistema actual y el que se va a desarrollar y los requisitos se derivan de las respuestas obtenidas. Se debe tener experiencia y capacidad para elegir bien a los entrevistados y obtener de Técnicas para ellos toda la información posible en un identificar y analizar período de tiempo limitado. 37 Observación Permite obtener información precisa sin que los sujetos o hechos observados se den cuenta de que están ofreciendo datos sobre comportamientos ante actos concretos. Ayuda a descubrir requisitos implícitos del sistema que reflejan la verdadera forma de trabajar en la organización. Proporciona información de primera calidad y da la oportunidad de analizar un fenómeno en el mismo momento en que se produce. Las personas pueden tener dificultad para explicar cómo trabajan y cómo se relacionan con otras funciones en la organización. Además, muchos factores que afectan al trabajo sólo pueden ser percibidos por un observador sin prejuicios. Técnicas para identificar y Esta técnica se suele combinar con la creación de analizar prototipos. 38 Cuestionario Esta técnica requiere del conocimiento previo del ámbito del problema. Consiste en redactar un documento con preguntas cuyas respuestas sean cortas y concretas, o incluso cerradas (con varias opciones). El cuestionario será cumplimentado por el grupo de personas entrevistadas o, simplemente, para recoger información independientemente de una entrevista. Técnicas para identificar y analizar 39 Documentación Se trata de documentación referida al ámbito y entorno del software. Los tipos de documentos pueden ser: relativos a la actividad del usuario, impresos que se usen (sin cumplimentar y cumplimentados para conocer los datos que se manejan), informes que se generen, información de apoyo a las tareas del usuario, documentación de los sistemas con los que haya que interactuar, etc. Técnicas para identificar y analizar 40 Brainstorming Es una técnica de reunión donde los participantes exponen sus ideas libremente (Raghavan, Zelesnik & Ford, 1994). Es sencilla de aplicar y se aconseja aplicarla en los primeros encuentros con los stakeholders. Sirve para ofrecer una visión general de las necesidades del sistema sin entrar en los detalles. El grupo debe ser de 10 personas como máximo y una de ellas debe asumir el rol de Técnicas para moderador. identificar y analizar 41 Workshop Es un taller de trabajo intensivo, focalizado y concentrado en un propósito concreto que acelera el proceso de captura de requisitos. Promueve la participación, el compromiso y la motivación de los stakeholders y facilita el consenso. Está dirigido por un facilitador y su duración es variada (mínimo 3 horas). Provee un marco para la aplicación de otras técnicas de identificación (Brainstorming, Técnicas para Storyboards, etc.) identificar y analizar 42 Mapas conceptuales Son grafos donde los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos (Pan, Zhu & Johnson, 2001). Se desarrollan con el usuario y sirven para aclarar los conceptos relacionados con el sistema a desarrollar. Son fáciles de entender por el usuario si se elaboran en su lenguaje. Técnicas para identificar y analizar 43 Glosarios y ontologías Facilitan el entendimiento entre stakeholders y desarrolladores a la hora de identificar requisitos. Permiten establecer un marco de terminología común. El glosario de términos debe recoger y definir los conceptos más relevantes y críticos para el sistema. La ontología no sólo contiene los términos, también las relaciones entre ellos. Técnicas para identificar y analizar 44 Storyboard Se trata de una serie de sketches dispuestos en formato secuencial de viñetas. Aplicado al diseño de sistemas interactivos, representa cómo se usará el sistema durante la realización de una tarea. romanpichler.com Es la noción más simple de lo que se entiende por prototipo. Técnicas para identificar y analizar 45 Escenario Proporciona información sobre las 1. It’s Tuesday morning, and Mary is working on her computer. She wants to book Roger Smith on a public necesidades funcionales del Certified Scrum Product Owner course taught by Roman. sistema. 2. Mary visits romanpichler.com and chooses a public CSPO class. Describe parcialmente el 3. She enters the participant information including first name, last name, email address, special dietary comportamiento del sistema en una requirements. 4. She then chooses a payment option and enters the situación determinada. payment details. 5. Mary accepts the terms and conditions, and confirms the Se puede hacer en forma de booking. 6. Mary sees that her booking has been successful. After a secuencia de pasos o de diagrama short while, Roger receives an email confirmation with the booking details. de flujo. Técnicas para identificar y analizar 46 Lenguaje natural Consiste en definir los requisitos en “El sistema deberá proporcionar una lenguaje natural sin usar reglas. respuesta rápida al usuario.” Es expresivo, intuitivo y universal pero también puede ser vago, ambiguo e “El sistema deberá soportar un impreciso. Su interpretación depende del máximo de 1000 usuarios dominio y experiencia del lector. concurrentes sin que el tiempo de respuesta medio aumente más de un Se aconseja usar un formato estándar que 10%.” defina cada requisito en una sola oración, diferenciar entre los obligatorios y deseables, evitar jergas técnicas y asociar una razón a cada requisito. Aunque se critica mucho su uso, es una de las técnicas más extendidas por lo que se Técnicas para especificar sigue usando para documentar los requisitos. 47 Plantilla o lenguaje estructurado Describe los requisitos mediante el lenguaje natural pero de manera estructurada para asegurar que haya cierta uniformidad en la especificación. Hace uso de plantillas y constructos de programación para mostrar alternativas e iteración, etc. Una plantilla es una tabla con una serie de campos y una estructura predefinida que el equipo de desarrollo va cumplimentando usando para ello el lenguaje del usuario. Las plantillas eliminan parte de la ambigüedad del lenguaje natural al estructurar la información. Técnicas para especificar 48 Lenguajes o notaciones gráficas Estas técnicas ayudan a especificar requisitos funcionales en forma de diagramas con la ayuda de anotaciones de texto. UML (Unified Modeling Language) es el lenguaje más utilizado en las últimas décadas para especificar requisitos funcionales. Técnicas para especificar 49 Caso de uso Sirve para definir los requisitos funcionales y es muy fácil de entender para los stakeholders. Describe la secuencia de interacción que se producen entre el sistema y los actores para realizar una determinada función. Los actores son elementos externos que interactúan con el sistema (personas, otros sistemas, etc.) como si de una caja negra se tratase. Un actor puede participar en varios casos de uso y un caso de uso puede interactuar con varios actores. Cada caso de uso debe documentarse con una descripción textual y los casos de uso se Técnicas para especificar documentan mediante un diagrama de casos de uso de alto nivel. Es parte de UML (Lenguaje Unificado de Modelado). 50 Prototipo Constituye una visión preliminar del sistema que permite simular aspectos relacionados con la interfaz de usuario o con la funcionalidad. Sirve para explorar, comunicar y evaluar ideas y también para comprobar si el usuario está conforme con los requisitos definidos. Se realiza mediante un proceso Técnicas para Técnicas para identificar y iterativo con la participación del analizar validar usuario. 51 Revisión o Walk-through Un grupo de personas que incluye a cliente y usuarios revisa el documento de requisitos. Los pasos a seguir son: identificar problemas, convocar reunión y adoptar acuerdos. Permite validar la correcta interpretación de la información transmitida, verificar la consistencia de la documentación y la completitud de la información. Es una de las técnicas más utilizadas. Técnicas para validar 52 Auditoría Consiste en chequear el documento de requisitos y se usa como guía para identificar problemas habituales. Se pueden utilizar listas de comprobación (checklists). Los checklists suelen estar predefinidos o definidos al comienzo del proceso. Hay checklists adaptados a diferentes tipos de sistemas. Técnicas para validar 53 Casos de prueba Se diseñan casos de prueba Caso de Precondición Pasos de prueba Datos de Resultado prueba prueba esperado que ayuden a detectar Verificar acceso El usuario deberá 1.Introducir nombre Username: El usuario debe problemas en los requisitos. con credenciales tener conexión de red. de usuario válido. 2.Introducir Tom Password: poder acceder sin problema Si una prueba es difícil o válidas. contraseña válida. 3.Hacer clic en el 1234.ABC botón “Login”. imposible de diseñar, los requisitos podrían ser difíciles Verificar acceso con El usuario deberá tener conexión 1.Introducir nombre de usuario válido. Username: Tom El usuario no debe poder de implementar. credenciales no válidas. de red. 2.Introducir contraseña no Password: aaaa acceder y debe mostrarse un válida. mensaje de error 3.Hacer clic en el botón “Login”. Técnicas para validar 54 Matriz de trazabilidad Permite alinear los requisitos de usuario con los objetivos del negocio. Se trata de una tabla que relaciona los requisitos con su origen y permite hacer un seguimiento desde su concepción hasta los entregables del proyecto. La matriz debe mantenerse actualizada en todo momento para hacer un seguimiento adecuado. Técnicas para validar 55 Historia de usuario Se trata de una explicación general e informal de una funcionalidad del software escrita desde la perspectiva del usuario final (no es un requisito del sistema). Su propósito es articular cómo la funcionalidad proporcionará valor al cliente. Una historia de usuario tiene la siguiente forma: “As a , I want so that ”. Técnicas para Técnicas para identificar y especificar analizar 56 Historia de usuario Modelo INVEST quién Una buena historia debe ser: qué I - Independent (independiente) N - Negotiable (negociable) V - Valuable (valiosa) E - Estimable (estimable) S - Small (pequeña) T - Testable (comprobable) (Modelo INVEST, Bil Wake 2003) para qué 57 Historia de usuario Criterios para dividir una historia Spike Mike Cohn Rules Paths SPIDR Data Interfaces https://www.mountaingoa tsoftware.com/exclusive/s pidr-poster-download 58 SPIDR Spikes: Una actividad de investigación y exploración previa para construir el conocimiento necesario para dividir una historia de usuario que sea compleja. Paths: Cuando se trate de historias grandes porque haya varios caminos posibles para que el usuario haga algo, los diferentes caminos son una buena estrategia de división. Interfaces: División de la historia en términos de la diversidad que aporta cada una de las interfaces o medios por los que el usuario puede interactuar con el sistema. Data: Es posible que la historia se pueda dividir por tipos de datos o parámetros que devuelve una función e irlos incorporando incrementalmente. Rules: Se trata de la división por las diferentes reglas (reglas de negocio, etc.) que ha de seguir una historia de usuario. 59 Historia de usuario Criterios de aceptación Front Back As a Acceptance criteria: I want (Conditions of satisfaction) So that …. Acceptance criteria: As an Account Manager The report is sent daily to my I want a sales report of my account inbox. to be sent to my inbox daily The report contains the following So that I can monitor the sales progress of my customer portfolio sales details: … The report is un csv format. AgileQuestions.com 60 Lenguaje Gherkin Gherkin es un Lenguaje Específico de Dominio (DSL) diseñado para facilitar la comunicación entre perfiles de negocio y perfiles tecnológicos. Se usa habitualmente con el enfoque BDD - Desarrollo Dirigido por Comportamiento (Behaviour Driver Development) y sirve para describir el comportamiento del software (funcionalidad). También se usa para escribir los criterios de aceptación de las historias de usuario Los elementos del lenguaje más utilizados son: Feature, Scenario, Given, When, Then y And. Una feature proporciona una descripción de alto nivel de una función del software y agrupa los scenarios relacionados. Se puede escribir como una historia de usuario. Un scenario define un ejemplo concreto que contiene una regla de negocio para alcanzar la feature. Se escriben con el patrón GIVEN-WHEN-THEN. 61 Historia de usuario Criterios de aceptación con Gherkin https://dannorth.net/ 62 Historia de usuario Ejemplo Gherkin Story: Account Holder withdraws Scenario 2: Account has insufficient funds. cash. Given the account balance is \$10 And the card is valid As an Account Holder I want to And the machine contains enough money withdraw cash from an ATM So When the Account Holder requests \$20 that I can get money when the Then the ATM should not dispense any money bank is closed. And the ATM should say there are insufficient funds And the account balance should be \$10 And the card should be returned Scenario 1: Account has sufficient funds. Given the account balance is \$100 And the card is valid Scenario 3: Card has been disabled. And the machine contains enough money Given the card is disabled When the Account Holder requests \$20 When the Account Holder requests \$20 Then the ATM should dispense \$20 Then the ATM should retain the card And the account balance should be \$80 And the ATM should say the card has And the card should be returned been retained 63

Requisitos del Software 1 Curso 2024-2025 PDF

Document Details

Tags

Related

Summary

Full Transcript