De clase mundial

INGENIERAdE REQUISITOS

REQUISITOS - CLASIFICACIN - INGENIERA

ANLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIN

FASE IdENTIFICACIN

ACTIVIdAd dE PROYECTO1. Determinar las especificaciones

funcionales del Sistema de Informacin.

ACTIVIdAd dE APRENdIZAJE3. Elaborar el Documento Tcnico de

Identificacin de necesidades del Sistema a desarrollar

(Documento SRS)

CONteNidO

Fase

iden

tific

aci

n

AD

SI

CONteNidO

REQUISITOS 4 8 12 14CLASIFICACIN INGENIERAConceptoCmo deben ser?

Qu deben indicar?

Cmo obtener Requisitos?

Problemas comunes al obtener

ADSI - Anlisis y desarrollo de sistemas de informacin - SENA, DE CLASE MUNDIAL

ADSI - Fase 1 identificacin - Ingeniera de Requisitos

Requisitos No Funcionales

Requisitos Funcionales

Aspectos a tener en cuenta al describir requisitos

Forma de Presentacin de los Requisitos

Participantes en el Proceso de Requisitos

Referencias

Glosario

Este material puede ser distribuido, copiado y exhibi-do por terceros si se muestra en los crditos. No se puede obtener ningn beneficio comercial y las obras derivadas tienen que estar bajo los mismos trminos de licencia que el trabajo original.

Creative Commos

4 5

