Engenharia de Software Requisitos de Software

Fernanda Campos Aula 10

Designaes equivalentes

descoberta de requisitos identificao de requisitos "elicitao" de requisitos captura de requisitos aquisio de requisitos levantamento de requisitos

Requisitos

Processo de Engenharia de Requisitos: modelo de actividades de alto nvel

identificao , descoberta de requisitos
documento de requisitos

anlise e negociao de requisitos especificao, documentao de requisitos

validao de requisitos

necessidades dos usurios, sistemas legados, informao do domnio, normas organizacionais, etc.

Processo de engenharia de requisitos: modelo em espiral

(Kotonya e Sommerville, 1998; SWEBOK)

Dimenses da descoberta de requisitos

conhecimento geral do domnio

compreender o domnio de aplicao compreender as necessidades e restries dos interessados

que actividades devem ser suportadas pelo sistema? qual o papel de sistemas existentes? etc.

estende e especializa conhecimento geral do domnio

compreender o problema a ser resolvido

compreender o contexto de negcio

como que o sistema contribui para os objectivos do negcio? etc.
Kotonya, 1998

Requisitos do usurio, do sistema e do software

Definio e especificao

Interessados nos requisitos

Problemas comuns

Fontes de requisitos

objectivos gerais de alto nvel do sistema

objectivos gerais de alto nvel do sistema, problema que o sistema deve resolver, motivao para a implementao do sistema, factores crticos de sucesso, interesse para o negcio, ... necessrio avaliar custos e benefcios de atingir os objectivos, por exemplo com estudo de viabilidade necessrio para inferir conhecimento tcito que os stakeholders no explicitam, avaliar trade-offs entre requisitos conflituosos, etc. pode ser obtido junto de especialistas do domnio, documentos, etc. fundamental identificar, representar e gerir os pontos de vista, interesses e necessidades de todos os interessados no sistema (usurios, clientes, etc.)

conhecimento do domnio de aplicao

stakeholders do sistema

Fontes de requisitos

ambiente operacional

o ambiente operacional em que o sistema vai executar pode impor diversos requisitos

aproveitamento de infra-estruturas fsicas e lgicas existentes interoperabilidade com sistemas existentes (internos ou externos) etc.

ambiente organizacional

muitos sistemas destinam-se a suportar processos de negcio, devendo-se adequar estrutura, cultura, polticas, regras e normas internas da organizao (intra/inter) normas, regulamentos, legislao, etc. podem impor requisitos exemplos: lei de proteco de dados pessoais, normas de acessibilidade, ...

ambiente externo

Produtos e sistemas existentes como fontes de requisitos

produtos de mercado produtos concorrentes

quando se desenvolve um produto para um mercado,

solues candidatas

necessrio posicion-lo e diferenci-lo em relao aos produtos existentes por vezes compatibilidade com produtos concorrentes uma vantagem por vezes pretende-se copiar as funcionalidades de um produto existente (exemplo: open office)

quando se pretende adquirir um produto de mercado,

conveniente formular os requisitos em termos que facilitem a anlise de adequao das solues existentes no mercado

sistemas e produtos internos interoperabilidade com sistemas existentes substituio ou evoluo de sistemas existentes

Como descrever requisitos?

Requisitos funcionais

Requisitos no funcionais

Tipos de requisitos no funcionais

Requisitos no funcionais e mtricas

Engenharia de requisitos

Engenharia de requisitos

Processo de Engenharia de Requisitos

Estudo da Viabilidade

Levantamento de requisitos

Tcnicas de descoberta de requisitos

anlise de documentao anlise de sistemas existentes entrevistas encontros facilitados (workshops, brainstorming) cenrios prottipos observao e anlise social, estudos etnogrficos soft systems methods reutilizao de requisitos

Anlise de requisitos

Descrio dos requisitos

Verificao e validao de requisitos

Abordagens para levantamento/ anlise/especificao

Anlise de documentao

sobre o domnio da aplicao sobre o organizao sobre a legislao sobre sistemas existentes ...

Anlise de sistemas existentes

sempre sistemas existentes so fontes de requisitos

Entrevista

entrevistar os futuros usurios e outros stakeholders a tcnica mais vulgar e simples de obter informao para identificar requisitos

Entrevista

