Soluciones de Gestión de Requisitos. Telelogic AB

Transcripción

1 Soluciones de Gestión de Requisitos

2 Presentación Ismael Cuendias Rubio Telelogic Ibérica, Madrid Account Manager

3 Telelogic Creada 1983 Sede principal Malmö, Suecia Empresa Pública Ingresos 2004 Cotiza en la bolsa de Estocolmo desde 1999 US$ 142 millones Crecimiento DOORS % Clientes + 200,000 Usuarios DOORS DOORS R&D & Support are certified ISO9001

4 Comunicaciones Ayudando a nuestros clientes a resolver sus desafíos más complejos Militar Aeroespacial Transportes Automóviles Finanzas Seguros Comercio

5 Ciclo de Vida de Desarrollo Integrado y Automatizado Visibilidad total a lo largo de todo el ciclo de vida Control y Predictibilidad Comunicación y Colaboración Reutilizar la experiencia como generador de éxito

6 Productos Telelogic Telelogic DOORS Requirements Management Solutions Telelogic Focal Point Value Engineering Decision Support Portfolio Management Telelogic SYNERGY Change & Configuration Management Solutions Telelogic Dashboard Project Visibility and Control Telelogic TAU Design, Implementation & Test Solutions Telelogic System Architect Enterprise Architecture Telelogic Logiscope Software Quality Assurance Telelogic DocExpress Automated Documentation Generation

7 - Bueno, qué es todo esto de la Gestión de Requisitos? - Qué tiene que ver conmigo? Mr. Who cares?

8 Qué es Gestión de Requisitos? The purpose of requirements management is to establish a common understanding between the customer and the project... This agreement with the customer is the basis for planning and managing the project. The Capability Maturity Model for Software (CMM ) from the Software Engineering Institute at Carnegie Mellon University. -

9 Por qué es tan importante?

10 Requisitos durante el ciclo de vida Captura de Requisitos & Engineering Analisis & Diseño Modelado Simulación Coding Pruebas Gestión de Requisitos & Trazabilidad Documentación Gestión de Proyectos Gestión de Configuración Metricas

11 Mejor Mas rápido CALIDAD Mas barato Este es el objetivo y el Desarrollo Dirigido por Requisitos le ayudará a conseguirlo.

12 -Empiezo a pensar que esto realmente merece la pena.

13 Soluciones Telelogic para RM DOORS - la solución ideal para Gestión de Requisitos con la complejidad de los proyectos actuales DOORS/Analyst - extensión de las capacidades de DOORS con representación gráfica formal de los requisitos via UML DOORS XT - extensión de los beneficios de la Gestión de Requisitos para proyectos distribuidos geograficamente DOORSnet - interfaz web para revisiones de información desde cualquier localización

14 Telelogic es el líder The requirements management segment of the application development software market saw phenomenal growth of 38.7 percent in Telelogic, with a 41 percent market share, leads this market. Gartner Dataquest,2004

15 Es fácil empezar a usar DOORS?

16 Organización de la Información en DOORS Jerarquía ilimitada de Proyectos/Carpetas facilitando escalabilidad Unique! Carpetas Carpeta Borrada Proyectos Documentos DOORS Organice Sus Proyectos

17 Documento DOORS Unique! Toda la información deseada en una vista Mejora productividad, reduce errores, incrementa calidad

18 Cómo introducimos la información?

19 Escribir Requisitos en DOORS Utilizamos plantillas Escribimos nuestros requisitos

20 Importar información & Crear Documentos MS-Word MS-Word RTF OLE Direct Entry Microsoft HTML Word PowerPoint Excel Outlook ASCII Spreadsheet MS-Project Tool Integrations* FrameMaker DOORS RTF MS-Word ASCII Spreadsheet MS-Project Tool Integrations* FrameMaker Print * See later Integrations slide

21 Importar desde Microsoft Word

22 Informes formales

23 Cómo gestiono la trazabilidad?

24 Trazabilidad: drag-and-drop linking Drag-anddrop para unir dentro de un documento..... O de un documento a otro

