Elicitação de Requisitos

Objetivos

• Descrever o processo da elicitação e análise requisitos.

• Introduzir um número de técnicas elicitação de requisitos e análise de requisitos.

• Discutir como protótipos podem ser usados no processo de ER.

Elicitação de requisitos

• ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão

• Cabe à elicitação a tarefa de identificar os fatos relacionados aos requisitos do Sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado daquele software

Componentes da elicitação de requisitos

Problema a ser resolvido

Domínio da aplicação

Contexto do negócio

Necessidades dos

stakeholders

Atividades da Elicitação

• Entendimento do domínio da aplicação

• O conhecimento do domínio da aplicação é o conhecimento geral onde o sistema será aplicado.

• Entendimento do problema

• Os detalhes dos problemas específicos do problema do cliente onde o sistema será aplicado deve ser entendido.

Atividades da Elicitação

• Entendimento do negócio

• Você de entender como os sistemas interagem e contribuem de forma geral com os objetivos de negócio.

• Entendimento das necessidades e limitações dos stakeholders do sistema

• Você deve entender, em detalhe, as necessidades específicas das pessoas que requerem suporte do sistema no seu trabalho.

Elicitação de Requisitos: Dificuldades • Usuários podem não ter uma idéia precisa do

sistema por eles requerido;

• Usuários têm dificuldades para descrever seu conhecimento sobre o domínio do problema;

• Usuários e analistas têm diferentes pontos de vista do problema (por terem formações diferentes)

• Usuários podem antipatizar com o novo sistema e se negar a participar da elicitação (ou mesmo fornecer informações errôneas).

Bacalá 7

Elicitação, análise e negociação

O processo da elicitação de requisitos

Estágios da Elicitação

Bacalá 10

Definir objetivos

Aquisição de conhecimento do background

Organização do conhecimento

Coletar os requisitos dos stakeholders

Estágios da Elicitação

• Definir objetivos

• Os objetivos organizacionais devem ser estabelecidos incluindo objetivos gerais do negócio, um descrição geral do problema a ser resolvidos porque o sistema é necessário e as limitações do sistema.

• Aquisição de conhecimento do background

• Informação de background do sistema inclui informação acerca da organização onde o sistema será instalado, o domínio de aplicação do sistema e informação acerca de outros sistemas existente

Estágios da Elicitação

• Organização do conhecimento

• A grande quantidade de conhecimento que foi coletada nos estágios anteriores devem ser organizadas e colocadas em ordem.

• Coletar os requisitos dos stakeholders

• Os stakeholders do sistema são consultados para descoberta de seus requisitos.

Algumas técnicas de elicitação

• Entrevistas

• Questionários

• Brainstorm

• Leitura de documentos

• Cenários

• Observações e análise sociais (etnografia)

• Reuso de requisitos

• Prototipação

Entrevistas e questionários

• Defina onde começar

• Sempre pergunte:

• O que? Por que(m)? Como?

• Pergunte o óbvio

• Organize as respostas: durante e depois

• Observe

• Seja humilde, procure aprender!

Brainstorm

• Não pode ter muita gente

• Pessoas com diferentes perfis

• Presença de um facilitador

• Aceite todo tipo de sugestão e filtre depois!

• Evite pensar em detalhes

• Consulte todos

• Dê sugestões

Cenários

• São estórias que explicam como um sistema poderá ser usado.

• São exemplos de sessões de interação que descrevem como o usuário interage com o sistema.

• O termo “caso de uso” ou use case (um caso específico de uso do sistema) é usado às vezes para se referir a um cenário.

Exemplo de cenário: Sistema de livraria virtual • Entre no sistema

• Escolha o comando “pedido de documentos”

• Entre o número de referência do documento pedido

• Selecione um ponto de entrega

• Saia do sistema

Observação e análise social

• As pessoas geralmente acham difícil descrever o que elas fazem. Às vezes, a melhor forma de entender será observá-las no trabalho.

