Ingeniera de Requerimientos Requerimientos de Software

Estudia el proceso de establecer los servicios que el cliente requiere de un sistema y las restricciones sobre las cuales se desarrollar y se operar Los requerimientos son las descripciones de los servicios del sistema y las restricciones

Slide 1

Slide 2

Que es un requerimiento?
Varia desde un alto nivel de abstraccin hasta una descripcin matemtica Provee dos funciones
Bases para una licitacin (permite cierta instanciacin) Bases para un contrato (se debe estar detallado lo mximo posible)

Abstraccin de Requerimientos (Davis)

If a comp any w ishes to let a cont ract for a large software deve lopmen t project, it must define its need s in a sufficien tly ab stract way that a solution is not pre-defined. The requirements must be written so that several contractors can b id for the con tract, offering, pe rhaps, different ways of meeting the client organisations need s. Once a contract has been a warded, the contractor must write a system definition for the client in more de tail so that the c lient und erstands and can val idate what the software will do. Both o f these docu ments may be ca lled the requirements document for the system.

Slide 3

Slide 4

Tipos de Requerimientos
Requerimientos de Usuario
Descritos en lenguaje natural y diagramas de servicios Escritos por los clientes Base para la licitacin Documento estructurado especificando detalladamente las funciones del sistema y las restricciones operacionales Base para el contrato

Ejemplos

Requerimientos del sistema

Slide 5

Slide 6

Tipos de requerimientos
Funcionales
Servicios Restricciones de tiempo Restricciones en el proceso Estndares de la empresa, etc. Legales Estndares del dominio

Ejemplo: LIBSYS
Un sistema de bibliteca que provee un interfase a un cierto nmero de bases de datos en diferentes bibliotecas Los usuarios pueden buscar, bajar e imprimir artculos

Non-funcionales

Requerimientos de Dominio

Slide 7

Slide 8

Ejemplos de requerimientos funcionales

El usuario debe ser capaz de buscar en todas o en una bilioteca en particular El sistema debe tener un apropiado para los artculos visor (reader)

Ambiguedades
Especificaciones que pueden interpretarse de varia formas Ejemplo: el trmino apropiado
Intencin del usuario: un visor especial para cada tipo de archivos (pdf, ps, dvi, word, etc.) Intencin del desarrollador: un visor que despliegue en texto los archivos

Cada orden debe tener un identificador nico para futuras referencias

Slide 9

Slide 10

Completitud y Consistencia
Completo Debe incluir TODAS las funciones requeridas Consistente No debe tener conflictos En la prctica es imposible tener ambas

Tipos de requerimientos no funcionales

Slide 11

Slide 12

Ejemplos:
Producto
8.1 La interfase de LIBSYS debe estar implementada en HTML sin marcos ni applets

Presentacin estructurada de los requerimientos

Organizacional
9.3.2 El desarrollo del sistema y la documentacin debe cumplir con el estndar : XYZCo-SP-STAN-95.

Requerimiento externo
7.6.5 El sistema no debe proveer informacin personal de los operadores excepto por el nombre

2.6.1 Grid facilities The editor shall provide a grid facility where a m atrix of horizontal and vertical lines provide a background to the editor window. This grid shall be a passive grid where the alignment of entities is the user's responsibility. Rationale: A grid helps the user to create a tidy diagram with well-spaced entities. Although an active grid, where entities 'snap-to' grid lines can be u seful, the positioning is imprecise. The user is the best person to decide where entities should be positioned. Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6 Source: Ray Wilson, Glasgow Office

Slide 13

Slide 14

Requerimientos y Diseo
En teora: Requerimientos Qu debe hacer el sistema? Diseo: Cmo lo debe hacer? En la prctica: son inseparables
Una arquitectura sistemtica generalmente se obtiene a partir de los modelos de los requerimientos

Problemas con el lenguaje natural

Ambiguedad
Varias interpretaciones

Demasiada-flexibilidad
Muchas formas de decir lo mismo LN no tiene estructura

Falta de modularizacin

Slide 15

Slide 16

Alternativas del lenguaje natural