25 Un Ejemplo Unique! Reqts. Usuario Reqts. Tecnicos Diseño Casos de Test (b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed as design and development evolves. The plans shall be updated as design and development evolves. The plans shall be approved as design and development evolves (c) Design Input 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient The procedures shall include a mechanism for addressing incomplete requirements The procedures shall include a mechanism for addressing ambiguous requirements The procedures shall include a mechanism for addressing conflicting requirements The design input requirements shall be documented by a designated individual(s) The design input requirements shall be reviewed by a designated individual(s) The design input requirements shall be approved by a designated individual(s) The approval, including the date and signature of the individual(s) approving the requirements, shall be documented Questions Summarize the manufacturer's written procedure(s) for identification and control of design input From what sources are design inputs sought? Do design input procedures cover the relevant aspects, such as: (Mark all that apply and list additional aspects.) intended use user/patient/clinical performance characteristics safety limits and tolerances risk analysis toxicity and biocompatibility electromagnetic compatibility (EMC) compatibility with accessories/auxiliary devices compatibility with the environment of intended use human factors physical/chemical characteristics labeling/packaging reliability statutory and regulatory requirements voluntary standards manufacturing processes sterility MDRs/complaints/failures and other historical data design history files (DHFs) For the specific design covered, how were the design input requirements identified? For the specific design covered, how were the design input requirements reviewed for adequacy? (b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design 1.1. Identify and development impacted elements due to a change in another element 1. Capture design and related information activities and define responsibility for implementation. Traceability Reports: consistency 1. Capture with design driving and related design information elements 1.1. Input electronically formatted data 1.1. Input electronically formatted data The plans shall identify and describe the interfaces with different groups or activities that provide, Impact or result Reports: other design elements affected 1.2. Reference external information sources 1.2. Reference external information sources 1.3. Reference external documentation in, input to the design and development process. Links to impacted design elements 1.3. Reference external documentation Create backward traces to design elements within and across any organizational 2. Store design and related information The plans shall be reviewed as design and development evolves. procedure 2. Store design and related information 2.1. Identify and tag design information The plans shall as unique be updated design as design elements and development evolves. The plans shall be approved as design and development evolves. Traceability Reports: Procedure 2.1. Identify Attribute and tag design information as unique design elements 2.2. Organize design elements 2.2. Organize design elements Create backward traces to design elements within and across any project milestone Organize by Design Control Guidance Element Organize by Design Control Guidance Element Organize by inter-relationships (c) Design Input Traceability Reports: Milestone Organize Attribute by inter-relationships 2.3. Ensure all design elements are 2.1. available Each manufacturer shall establish procedures to ensure that the design requirements relating Create to backward a traces to design 2.3. Ensure elements all design within elements and are across available Design Control Store design elements by Design device Control are appropriate Guidance and Element address the intended use of the device, including the needs of the user Guidance Elements Store design elements by Design Control Guidance Element Store design elements and their and historical patient. values Store design elements and their historical values 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating Traceability to a Reports: Linked design elements 3. Manage all user needs device are appropriate and address the intended use of the device, including the needs Create of the user forward impacts 3. to design Manage elements all user needs within and across any organizational 3.1. Identify the source of the user needand patient. procedure 3.1. Identify the source of the user need 3.2. Identify all user types (groups) 2.3. The procedures shall include a mechanism for addressing incomplete requirements. Impact Reports: Procedure 3.2. Identify Attribute all user types (groups) 3.3. Identify the customer (s) 2.4. The procedures shall include a mechanism for addressing ambiguous requirements Identify the customer (s) 2.5. The procedures shall include a mechanism for addressing conflicting requirements Create forward impacts to design elements within and across any project milestone 3.4. Profile the expected patients 3.4. Profile the expected patients 3.5. State the intended use of the 2.6. product The (family) design input requirements shall be documented by a designated individual(s). Impact Reports: Milestone 3.5. State Attribute the intended use of the product (family) 3.6. Capture the acceptance criteria 2.7. for The each design user need input requirements shall be reviewed by a designated individual(s) Create forward impacts to design 3.6. Capture elements the acceptance within and criteria across for each Design user need Control 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 4. Manage design input requirements2.9. The approval, including the date and signature of the individual(s) approving the requirements, 4. Manage design input requirements shall be documented. Impact Reports: Linked design elements 4.1. Identify the source of the requirement 4.1. Identify the source of the requirement Questions Associate changed design elements with related elements 4.2. Identify the associated user need 4.2. Identify the associated user need 4.3. Capture requirement description and attributes Summarize the manufacturer's written procedure(s) for identification and control Link of Change Design Object 4.3. with Capture affected requirement design element(s) description and attributes 4.4. Capture acceptance criteria design input. Traceability Links and Reports 4.4. from Capture affected acceptance design criteria element(s) 4.5. Assign responsibility for each requirement From what sources are design inputs sought? 4.5. Assign responsibility for each requirement Do design input procedures cover the relevant aspects, such as: (Mark all that Impact apply and Links and Reports from affected design element(s) 4.6. Manage incomplete requirements 4.6. Manage incomplete requirements list additional aspects.) Associate design element changes with decisions, rationale, and approval authority 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements 4.8. Manage conflicting requirements intended use information 4.8. Manage conflicting requirements 4.9. Approve all requirements user/patient/clinical Change Decision Objects 4.9. with Approve following all requirements Attributes: performance characteristics safety Disposition Attribute 5. Manage acceptance 5. Manage acceptance 5.1. Ensure the acceptance of every user need limits and tolerances Decision Attribute 5.1. Ensure the acceptance of every user need 5.2. Ensure the acceptance of every design input requirement risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.3. Document the results of every user need acceptance toxicity test and biocompatibility Owner Attribute 5.3. Document the results of every user need acceptance test 5.4. Document the results of every design input requirements electromagnetic test compatibility (EMC) 5.4. Document the results of every design input requirements test 5.5. Make acceptance results available compatibility with accessories/auxiliary devices Management Approval Attribute 5.5. Make acceptance results available compatibility with the environment of intended use Provide associations within and across any organizational procedure 6. Manage change human factors Change Design Object 6. Traceability Manage change Link on Procedure Attribute 6.1. Maintain history of design element changes physical/chemical characteristics Change Design Object Impacts 6.1. Maintain Link history on Procedure of design Attribute element changes Make complete change history available labeling/packaging Make complete change history available Maintain history within and across any organizational reliability Provide associations within and across any project milestone procedure Maintain history within and across any organizational procedure Maintain history within and across any project statutory milestone and regulatory requirements Change Design Object Traceability Link on Milestone Attribute Maintain history within and across any project milestone Maintain history within and across any Design voluntary Control standards Guidance Elements Change Design Object Impacts Link Maintain on Milestone history within Attribute and across any Design Control Guidance Elements 6.2. Capture frequency and nature of element changes manufacturing processes Provide associations within 6.2. and Capture across frequency Design and Control nature Guidance of element changes Elements Provide rationale for change sterility Provide rationale for change Describe decisions made MDRs/complaints/failures and other historical data Change Design Object Traceability Link to traced design elements Describe decisions made Identify approval authority for the change design history files (DHFs) Change Design Object Impacts Link Identify to linked approval design authority elements for the change Capture date, time, and signature of approving For the specific authority design covered, how were the design input requirements 1.3. Mange identified? the change process Capture date, time, and signature of approving authority 6.3. Identify impacted elements due to a change For in the another specific element design covered, how were the design input requirements reviewed for Design Change Module 6.3. Identify impacted elements due to a change in another element Create backward traces to design elements adequacy? within and across any organizational procedure Design Change Reports Create backward traces to design elements within and across any organizational procedure Create backward traces to design elements within and across any project milestone Create backward traces to design elements within and across any project milestone Object History Object History Reports Versions Baselines 1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements Create backward traces to design elements within and across any organizational procedure Traceability Reports: Procedure Attribute Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute Create backward traces to design elements within and across Design Control Guidance Elements Traceability Reports: Linked design elements Create forward impacts to design elements within and across any organizational procedure Impact Reports: Procedure Attribute Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute Create forward impacts to design elements within and across Design Control Guidance Elements Impact Reports: Linked design elements 1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s) Associate design element changes with decisions, rationale, and approval authority information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements 1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines Es dificil predecir el impacto de un cambio antes de que el trabajo se haya terminado

