Aula 8 texto

PROF. HORACIO

Disciplina: REQUISITOS DE SISTEMAS Aula 08: VALIDAÇÃO DE REQUISITOS Introdução da aula Em continuidade aos conteúdos sobre a engenharia de requisitos, detalharemos sobre o terceiro dos quatros tópicos que começamos nas aulas 6 e 7. Hoje a foco será sobre a elicitação de requisitos, destacando a importância no resultado de um software que atenda as necessidades dos usuários.

Uma validação tem um comportamento de uma área de staff, ou seja, é um etapa de apoio que serve para averiguar e comprovar o que fora previamente estabelecido. No tocante a engenharia de requisitos, através de estratégias de testes e de evidências da atividade de validação, tem por objetivo apurar que as especificações do software estão de acordo com as necessidades e usos pretendidos pelo usuário, portanto os resultados a serem apurados estarão consistentes.

O processo de validação de requisitos é também uma fase importante na elaboração de um documento de requisitos. Mesmo atendendo as etapas de elicitação, pode incorrer que erros passem despercebidos na etapa, pode criar certos problemas quando esses erros forem detectados numa fase posterior, ou seja, o documento de requisitos já terá sido validado pelo cliente.

Livro

SOMMERVILLE, I., Engenharia de Software, 9ª Edição. Pearson, 2011. Capítulo 4: Engenharia de Requisitos.

Seja bem-vindo a terceira etapa das nossas aulas sobre as atividades da área de requisitos.

Continuaremos imersos nos conteúdos sobre a engenharia de requisitos; nossa aula de hoje trabalhar sobre a validação de requisitos, destacando a importância no resultado de um software que atenda as necessidades dos usuários.

Revisando sobre as quatro atividades da área de engenharia de requisitos (principalmente se precisa revisar algum assunto), veja ordem abaixo: Aula 6 - Viabilidade.

PROF. HORACIO Aula 7 – Elicitação.

Aula 8 – Validação.

Aula 9 – Gerenciamento.

Estas atividades fazem parte do que definimos como processo de engenharia de requisito. Lembre-se que não temos um comportamento e necessidade uniforme na área de software. Quando decidimos construir um sistema, certamente temos uma necessidade e um perfil que nos torna único, portanto, “em praticamente todos os sistemas os requisitos mudam.” (Sommerville, 2009). Com base nesse cenário, tornar-se necessário então a padronização o procedimento, para ter maior convicção da acertabilidade do que está sendo desenvolvido.

Portanto, caso tenha o desejo em atuar na área de projetos, certamente lhe será requerido conhecer bem sobre as atividades inerentes a engenharia de requisitos, no tocante a entender o real problema do seu cliente. Tendo em mãos essa importante informação, terás grandes possibilidades de um resultado mais apurado e correto. Faça um bom proveito!

Vamos lá!

PROF. HORACIO

O processo de validação de requisitos é também uma fase importante na elaboração de um documento de requisitos. Mesmo atendendo as etapas de elicitação, pode incorrer que erros passem despercebidos na etapa, pode criar certos problemas quando esses erros forem detectados numa fase posterior , ou

seja, o documento de requisitos já terá sido validado pelo cliente.

Na etapa de elicitação aprendemos que vamos levantar e evidenciar o requisito. Agora, vamos DEMONSTRAR que conseguimos compreender e definir bem as características a serem incorporadas no software. Para este momento, o contatado é quem assume o papel principal, sendo o foco da comunicação; o contratante acompanha e avalia.

Esse processo da engenharia de requisitos trata em especial dos critérios relacionados à consistência, precisão, contextualização de requisitos levantados no processo de identificação e descoberta e de análise e negociação de requisitos.

Segue uma relação de propriedades que são avaliadas no tocante ao documento de requisitos de software pela equipe responsável na validação: 1. Completude e consistência 2. Conformidade com os padrões 3. Conflitos de requisitos 4. Erros técnicos 5. Requisitos ambíguos Sommerville (Engenharia de Software, 2009) destaca que “o custo para consertar um problema de requisitos por meio de uma mudança no sistema é geralmente muito maior do que o custo para consertar erros de projetos ou codificação. A razão para isso é que a ocorrência de mudança dos requisitos normalmente significa que o projeto e a implementação do sistema devem ser alterados.”

Daí então a característica crítica nessa atividade, e o destaque como sendo um dos mais importantes na engenharia de requisitos. Tendo em visto que um documento de requisitos bem definido permite aos envolvidos atuar de maneira consistente nas incoerências e inconformidades no desenvolvimento de um produto de software. Perceba que também o contexto da validação nos permite a identificação destas mesmas incoerências na fase anterior à versão final do relatório de requisitos, o que proporciona um nível de acerto maior, e minimiza consideravelmente uma detecção vindoura destas incoerências numa fase posterior, ou, pior ainda, até mesmo na finalização do sistema.

PROF. HORACIO Sommerville (Engenharia de Software, 2009) enfatiza ser possível afirmar que o processo de validação de requisitos está para o documento de requisitos assim como a fase de testes unitários e de sistema está para a fase de desenvolvimento de um projecto de software. É encontrado e provado pela literatura que detectar um erro em fases finalistas de um projeto, pode chegar a ser danoso a ponto de incompatibilizar a continuidade, visto que pode ser tão custosa que não existe recursos para comportá-la. Por isso, a atenção deve ser constante e minuciosa.