• Etnografia é uma técnica das ciências sociais que se mostrou útil no entendimento dos processos reais realizados nos trabalhos.

• Os processos reais de trabalho geralmente diferem daqueles processos formais descritos.

• Um etnógrafo passa algum tempo observando as pessoas no trabalho e constrói uma imagem de como o trabalho é realizado.

Diretrizes para etnografia

• Procure formas não padronizadas de trabalho.

• Gaste algum tempo conhecendo as pessoas e estabeleça um relacionamento de confiança.

• Tome nota, de forma detalhada, de todas as práticas de trabalho. Analise-as e chegue a uma conclusão a partir delas.

• Combine observação com entrevistas abertas.

• Organize regularmente sessões de relato, onde o etnógrafo fala para pessoas externas ao processo.

• Combine etnografia com outras técnicas de elicitação.

Reuso de requisitos

• Envolve considerar requisitos que foram desenvolvidos para um sistema e usá-los em sistemas diferentes.

• O reuso de requisitos economiza tempo e esforço, pois requisitos reutilizados já foram analisados e validados em outros sistemas.

Prototipação (na Elicitação)

• Um protótipo é uma versão inicial de um sistema que poderá ser usado para experimentação.

• Protótipos são úteis para elicitação de requisitos porque os usuários poderão experimentar o “sistema” e mostrar os pontes fortes e fracos. Eles terão algo concreto para criticar.

• O desenvolvimento rápido dos protótipos é essencial para que eles fiquem disponíveis logo para o processo de elicitação.

Benefícios da prototipação

• O protótipo permite que os usuários experimentem e descubram o que eles realmente necessitam para suportar o trabalho deles

• Estabelece a viabilidade e utilidade antes que altos custos de desenvolvimento tenham sido realizados

• Essencial para desenvolvimento do aspecto look and feel da interface do usuário

• Pode ser usado para teste do sistema e desenvolvimento da documentação

• Força um estudo detalhado dos requisitos, revelando inconsistências e omissões

Análise de requisitos

• O objetivo da análise de requisitos é descobrir problemas, incompletude e inconsistência nos requisitos elicitados.

• Outro objetivo importante da análise de requisitos é descobrir as interações (rastreamento) entre requisitos e informar os conflitos e sobreposições encontrados.

• Os problemas existentes com os requisitos são retornados aos stakeholders para resolvê-los, através de um processo de negociação.

• A análise é intercalada com elicitação, pois problemas são descobertos quando os requisitos são elicitados.

• Uma lista de verificação de problemas (checklist) poderá ser usada para ajudar a análise. Cada requisito poderá ser avaliado contra esta lista.

Análise e negociação de requisitos

Estágios da análise dos requisitos • Checagem da necessidade

• A necessidade dos requisitos é analisada. Em alguns casos, alguns requisitos propostos podem não contribuir para os objetivos de negócio da organização ou para o problema específico tratado pelo sistema.

• Checagem da consistência e completude

• Os requisitos são verificados entre si para determinar consistência e completude. Consistência significa que nenhum requisito deve ser contraditório; completude significa que nenhum serviço (ou limitação) que seja necessário foi esquecido.

Estágios da análise dos requisitos • Checagem da viabilidade

• Os requisitos são verificados para garantir que são viáveis dentro do orçamento e tempo disponível para o desenvolvimento do sistema.

Uso de checklist para análise

• Projeto prematuro

• Os requisitos incluem informação prematura de projeto ou implementação?

• Requisitos combinados

• A descrição do requisito descreve um requisito único ou este pode ser descrito em vários requisitos diferentes?

• Requisitos desnecessários

• O requisito é realmente necessário, ou será que é uma mera adição cosmética ao sistema?

Uso de checklist para análise

• Uso de hardware não padronizado • Os requisitos implicam no uso de uma plataforma de hardware

não padronizada? Para tomar esta decisão, você precisa conhecer os requisitos de plataforma do computador.

• Está de acordo com os objetivos de negócio • O requisito é consistente com os objetivos de negócio definidos

