engenharia de requisitos

Engenharia de Requisitos

Equipe

• Amilton Luiz

• Hugo Magalhães

• Lucas Fábio

• Márcia Maria

• Rhaissa Santos

• Rodrigo Venâncio

• Tamires Guedes

Engenharia de requisitos

• Processo que engloba todas as atividades que contribuempara a produção de um documento de requisitos e suamanutenção ao longo do tempo


• Fases

• identificação;

• análise e negociação;

• especificação e documentação;

• validação.

• Antes dessas fases:

• estudos de viabilidade que, a partir das restrições doprojeto, determinam se este é ou não viável e se deve prosseguirpara a identificação dos requisitos


Análise de Viabilidade

IdentificaçãoAnálise e

negociação

Especificação e documentação

ValidaçãoGestão

Estudo de viabilidade

• Será que o sistema contribui para os objetivos da organização?

• Dadas as restrições tecnológicas, organizacionais(econômicas, políticas, ambientais, recursos disponíveis) etemporais associadas ao projeto, será que o sistema pode serimplementado?

• Caso haja necessidade de integração entre diferentessistemas, será que esta é possível?


• Se o novo sistema não fosse implementado, quais seriam asalternativas para a organização?

• Quais são os problemas que os sistemas atuais apresentam ecomo é que um sistema novo irá resolver estas falhas?

• De que forma é que o sistema irá contribuir diretamente paraos objetivos da organização?

• É possível a integração com os outros sistemas da organização(de um ponto de vista tecnológico)? Com que facilidade é quese consegue partilhar informação entre estes sistemas?


• O estudo de viabilidade deverá culminar com a produção deum relatório e deverá determinar a continuação dodesenvolvimento do projeto, tornando mais claras asrestrições (econômicas, temporais e organizacionais) doprojeto e definindo mesmo alguns requisitos de alto nível.

Identificação

• Atividades desta fase:

• Compreensão do domínio: é muito importante para o analistacompreender o domínio no qual a organização e o projeto seinserem; quanto maior for o conhecimento acerca dodomínio, mais eficaz será a comunicação entre o analista e aspartes interessadas.

• Identificação das partes interessadas: estes já deverão ter sidoidentificados nos estudos de viabilidade, porém para efeitos deidentificação de requisitos convém concentrar as atenções nosusuários do sistema.

Identificação

• Atividades dessa fase

• Captura: consiste na obtenção com o cliente dos requisitos(funcionais e não-funcionais) pretendidos para o sistema.

• Identificação e análise de problemas: os problemas devem seridentificados (e a sua definição deve ser consensual) e devem serpropostas soluções em conjunto com as partes interessadas.

Identificação

• Técnicas

• Entrevistas

• Questionários

• Workshops (reuniões)

• Cenários (série de eventos hipotéticos)

• Prototipagem

• Estudo etnográfico (observação direta)

Análise e Negociação de Requisitos• Atividades dessa fase:

• classificação: agrupamento de requisitos em "módulos" parafacilitar a visão global do funcionamento pretendido para osistema;

• resolução de conflitos: dada a multiplicidade e diversidade depapéis das partes interessadas envolvidas na captura e análise derequisitos, é inevitável a existência de conflitos nos requisitosidentificados; é importante resolver estes conflitos o mais brevepossível;

Análise e Negociação de Requisitos• Atividades dessa fase

• priorização: consiste na atribuição de uma "prioridade" a cadarequisito (por exemplo elevada/média/baixa); obviamente, estepode ser um fator gerador de conflitos;

• confirmação: é confirmada com as partes interessadas acompletude dos requisitos, sua consistência e validade (deacordo com o que se pretende do sistema).

Análise e Negociação de Requisitos• Cuidados necessários às negociações:

• saber lidar com ataques pessoais (evitando-os sempre quepossível, remetendo a sua resolução para mais tarde, fora dereunião), de preferência nunca tomando partidos;

• fomentar a justificação das posições (negativas) tomadas pelosintervenientes na negociação;

Análise e Negociação de Requisitos• Cuidados necessários às negociações:

• salientar (e procurar encontrar) os benefícios que uma soluçãoapresenta para todos os envolvidos;

• relaxar restrições, quando se torna óbvio que as atuais nãolevarão a um consenso.

Especificação e Documentação

• Produção propriamente dita do Documento de Especificaçãode Requisitos

• Tipos de requisitos:

• Funcionais

• Não-funcionais

• Tipos de especificação:

• Especificação de requisitos do usuário ou utilizador;

• Especificação de requisitos do sistema;

• Especificação do design da aplicação.