26 Trazabilidad a Baselines User Requirements System Requirements Test User Requirements Baseline 1 System Requirements Baseline 1 Tests Baseline 1 Trazabilidad creada entre documentos actuales pero para algunos es necesario hacer baselines antes que otros. Entonces podemos hacer enlaces a la baseline para conformidad con esa fase Cuando hagamos la ultima baseline el historico de trazabilidad se completa

27 Simplificando Complejidad Incremento (b) Design and Developm ent Planning Each m anufacturer shall establish and m aintain plans that describe or reference the design and developm ent activities and define responsibility for im plem entation. The plans shall identify and describe the interfaces w ith different groups or activities that provide, or result in, input to the design and developm ent process. The plans shall be review ed as design and developm ent evolves. The plans shall be updated as design and developm ent evolves. The plans shall be approved as design and developm ent evolves (c) Design Input 2.1. Each m anufacturer shall establish procedures to ensure that the design requirem ents relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient Each m anufacturer shall m aintain procedures to ensure that the design requirem ents relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient The procedures shall include a m echanism for addressing incom plete requirem ents The procedures shall include a m echanism for addressing am biguous requirem ents The procedures shall include a m echanism for addressing conflicting requirem ents The design input requirem ents shall be docum ented by a designated individual(s) The design input requirem ents shall be reviewed by a designated individual(s) The design input requirem ents shall be approved by a designated individual(s) The approval, including the date and signature of the individual(s) approving the requirem ents, shall be docum ented Q uestions Sum m arize the m anufacturer's w ritten procedure(s) for identification and control of design input From what sources are design inputs sought? D o design input procedures cover the relevant aspects, such as: (M ark all that apply and list additional aspects.) intended use user/patient/clinical perform ance characteristics safety lim its an d to leran ces risk analysis toxicity and biocom patibility electrom agnetic com patibility (EM C ) com patibility w ith accessories/auxiliary devices co m p atib ility w ith th e en v iro n m en t o f in ten d ed u se hum an factors physical/chem ical characteristics lab elin g /p ack ag in g reliab ility statutory and regulatory requirem ents voluntary standards m anufacturing processes sterility M DRs/com plaints/failures and other historical data design history files (D HFs) For the specific design covered, how were the design input requirem ents identified? For the specific design covered, how were the design input requirem ents review ed for adeq uacy? C o m ply w ith F D A D esig n C o n trol G uidan ce G M P R eg ulatio n 1. Capture design and related inform ation 1.1. Input electronically form atted data 1.2. Reference external inform ation sources 1.3. Reference external docum entation 2. S to re d esign and related inform ation 2.1. Identify and tag design inform ation as unique design elem ents 2.2. O rganize design elem ents O rganize by D esign Control G uidance Elem ent O rgan ize b y inter-relationships 2.3. Ensure all design elem ents are available Store design elem ents by D esign Control G uidance Elem ent Store design elem ents and their historical values 3. M anage all user needs 3.1. Identify the source of the user need 3.2. Id entify all user typ es (group s) 3.3. Identify the custom er (s) 3.4. Profile the expected patients 3.5. State the intended use of the product (fam ily) 3.6. Capture the acceptance criteria for each user need 4. M anage design input requirem ents 4.1. Identify the source of the requirem ent 4.2. Identify the associated user need 4.3. Capture requirem ent description and attributes 4.4. Capture acceptance criteria 4.5. A ssign respo nsib ility for each requirem ent 4.6. M anage incom plete requirem ents 4.7. M anage am biguous requirem ents 4.8. M anage conflicting requirem ents 4.9. A pp rov e all req uirem ents 5. M anage acceptance 5.1. Ensure the acceptance of every user need 5.2. Ensure the acceptance of every design input requirem ent 5.3. D ocum ent the results of every user need acceptance test 5.4. D ocum ent the results of every design input requirem ents test 5.5. M ake acceptance results available 6. M anage change 6.1. M aintain history of design elem ent changes M ake com plete change history available M ain tain histo ry w ithin and acro ss an y organ ization al procedure M ain tain histo ry w ithin and acro ss an y project m ilesto ne M ain tain histo ry w ithin and acro ss an y D esig n C o ntrol G uid ance E lem en ts 6.2. Capture frequency and nature of elem ent changes Provide rationale for change D escribe decisions m ade Id entify app rov al au tho rity fo r th e chang e Capture date, tim e, and signature of approving authority 6.3. Identify im pacted elem ents due to a change in another elem ent Create backw ard traces to design elem ents w ithin and across any organizational procedure Create backw ard traces to desig n elem ents w ithin and across any p roj ect m ilestone (b) Design and Development Planning E ach m anufacturer shall estab lish and m ain tain p lan s that describe or referen ce the desig n and d evelop m en t activities and define respon sibility fo r im p lem en tation. T h e plan s sh all identify and describe the interfaces w ith d ifferent group s or activities th at p rov ide, or resu lt in, input to the design and developm ent process. Incremento 2 Comply with FDA Design Control Guidance GMP Regulation 1. Capture design and related inform ation 1.1. Inp ut electron ically form atted data 1.2. R eference external inform ation sources 1.3. Reference external docum entation The plans shall be reviewed as design and developm ent evolves. The plans shall be updated as design and developm ent evolves. The plans shall be approved as design and developm ent evolves (c) Design Input 2.1. E ach m anufacturer shall estab lish p rocedures to ensu re that the design req uirem ents relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient E ach m anufacturer shall m ain tain procedures to ensu re that the design requ irem ents relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient T h e proced ures shall include a m echanism for addressin g in co m p lete req uirem ents The procedures shall include a m echanism for addressing am biguous requirem ents The procedures shall include a m echanism for addressing conflicting requirem ents The design input requirem ents shall be docum ented by a designated individual(s) The design input requirem ents shall be reviewed by a designated individual(s) The design input requirem ents shall be approved by a designated individual(s) The approval, including the date and signature of the individual(s) approving the requirem ents, shall be docum ented Q uestio ns Sum m arize the m anufacturer's written procedure(s) for identification and control of design input From w hat sources are design inputs sought? D o design input procedures cover the relevant aspects, such as: (M ark all that apply and list add itio nal asp ects.) inten ded use user/patient/clinical perform ance characteristics safety lim its an d to leran ces risk an alysis tox icity and bio co m patib ility electrom agnetic com patibility (EM C) co m p atibility w ith accesso ries/au xiliary devices co m p atibility w ith the env iron m en t of in ten ded u se hum an factors phy sical/ch em ical ch aracteristics lab eling /packaging reliab ility statutory and regulatory requirem ents voluntary standards m anufacturing processes sterility M DRs/com plaints/failures and other historical data design history files (D H Fs) F o r the specific d esig n cov ered, how w ere th e d esig n in pu t requirem ents id en tified? For the specific design covered, how were the design input requirem ents reviewed for adeq uacy? 2. Store design and related inform ation 2.1. Identify and tag design inform ation as unique design elem ents 2.2. Organize design elements Organize by Design Control Guidance Elem ent Organize by inter-relationships 2.3. Ensure all design elem ents are available Store design elements by Design Control Guidance Elem ent Store design elem ents and their historical values 3. M anage all user needs 3.1. Identify the source of the user need 3.2. Identify all user types (groups) 3.3. Identify the custom er (s) 3.4. Profile the expected patients 3.5. State the intended use of the product (fam ily) 3.6. Capture the acceptance criteria for each user need 4. M anage design input requirem ents 4.1. Identify the source of the requirem ent 4.2. Identify the associated user need 4.3. Capture requirem ent description and attributes 4.4. Capture acceptance criteria 4.5. Assign responsibility for each requirem ent 4.6. M anage in co m plete requirem ents 4.7. M anage am biguous requirem ents 4.8. M anage co nflictin g requ irem ents 4.9. Approve all requirem ents 5. M anage acceptance 5.1. Ensure the acceptance of every user need 5.2. Ensure the acceptance of every design input requirem ent 5.3. Docum ent the results of every user need acceptance test 5.4. Docum ent the results of every design input requirem ents test 5.5. M ake acceptance results available 6. M anage change 6.1. M aintain history of design elem ent changes M ake com plete change history available M aintain history within and across any organizational procedure M aintain history within and across any project m ilestone M aintain history within and across any Design Control Guidance Elem ents 6.2. Capture frequency and nature of elem ent changes Provide rationale for change D escribe decisions m ade Identify approval authority for the change Capture date, tim e, and signature of approving authority 6.3. Identify im pacted elem ents due to a change in another elem ent Create backward traces to design elem ents within and across any organizational procedure Create backward traces to desig n elem ents within and across any p roject m ilestone