no documento de requisitos?

• Ambiguidade de requisitos • O requisito é ambíguo, isto é, pode ser lido de forma diferente

por pessoas diferentes? Quais são as possibilidades de interpretação dos requisitos?

Uso de checklist para análise

• Realismo dos requisitos

• O requisito é realístico em relação a tecnologia usada para a implementação do sistema?

• Teste dos requisitos

• Podemos testar os requisitos, ou seja, eles foram escritos de tal forma que um engenheiro de teste poderá derivar o teste que mostrará se o sistema satisfaz os requisitos?

Negociação de requisitos

• Problemas nos requisitos são inevitáveis quando um sistema possui muitos stakeholders. Conflitos não são falhas, mas refletem necessidades e prioridades diferentes entre as partes interessadas.

• A negociação de requisitos é o processo de discussão dos conflitos de requisitos e a busca de um compromisso no qual todas as partes interessadas concordem.

Negociação de requisitos

• No planejamento do processo de engenharia de requisitos, é importante deixar tempo para negociação.

• Alcançar um compromisso aceitável pode tomar um tempo considerável.

Estágios da negociação

• Discussão dos requisitos • Os requisitos que foram identificados como problemáticos são

discutidos e os stakeholders envolvidos apresentam seus pontos de vista acerca dos requisitos.

• Priorização dos requisitos • Os requisitos disputados são priorizados para identificar

requisitos críticos e ajudar o processo de tomada de decisão.

• Concordância dos requisitos • Soluções para os problemas dos requisitos são identificadas e um

conjunto de requisitos são acordados. Geralmente isto envolve mudanças em alguns dos requisitos.

Encontros de negociação

• A natureza dos problemas associados com os requisitos são explicados.

• As partes interessadas discutem como o problema poderá ser resolvido.

• São atribuídas prioridades aos requisitos.

• As ações que dizem respeito ao requisito são concordadas. Estas ações podem ser: deletar o requisito, sugerir modificações ao requisito ou elicitar mais informações sobre o requisito.

Documentação de requisitos

• O documento de requisitos é a documentação oficial que descreve os requisitos do sistema

• Na medida do possível, ele deve definir O QUE o sistema deve fazer em vez do COMO ele deve fazer

• Funciona como um acordo contratual entre os clientes e fornecedores de um software

O essencial na escrita de um documento de requisitos • Requisitos são lidos mais frequentemente do

que são escritos. Então, deve-se investir tempo lendo e entendendo os requisitos no documento

• Não assuma que todos os leitores dos requisitos tenham o mesmo background e usem a mesma terminologia sua

• Permita tempo para revisão e ajustes do documento de requisitos

Problemas com a documentação em Linguagem Natural • Falta de clareza

• Precisão é difícil sem tornar o documento difícil para leitura

• Confusão entre requisitos

• Requisitos funcionais e não funcionais tendem a ser misturados

• Fusão de requisitos

• Vários requisitos diferentes podem ser expressos juntos

Problemas com a documentação em Linguagem Natural • Ambiguidade

• Os leitores e escritores do requisito devem interpretar as mesmas palavras da mesma maneira. LN é naturalmente ambígua o que torna o seu uso muito difícil.

• Flexibilidade • A mesma coisa pode ser dita de várias formas diferentes na

especificação

• Falta de modularização • Estruturas de LN são inadequadas para estruturar requisitos do

sistema

• Conclusão: Necessidade de uma notação mais apropriada

Pontos principais

• A elicitação de requisitos envolve a compreensão do domínio da aplicação, o problema específico a ser resolvido, as necessidades e limitações organizacionais e as facilidades especificas necessárias para as partes interessadas.

• Os processos de elicitação de requisitos, análise e negociação são interativos e intercalados, precisando serem repetidos várias vezes.

• Existem várias técnicas de elicitação de requisitos que podem ser usadas, incluindo entrevistas, cenários, métodos soft systems, prototipagem e observação dos participantes.

Pontos principais