São exemplos dos problemas que o processo de validação pode solucionar:  Não conforme as normas de qualidade do projeto e da empresa.  Descrição pouco clara dos requisitos.  Ambiguidade entre requisitos.  Falhas na modelagem dos requisitos.  Conflitos entre requisitos.  Requisitos não realistas.  Ausência de informação.

Na figura abaixo, segue uma síntese no tocante aos insumos e produtos gerados pela atividade da validação de requisitos.

Fonte: http://www.cin.ufpe.br/~if119/aulas/cap4.PDF

A partir da compreensão do que na figura acima está disposto, claramente conseguimos ter a percepção de um sistema da informação, contendo: entrada, processamento e saída. Com base nesse modelo, então

PROF. HORACIO define-se que o processo de validação de requisitos têm como entrada o arcabouço oriundo dos processo de: (a) análise e elicitação de requisitos; (b) das normas de qualidade da organização; (c) conhecimento empírico obtido contido na empresa, principalmente vindo de outros projetos ou de skateholders experientes no assunto. Na etapa de processamento temos a validação dos requisitos, que gera como saída uma lista de problemas que devem ser resolvidos e ações que são combinadas.

Passaremos então a estudar sobre as técnicas existentes para o processo de validação.

Técnicas no Processo de Validação

Revisão dos Requisitos É uma técnica, como o nome já sugere, a qual são analisados e revisados sistematicamente todos os requisitos elicitados, executando um checagem no tocante a erros e inconsistências. É uma boa prática para esta técnica uma reunião formal com representantes ou especialistas de todas as áreas, tanto do contratante como do contratado. Portanto, todas as equipes deverão ter representação.

São recomendadas as seguintes providências: 1. Planejamento do que será revisado.

2. Estabelecer e convidar os envolvidos.

3. Definir local e tempo para a reunião.

4. Escolher para condução alguém “livre de vícios”, ou seja, que não estava integrado à equipe desenvolveu o documento de requisito.

5. Realizar procedimento de checklists para os requisitos e nas relações entre eles.

6. Distribuir previamente todos os documentos a serem utilizados na reunião.

7. Apresentar cada requisitos individualmente.

8. Discutir e anotar comentários para cada requisito que apresenta erro ou inconsistência.

9. Estabelecer um período de soluções após todo o término dos relatos apurados nas análises.

10. Apurar a qualidade final do documento de requisitos.

No tocante ao item 10, segue na tabela abaixo questões e respectivos atributos de qualidade que devem ser considerados na apuração Questões Questões atributo de qualidade

Atributo de Qualidade rastreabilidade, conformidade com

PROF. HORACIO

normas Os termos especializados aparecem no glossário

compreensibilidade

O requisito depende de outros para se compreender o seu significado? compreensibilidade, completude Há requisitos que usam omesmo termo com senti dos diferentes?

O mesmo serviço é solicitado em vários requisitos? Há contradições nestas solicitações?

Se os requisitos fazem referência a outras facilidade, isso está descrito algures no documento?

Os requisitos relacionados estão agrupados? Se não como se referenciam mutuamente?

ambiguidade consistência, redundância completude organização, rastreabilidade

(Fonte: http://pt.wikipedia.org/wiki/Valida%C3%A7%C3%A3o_de_requisitos): Prototipagem A fim de estabelecer uma demonstração mais didática sobre o projeto, desenvolve-se um protótipo para que os stakeholders possam compreender de maneira mais exata o funcionamento do sistema. “Nessa abordagem para avaliação, um modelo executável do sistema é demonstrado para os usuários finais e clientes.” (Sommerville, 2009). O objetivo é tornar mais fácil a fase de validação de requisitos, visto que, através da demonstração visual, tornar-se mais intuitivo detectar inconsistências e problemas nos requisitos.

Experientes nessa técnica evidenciam algumas preocupações para sua adoção: 1. A qualidade do protótipo poderá levar a desilusões para os utilizadores finais, visto do ambiente projetado para os testes não ser aprazível aos usuários, principalmente no tocante as telas do sistema (as interfaces).

2. Mediante a anuência do que foi apresentado com teste, incentivar os programadores a uma baixa qualidade nas interfaces 3. O tempo gasto no desenvolvimento do protótipo em detrimento dos prazos estabelecidos para o projeto.

Testes de Requisitos Uma propriedade importante para cada requisito é o de ser testável. Para cada requisito funcional deve ser possível definir um ou mais testes a serem realizados no sistema final para ser possível verificar se o sistema cumpre o requisito na integra. Caso tal propriedade não esteja presente, ou até mesmo se for muito difícil testá-lo; tal circunstância indica a necessidade de uma retificação.

PROF. HORACIO A realidade implica em uma probabilidade considerável para que todo o requisito que não pode ser testado muito provavelmente será instituidor de problemas. Deve-s então reconsiderar a presença deste, buscando por alternativas testáveis.

Então quando da realização dos testes, deve-se tomar nota das características observadas quanto ao requisitos em si (identificador, requisitos relacionados), como aqueles relacionados aos testes (descrição ,

problemas, comentários, recomendações, etc.).