Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos é um conjunto de atividades com propósito de identificar e comunicar o propósito de um software, e o contexto no qual ele será usado. Portanto, engenharia de requisitos age como uma ponte entre as necessidades reais dos stakeholders (usuários , clientes, e outros indivíduos afetados pelo sistema de software) e as capacidades e oportunidades providas pelo software.

Engenharia de Requisitos

• Levantamento de Requisitos. – Necessidades dos usuários, informações de domínio,

sistemas existentes, regulamentos e leis, etc.

• Análise de Requisitos. – Modelagem.

• Documentação de requisitos.

• Verificação e validação de requisitos.

O que são requisitos e quais são os seus tipos?

Requisitos • Requisitos são descrições dos serviços que devem ser providos pelo sistema e de suas restrições operacionais (SOMMERVILLE, 2007). • Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos (PFLEEGER, 2004). • Um requisito é alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006).

Requisitos

Os requisitos de um sistema incluem especificações dos serviços que o sistema deve prover, restrições sob as quais ele deve operar, propriedades gerais do sistema e restrições que

devem ser satisfeitas no seu processo de desenvolvimento

Tipos de Requisitos • Requisitos Funcionais: funcionalidades do sistema

– são declarações de serviços que o sistema deve prover, descrevendo o que o sistema deve fazer (SOMMERVILLE, 2007).

– descreve uma interação entre o sistema e o seu ambiente (PFLEEGER, 2004), – Pode descrever, ainda, como o sistema deve reagir a entradas específicas, como o

sistema deve se comportar em situações específicas e o que o sistema não deve fazer (SOMMERVILLE, 2007).

• Requisitos Não Funcionais: características e qualidades que não são funções (ex.: segurança, precisão, performance, custo, usabilidade, etc.) – descrevem restrições sobre os serviços ou funções oferecidos pelo sistema

(SOMMERVILLE, 2007), as quais limitam as opções para criar uma solução para o problema (PFLEEGER, 2004).

– são muito importantes para a fase de projeto (design), servindo como base para a tomada de decisões nessa fase.

Exemplos • Requisitos Funcionais

– O elevador deve levar as pessoas ao andar que elas escolheram.

– O sistema deve mostrar na tela a raíz quadrada do número usado como entrada.

– O sistema deve registrar locações de filmes, devendo ser registrados o cliente, os itens locados, a data da locação, a data de expiração da locação e o valor da locação.

– O sistema deve permitir que professores e pedagogos sejam capazes de criar e editar listas de chamada, atribuindo presença ou falta para alunos em uma data.

– O sistema deve permitir que usuários criem playlists e adicionem, removam, e reordenem músicas nessas playlists. A mesma música poderá ser adicionada em diferentes playlists.

• Requisitos Não-Funcionais – O sistema deve estar disponível pela Internet, a partir dos principais navegadores disponíveis

no mercado. (requisito de portabilidade).

– O sistema deve retornar os resultados da busca em 10ms (requisito de eficiência).

Tipos de Requisitos Não-Funcionais (SOMMERVILLE, 2007)

• Requisitos de produto: especificam o comportamento do produto (sistema). Referem-se a atributos de qualidade que o sistema deve apresentar, tais como:

– Confiabilidade, usabilidade, compatibilidade, segurança, eficiência, de desempenho, manutenibilidade e portabilidade, testabilidade, disponibilidade, modificabilidade, etc.

Tipos de Requisitos Não-Funcionais (SOMMERVILLE, 2007)

• Requisitos organizacionais: são derivados de metas, políticas e procedimentos das organizações do cliente e do desenvolvedor. – requisitos de processo (padrões de processo e modelos de

documentos que devem ser usados), – requisitos de implementação (tal como a linguagem de

programação a ser adotada), – restrições de entrega (tempo para chegar ao mercado -

time to market, restrições de cronograma etc.), – restrições orçamentárias (custo, custo-benefício) etc.

Tipos de Requisitos Não-Funcionais (SOMMERVILLE, 2007)

• Requisitos externos: referem-se a todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento.

– requisitos de interface/interoperabilidade com sistemas externos ou de outras organizações,

– requisitos legais (tais como requisitos de privacidade) e

– requisitos éticos.

Observação • Requisitos funcionais normalmente possuem

critérios de satisfação bem definidos, mas requisitos não-funcionais nem sempre possuem critérios de satisfação bem definidos. – Ex: como saber se um elevador é rápido?

• Os requisitos não-funcionais devem ser refinados, de forma que eles passem a ser verificáveis. – Ex.: o elevador deve chegar ao andar em 30s depois que o

botão foi pressionado.

Observação

Requisitos não funcionais podem se referir ao sistema como um todo ou a partes específicas.

Características Desejáveis em Requisitos • Corretude (acurácia): eles devem descrever de forma acurada as necessidades

dos clientes. • Completude: a lista de requisitos descreve completamente o que os

stakeholders desejam. • Pertinência: os requisitos listados de fato são importantes para atender aos

stakeholders. • Simplicidade (ou não compostos): cada requisito deve expressar um pedaço

específico de funcionalidade que o sistema deve prover. • Testabilidade: deve ser possível verificar se um determinado requisito foi

atendido ou não pelo sistema. • Concistência: os requisitos não devem ser inconsistentes entre si. • Não-ambiguidade: a descrição dos requisitos deve ser clara e não ambígua

para evitar erros nas próximas fase do processo.

Características Desejáveis em Requisitos

• Valor: os requisitos devem trazer valor para os clientes e usuários.

