Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Requisitos no funcionales

No description
by

Jose Córcoles

on 6 May 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Requisitos no funcionales

Tema 5: Requisitos NO Funcionales
Jose E. Córcoles Definiciones:
Es un requisito software que describe no lo que el software hará,
sino como lo hará, como por ejemplo, requisitos de rendimiento.
Los requisitos no funcionales son difíciles de verificar/testear,
y por ello son evaluados subjetivamente Thayer Requisito no funcional: característica requerida del sistema, del proceso de desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo, que señala una restricción del mismo. Sommerville De calidad y restricciones Pohl Suelen ser requisitos más críticos que los requisitos funcionales
Suelen ser difíciles de verificar Tipos de Requisitos Requisitos de producto: Especifican el comportamiento del producto: Tiempo de respuesta, memoria requerida, fiabilidad, portabilidad, usabilidad… Requisitos de organización:  Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador:  Estándares de proceso, lenguajes de programación, métodos de diseño, estándares de documentación... Requisitos externos:  Factores externos al sistema y de su proceso de desarrollo:  Interoperabilidad, éticos, legislativos, privacidad, seguridad... Sommerville Phol Calidad y Restricciones...

Requisitos no-funcionales,
son solo requisitos mal
refinados .... Continuamos ... “El máximo espacio de almacenamiento ocupado por el sistema debe ser de 8 MB porque el sistema debe alojarse completamente en una memoria de sólo lectura e instalarse en el coche” “El proceso software y los documentos a realizar deben conformar el proceso y los
estándares de documentación recogidos en la norma TELMo-ES-2003” “El sistema no debe revelar ninguna información personal sobre los clientes excepto su nombre y su número de referencia" NFR Framework (Cheng et.al) Ve a los objetivos no funcionales como objetivos que pueden tener conflictos entre ellos y que deben ser tratados como objetivos del software a ser satisfechos. El concepto de softgoal (objetivo del software) fue introducido para representasr la naturaleza abstracta e informal del requisito no funcional. Cada softgoal será descompuesto en objetivos menores
representado por un estructura tipo grafo inspirada en “arboles y/o”, usados en la solución de problemas. Este proceso continúa hasta que el ingeniero de requerimientos considere el softgoal como satisfecho (en el sentido de operacionable). Ejemplo Basada en UCs (Digión, L.B.) Ampliar el caso de uso con un registro para los requisitos no funcionales
asociados a ese caso de uso Ejemplo Ejemplos de Requisitos Accesibilidad,
Auditoría y control,
Disponibilidad,
Copia de seguridad,
Capacidad actual y previsiones,
Certificación,
Recuperación de Desastres,
Eficiencia (consumo de recursos para la carga dada),
Eficacia (resultante de rendimiento en relación con el esfuerzo),
Extensibilidad,
Interoperabilidad,
Mantenimiento,
Operatividad,
Rendimiento / Tiempo de respuesta,
Portabilidad,
Recuperación,
Fiabilidad (por ejemplo, Tiempo medio entre fallos – MTBF),
Las limitaciones de recursos (la velocidad del procesador, memoria, espacio en disco, ancho de banda de red etc), Tiempo de respuesta,
Robustez,
Escalabilidad (horizontal, vertical),
Seguridad,
Estabilidad,
Seguridad,
Testeabilidad… Una buena definición de requisitos no funcionales (NFR) es tán importante como los requisitos funcionales. Deben de ser apropiadamente definidos, analizados y trazados. Funcionalidad (Funcionallity) (Rendimiento de funciones, seguridad)
Facilidad de uso (Usability): factores humanos relacionados con su manejo, ayuda y documentación.
Fiabilidad (Reliability): Capacidad de recuperación ante los fallos.
Rendimiento (Perfomance): Tiempos de respuesta, precisión, eficacia.
Soporte (Supportability): Adaptabilidad, facilidad de mantenimiento, internacionalización, configurabilidad. (F)URPS+ Ejemplo Facilidad de uso (usability): „ Se debe ver el texto fácilmente a una distancia de 1 metro
„ Fiabilidad (reliability): Si se produce algún fallo al usar un servicio externo (autorización de pago) solucionarlo localmente
„ Rendimiento (performance): „ conseguir la autorización de pago en menos de 1 minuto, el 90% de las veces
„ Soporte (supportability): „ El sistema debe ser instalable por los usuarios Verificables RNF imprecisos (una primera versión)
- Los usuarios especializados deberán utilizar el sistema fácilmente.
- El sistema deberá estar organizado para minimizar los 18
El sistema deberá estar organizado para minimizar los errores del usuario.