Notation Structured natural language Design description language s Graphical notations Description This approach depends on defining standard forms or templates to express the requirements specification. This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system. This approach is not now widely used although it can be useful for interface specifications. A graphical language, supplemented by text annotations is used to define the functional requirements for the system. An early example of such a graphical language was SADT. Now, use-case descriptions and sequence d iagrams are commonly used . These are notations based on mathematical concep ts such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. Howeve r, most customers dont understand formal specifications and are reluctant to accept it as a system contract.

Lenguaje natural estructurado

Insulin Pump/Control Software/SRS/3.3.2 Function Compute insulin dose: Safe sugar level Description Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units. Inputs Current sugar reading (r2), the previous two readings (r0 and r1) Source Current sugar reading from sensor. Other readings from memory. Outputs CompDose the dose in insulin to be delivered Destination Main control loop Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can be delivered. Requires Pre-condition Post-condition Side-effects Two previous readings so that the rate of change of sugar level can be computed. The insulin reservoir contains at least the maximum allowed single dose of insulin.. r0 is replaced by r1 then r1 is replaced by r2 None

Mathematical specifications

Slide 17

Slide 18

Tabular specification
Condition Sugar level falling (r2 < r1) Sugar level stable (r2 = r1) Sugar level increasing and rate of increase decreasing ((r2-r1)<(r1-r0)) Sugar level increasing and rate of increase stable or increasing. ((r2-r1) (r1-r0)) Action CompDose = 0 CompDose = 0 CompDose = 0 CompDose = round ((r2-r1)/4) If rounded result = 0 then CompDose = MinimumDose

Modelos Grficos
Los modelos grfios son tiles cuando se necesitan mostrar relaciones, sequencias o cambios de estado de los componentes

Slide 19

Slide 20

Diagramas de secuencia
Muestran la secuencia de eventos que suceden durante la interaccin del sistema con el usuario Se leen de arriba hacia abajo Ejemplo: Cajero automtico
Validar tarjeta Manejar peticin Completar transaccin

Diagrama de secuencia de un cajero automtico

Slide 21

Slide 22

Estudio de factibilidad
Permite decidir si vale la pena (o no) realizar el sistema Estudio corto que se enfoca en lo siguiente:
El sistema cumple con los objetivos organizacionales El sistema puede ser construido con los recursos econmicos y tecnolgicos existentes El sistema puede ser integrado

Implementacin del estudio de factibilidad

Basado en la informacin preliminar de lo que se requiere y debe hacerse por escrito Preguntas que debe responder:
Que pasara si el sistema no se implementa? Cuales son los problemas del proceso actual? Como ayudar el sistema a resolverlos? Cuales sern los problemas de integracin? Se necesita nueva tecnologa? Habilidades? Cuanto costar?

Slide 23

Slide 24

Anlisis basado en puntos de vista

Puntos de vista son una forma de estructurar los requerimientos para presentar diferentes perspectivas Este enfoque multi-perspectiva es importante porque no hay una simple vista del sistema

Tipos de puntos de vista

Vista de un interactor
Gente u otros sistemas que interactan directamente con el sistema. Ejemplo en un cajero automtico el cliente y la base de datos son los interactores Gente que no usa el sistema pero que tiene cierta influencia con los requermientos- Ejemplo: administradores y personal de seguridad Ejemplo: estndares interbancarios

Vista indirecta

Vista del dominio

Slide 25

Slide 26

Ejemplo: LIBSYS

Escenarios
Un escenario es una situacin de la vida real en el cual el sistema podra utilizarse Deben incluir
Descripcin de ls situacin de entrada Descripcin del flujo normal de eventos Descripcin de excepciones (errores) Informacin de actividades concurrentes Descripcin del estado cuando termina el escenario

Slide 27

Slide 28

LIBSYS scenario (1)