a entrevista uma tcnica simples, mas no fcil de aplicar

enviesamento do entrevistador predisposio do entrevistado relao pessoal

Entrevista

tipos de entrevistas

estruturadas vs. no estruturadas descontextualizadas vs. contextualizadas pela

soluo

Workshop

uma workshop de requisitos uma tcnica de grupo para o debate e acordo das questes asociadas identificao dos requisitos

levada a cabo atravs da formao de um

grupo de representantes dos stakeholders facilitada por algum com competncia para conduzir o processo de identificao e anlise de requisitos

Workshop

preparao

"vender" o conceito assegurar a participao dos stakeholders

adequados garantir os aspectos logsticos fornecer materiais para discusso antecipadamente escolher o facilitador estabelecer uma agenda

Workshop

conduo

"soltem os ces"... brainstorming produo de documentos e continuao

Brainstorming

brainstorming uma tcnica para a gerao de novas ideias por um conjuto de pessoas

encoraja a participao de todos permite o aproveitamento e refinamento de outras

ideias pode ser bastante produtiva (n de idias/hora) o resultado pode ser um conjunto de solues encoraja o pensamento livre... (maluquices...)

Brainstorming

regras do brainstorming

no permitir crticas ou debate deixar a imaginao voar... gerar tantas ideias quanto for possvel mutar e combinar ideias

Brainstorming: processo
definir objectivos explicar as regras gerar e documentar ideias reduzir ideias

Brainstorming: reduzir ideias

"podar" idias agrupar idias definir as caractersticas de cada idia estabelecer prioridades

Cenrio

abordagem para colocar os interessados num sistema perante uma situao realista em que simulam ou apenas antevem a sua interaco com o sistema

materializam-se em histrias que explicam

como que o sistema poder ser usado

Cenrio: objectivos

identificar e clarificar requisitos

adicionar detalhes a requisitos mais gerais compreender a relao entre requisitos compreender um requisito no seu contexto de
utilizao verificar se a sua relao com outros requisitos faz sentido

validar requisitos

cenrios versus casos de uso

Existem diferentes opinies sobre a relao existente entre casos de uso e cenrios: H quem os considere sinnimos H quem considere que um cenrio corresponde a um conjunto de

casos de uso (fluxo normal de eventos, e cada fluxo excepcional seriam casos de uso separados) H quem considere que um caso de uso corresponde a um conjunto de cenrios

Em UML, um caso de uso admite variantes, podendo-se considerar cada variante como um cenrio Cada cenrio pode ser representado por um diagrama de interaco (normalmente um diagrama de sequncia)

Observao e anlise social

grande parte dos sistemas que desenvolvemos visam apoiar o trabalho das pessoas
o trabalho uma atividade social que envolve grupos de pessoas que cooperam para levar a cabo diferentes tarefas

Observao e anlise social

as pessoas encontram frequentemente dificuldade em tornar explcita a forma como realizam tarefas e como trabalham em conjunto com outros
quando as tarefas se tornam rotina e as pessoas tendem a no pensar nelas conscientemente, torna-se difcil que articulem como que o trabalho realizado

as pessoas usam artefactos (ferramentas, documentos, etc.) de uma forma intuitiva

Observao e anlise social

estudos etnogrficos

observao detalhada das prticas sociais de

uma sociedade uma compreenso total destas prticas s possvel pela observao do detalhe e a partir do interior da comunidade um grupo de funcionrios numa biblioteca, num banco, num laboratrio tm caractersticas dos elementos de uma sociedade

Observao e anlise social

estudos etnogrficos e identificao de requisitos

atravs das tcnicas convencionais os estudos etnogrficos ajudam a fazer emergir requisitos derivados de formas rotineiras e tcitas de trabalhar

h requisitos que no se conseguem identificar

Prototipagem

um prottipo uma verso inicial de um sistema usada para apoiar essencialmente as fases de identificao, anlise e validao de requisitos

Prototipagem

caractersticas

desenvolvimento rpido funcionalidades limitadas requisitos no funcionais pouco considerados vrias tecnologias pode ir desde maquetas a prottipos
evolutivos

Prototipagem: tipos

protipagem descartvel (throw away) o objectivo o apoio identificao dos requisitos os requisitos objecto de prototipagem devero ser aqueles
mais difceis de compreender pelos stakeholders