• Estimabilidade: deve ser possível estimar quantos recursos (tempo, funcionários, dinheiro, etc.) serão necessários para atender o requisito.

• Rastreabilidade: os requisitos devem ser identificados de forma que seja fácil se referir a ele.

A lista de requisitos é completa?

Regras de Negócio: regras que devem ser obedecidas pelo

sistema

Regras de Negócio: regras que devem ser obedecidas pelo

sistema

Como Obter Requisitos?

De onde vêm os requisitos • Requisitos são levantados junto aos Stakeholders

– Clientes, usuários, técnicos, etc.

• Domínio da Aplicação

– Regulamentação, regras, e processos de um banco, escola, ou qualquer instituição na qual o sistema será usado.

• Documentação

– Manuais, regimentos, tutoriais, etc.

Levantamento de Requisitos

1. Entendimento do Domínio de Aplicação

2. Identificação de Fontes de Requisitos

3. Análise de Interessados

4. Seleção de Técnicas de Levantamento de Requisitos

5. Levantamento de Requisitos de Interessados e Outras Fontes

O Desafio do Levantamento de Requisitos • O conhecimento frequentemente não é

explícito e não está escrito, mas é distribuído em várias fontes.

• O analista pode ter que falar com muitas pessoas para obter o conhecimento. O conhecimento pode ser conflitante entre diferentes pessoas.

• Pessoas nem sempre são capazes ou estão preparadas para descrever exatamente como elas vão executar tarefas.

O Desafio do Levantamento de Requisitos • Pessoas podem não estar disponíveis para

demonstrar um processo (por estarem ocupadas, por exemplo), ou fazendo outras coisas ao mesmo tempo (o que pode introduzir ruído),

• Pessoas podem mudar a forma de realizar a atividade quando sabem que estão sendo observadas.

• Pessoas podem não se sentirem à vontade para dizer o que você precisa, ou podem não querer dizer, e até descrever um processo diferente da realidade (conscientemente ou não) para se beneficiarem, defender uma agenda, ou para influenciar as ações.

Técnicas de Levantamento de Requisitos

• Coleta de informações através de estudo sobre o domínio (background reading) – Ler documentos como relatórios da empresa e gráficos

organizacionais, manuais de políticas, descrições de cargos, documentação de sistemas existentes, etc.

– Bom para obter informações antes de entrevistar pessoas. – Adequado quando o analista não conhece o domínio. – Um ponto negativo é que documentos podem estar fora

de sincronia com a realidade e não refletir a conjuntura atual da organização.

Técnicas de Levantamento de Requisitos • Levantamento e amostragem de dados organizacionais

– Formulários, invoices, informações financeiras, resultados de pesquisas, dados de marketing, etc.

• Entrevistas – Os entrevistados devem ser escolhidos cuidadosamente. – Podem ser estruturadas ou não – Permitem coletar um conjunto rico de informações como opiniões e fatos. – Dá dinamicidade ao processo de levantamento de requisitos. – Permite ao analista se aprofundar em questões através de questões seguintes. – Do lado negativo, requer um conjunto de habilidades e é difícil de se tornar

proeficiente. Além disso, informações faltantes podem ser identificadas apenas a posteriori e isso é problemático se os entrevistados são difíceis de serem acessados.

– Não é suficiente coletar muitas informações. Se estas informações são difíceis de analisar ou irrelevantes, elas podem se tornar inúteis. É necessário saber conduzir a entrevista de forma a maximizar a aquisição de informações úteis.

Técnicas de Levantamento de Requisitos

• Questionários e pesquisas (surveys) – Permitem a coleta de informações de grandes quantidades de

pessoas. – Limita a quantidade de informações que o usuário pode prover

e que podem ser relevantes para o sistema.

• Reuniões, cinâmicas de grupo, focus groups, brainstorms. – Reuniões são importantes para apresentar as informações que

foram coletadas e para obter feedback dos stakeholders e confirmar ou refutar o que foi aprendido.

– É importante ter objetivos claros e que os encontros sejam planejados cuidadosamente.

Técnicas de Levantamento de Requisitos

• Prototipação: visualizações de como o sistema funcionaria são apresentadas aos stakeholders para verificar se elas fazem sentido.

Como Documentar Requisitos?

Requisitos de Usuários e de Sistema • Requisitos de Clientes:

– Normalmente registrados em um Documento de Definição de Requisitos. – Escrito para os clientes – Frequentemente em linguagem natural – Sem detalhes técnicos

• Requisitos de Sistema: – Normalmente descritos em um Documento de Especificação de

Requisitos. – Escrito para desenvolvedores – Requisitos mais detalhados – Especificado claramente e com mais rigor – Pode conter detalhes técnicos

Descrições de Requisitos • Frases do tipo “o sistema deve”.

– O sistema deve permitir que estudantes se matriculem em disciplinas.

– O sistema deve permitir que professores gerenciem notas de alunos.

• Estórias de usuários.

– Eu como estudante devo ser capaz de me matricular em disciplinas.

– Eu como professor posso gerenciar a nota dos alunos de forma que eu possa corrigir notas digitadas incorretamente, se necessário.

Regras de Negócio

Estórias de Usuários

Estórias de usuário contém: • Uma descrição escrita da história utilizada para

planejar e como um lembrete do que deve ser feito;

• Conversações sobre a história que servem para “refrescar” os detalhes da história;

• Testes que transmitem e documentam detalhes e podem ser usados para determinar quando uma história está completa.