Initial assu mption: The user has logged on to the LI BS YS sys tem and ha s locat ed the journa l contai ning the copy of the a rticle . Norm al: The user selec ts the article to be copied. He or she is then pr ompted by the sys tem to ei the r provide subscribe r inform ation for the jour na l or to indicate how the y will pay for the article . Alte rnat ive payment me thods ar e by credit ca rd or by q uoting an organi sa tional acco unt num ber. The user is the n ask ed to fill in a copyright form that ma intai ns deta ils of the trans ac tion and they then subm it this to the LIBSYS sys te m. The copyright fo rm is c hec ked and, if OK , the PDF version of the artic le is d ow nl oaded to the LIBSY S working area on the userscom puter and the user is inform ed that it is avai lab le. The user is asked t o se lec t a pr inter and a copy of the article is printe d. If the article has been flag ged as print-onlyit i s del ete d from the us er system o nce the user has confirm ed that printing is com plete . s

LIBSYS scenario (2)

What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the fo rm should be re-presented to the user for correction. If the resubmitted form is s till incorrect then the use rs request for the article is rejec ted. The p ayment ma y be rejecte d b y the s ystem. T he users r quest f or the article is rejected. e The a rticle download m ay fail. Retry until succe ssf ul o r the user terminates the s ession. It may not be poss ible to print the article. If t he article is not flagged as print-onlythe n it is held in the LIBSYS workspace. Otherwise, the artic le is d eleted and the user acc ount credited with the cost of the s article . Ot her activities: Sim ultaneous d ownloads o f other article s. System state on completion: User is logged on. The downloaded article has been dele ted from LIBS YS workspace if it has been flagged as print -only.

Slide 29

Slide 30

Casos de Uso
Los casos de uso son una tcnica de especificacin basada en escenarios y utiliza notacin UML Identifica los actores y se describe la interaccin El conjunto de casos de uso debe describir todas las posibles iteracciones con el sistema Se pueden agregar diagramas de secuencia para completar la especificacin

Caso de uso de impresin de un artculo

Slide 31

Slide 32

Mas casos de uso de LIBSYS

Diagrama de secuencia de la impresin del artculo

Slide 33

Slide 34

Validacin de requerimientos
El objetivo es demostrar que los requerimientos son los que el usuario realmente desea Dado que un error en los requerimientos es tan costoso el proceso ES NECESARIO
Un error en los requerimientos puede costar hasta 100 veces cuando se detecta despues de la entrega que un error de implementacin

Actividad 4

Slide 35

Slide 36

Verificacin de requerimientos
Validez. El sistema provee las funciones que necesita el cliente? Consistencia. Hay conflictos? Completitud. Estn incluidas todas las funciones requeridas? Realismo. Los requerimientos pueden ser implementados dadas las restricciones tecnolgicas y econmicas?

Tcnicas de verificacion de requerimientos

Revisiones
Anlisis manual y sistemtico de requerimientos Utilizar ejecutables para validar requerimientos Desarrollo de casos de prueba para checar testability

Prototipado Generacin de casos de pruebas

Slide 37

Slide 38

Mas propiedades de los requerimientos

Verificabilidad. Se puede probar el requerimiento? Comprehensibilidad. Es comprensible el requerimiento? Rastreabilidad. Es el origen del requerimiento claramente identificable? Adaptabilidad. Pueden los requerimientos cambiar sin tener un impacto en los otros requerimientos?

El Documento de Requerimientos
El documento de requerimientos el la declaracin oficial de lo que se requiere de los desarrolladores Debe incluir los requerimientos del usuario y los del sistema NO es un documento de diseo. Debe especificar QU DEBE hacerse y no CMO debe hacerse

Slide 39

Slide 40

Guas para escribir el Documento de Requerimiento

Invente un formato estndar y selo para todos los requerimientos Use el lenguaje en una forma consistente. Ejemplo: Debe para requerimientos indispensables, Podra para requerimientos deseables Identifique los puntos claves utilizando algn tipo de nfasis (subrayado, negritas, etc.) Evite el uso de lenguaje especializado de computacin

Usuarios del documento

Slide 41

Slide 42

Estructura Estndar del Documento de Requerimientos (IEEE)

Introduccin Glosario Requerimientos del usuario Requerimientos del sistema Modelos del sistema Appendices Index

Actividad 4

Slide 43

Slide 44