{

AD

SI

[

An

lisis

y d

esar

rollo

de

sist

emas

de

info

rmac

in

]

Fase

iden

tific

aci

nS

EN

A, D

E C

LAS

E M

UN

DIA

L

ReQUiSitOSEl anlisis de requisitos es una de las tareas ms importantes en el ciclo de vida del desarrollo de software, puesto que en ella se determinan los planos de la nueva aplicacin.

En cualquier proyecto software los requisitos son las necesidades del producto que se debe desarrollar. (Monferrer, 2001, p1)

Es por esto que para realizar un buen anlisis de los requisitos, se deben identificar claramente estas necesi-dades y documentarlas. Como arte-facto se debe producir y entregar un documento de especificacin de re-quisitos en el que se describa lo que el futuro sistema debe hacer.

se suelen especificar en lenguajenatural,

se expresan de forma individual(p.ej. esquemticamente).

se organizan de forma jerrquica(a distintos niveles de detalle).

amenudo,senumeran(parafacili-tar su gestin).

El anlisis de requisitos se puede de-finir como el proceso del estudio de las necesidades de los usuarios para llegar a una definicin de los requisi-tos del sistema, hardware o softwa-re, as como el proceso de estudio y refinamiento de dichos requisitos, definicin proporcionada por el IEEE [Piattini, 1996]. Asimismo, se define requisito como una condicin o ca-pacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado [Piattini, 1996]. Esta definicin se extiende y se aplica a las condiciones que debe cumplir o poseer un sistema o uno de sus com-ponentes para satisfacer un contrato, una norma o una especificacin.

En la determinacin de los requisitos no slo deben actuar los analistas, es muy importan-te la participacin de los propios usuarios, porque son stos los que mejor conocen el sistema que se va a automatizar. Analista y cliente se deben poner de acuerdo en las ne-cesidades del nuevo sistema, ya que el clien-te no suele entender el proceso de diseo y desarrollo del software como para redactar una especificacin de requisitos software (ERS) y los analistas no suelen entender com-pletamente el problema del cliente, debido a que no dominan su rea de trabajo.

REQUI-SITOS

CONCEpTOMonferrer (2001) comenta:

76[

A

nlis

is y

des

arro

llo d

e si

stem

as d

e in

form

aci

n

]

SE

NA

, DE

CLA

SE

MU

ND

IAL

Fase

iden

tific

aci

n

AD

SI

CmO dEbEN SER?

QU dEbEN INdICAR?

deben ser:Clarosyconcretos: (evitando imprecisio-

nes y ambigedades) p.ej. Uso de puntos suspensivos, etcteraConcisos: (sin rodeos ni figuras retricas).Completosyconsistentes.

Loqueseesperaquehagaelsistema(qu?).Sujustificacin (por qu ha de ser as? quin lo propuso?).Loscriteriosdeaceptacin que sean aplicables (cmo

se verifica su cumplimiento?).

CmO ObTENER

REQUISITOS?

pRObLEmAS COmUNES AL ObTENER REQUISITOS

Revisar las necesidades de los clientes,usuarios y otros interesados.

Revisarlasituacinactual.Revisarlaorganizacinactual.Conocerlaversinactualdelsistema.Entrevistar desarrolladores de versiones

anteriores.Revisardocumentosexistentes (antece-

dentes).Revisarsistemasanlogos(antecedentes).Se debe trabajar en conjunto con los

usuarios y clientes.

Distintosusuariostienendistintosrequisitos,sedebenencon-trar todas las fuentes.

Nosabenloquequierendelsistema,sloentrminosgenera-les, no conocen el costo de sus peticiones.

Losrequisitosestnensustrminosyconconocimientoimpl-cito de su propio trabajo.

Laprioridadquesedaalosrequisitosvaraconeltiempo.Aparecennuevosrequisitos.Unrequerimientoes,aveces,difcildeverificar(especialmente,

si es un requisito no funcional).Adems,sisomosincapacesdeespecificarlo,cmosabemos

que realmente es un requisito? Laexistenciadeunrequerimientohadeestardebidamentejus-

tificada (debemos saber por qu es un requisito del sistema).

8REQUISITOS FUNCIONALES

9

AD

SI

Fase

iden

tific

aci

n

[

An

lisis

y d

esar

rollo

de

sist

emas

de

info

rmac

in

]

Expresanlanaturalezadelsistema(comointeraccionael sistema con su entorno y cules van a ser su estado y funcionamiento).

ServiciosofuncionesqueproveerelsistemaDescribenlainteraccinentreelsistemayelentorno.

Definen el qudebe hacer un sistema

Restricciones a los servicios o funcionesofrecidos por el sistema.

Describenrestriccionesquelimitanlaselec-ciones para construir una solucin.

Definen el com debe hacer un sistema

Debenestarredactadosdetal formaqueseancomprensiblespara usuarios sin conocimientos tcnicos avanzados (de infor-mtica, desarrollo de software).

Debenespecificarelcomportamientoexternodelsistemayevitar,en la medida de lo posible, establecer caractersticas de su diseo.

Debenpriorizarse(almenos,sehadedistinguirentrerequisitosobligatorios y requisitos deseables).

Deben especificarse cuantitativamente, siempre que sea posible (para que se pueda verificar su cumplimiento).

CLA-

SiFi-

REQUISITOS NO FUNCIONALES

CA-

Ci

N

Ellenguajedeprogramacindebeserjava.Eltiempoderespuestaenlasconsultasno

debe superar los 5 segundos.Ejemplos:

Ejemplos:

Sedebesolicitar la identificacin,nombres, apellidos, genero, co-rreo electrnico.

Debegenerarun listadodetodaslas personas de acuerdo al genero

Rendimientodelsistema: Fiabilidad, tiempo de respuesta,

disponibilidad

Interfaces: Dispositivos de E/S, usabilidad,

interoperabilidad

Procesodedesarrollo: Estndares, herramientas, plazo

de entrega.

DelProducto: Especifican restricciones al com-

portamiento del producto.

Ejemplos: desempeo, confiabili-dad, portabilidad, usabilidad.

DelaOrganizacin: Se derivan de las polticas y pro-

cedimientos existentes en la or-ganizacin del cliente y en la del desarrollador.

Ejemplos: estndares, lenguajes de programacin, mtodo de diseo

Externos:Se derivan de factores externos, como:

- Interoperabilidad: con otros sis-temas.

- Legislativos: privacidad, seguridad.- ticos: dependen del contexto,

las personas, etc

10 11

AD

SI S

EN

A, D

E C

LAS

E M

UN

DIA

LFa

se id

entif

icac

in

[

An

lisis

y d

esar

rollo

de

sist

emas

de

info

rmac

in

]

ASpECTOS A TENER EN CUENTA AL dESCRIbIR REQUISITOS

FORmA dE pRESENTACIN dE LOS REQUISITOS

UbicacinyEntornoFsi-cos: dnde, uno o varios, restricciones ambientales.

CdigodelRequisito RF1

Tipo Funcional

Descripcin El sistema deber generar los reportes de todos los alumnos de una institucin.

Entradas PInformacin de alumnos por curso.

Salidas El reporte de alumnos

EjemploGeneracindereportes:

Cdigo del Requisito

Descripcin

Salidas

Tipo

Entradas

RF_numero, para requisito funcional

RNF_numero para requisito no funcional

Breve descripcin del requisito

Lo que genera el requisito.

Funcional

No Funcional

Lo que se necesita para poder cumplir

el requisito

Nombre

Interfaces: Entrada de 1 o + sistemas, Salida a 1 o + sistemas, restricciones de formato, soporte.

Usuarios y Factores Hu-manos: capacidad de cada tipo de usuario, tipo de entrenamiento, facili-dad de uso, posibilidad de mal uso.

Funcionalidad y Restric-ciones asociadas: qu debe hacer, cundo, mo-dos de operacin, cmo y cundo se puede mo-dificar el sistema, res-tricciones de velocidad, tiempo de respuesta, ca-pacidad de proceso.

Documentacin: cunta, formato, para quin.

Datos: formatos E/S, fre-cuencia, fuentes, desti-nos, calidad requerida, precisin en clculos, flu-jo en el sistema.

Recursos: materiales, per-sonal y otros para cons-truir, usar y mantener el sistema, habilidades de los desarrolladores, ne-cesidades de espacio y ambientales, calendario prescrito, limitaciones en presupuesto.

Seguridad: control de acceso a las funciones/datos, aislamiento de los programas, respal-dos-frecuencia, disponi-bilidad-, seguridad fsica.

AseguramientodelaCalidad

Confiabilidad: tiempo medio entre fallas, robus-tez, tolerancia a fallas.

Disponibilidad: t iem-po para estar operativo luego de falla- manteni-miento estando activo- tiempo mximo de no disponibilidad.

Mantenibilidad.

Seguridad.

Portabilidad

12 13

iNgeNieRiAAdministracindeRequisitos

AD

SI S

EN

A, D

E C

LAS

E M

UN

DIA

LFa

se id

entif

icac

in

[

An

lisis

y d

esar

rollo

de

sist

emas

de

info

rmac

in

]

Obtencin Anlisis Especificacin Validacin Verificacin

Planificacin Trazabilidad Medicin y Evalucacin

Administracin del cambio

ProcesodeRequisitosAdministracindeRequisitos

IngenieradeRequisitos

pARTICIpANTES EN EL pROCESO dE REQUISITOSClienteyUsuarios: Requisitos adecuados a sus necesidades.Diseadores: para lograr diseo que satisfaga las necesidades.SupervisoresdelContrato: Hitos de Control, cronogramas.GerentesdelNegocio: Impacto en la Organizacin.Verificadores: para poder verificar si el sistema los satisface.

14 15

AD

SI

[

An

lisis

y d

esar

rollo

de

sist

emas

de

info

rmac

in

]

SE

NA

, DE

CLA

SE

MU

ND

IAL

Fase

iden

tific

aci

n

Monferrer,(2000-2001).E78.IngenieradelSoftware.UniversitatJau-me I, Departament dInformtica 5 Curso de Ingeniera Informtica

Artefacto de software: (software artefact) Cualquier cosa que resulte del proceso de desarrollo de softwa-re; por ejemplo: documentos de re-quisitos, especificaciones, diseos, software, etc.

Calidad: (quality, ISO 8402, 1994) Conjunto de propiedades y de carac-tersticas de un producto o servicio, que le confieren su aptitud para sa-tisfacer unas necesidades explcitas e implcitas. (The totality of features and characteristics of a product or service that bear on its ability to sa-tisfy stated or implied needs).

Especificacin: [Piattini, 96]. Es un documento que define, de forma completa, precisa y verificable, los re-quisitos, el diseo, el comportamien-to u otras caractersticas de un siste-ma o componente de un sistema.

Fiabilidad: (reliability,ISO 9126) Grado en que el sistema responde bajo las condiciones definidas durante un inter-valo de tiempo dado. Se divide en las subcaracterticas madurez, tolerancia a fallos, capacidad de recuperacin.

Funcionalidad: (functionality, ISO 9126) Grado en que las necesidades asumidas o descritas se satisfacen. Se divide en las subcaracterticas idoneidad, precisin, interoperabili-dad, seguridad.

REFERENCIASGLOSARIO

IEEE: (Institute of Electrical and Elec-tronics Engineers). Asociacin de profesionales norteamericanos que aporta criterios de estandarizacin de dispositivos elctricos y electrnicos.

IngenieradeRequisitos: Proceso de descubrir, analizar, documentar y veri-ficar los servicios y sus restricciones.

Interoperabilidad: (interoperabili-ty,ISO 9126) Subcaracterstica de funcionalidad, que indica el grado en que el sistema puede interactuar con otros sistema.

Operabilidad: (operability , ISO 9126) Subcaracterstica de facilidad de uso, que indica las caractersti-cas del software que influyen en el esfuerzo del usuario para operar y control operacional.

Portabilidad: (portability, ISO 9126) Conjunto de caractersticas que de-terminan la capacidad del software para ser transferido de un entorno de operacin a otro. Se divide en las subcaracterticas adaptabilidad, fa-cilidad de instalacin, coexistencia, reemplazo.

Precisin: (suitability, ISO 9126) Subcaracterstica de funcionalidad, que indica el grado de exactitud de los efectos del sistema (i.e. salida).

Requerimientos: son las necesidades que provienen del Negocio (Usua-rios). Se plasman en el documento de requerimientos del negocio.

Requisitos: son las especificaciones puntuales sobre los servicios que debe ofrecer el sistema software y sus restricciones. Se plasman en el documento de especificacin de re-querimientos de software (SRS)

Requisitosdelsistema: Son los re-quisitos para todo el sistema.

Requisitosdelsoftware: [SOMMER-VILLE, 2002] Es la descripcin de los servicios y restricciones de un siste-ma de software, es decir, lo que el software debe hacer y bajo qu cir-cunstancias debe hacerlo.

Seguridad: (security, ISO 9126) Sub-caracterstica de funcionalidad, que indica el grado en que un acceso no autorizado (accidental o deliberado) se prevenga y se permita un acceso autorizado.

Sistema: Pensando en la solucin, se puede definir como aquella que in-cluye hardware, software, firmware, personas, informacin, tcnicas, ser-vicios, y otros elementos de soporte.

Stakeholder: (stakeholder) Cualquier persona interesada en, afectada por y/o implicada con el funcionamiento del sistema software. Por ejemplo, el usua-rio, el cliente, nuestra empresa, etc.

Pressman,R.(2006).IngenieradeSoftware: Un enfoque Prctico. VI Edicin. McGrawHill.

SommervilleI.,(2005).IngenieradelSoftware.Spti-ma edicin, Mxico DF, Editorial Pearson.

IngenieradeRequisitos:http://www.slideshare.net/ssharLudena/ingeniera-de-requisitos.

TrminosdeCalidad: http://squac.iti.upv.es/glosario-calidad/

LdER dEL PROGRAMA AdSI Vanessa Cristina Miranda Canovanessa24@misena.edu.co

COMPILACIN Y PREPARACINCsar Marino Cullar ChacnVanessa Cristina Miranda Cano

ASESORA PEdAGGICA Claudia Herrera Cifuentes pipelore@yahoo.com

LdER LNEA dE PROdUCCINIliana Eneth Molina Cuartailmocu@sena.edu.co

dISEO EdITORIAL Y PORTAdARicardo Burbano Martnezribuma@gmail.com

ILUSTRACIN PORTAdASal Suazassuaza@gmail.com

dIAGRAMACINCoproduccinLnea de Produccin - Regional Santander

Ricardo Burbano Martnezribuma@gmail.com