4- Engenharia de Requisitos

Engenhria de Requisitos

Engenharia de Software

Caainã Jerônimo de Souza Nascimento

https://sites.google.com/site/esjogos161/ caainajeronimo@gmail.com

Engenharia de Requisitos

• O processo de estabelecer quais as funções e serviços necessários além de restrições sobre sua operação e desenvolvimento.

• Ao final, temos como produto um documento de requisitos, que deve ser validade pelo cliente.

O que é Requisito?

• Uma declaração abstrata e de alto nível de uma função ou serviço. • Tipos:

• Requisitos de usuário (Alto nível): Requisitos de usuário são declarações, em uma linguagem natural com diagramas, de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais este deve operar.

• Requisitos de Sistema (Mais detalhado): São descrições mais detalhadas das funções, serviços e restrições operacionais do sistema de software. O

documento de requisitos do sistema (às vezes, chamado especificação funcional) deve definir exatamente o que deve ser implementado.

Classificação – Requisitos Funcionais

• Descreve funcionalidade e serviços do sistema.

• Descreve como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações.

Requisitos não-funcionais

• Definem as propriedades e restrições do sistema, como tempo de resposta, desempenho, espaço, etc.

• Requisitos de processo também podem especificar o uso de determinadas linguagens de programação, método de desenvolvimento.

• Requisitos não funcionais dizem respeito ao sistema como um todo. • Podem ser mais críticos que requisitos funcionais.

RNF de Produto

• O produto deve se comportar de forma particular

• Exemplos Incluem requisitos de desempenho quanto à rapidez com que o sistema deve executar e quanta memória ele requer, requisitos de confiabilidade que estabelecem a taxa aceitável de falhas,

RNF Organizacional

• Esses são requisitos gerais de sistemas derivados das políticas e procedimentos da organização do cliente e do desenvolvedor.

• Exemplos incluem requisitos do processo operacional, que definem como o sistema será usado, requisitos do processo de

desenvolvimento que especificam a linguagem de programação, o ambiente de desenvolvimento ou normas de processo a serem

RNF Externo

• Esse tipo abrange todos requisitos que derivam de fatores externos ao sistema e seu processo de

desenvolvimento.

• Podem incluir requisitos reguladores, que definem o que deve ser feito para que o sistema seja

aprovado para uso, por um regulador, tal como um banco central; requisitos legais, que devem ser

seguidos para garantir que o sistema opere dentro da lei; e requisitos éticos, que asseguram que o

sistema será aceitável para seus usuários e o público em geral.

Elicitação e Análise de Requisitos

• Também denominada de descoberta (levantamento) de requisitos • Envolve pessoal objetivando descobrir o domínio de aplicação,

serviços que devem ser fornecidos bem como restrições • Deve envolver os Stakeholders

• Um stakeholder do sistema é quem tem alguma influência direta ou indireta sobre os requisitos do sistema.

• Podem ser usuários finais que irão usar o sistema e qualquer outra pessoa que será afetada por ele.

Stakeholders

• Os stakeholders costumam não saber o que querem

• Stakeholders expressam requisitos em seus próprios termos e com o conhecimento implícito de seu próprio trabalho

• Diferentes stakeholders têm requisitos diferentes e podem expressar essas diferenças de várias maneiras

Modelo

Coleta de requisitos

• A coleta de requisitos é feita através de técnicas

• Nesta etapa, os requisitos são simplesmente documentados à medida que são coletados

• Resulta em documento preliminar

Entrevistas

• Técnica direta

• Pode ser usada na análise do problema e na elicitação de Requisitos • Entender problemas reais e soluções potenciais das perspectivas dos

usuários, clientes, e outros stakeholders.

• Estar aberto a novas ideias, evitar ideias preconcebidas sobre os requisitos e estar disposto a ouvir os stakeholders.

• Você geralmente tem de fazer algumas perguntas para começar e manter a entrevista centrada no sistema que será desenvolvido.

Devemos Identificar

• Quem é o cliente? E o usuário?

• Possuem necessidades diferentes?  

• Quais são suas Capacidades, Backgrounds...? • Qual é o problema?

• Como é resolvido atualmente? • Qual a razão para resolvê-lo?

Brainstorming

• Estabeleça o objetivo da sessão • Gere quantas ideias for possível • Deixe sua imaginação livre

• Não admita críticas ou debates • Ajuste e combine as ideias

Etnografia

• Técnica de observação ambiente de trabalho

• Um analista faz uma imersão no ambiente de trabalho em que o sistema será usado

• O trabalho do dia a dia é observado e são feitas anotações sobre as tarefas reais em que os participantes estão envolvidos.

• O valor da etnografia é que ela ajuda a descobrir requisitos implícitos do sistema que refletem as formas reais com que as pessoas

trabalham, em vez de refletir processos formais definidos pela organização

Prototipação de Telas

• Prototipa só a interface • Ajuda na sua melhora

• Ajuda no entendimento dos requisitos • Custo baixo e rápido

• Não precisa ser executável

• Uma pessoa simula a execução

Caso de uso

• Narrativas do uso do sistema

• Oferece algo de valor para o usuário • Definem vários cenários de uso

• Requisitos funcionais

Atores

• Objeto que fornece eventos e recebe respostas do sistema • Ex: Classe de pessoa ou sistema externo

• De alguma forma participa no sistema

• Caso de uso só faz sentido se tiver pelo menos um ator envolvido. • Observar dois tipos de atores:

• Usuários que solicitam/esperam algo do sistema • Sistemas externos que o sistema necessita

Documentação de requisitos

• Níveis de descrição

• Requisitos de Usuário: Sentenças em linguagem natural, diagramas, etc. descrevendo quais os serviços a serem oferecidos e as

restrições sob as quais o sistema irá operar

• Requisitos de Sistema: Descrição mais detalhada de serviço e

restrições (especificação funcional) a ser seguida pela equipe de desenvolvimento

Vantagens e desvantagens de usar

a linguagem natural

• Falta de Clareza

• Ambigüidades, Imprecisão • Confusão de Requisitos

• A separação de RF e RNFs pode não ser clara • Fusão de Requisitos

Validação de Requisitos

• Validade: Os requisitos devem ser descritos corretamente

• Consistência: Requisitos no documento não devem entrar em conflito • Completude: Deve incluir requisitos que definam todas as funções e

restrições pretendidas pelo usuário do sistema

• Realismo: Verificar para assegurar que realmente podem ser implementados

Técnicas de Validação

• Revisões de requisitos: Os requisitos são analisados sistematicamente por uma equipe de revisores que verifica erros e inconsistências

• Prototipação: Um modelo executável do sistema em questão é demonstrado para os usuários finais e clientes. Estes podem

experimentar o modelo para verificar se ele atende a suas reais necessidades

• Geração de casos de teste: Os requisitos devem ser testáveis. Se os testes forem concebidos como parte do processo de validação, isso frequentemente revela problemas de requisitos