28 Pueden ser los requisitos imágenes?

29 DOORS/Analyst Primera Herramienta de Modelado Visual dentro una Herramienta de Gestión de Requisitos Unique!

30 DOORS/Analyst Definición de diagramas o modelos completos Crear diagramas a partir de requisitos textuales y mantenerlos sincronizados Enlazar los requisitos textuales con sus correspondientes elementos gráficos Salvar! Crear!

31 DOORS/Analyst TAU Integración DOORS/Analyst, TAU/Architect y TAU/Developer workflow Reusar modelos DOORS/Analyst en TAU/Architect Refinar, simular y verifcar el modelo de la arquitectura DOORS/Analyst Reusar y refinar el modelo, simular y generar la aplicación Traceability TAU/Architect Traceability TAU/Developer Application

32 Cómo puedo gestionar mis recursos de manera más efectiva?

33 Telelogic Focal Point Complemento ideal a DOORS Priorización basada en el valor para nosotros y el cliente Soporte a la toma de decisiones sobre funcionalidades en la fase inicial del ciclo de vida para optimizar la asignación de recursos e inversiones Intercambio de datos entre DOORS y Focal Point Focal Point para desarrollar las funcionalidades adecuadas y Gestión de Requisitos para desarrollar adecuadamente esas funcionalidades

