Engenharia de requisitos
Transferir como PPTX, PDF0 gostou1,282 visualizações
O documento apresenta os conceitos e processos da engenharia de requisitos, incluindo suas fases (identificação, análise e negociação, especificação e documentação e validação), técnicas e atividades em cada fase, e a importância da gestão de requisitos.
Engenharia de requisitos
- 2. Equipe • Amilton Luiz • Hugo Magalhães • Lucas Fábio • Márcia Maria • Rhaissa Santos • Rodrigo Venâncio • Tamires Guedes
- 3. Engenharia de requisitos • Processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo
- 4. Engenharia de requisitos • 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 do projeto, determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos
- 5. Engenharia de requisitos Análise de Viabilidade Identificação Análise e negociação Especificação e documentação ValidaçãoGestão
- 6. 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) e temporais associadas ao projeto, será que o sistema pode ser implementado? • Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?
- 7. Estudo de viabilidade • Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização? • Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas? • De que forma é que o sistema irá contribuir diretamente para os 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 é que se consegue partilhar informação entre estes sistemas?
- 8. Estudo de viabilidade • O estudo de viabilidade deverá culminar com a produção de um relatório e deverá determinar a continuação do desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projeto e definindo mesmo alguns requisitos de alto nível.
- 9. Identificação • Atividades desta fase: • Compreensão do domínio: é muito importante para o analista compreender o domínio no qual a organização e o projeto se inserem; quanto maior for o conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista e as partes interessadas. • Identificação das partes interessadas: estes já deverão ter sido identificados nos estudos de viabilidade, porém para efeitos de identificação de requisitos convém concentrar as atenções nos usuários do sistema.
- 10. 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 ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas.
- 11. 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)
- 12. Análise e Negociação de Requisitos • Atividades dessa fase: • classificação: agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento pretendido para o sistema; • resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes conflitos o mais breve possível;
- 13. Análise e Negociação de Requisitos • Atividades dessa fase • priorização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa); obviamente, este pode ser um fator gerador de conflitos; • confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade (de acordo com o que se pretende do sistema).
- 14. Análise e Negociação de Requisitos • Cuidados necessários às negociações: • saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua resolução para mais tarde, fora de reunião), de preferência nunca tomando partidos; • fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação;
- 15. Análise e Negociação de Requisitos • Cuidados necessários às negociações: • salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envolvidos; • relaxar restrições, quando se torna óbvio que as atuais não levarão a um consenso.
- 16. Especificação e Documentação • Produção propriamente dita do Documento de Especificação de 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.
- 17. Especificação e Documentação • Requisitos Funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido.
- 18. Especificação e Documentação • Requisitos Não-funcionais: referem-se a aspectos não- funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.
- 19. Especificação e Documentação • O Documento de Especificação de Requisitos inclui uma combinação dos requisitos do utilizador e do sistema e tem diferentes utilidades para diferentes pessoas: • Clientes: confirmar a completude dos requisitos e propor alterações. • Gestores: orçamentar o sistema e planejar o processo de desenvolvimento. • Engenheiros: compreender o sistema a desenvolver. • Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos. • Engenheiros (manutenção): compreender o sistema e a ligação entre as suas partes.
- 20. Especificação e Documentação • 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
- 21. Validação • Objetivo: demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende • Pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos.
- 22. Validação • Atributos que DEVEM ser observados na validação: • Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especificação final obtida. • Consistência: não devem existir conflitos entre os requisitos identificados.
- 23. Validação • Atributos que DEVEM ser observados na validação: • Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas. • Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema. • Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável.
- 24. Validação • Atributos que DEVEM ser observados na validação: • Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial. • Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos.
- 25. Validação • Atributos que DEVEM ser observados na validação: • Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especificação deve obedecer às normas usadas ao longo de todo o documento.
- 26. Validação • Técnicas • Revisão de Requisitos • Prototipificação • Geração de casos de teste • Análise de consistência automática
- 27. Gestão de Requisitos • Devem estar definidas desde o início da gestão de requisitos polí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 de atividades que permitem avaliar o custo e impacto das alterações. • Rastreabilidade: relações entre os requisitos e relações entre requisitos e design; estas podem precisar de manter associada a cada requisito informação como a parte interessada que a propôs, dependências de outros requisitos e associação a módulos específicos do design do sistema. • Ferramentas a utilizar: para sistemas grandes, a quantidade de informação a processar pode ser elevada, sendo o uso de ferramentas CASE aconselhado.
- 28. 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 esteja definido de um modo formal
- 29. Referências • Soares (2005). Introdução, Identificação e Análise em Engenharia 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 Requirements Engineering. R. H. Thayer, M. Dorfman. IEEE Computer Society Press. 1993. • Sommerville (2001). Software Engineering. Ian Sommerville. Addison Wesley. 2001.