• Protótipos são efetivos para a elicitação de requisitos pois as partes interessadas têm algo para experimentar e encontrar seus reais requisitos.

• Listas de checagem são formas particularmente úteis para organizar o processo de validação dos requisitos. Elas lembram ao analista o que deve ser checado quando da leitura dos requisitos propostos.

• Negociação dos requisitos é sempre necessário para resolver conflitos e remover a sobreposição de requisitos. Negociação envolve a troca de informação, discussão e resolução de conflitos.

VALIDAÇÃO DE REQUISITOS

Objetivos da Validação

• Certificar que o documento de requisitos é uma descrição aceitável do sistema a ser implementado

• Verificar as seguintes propriedades do documento:

• Completude e consistência

• Se está de acordo com os padrões

• Conflitos de requisitos

• Erros técnicos

• Requisitos ambíguos

Análise e validação

• Análise trabalha com os dados ‘crus` que foram elicitados dos stakeholders do sistema

• Neste estágio a pergunta chave a ser respondida é “Temos os requisitos certos?”

• Validação usa uma versão final do documento de requisitos, como os requisitos que foram negociados e concordados

• Neste estágio a pergunta chave a ser respondida é “Temos certo os requisitos?”

Entradas e saídas da validação

Entradas da validação

• Documento de requisitos • Deve ser um versão completa do documento, não uma versão

preliminar. Formatada e organizada de acordo com os padrões organizacionais.

• Conhecimento organizacional • Conhecimento, frequentemente implícito, da organização que

poderá ser usado para julgar o realismo dos requisitos

• Padrões organizacionais • Padrões locais, ex. para a organização do documento de

requisitos

Saídas da validação

• Lista de problemas

• Lista dos problemas descobertos no documento de requisitos

• Ações concordadas

• Lista de ações que foram acertadas em resposta aos problemas dos requisitos. Alguns problemas podem ter várias ações corretivas; alguns problemas podem não ter ações associadas.

Exemplo 1

• O Gerenciador de Tarefas deve fornecer mensagens de status a intervalos regulares e não menos que a cada 60 segundos

• Problemas:

• Quais são as mensagens de status?

• Quais as condições para fornecer a mensagem?

• Como elas são fornecidas?

• Por quanto tempo as mensagens são exibidas?

• Intervalo de 80 segundos satisfaz o requisito. Intervalo de 80 dias também

Exemplo 2

• O Editor XML deve alternar entre exibir e esconder caracteres não-imprimíveis, instantaneamente

• Problemas: • Instantâneo?

• O que provoca a mudança? É temporizado, é acionado pelo usuário?

• O que será alterado? O texto selecionado, o documento inteiro, a página atual, etc.

• Quais são os caracteres não imprimíveis? Texto oculto, comentários, tags, etc.

Exemplo 3

• O Parser de XML deve produzir um relatório de erros de marcadores que permite uma rápida resolução dos erros quando usado por usuários novatos em XML

• Problemas:

• Quão rápido?

• Qual o conteúdo do relatório de erros?

• Quando o relatório é gerado?

• Como testar esse requisito?

Exemplo 3

• O Parser de XML deve produzir um relatório de erros de marcadores que permite uma rápida resolução dos erros quando usado por usuários novatos em XML

• Melhoria: 1. Depois que o Parser de XML tiver terminado de analisar um

arquivo, ele deve gerar um relatório de erros que contém o número da linha e o texto de qualquer erro de XML encontrado no arquivo analisado, assim como a descrição de cada erro encontrado

2. Se nenhum erro de análise for encontrado, o Parser não deverá gerar um relatório de erros

IMPORTÂNCIA DA VALIDAÇÃO DE REQUISITOS

Mariner Bugs Out (1962)

• Cost: $18.5 million

• Disaster: The Mariner 1 rocket with a space probe headed for Venus diverted from its intended flight path shortly after launch. Mission Control destroyed the rocket 293 seconds after liftoff.

• Cause: A programmer incorrectly transcribed a handwritten formula into computer code, missing a single superscript bar. Without the smoothing function indicated by the bar, the software treated normal variations of velocity as if they were serious, causing faulty corrections that sent the rocket off course.

Hartford Coliseum Collapse • Cost: $70 million, plus another $20 million damage to the

local economy

• Disaster: Just hours after thousands of fans had left the Hartford Coliseum, the steel-latticed roof collapsed under the weight of wet snow.

• Cause: The programmer of the CAD software used to design the coliseum, incorrectly assumed the steel roof supports would only face pure compression. But when one of the supports unexpectedly buckled from the snow, it set off a chain reaction that brought down the other roof sections like dominoes.

Wall Street Crash (1987)

• Cost: $500 billion in one day

• Disaster: On “Black Monday” (October 19, 1987), the Dow Jones Industrial Average plummeted 508 points, losing 2.6% of its total value. The S&P 500 dropped 20.4%. This was the greatest loss Wall Street ever suffered in a single day.

• Cause: A long bull market was halted by a rash of SEC investigations of insider trading and by other market forces. As investors fled stocks in a mass exodus, computer trading programs generated a flood of sell orders, overwhelming the market, crashing systems and leaving investors effectively blind.

Como realizar a validação?

• Revisão de requisitos

• Prototipagem

• Validação de modelos

• Teste de requisitos

Revisão de requisitos

•Um grupo de pessoas lê e analisa os requisitos, procura problemas, se reúne, discute os problemas e concorda nas ações para tratar estes problemas

Processo de revisão de requisitos

Atividades de Revisão

• Planejar a revisão • Selecionar time de revisão, hora e local para o encontro

de revisão.

• Distribuir os documentos • O documento de requisitos é distribuído entre os

membros do time de revisão

• Preparar para revisão • Cada revisor individualmente lê os requisitos e encontra

conflitos, omissões, inconsistências e desvios dos padrões e outros problemas.

Atividades de Revisão

• Realizar o encontro de revisão • Os problemas e comentários individuais são discutidos e um

conjunto de ações para tratar dos problemas é concordado.

• Ações de acompanhamento • O chefe da revisão verifica se todas as ações acertadas foram

executadas.

• Revisar o documento • O documento de requisitos é revisado para refletir as ações

concordadas. Nestes estágio, pode ser aceito ou revisado novamente

Ações para os problemas

• Clarificação dos requisitos

• O requisito pode ter sido mal escrito ou pode ter acidentalmente omitido alguma informação que foi coletada durante a fase de requisitos.

• Falta de informação

• Alguma informação está faltando no documento de requisitos. É responsabilidade do engenheiro de requisitos que está revisando o documento descobrir esta informação dos stakeholders do sistema.

• Conflito de requisitos

• Existe um conflito significante entre requisitos. Os stakeholders envolvidos devem negociar para resolver o conflito.

• Requisito não realístico

• O requisito não poderá ser implementado com a tecnologia disponível ou dentro da limitações do sistema. Os stakeholders devem ser consultados para decidir como tornar o requisito mais realístico.

Cheque de pré-revisão

• Revisões são caras porque envolvem um número de pessoas que gastará tempo lendo e verificando o documento de requisitos

• Estes gastos podem ser reduzidos usando uma pré-revisão, onde uma pessoa verifica o documento e procura por problemas mais simples tais como: erros tipográficos, falta de aderência ao padrão, falta de algum requisito, etc.

• O documento poderá ser retornado para correção ou enviada a lista de problemas para os revisores

Cheque de pré-revisão

Participantes do time de revisão • Os revisores devem incluir um número de

stakeholders com backgrounds diferentes

• Pessoas com backgrounds diferentes trazem seus conhecimentos e habilidades para a revisão

• Os stakeholders se sentem envolvidos no processo e ER e desenvolvem um entendimento das necessidades dos outros stakeholders

• O time de revisão deve sempre incluir um especialista no domínio e um usuário final Time independente

Critérios de revisão

• Entendimento • Os leitores do documento podem entender o que o requisito significa?

• Redundância • A informação está desnecessariamente repetida no documento?

• Completude • O revisor conhece algum requisito que está faltando ou existe alguma

informação que está faltando na descrição individual de um requisito?

• Ambiguidade • Os requisitos foram expressos usando termos que estão claramente

definidos? É possível que leitores de backgrounds diferentes fazerem interpretações diferentes dos requisitos?

Critérios de revisão

• Consistência • As descrições dos diferentes requisitos incluem contradições? Existem

contradições entre requisitos individuais e requisitos gerais do sistema?

• Organização • O documento está estruturado de uma forma apropriada? As descrições dos

requisitos estão organizadas de forma que requisitos relacionados estejam agrupados?

• Conformidade a padrões • O documento de requisitos ou os requisitos individuais estão conforme o padrão

definido? Os desvios do padrão estão justificados?

• Rastreamento • Os requisitos estão identificados de forma não ambígua, incluindo links a outros

requisitos relacionados e às razões porque os requisitos foram incluídos?

Questões para o checklist

• Cada requisito está unicamente identificado?

• Os termos especializados estão definidos no glossário?

• O requisito sozinho faz sentido, ou precisamos examinar outros requisitos para entendê-lo?

• Os requisitos individuais usam os termos de forma consistente?

• O mesmo serviço é solicitado em requisitos diferentes? Existem contradições nestas solicitações?

• Se um requisitos faz referência a alguma outra facilidade, elas são descritas em outra parte do documento?

• Os requisitos que são relacionados estão agrupados? Se não, há um referência entre eles?

Exemplo de checklist • OBS: na prática, checklists não devem ser tão grandes!

• Organização e completude • Todas as referências a outros requisitos estão corretas?

• Todos os requisitos estão escritos em um nível de detalhamento apropriado e consistente?

• Os algoritmos intrínsecos a requisitos funcionais estão definidos?

• A especificação incluí todas as necessidades do sistema e do cliente?

• Corretude • Cada requisito está escrito com uma linguagem clara, concisa e não ambígua?

• A satisfação de cada requisito pode ser verificada através de testes, demonstração, revisão ou análise?

• Cada requisito está dentro do escopo do projeto?

• Rastreabilidade • Cada requisito está unicamente e corretamente identificado?

• Cada requisito funcional de software está ligado um requisito de mais alto nível?

Prototipagem

• Protótipos para validação de requisitos demonstram os requisitos e ajudam aos stakeholders a descobrirem problemas

• Protótipos para validação devem ser completos, razoavelmente eficientes e robustos. Deverá ser possível usá-los da mesma forma que o sistema requerido

• Documentos do usuário e treinamento devem ser providenciados

Prototipagem para validação

Atividade de Prototipagem

• Escolha os testadores do protótipo • Os melhores testadores são os usuários bem experientes e que

tenham cabeça aberta sobre o uso do novo sistema.

• Usuários finais que têm funções diferentes devem estar envolvidos para que diferentes áreas da funcionalidade do sistema possam ser cobertas.

• Desenvolva os cenários de teste • É necessário um planejamento detalhado para preparar um conjunto

de cenários de teste amplo, que faça cobertura de uma grande quantidade de requisitos.

• Os usuários finais não devem apenas brincar com o sistema, pois isto poderá não exercitar aspectos críticos do sistema.

Atividade de Prototipagem

• Execute cenários

• Os usuários do sistema, geralmente sozinhos, passa a testar o sistema através da execução do cenário planejado.

• Documente problemas

• É melhor definir algum formulário de problemas (eletrônico ou em papel) para que os usuários possam preencher ao encontrar um problema.

Desenvolvimento do manual de usuário • A escrita de um manual de usuário a partir de

requisitos força uma análise detalhada dos requisitos e assim poderá revelar problemas com os requisitos

• Informação do manual de usuários

• Descrição da funcionalidade e como ela é implementada

• Que partes do sistema não foi implementada

• Como resolver problemas

• Como instalar e começar o sistema

Validação do Modelo

• Validação dos modelos do sistema é uma parte essencial do processo de validação

• Objetivos da validação dos modelos • Demonstrar que cada modelo é auto consistente

• Se existem vários modelos do sistema, demonstrar que eles são internamente e externamente consistentes

• Demonstrar que os modelos refletem de forma precisa os reais requisitos dos stakeholders do sistema

• Alguma verificação é possível com ferramentas automáticas

• Parafrasear o modelo é uma forma efetiva de checagem

Teste dos requisitos

• Cada requisito deve ser testável, isto é deverá ser possível definir um teste para verificar se o requisito foi ou não alcançado.

• A invenção de testes de requisitos é uma técnica efetiva de validação, pois informação ambígua ou incompleta dificulta a formulação dos testes

• Cada requisito funcional deve ter um teste associado

Definição de caso de teste

• Qual cenário de uso poderá ser usado para testar um requisito?

• O requisito, sozinho, inclui informação suficiente para a definição de um teste?

• É possível testar o requisito usando um único teste ou são necessários múltiplos testes?

• O requisito poderá ser reescrito para tornar os casos de teste mais óbvios?

Formulário de teste de requisito • O identificador do requisito

• Deve haver pelo menos um para cada requisito.

• Requisitos relacionados

• Devem ser referenciados, pois o teste poderá ser relevante também a estes requisitos.

• Descrição do teste

• Uma breve descrição do teste. Deve incluir as entradas do sistema e as saídas correspondentes.

• Problemas do requisito

• Uma descrição dos problemas que tornaram difícil ou impossível a definição do teste.

• Comentários e recomendações

• São conselhos de como resolver os problemas dos requisitos que foram descobertos.

Exemplo de teste de requisitos

• Quando os usuários acessarem o sistema, eles serão apresentados a páginas web com todos os serviços disponíveis para eles.

Formulário de teste de requisitos

Requisitos difíceis de testar

• Requisitos do sistema

• Requisitos que se aplicam ao sistema como um todo.

• Em geral, estes são os requisitos mais difíceis de validar independentemente do método usado, pois podem ser influenciados por quaisquer dos requisitos funcionais.

• Testes que não são executáveis, não podem testar características gerais não-funcionais do sistema, tais como usabilidade.

Requisitos difíceis de testar

•Requisitos exclusão

• Existem requisitos que excluem comportamentos específicos.

• Por exemplo, um requisito poderia dizer que falhas do sistema nunca devem corromper o banco de dados. Não será possível testar este requisito exaustivamente.

Requisitos difíceis de testar

•Alguns requisitos não-funcionais

• Alguns requisitos não-funcionais, tais como requisitos de confiabilidade só podem ser testados com um grande conjunto de teste. • O projeto destes testes não ajuda a validação dos requisitos.

Pontos principais

• A validação de requisitos deve focar em verificar se a versão final do documento de requisitos apresenta conflitos, omissões ou desvios dos padrões.

• As entradas do processo de validação são os documentos de requisitos, padrões organizacionais, e conhecimento implícito da organização. As saídas são uma lista de problemas dos requisitos e as ações concordadas para tratar estes problemas.

• Revisões envolvem um grupo de pessoas fazendo análise detalhada dos requisitos.

• Os custos de revisão podem ser reduzidos se forem verificados, antes da revisão, desvios do padrão organizacional.

Pontos principais

• Checklists sobre o que procurar podem ser usadas para guiar o processo de revisão de requisitos.

• Prototipagem é efetivo para validação de requisitos se um protótipo for desenvolvido durante o estágio de elicitação de requisitos.

• Os modelos do sistema são validados através do seu parafraseamento. Isto significa que eles são sistematicamente traduzidos em uma descrição em linguagem natural.

• Projetando testes para requisitos pode revelar problemas com os requisitos. Se um requisito não estiver claro, poderá ser impossível definir uma teste para ele.