34 Toma de decisiones Priorizar metodicamente el esfuerzo basado en el valor 80% del valor proviene del 20% del coste identifiquemos ese 20%!

35 Comparar Coste y Valor Para cada funcionalidad y simular escenarios Costs Value per customer/market

36 Diagramas Gantt: Gestión Proyectos

37 Gestión de Productos

38 Cómo puedo gestionar los cambios?

39 Remitir propuestas con SYNERGY/Change DOORS Ciclo de Trabajo Configurable Rework SYNERGY Resolved Propose Change Review Assign Test Assigned Closed Conclude Defer

40 Revisión de las propuestas de cambio Peticiones de Cambio de Requisitos para ser revisadas se listan para el analista DOORS crea automaticamente una vista específica para facilitar la revisión Cada revisor puede indicar su aprobación y comentarios

41 DOORS Change Proposal System (CPS) User submits Change Proposal Accepted Collect changes from all users including DOORSnet Changes reviewed on-line On Hold In Review Rejected

42 Cómo aseguro la notificación y el control de los cambios producidos?

43 Suspect Links Si la información está enlazada un cambio efectuado aquí debe notificarse aquí.

44 Suspect Links Suspect links visibles directamente en el documento - Unique! como alarmas o con descripción completa Nunca perder un cambio

