Sistemas IIClase 3Metodologas Desarrollo de SoftwareFabin Andrs GiraldoCOD:1800026Conceptos bsicos -Ingeniera de Software Laingenieradel softwareesunadisciplinaquetienecomo objetivo el desarrollo de sistemas que permiten larealizacindetareasoactividadesespecficasapartirde un conjunto de componentes lgicos. El desarrollodeSistemasdeSoftwareesunprocesocostoso y con frecuencia un proceso complejo. El director de Proyecto y el equipo de desarrollo debenhacer frente a muchas presiones de los interesados enel Proyecto durante el proceso de desarrollo desoftware. Esas presiones impactan la calidad y loscostos del software producido.2Narciso Cerpa and June M. Verner. 2009. Why did your project fail?. Commun. ACM 52, 12 (December 2009),130-134. DOI=10.1145/1610252.1610286 http://doi.acm.org/10.1145/1610252.1610286Conceptos bsicos -Ingeniera de Software Unametodologaguael procesodeconstruccindesoftware. Desde la identificacin de requerimientoshasta la implantacin de la solucin computacional. El uso de una metodologa adecuada juega un rolimportante en el proceso de desarrollo de software, paraasegurar que elProyecto se entrega dentro deltiempoprevisto, dentro de los costos y cumple con losrequerimientos de los usuarios.3Narciso Cerpa and June M. Verner. 2009. Why did your project fail?. Commun. ACM 52, 12 (December 2009),130-134. DOI=10.1145/1610252.1610286 http://doi.acm.org/10.1145/1610252.1610286Conceptos bsicos -Ingeniera de Softwarehttp://xue.medellin.unal.edu.co/~cmzapata/cursos/requisitos/requisitos.htmMetodologas de desarrollo de SoftwareMetodologas TradicionalesPrincipios RolesArtefactosFases DisciplinasCascadaIterativaEspiralRUPMetodologas de desarrollo de SoftwareMetodologas de Desarrollo gilA. Moran, Agile Risk Management, SpringerBriefs in Computer Science, 1 DOI: 10.1007/978-3-319-05008-9_1, The Author(s) 2014Barlow, Jordan B.; Giboney, Justin Scott; Keith, Mark Jeffrey; Wilson, David W.; Schuetzler, Ryan M.; Lowry, Paul Benjamin; and Vance, Anthony (2011) "Overview and Guidance on Agile Development in Large Organizations," Communications of the Association for Information Systems: Vol. 29, Article 2.Metodologas de desarrollo de Software7El modelo en Cascada fue el primermodelo de proceso en ingenierade Software. Fue adaptado para alproceso de desarrollo de softwarepor Winston Royce en 1970.Fue El modelo de proceso por unlargo tiempo. Fue tambinconocido como el modelo de ciclode vida de Software.W. W. Royce. 1987. Managing the development of large software systems: conceptsand techniques.In Proceedings ofthe 9th internationalconference on SoftwareEngineering (ICSE '87). IEEE Computer Society Press, Los Alamitos, CA, USA, 328-338.Metodologas de desarrollo de Software Enel modelooriginal deRoyce, existensietefasesdistintas: Requerimientosdel sistema, Requerimientosde Software, Anlisis, Diseo del programa, codificacin,pruebas y operacin. Cada fase tiene un resultado especificado,generalmenteundocumentoquedebeser aprobadoantes de la siguiente fase.8Metodologas de desarrollo de Software Anlisis de requerimientos y definicin: Enestafase,lafuncionalidad deseada del Sistema de informacin esespecificada. El anlisis de requerimientos se divide en dosRequerimientos del sistema.Requerimientos del Software. Los requerimientos del Sistema tienenrelacincontodoslos componentes de un Sistema de informacin (i.e.hardware, canales de comunicacin, personas, etc.). Losrequerimientos desoftwaresonlas funcionalidadesdeseadas en la herramienta computacional.9Metodologas de desarrollo de Software Diseo Preliminar: Los componentes principales del Sistemadeinformacinsonidentificados. Si existeunaarquitecturageneraldelSistema, entonces esos componentes se ponenen la nueva arquitectura. Diseo Detallado: Los componente principales sonespecificados en detalle y refinados en pequeoscomponentes de acuerdo al paradigma de diseo(Programacin Estructurada, Programacin Orientada aobjetos, etc.)oaproximacinparticularqueseesteusandoen el Proyecto. Las interacciones entre los componentesdeben ser especificados. La lgica delprograma, elflujo detrabajo y la estructura de la base de datos son establecidos.10Metodologas de desarrollo de Software Mdulo de implementacin y pruebas: Loscomponentes especificados en el diseo sonimplementados como programas o mdulos deprogramas. Cadamduloes examinadoatravs depruebasparavalidarquetrabajaapropiadamente. Loserrores detectados durante las pruebas deben sercorregidos. Integracin y prueba del sistema:Loscomponentesindividuales del Sistema son integrados y probadosjuntos para asegurar que el Sistema trabaja de acuerdoa la especificacin de requerimientos.11Metodologas de desarrollo de Software Documentacin: Una tarea importante es ladocumentacin del Sistema de informacin.Ejemplo: Documento de usuario final (Como usar el sistema). Documento de administrador del Sistema (Comoejecutar el sistema), Documentacin de mantenimiento (Como hacercambios en el sistema), Documentacin API (Como usar las interfaces deprogramacin, si estas son provistas).12Metodologas de desarrollo de Software Operacin y mantenimiento: Luego que el Sistema esprobado y documentado, El software es entregado a losusuario internos o externos. El Sistema es instalado enel ambientedeproduccin(Eje. Computadorsobreesque va ser instalado) y es puesto en operacin.13Metodologas de desarrollo de SoftwareFALENCIAS DE METODOLOGA CASCADA El estricto orden secuencial no es lo que sucede en losproyectos reales. No es realista que una fase pueda serdefinidacomplementedeentradayconlosresultadosesperados antes de la siguiente fase. Algunasveces, losrequerimientosespecificados sondifciles o imposibles de transformar en un diseousando un esfuerzo razonable, hacer una revisin de losrequerimientos se hace necesario.14Metodologas de desarrollo de Software Durantelaimplementacinalgunascaractersticasdediseo son complejas de implementar y todo ajustar eldiseo. Igualmente, errores de diseo son detectados enla fase de implementacin, requiriendo repeticin dealgunas fases realizadas anteriormente.15Metodologas de desarrollo de Software16Ciclo de Vida con iteracionesMetodologas de desarrollo de Software Frecuentemente, el siguiente grfico es mostrado en la literatura de ingeniera de software. Dicho grfico ilustra el dilema del modelo en Cascada.17Metodologas de desarrollo de SoftwareRoles: Los roles que especifica el modelo cascada son: Analista del negocio Arquitecto Desarrolladores Testers Clientes1819PRINCIPIOS DE UML20 Lenguaje Unificado de Modelado (UML) es un lenguajede modelamiento visual de propsito generalPuede soportar todos los ciclos de vida de software existentes. El lenguaje Unificado de Modelado (UML) es unlenguaje estndar de propsito general para especificar,visualizar, construir y documentar los artefactos desistemas de software. Incorpora las mejores prcticas de ingeniera deSoftware. UML no es una Metodologa!UML es un lenguaje visual.CASCADA, RUP son metodologas.UML21 Los diagramas de estructura modelan la estructura del Sistema (Modelo esttico del sistema). Los diagramas de comportamiento modelan el comportamiento dinmico del sistema (Modelo dinmico).UML tiene 13 tipos de diagramasUML22REQUERIMIENTOS La propuesta delflujo de requerimientos es crearunaespecificacindealtonivel quepuedaserimplementada. Se debe entrevistar a los Interesados para buscarque necesita el Sistema hacer para ellos. Susrequerimientos.REQUERIMIENTOSREQUERIMIENTOSREQUERIMIENTOS23REQUERIMIENTOS24REQUERIMIENTOS25REQUERIMIENTOS26REQUERIMIENTOSLA IMPORTANCIA DE LOS REQUERIMIENTOS27IncompleterequirementsLack of userinvolvementLack of resourcesUnrealisticexpectationsLack of executivesupportChangingrequirementsLack of planningDidn't need it anylongerLos requerimientos incompletos son la raznPrincipal para que los proyectos fallen.The Standish Group, "The CHAOS Report (1994) "REQUERIMIENTOS28The Standish Group, "The CHAOS Report (2014) "29REQUERIMIENTOSQU SON LOS REQUERIMIENTOS? Requerimientos- Una especificacin que podra ser implementada: Los requerimientos son declaraciones que identifican atributos,caractersticas, capacidades, cualidades que necesita cumplir unsistema de informacin (o un software) para que tenga valor yutilidad para el usuario. Que comportamientos debera el Sistema ofrecer. Una propiedad especfica del Sistema. Una restriccin sobre el Sistema. La especificacin de Requerimientos de software consiste de: El modelo de requerimientos que comprende los requerimientos funcionales y no funcionales. El modelo de casosde usoque comprende los actores y casos de uso.30REQUERIMIENTOS En UML no hay un camino estndar para escribir requerimientos! Se recomienda estructuras de oraciones uniformes. Requerimientos Funcionales Que debe hacer el Sistema. El Sistema ATM deber proveer mecanismos para la autenticacin de un usuario del sistema" Requerimientos no Funcionales una restriccin sobre como los requerimientos funcionales son implementados. El Sistema ATM deber autenticar un usuario del Sistema en 4 segundos o menos" El deber e.g. "32 The ATM system shall validate the PIN number."Identificador nico Nombre del Sistema Funcin a ser ejecutadaEscribiendo Requerimientos.REQUERIMIENTOS31Plantilla para la especificacin de RequerimientosREQUERIMIENTOS Nmero del requerimiento: Un identificador nico para el requerimiento. Tipo de Requerimiento: Requerimiento Funcional: Son los temas esencialesofundamentalesdel producto. Describenloqueelproducto debe hacer o las acciones deprocesamiento que se deben realizar. Requerimiento No Funcional: Son las propiedadesque las funciones deben tener, tales con rendimiento,usabilidad. Son tan importantes como losrequerimientos funcionales para el xito del producto32REQUERIMIENTOSTipo de Requerimiento: Restricciones del Proyecto: Restricciones en elproducto debido al presupuesto o el tiempodisponible para construir el producto. Restricciones de diseo: imponer restriccionessobrecmoel productodebeser diseado. Porejemplo, podratener queser implementadoeneldispositivo mvil , o podra tener que utilizar losservidores existentes y computadoras de escritorio , ocualquier otro tipo de hardware , software o prcticaempresarial.33REQUERIMIENTOS Problemas del Proyecto: definir las condiciones en quese har el proyecto. Nuestra razn de su inclusin comoparte de los requisitos es presentar una imagencoherente de todos los factores que contribuyen al xitoo fracaso del proyecto y para ilustrar cmo los gerentespueden utilizar requisitos de entrada en la gestin de unproyecto.34REQUERIMIENTOS Eventos/Caso de Uso #: Nmero evento de Negocio: Referencia a un evento importante en el negocio. Caso de uso del Negocio: Referencia al caso de uso del negocio que contiene el requerimiento.Caso de uso del producto: Referencia al caso de uso del producto a los cuales el requerimiento ha sido asignado. Descripcin: Una oracin que describe el requerimientodesdelaperspectivadealguienquetienequever conelnegocio (Ejemplo: El deber ). Razn Principal: Justificacin de porqu el requerimiento esimportante. Lo anterior, podra permitir identificar el beneficiode tener una solucin a este requerimiento.35REQUERIMIENTOS Autor: Persona que ha solicitado el requerimiento. Criterio de Aceptacin: Una medicin de la exigencia de talmanera que es posible probar no subjetivamente si lasolucin se ajusta el requisito original. Satisfaccin del cliente: En una escala de 1 a 5. cunto beneficio se obtiene si la solucin se ajusta al requisito? Insatisfaccin del Cliente: En una escala de 1 a 5 la cantidad de dao habr si no podemos ofrecer una solucin que se ajuste a este requisito? La satisfaccin e insatisfaccin del cliente son herramientas queayudan a las personas a pensar acerca del valor delrequerimiento y mantenerlos al tanto de que la definicin de unrequisito no garantiza necesariamente una solucin.36REQUERIMIENTOSPrioridad: Prioridad asignada al requerimiento. Se cuantificamediante la escala que mejor se adapte a suorganizacin. Por ejemplo, podra usar: Alto, Medio,Bajo. Cuando las expectativas delcliente son altas, la fechade entregay los recursosson limitados, esimportanteasegurarsedequelasfuncionesmsimportantesdelproducto sean entregadas tan pronto como sea posible37REQUERIMIENTOSBases de Datos: Rubn Francisco Manrique38REQUERIMIENTOS Conflictos: Otros requisitos que no se puedenimplementar si este requisito no se implementa como seespecifica. El propsitodeestoesparaanimar alagenteparaidentificar lasdecisionesyeleccionesquedeben hacerse antes de su implementacin. Materiales de Soporte: Referencia a documentos,ejemplos o personas que ilustran y pueden explicar msa cerca de los detalles del requerimiento39REQUERIMIENTOS Historia: Losatributosqueustedelijaparahacer unseguimiento al ciclo de vida de este requisito dentro desu organizacin. Por ejemplo, usted puede tener puntosde control de requisitos como: Fases del proyecto, Controles de revisin, nombre del responsable de aprobacin, fecha de aprobacin, fecha de aplicacin y as sucesivamente.El nmero de atributos histricos son los que laorganizacin decida.40REQUERIMIENTOS41REQUERIMIENTOSPLANTILLA ESPECIFICACIN DE REQUERIMIENTOS42http://www.volere.co.uk/Plantillas para la especificacinDe requerimientos.REQUERIMIENTOSRequerimientos de TestingSe deben identificar los requerimientos de testing para cada unode los requerimientos funcionales definidos en la seccinanterior. Puede haber ms de un test para validar unrequerimientofuncional. Losrequerimientosdetestingdebenser definidos aaltonivel perodebenvalidar claramentelosrequerimientos del software. Al igual quelos requerimientosfuncionales, los requerimientos de testing deben tener unidentificador nico.ST1 [Requerimiento de testing 1]ST2 [Requerimiento de testing 2]ST3 [Requerimiento de testing 3]ST4 [Requerimiento de testing 4]43REQUERIMIENTOS44REQUERIMIENTOS ATM Example: Practice Writing Test Requirements45REQUERIMIENTOSTest Requirements Identified (among others):46These are test requirements NOT tests because they do not describe the data element being used (like $20, $40, $60, $1) The data is irrelevant at this level, it will appear in the test cases used to cover these test requirementsREQUERIMIENTOS Test Scenarios/Cases for -Validate that a withdrawal of a multiple of $20, between $20-$300 can be done47Case # P/F $ entered ExpectedResultsActualResultsWD01 Pass 20 $20 withdrawnWD02 Pass 40 $40 withdrawnWD03 Pass 60 $60 withdrawnWD04 Pass 80 $80 withdrawnWD05 Pass 100 $100 withdrawn: : : :WD13 Pass 260 $260 withdrawnWD14 Pass 280 $280 withdrawnWD15 Pass 300 $300 withdrawnREQUERIMIENTOS Test Procedure & Script for previous example48REQUERIMIENTOSMatriz Requerimientos Funcionales vs. Requerimientos de TestingEn esta seccin se debe especificar la matriz que mapealosrequerimientosfuncionalesconlosrequerimientosdetesting.4950Requerimientos Modelamiento de Casos de UsoRequerimientos Parte 251CASOS DE USO Modelamiento de casos de uso es una forma deingeniera de requerimientos. El modelamiento de casos de uso procede de lasiguiente forma: Buscar los lmites del sistema Buscar los actores. Buscar los casos de uso Especificacin de los casos de uso Escenarios. Lo anterior, nos permite identificar los lmites delsistema, quienes o cuales son los usuarios delsistemas, y cuales funciones el Sistema debe ofrecer.52CASOS DE USO Antes de poder construir algo, nosotrosdebemos conocer:Cul es la frontera (alcance) del Sistema.Quin o que usa el Sistema.Que funciones debe proveer el Sistema a losusuarios. El modelo de casos de uso contiene:Lmite del sistemaActores Quin o que usa el sistemaCasodeusoLoquelos actoreshacenconelsistemaRelaciones- Relaciones entre los actores y loscasos de uso.NombreSistemaLmites del Sistema53CASOS DE USOQu son los actores? Un actor el cualquier cosa (Humano, Mquina) que interactencon el Sistema. Los actores permiten identificar que o quienes usan elSistema Los actores son externos al Sistema. Unactor especificaunrol queunaentidadexternaadoptacuando interacta con el Sistema.CustomeractorCustomer54CASOS DE USO Como identificar los actores: Quin o qu usa el sistema? Que roles juegan ellos en la interaccin? Quin instala el sistema? Quin inicia o apaga el sistema? Quin mantiene el sistema? Que otros sistemas usan el sistema? Quienes obtienen o proveen informacin alsistema?55CASOS DE USOQu son los casos de uso? Un caso de uso es una funcionalidad que necesita elactor que elSistema realice. Un caso de uso describe un proceso de negocio. Un caso de uso siempre es iniciado por un actor. El actor lanza el caso de uso. Ceroomsactoressecundariointeractanconel casodeusodealgnforma. Un caso de uso siempre es escrito desde el punto de vista del actor.PlaceOrder GetStatusOnOrder56CASOS DE USOIdentificando casos de uso Empezar con una lista de los actores que interactancon el Sistema. Para identificar un caso de uso, pregntese: Que funciones un actor especfico quiere del sistema? El Sistemaalmacenaorecuperainformacin?Si esas,Cuales actores inician/lanzan este comportamiento? Sonlosactoresnotificadoscuandoel Sistemacambiadeestado? Hay cualquier evento externo que afecte al sistema? Quinnotifica al Sistema de dichos eventos?57CASOS DE USOMail Order SystemPlace OrderSendCatalogueCancel OrderCheck OrderStatusCustomerShipProductShippingCompanyDispatcherRelaciones de ComunicacinActorNombredel sistemaLmitesMail Order System use case diagram Caso de UsoDiagrama de Casos de Uso58CASOS DE USOUse case: PaySalesTaxPrimary actors:TimePreconditions:1. It is the end of the business quarter.Postconditions:1. The Tax Authority receives the correct amount of Sales Tax.Main flow:The use case starts when it is the end of the business quarter.The system determines the amount of Sales Tax owed to the Tax Authority.The system sends an electronic payment to the Tax Authority.1.2.3.Nombre del Caso de UsoActores involucrados en el caso de usoEstado del Sistema antes de iniciar el caso de usoSecuencia de pasos del caso de usoEstado del Sistema cuando el caso de usofinalizaAlternative flows:None.Flujos alternativosID: 1 Identificador del Caso de UsoBrief description:Pay Sales Tax to the Tax Authority at the end of the business quarter.Descripcinimplicit time actor Secondary actors:TaxAuthorityEspecificacin de Casos de Uso59CASOS DE USO Precondiciones y poscondicionesson restricciones. Precondiciones restringen elcaso de uso antes de iniciar Las poscondiciones restringen elSistema luego que el caso deuso es ejecutado. Si noexistenprecondiciones oposcondiciones escriba "None"Place OrderPreconditions:1. A valid user has logged on to the systemPostconditions:1. The order has been marked confirmed and is saved by the system60CASOS DE USO El flujo de eventos lista los pasos del caso de uso Siempre inicia con un actor haciendo alguna accin Un buen camino para iniciar un flujo de eventos es:1) El caso de uso inicia cuando un El flujo de eventos debe ser una secuencia de pasos que son: Declarativos Numerados, Ordenados en el tiempo El flujo principal siempre es el escenario del da feliz o el mundoperfecto. Todo va como se esperaba y deseaba, y no hay errores,desviaciones, interrupciones, o ramas Alternativas pueden ser mostrados por ramificacin o por su inclusinen los flujos alternativos. The Flujo Principal61CASOS DE USOLa ramificacin dentro de un flujo: ifEl uso de la palabra if indica alternativas en el flujo de eventos Debe ir una expresin Boolean despus del if Use indentacin y numeracin para indicar la parte condicional del flujo Use else para indicar que sucede si la condicin es falsa.Use case: ManageBasketPrimary actors:CustomerPreconditions:1. The shopping basket contents are visible.Postconditions:None.Main flow:The use case starts when the Customer selects an item in the basket.If the Customer selects "delete item" If the Customer types in a new quantity1.2.3.The system removes the item from the basket.2.1The system updates the quantity of the item in the basket.3.1ID: 2Brief description:The Customer changes the quantity of an item in the basket.Alternative flows:None.Secondary actors:None.62CASOS DE USORepeticiones en un flujo: For Podemos usar lapalabraclaveForparaindicarlarepeticindeun flujo de eventos. La expresin deiteracin luego delestamento For indica elnmero de repeticionesde los estamentos queestn dentro del For.ID: 3Actors:CustomerPreconditions:None.Main flow:1. The use case starts when the Customer selects "find product".2. The system asks the Customer for search criteria.3. The Customer enters the requested criteria.4. The system searches for products that match the Customer's criteria.5. If the system finds some matching products then5.1 For each product found5.1.1. The system displays a thumbnail sketch of the product.5.1.2. The system displays a summary of the product details.5.1.3. The system displays the product price.6. Else6.1. The system tells the Customer that no matching products could be found.Postconditions:None.Alternative flows:None.Use case: FindProductBrief description:The system finds some products based on Customer search criteria and displays them to the Customer.63CASOS DE USORepeticiones en un flujo:While Se puede usar lapalabra clave whilepara indicar algo quese repite mientras lacondicin Boolean esverdadera.Main flow:Use case: CreateNewCustomerAccountPreconditions:None.Brief description:The system creates a new account for the Customer.Postconditions:1. A new account has been created for the Customer.Alternative flows:NoneThe use case begins when the Customer selects "create new customer account".While the Customer details are invalidThe system creates a new account for the Customer.The system asks the Customer to enter his or her details comprising email address, password and password again for confirmation.The system validates the Customer details.1.2.3.2.1.2.2ID: 5Primary actors:CustomerSecondary actors:None.64CASOS DE USODerivaciones: Flujos alternativos Pueden ser especificados uno o ms flujos alternativos: Flujos alternativos capturan errores, derivaciones, y interrupciones. Un flujo alternativo nunca retorna al flujo principal. Potencialmente existen muchos flujos alternativos!: Escoger los ms importantes y documentarlos.main flowalternative flowsUse caseOnly document enough alternative flows to clarify the requirements!65CASOS DE USOReferenciando los flujos alternativos. Liste los nombres de los flujos alternativos. Los flujos alternativos se buscan examinando cada paso en el flujo principal y analizando:AlternativasExcepcionesInterrupciones.alternative flows Main flow:Use case: CreateNewCustomerAccountPreconditions:None.Brief description:The system creates a new account for the Customer.Postconditions:1. A new account has been created for the Customer.Alternative flows:InvalidEmailAddressInvalidPasswordCancelThe use case begins when the Customer selects "create new customer account".While the Customer details are invalidThe system creates a new account for the Customer.The system asks the Customer to enter his or her details comprising email address, password and password again for confirmation.The system validates the Customer details.1.2.3.2.1.2.2ID: 5Primary actors:CustomerSecondary actors:None.66CASOS DE USO The alternative flow may be triggered instead of the main flow - started by an actor The alternative flow may be triggered after a particular step in the main flow - after The alternative flow may be triggered at any time during the main flow - at any timenotice how we name and numberalternative flows always indicate how the alternative flow begins. In this case it starts after step 2.2 in the main flowAlternative flow:Alternative flow: CreateNewCustomerAccount:InvalidEmailAddressPreconditions: 1. The Customer has entered an invalid email addressPrimary actors:CustomerPostconditions:None.The alternative flow begins after step 2.2. of the main flow.The system informs the Customer that he or she entered an invalid email address.1.2. ID: 5.1Brief description:The system informs the Customer that they have entered an invalid email address.Secondary actors:None.67CASOS DE USOTrazabilidad de los Requerimientos. Dado que se capturaron los requerimientos en el modelo derequerimientos y en los casos de uso se deben relacionar. Hay una relacin muchos a muchos entre requerimientos ycasos de uso. Un caso de uso cubre muchos requerimientos funcionales. Un requerimientos funcionales puede ser realizado por muchoscasos de uso. Debemos crear una Matriz de Trazabilidad derequerimientosR1R2R3R4R5U1 U2 U3 U4Use casesRequirementsMatriz deTrazabilidad deRequerimientos.EXERCISEConsider the outline for the following scenario:Thedevelopment of acomputersystemisrequiredbyacommunity bank. The community bank is a new venture tointroduce banking services to a local community that do notnormally use the facilities of the national banks. A system isrequired whereby customers may open accounts andperformtheusual transactionsontheseaccounts(creditthe account, debit the account, Certificate of Depositaccount and obtain the current balance). The bank is alsorequiredtoprovidetogovernment thevaluefor itstotalassets.68Remember the exercisedeveloped in the classEXERCISEACTIVITIES1. Identify and write the requirements.2. Develop the specification of requirements.3. Identify the testing requirements for each functionalrequirement.4. You have identify the use cases and you have fill the usecase specifications.5. Fill the traceability matrix.6. Design.1. Flowchart diagram (Functions)7. Code in Java programming language8. Test Scenarios/Cases69