ENGENHARIA DE REQUISITOS E O UP

ENGENHARIA DE REQUISITOS E O UP

A engenharia de software se produz através de um con-

junto de fases. Cada uma das fases pode envolver métodos,

ferramentas e procedimentos, cujas formas de estruturação

são citadas como modelo de engenharia de software (PRES-

SMAN, 2002). Ainda segundo Pressman (2002), indepen-

dentemente do modelo de desenvolvimento de software, o

processo contém três fases genéricas: defi nição, desenvol-

vimento e manutenção.

Quatro modelos de engenharia de software têm sido am-

plamente discutidos: o ciclo de vida clássico (ou cascata),

a prototipação, o modelo espiral e as técnicas de Quarta

Geração (PRESSMAN, 2002). Atualmente um novo modelo

tem sido bastante usado: o modelo iterativo e incremental

(JACOBSON; BOOCH; RUMBAUGH, 1999; PAULA

FILHO, 2001).

A análise de requisitos é uma etapa presente na fase

de defi nição do software, independentemente do modelo

de engenharia de software adotado. Paula Filho (2001)

afi rma que a engenharia de requisitos é formada por um

conjunto de técnicas empregadas para levantar, detalhar,

documentar e validar os requisitos de um produto de soft-

ware. Assim, é possível defi nir a engenharia de requisitos

como um campo da engenharia de software que visa a

aplicação de técnicas de engenharia em métodos de análise

de requisitos, que efetua a ligação entre a necessidade de

informatização de processos e o projeto do software que

atenderá a tais necessidades.

No decorrer das duas últimas décadas, uma série de méto-

dos de análise e especifi cação de requisitos foi desenvolvida,

sendo poucas as propostas que visam a sistematização da

defi nição de requisitos de forma menos subjetiva (SAN-

TANDER, 2002).

O UP (Processo Unifi cado) é um processo estabelecido

para o desenvolvimento de software resultado de três déca-

das de desenvolvimento e de uso prático. Jacobson, Booch

e Rumbaugh (1999) apresentam as origens do UP no pro-

cesso Objectory, que teve sua primeira versão apresentada

em 1987, passando pelas contribuições do Processo Ra-

tional Objectory (1997), até chegar ao Processo Unifi cado

da Rational – RUP (KRUCHTEN, 2003). O propósito do

UP, como qualquer outro processo de desenvolvimento,

é determinar um conjunto de atividades necessárias para

transformar requisitos em sistemas de software. Neste

vida de software do UP é dividido em quatro fases seqüen-

ciais (Concepção, Elaboração, Construção e Transição),

sendo que cada fase refere-se a uma determinada meta a

ser atingida ao longo do desenvolvimento.

Cada uma das quatro fases do UP é adicionalmente

dividida em iterações e fi nalizada com um ponto de

checagem que verifi ca se os objetivos daquela fase fo-

ram alcançados. Toda iteração é organizada em termos

de workflows