• Requisitos Funcionais: descrevem as funcionalidades que seespera que o sistema disponibilize, de uma forma completa econsistente. É aquilo que o utilizador espera que o sistemaofereça, atendendo aos propósitos para qual o sistema serádesenvolvido.


• Requisitos Não-funcionais: referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistemadeve operar ou propriedades emergentes do sistema.Costumam ser divididos em Requisitos não-funcionais de:Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.


• O Documento de Especificação de Requisitos inclui umacombinação dos requisitos do utilizador e do sistema e temdiferentes utilidades para diferentes pessoas:

• Clientes: confirmar a completude dos requisitos e proporalterações.

• Gestores: orçamentar o sistema e planejar o processo dedesenvolvimento.

• Engenheiros: compreender o sistema a desenvolver.

• Engenheiros (testes): desenvolver testes para validar ocumprimento dos requisitos.

• Engenheiros (manutenção): compreender o sistema e a ligaçãoentre as suas partes.


• Modelos:

IEEE

http://standards.ieee.org/findstds/standard/830-1993.html

Aida

https://sites.google.com/site/professoraaidaferreira/engenharia-de-software-iii/modelos/ESOO_requisitos.doc?attredirects=0&d=1











Validação

• Objetivo: demonstrar que o documento de requisitosproduzido corresponde, de fato, ao sistema que o clientepretende

• Pretende-se encontrar problemas/conflitos naespecificação, porém ao contrário das fases anteriores estafase lida com uma especificação completa dos requisitos.

Validação

• Atributos que DEVEM ser observados na validação:

• Validade: a especificação resulta da análise dos requisitosidentificados junto das diversas partes interessadas envolvidas.Como tal, requisitos identificados individualmente (isto é, juntode cada parte interessada) podem diferir da especificação finalque se atinge após o cruzamento de informação e é necessárioque cada cliente compreenda e aceite a especificação finalobtida.

• Consistência: não devem existir conflitos entre os requisitosidentificados.

Validação


• Compreensibilidade / Ambiguidade: os requisitos devem poderser compreendidos de forma inequívoca pelas partesinteressadas.

• Completude: todas as funcionalidades pretendidas devem fazerparte da especificação do sistema.

• Realismo: dadas as restrições do projeto(tecnológicas, financeiras e temporais) o sistema especificadotem de ser implementável.

Validação


• Verificabilidade: de forma a evitar futuras discordâncias quanto àconcretização dos requisitos especificados, estes devem serdescritos de modo a que seja possível verificar se foram ou nãoconcretizados, isto é, se o sistema final corresponde àespecificação inicial.

• Rastreabilidade: a origem dos requisitos, em relação aocliente, deve estar claramente identificada. Entre outrosmotivos, isto é importante para facilitar a gestão futura dosrequisitos.

Validação


• Conformidade com normas: para além dos aspectos funcionaisdos requisitos, a sua especificação deve obedecer às normasusadas ao longo de todo o documento.

Validação

• Técnicas

• Revisão de Requisitos

• Prototipificação

• Geração de casos de teste

• Análise de consistência automática

Gestão de Requisitos

• Devem estar definidas desde o início da gestão de requisitospolíticas para:• Identificação de requisitos: identificação unívoca em especial

para facilitar a rastreabilidade.

• Processo de gestão de mudanças a utilizar: conjunto deatividades que permitem avaliar o custo e impacto dasalterações.

• Rastreabilidade: relações entre os requisitos e relações entrerequisitos e design; estas podem precisar de manter associada acada requisito informação como a parte interessada que apropôs, dependências de outros requisitos e associação amódulos específicos do design do sistema.

• Ferramentas a utilizar: para sistemas grandes, a quantidade deinformação a processar pode ser elevada, sendo o usode ferramentas CASE aconselhado.

Gestão de Requisitos

• Para manter a consistência entre as várias alterações pedidas(e para estas serem feitas de um modo controlado), éimportante que o processo de gestão de mudanças estejadefinido de um modo formal

Referências

• Soares (2005). Introdução, Identificação e Análise emEngenharia de Requisitos. António Lucas Soares. 2005.

• Kotonya e Sommerville (1998). Requirements Engineering:Processes and Techniques. Gerald Kotonya, Ian Sommerville.Wiley. 1998.

• Thayer e Dorfman (1993). Software RequirementsEngineering. R. H. Thayer, M. Dorfman. IEEE Computer SocietyPress. 1993.

• Sommerville (2001). Software Engineering. Ian Sommerville.Addison Wesley. 2001.

engenharia de requisitos

Documents