45 Histórico y baselines Histórico del requisito Deshacer cualquier cambio Baseline previa Versión actual

46 Comparación de Baselines Proporciona una lista de todas las diferencias en un único informe

47 Cómo aseguro la conformidad?

48 Firmas electronicas Unique! Firmas electrónicas sobre las baselines habilitan: Capacidades de auditoria Soporte a procesos de calidad Verificación de intención Consenso documentado Conformidad con estándar FDA 21 CFR part 11 Provee testimonio de responsabilidad sin herramientas externas

49 Inclusión en los informes

50 Cómo puedo gestionar el trabajo en entornos distribuidos?

51 Multiples Métodos de Acceso Remoto DOORSnet Live web access Internet/intranet DOORS XT Fully functional distributed RM. Oracle based repository Import/Export of data Archive/Restore Round trip spread sheet export/import Partition/Rejoin Controlled move of data between databases

52 DOORS XT Arquitectura que provee acceso de alta velocidad sobre conexiones a la información con poco ancho de banda Completa interoperabilidad con DOORS

53 Edición con DOORSnet Acceso via Web con posibilidad de editar requisitos y atributos

54 Como puede DOORS ayudarme con mis pruebas?

55 DOORS Test Tracking Toolkit Unique! Para pequeñas aplicaciones de pruebas: Gestión de casos de pruebas en un módulo de DOORS Enlaces de requisitos a pruebas Comparación de los resultados de las pruebas Comprobación de cobertura completa contra requisitos

56 Test Cases Unique!

57 Compare Test Runs Unique!

58 Requirements Test Status Unique! Filter on reqs. that have failed/passed

59 Cómo puedo asegurar mi éxito usando DOORS?

60 Servicios Telelogic Professional Services Structured Requirements Management Writing Better Requirements Project Architecture Workshop Practical Application Mentoring Optimizing DOORS for your network On-Site/Public Training Using DOORS for Requirements Management Customizing DOORS with DXL DOORS Administration & Management Using DOORS with UML Customer Support GREAT JOB!!! I truly appreciate your professionalism and your ability to solve a customer's issue quickly. Large defense contractor Thank you again for a job well done. US Government Agency You should feel very fortunate that such talented and nice people work in your facility. Fortune 500 DOORS User

61 DOORS partners and integrations For best in class choice

62 DOORS Leadership Council Unique!

63 DOORS es unique! Unique: Unique: Unique: Unique: Unique: Unique: Unique: Unique: Vistas Configurables en el propio documento: Texto, imágenes, tablas, indicadores de enlaces, trazabilidad, atributos, valores calculados, barras de cambios, filtros, ordenaciones, suspect links Imagenes embebidas permitiendo enlaces a los elementos gráficos Electronic Signature Suspect Links en el propio documento Jerarquía ilimitada de carpetas y proyectos Posibilidad de abrir multiples proyectos a la vez Links a requisitos en baselines Soporte para testing

64 - Esto es muy interesante! Me gustaría saber más sobre Gestión de Requisitos y DOORS.

65 Información adicional: Durante la jornada. Su Oficina Local Telelogic en Madrid: Teléfono:

66 Putting you ahead in development!