RNF verificables (detallados)
- Los usuarios experimentados deberán poder utilizar todas las funciones del sistema después de un total de dos horas de entrenamiento.
- Después de este entrenamiento, el número medio de errores cometidos por los usuarios experimentados no excederá de dos por día. Los requisitos no funcionales pueden ser muy
difíciles de expresar con exactitud.
„ Los requisitos imprecisos pueden ser difíciles
difíciles de verificar
„ Ej: Un deseo general del usuario es, por ejemplo, la facilidad de uso
„ Requisito no funcional verificable
„ Una frase que incluye alguna medida que puede ser objetivamente probada Difíciles de expresar ¿Cómo los modelamos? ¿Cuáles son los NFR
de vuestro sistema? RUP - Requisitos suplementarios 1. Introduction
2. Functionality
3. Usability
4. Reliability
5. Performance
6. Supportability
7. Design Constraints
8. Online User Documentation and Help System Requirements
9. Purchased Components
10. Interfaces
10.1 User Interfaces
10.2 Hardware Interfaces
10.3 Software Interfaces
10.4 Communications Interfaces
11. Licensing Requirements
12. Legal, Copyright, and Other Notices
13. Applicable Standards Chung y Supakkul (2005) proponen un marco para la representación y la integración no Requisitos funcionales (NFR) con los requisitos funcionales (FRS) UCs con NFR (Chung & Supakkul) Step 1: Define System Boundary and Global NFR Softgoals.
The system will support customers in buying their books online and provide the vendor with sufficient information. The global NFR Softgoals are:
Portability: System has to run on top 5 of popular web browsers.
Availabiltiy: 99.99% Uptime has to guaranteed. Step 2: Identify Actors and Related NFR Softgoals
The actors in this example will be the Vendor, Customer and Payment System. The related NFR Softgoals are:
User Friendliness: Intuitive User Interface
Security: Send encrypted messages Step 3: Identify Use Cases and Related NFR Softgoals
Below the Use Cases with their related NFR Softgoals (if applicable) are summarized:
Gather Real Time Information (User Friendliness)
Place Order (User Friendliness)
Make Payment (Security)
Check Order Status (User Friendliness)
Process Payment (Security)
Update Order Status Step 4: Relocate Common NFRs Softgoals
The result of this step is presented in figure 1: The Integrated Use Case Diagram. After revisiting the Use Cases and the NFR Softgoals, the System Engineer will integrate both in one diagram. Step 5: Refine and Satisfice NFR Softgoals
The result of this step is a Softgoal Interdepency Graph. This graph gives an overview of the NFR Softgoals and their dependencies, satisfied and denied softgoals, etcetera. In this case for example the User Friendliness should be worked out for User Friendliness for the Client and User Friendliness on the Vendor side. Which will result in a Softgoal Interdepency Graph. Step 6: Satisfice Selected Operationalizing Softgoals
This step is used to analyze and operationalize the selected softgoals. Step 7: Develop Architecture and Design for the Use Cases
The software development team uses the results of the previous steps for the software architecture and design. This will be developed based on the NFR Softgoals. They will create UML component diagrams and sequence diagrams with those results in mind. Conclusiones Difíciles definir los NFR
Difíciles para que sean verificables
Full transcript