prototipagem evolutiva o objectivo proporcionar um sistema "produtivo" o mais

rpido possvel ao cliente os requisitos objecto dos prottipos iniciais devero ser aqueles mais facilmente compreendidos e que podem dar rapidamente um valor acrescentado til ao utilizador

prototipagem: benefcios

benefcio principal

os clientes e usurios finais tm contacto com um sistema realista cedo o que lhes permite compreender melhor os requisitos que pretendem identificar e analisar ajuda a estabelecer a viabilidade e utilidade do sistema a nica forma efectiva de desenvolver o prottipo pode ser usado na validao o estudo cuidadoso dos requisitos ajuda a revelar inconsistncias e lacunas

outros benefcios

Prototipagem: custos

a deciso de usar a prototipagem deve ser tomada com recurso a uma anlise custo-benefcio
custos envolvidos na prototipagem
alargados, prottipos incompletos

formao, desenvolvimento, prazos mais

Reutilizao de requisitos

Envolve pegar nos requisitos que foram desenvolvidos para um sistema e us-los num sistema diferente Poupa tempo e esforo, pois os requisitos reutilizados j foram analisados e validados noutros sistemas correntemente um processo informal, mas a reutilizao mais sistemtica poderia conduzir a poupanas maiores Grau de reutilizao pode chegar a 50%

Algumas possibilidades de reutilizao

requisitos que tm a ver com o domnio de aplicao exemplo no domnio da hotelaria: um quarto no pode ser vendido a dois clientes diferentes para a mesma data podem ser requisitos comuns a uma famlia / linha de produtos / aplicaes / sistemas requisitos que tm a ver com o estilo de apresentao da informao garantir consistncia de estilo entre aplicaes requisitos que reflectem polticas da organizao, como por exemplo polticas de segurana

exemplo: cifrar dados pessoais

Engenharia de requisitos orientada a pontos de vista

a engenharia de requisitos envolve capturar, analisar, conciliar e integrar diferentes pontos de vista sobre o sistema em causa cada ponto de vista pode referir-se a todo o sistema ou a uma parte do sistema a cada ponto de vista corresponde uma vista do sistema ou parte do sistema na descoberta de requisitos, preocupamo-nos em capturar os diferentes pontos de vista sobre o sistema

Pontos de vista diretos e indiretos

Pontos de vista directos

Interagem diretamente com o sistema pretendido Recebem servios do sistema ou fornecem informao de controlo Incluem operadores/usurios e outros sistemas com os quais o sistema em causa interage No interagem diretamente com o sistema Tm um interesse em alguns ou todos os servios que so fornecidos pelo sistema Geram requisitos que restringem os servios que so entregues aos pontos de vista diretos Incluem a organizao, entidades do ambiente envolvente, engenheiros que intervm na construo ou manuteno do sistema, entidades reguladores, etc.

Pontos de vista indirectos

Exemplos de pontos de vista diretos e indiretos

Num sistema de gesto de bibliotecas:

Ponto de vista da gesto da biblioteca, preocupado com os servios prestados pela biblioteca (indireto) Ponto de vista do atendimento da biblioteca, preocupado em atender os usurios usando servios do sistema (direto) Ponto de vista do usurio da biblioteca, que est preocupado com acesso aos servios do sistema atravs da Internet (direto) Ponto de vista sindical, que est preocupado com os efeitos da introduo do sistema no nvel da ocupao e deveres dos trabalhadores (indireto) Ponto de vista das leis de proteo de direitos de autor, que probem digitalizar livros (indireto)

Pontos de vista, stakeholders e fontes de requisitos

noo de ponto de vista mais genrica (e polivalente) do que a de stakeholder noo de ponto de vista mais prxima da noo de fonte de requisitos

inclui stakeholders podem existir fontes de requisitos que no so stakeholders

noo de ponto de vista tambm pode ser aplicada para se referir a

um sub-sistema funcional (exemplo: ponto de vista da aquisio de livros para a biblioteca) um aspecto transversal do sistema (exemplo: ponto de vista da segurana)

Gerenciamento de requisitos

Processo de levantamento/anlise/ especificao/validao

Documentao

Documento de requisitos da IEEE