Engenharia de Requisitos

Introdução

O que é

É o processo de compreensão e controle das mudanças nos requisitos do sistema

Após a instalação e o uso do sistema, surgirão novos requisitos

Razões pelas quais a mudança é inevitável

Após a instalação, o ambiente técnico e de negócios do sistema sempre muda

Um novo hardware pode ser introduzido

Pode ser necessário fazer a interface do sistema com outros sistemas

As prioridades do negócio podem mudar

Podem ser introduzidas novas legislações e regulamentos aos quais o sistema deve respeitar

As pessoas que pagam por um sistema e os usuários desse sistema raramente são os mesmos

novos recursos podem ser adicionados, para dar suporte ao usuário, a fim de que o sistema cumpra suas metas

Sistemas de grande porte têm uma comunidade de diversos usuários, com diferentes requisitos e prioridades, que podem ser conflitantes ou contraditórios

É preciso

Ter conhecimento sobre as necessidades individuais e manter as ligações entre as necessidades dependentes para conseguir avaliar o impacto das mudanças nos requisitos

Estabelecer um processo formal para fazer propostas de mudanças e a ligação destas às exigências do sistema.

O processo de gerenciamento de requisitos deve começar quando uma versão preliminar do documento de requisitos estiver disponível

Mas, deve se começar o planeamento de como gerenciar as mudanças de requisitos durante o processo de elicitação de requisitos

Planejamento de gerenciamento de requisitos

O é o primeiro estágio essencial no processo de gerenciamento de requisitos

Determina o nível de detalhamento requerido no gerenciamento de requisitos

Questões que devem ser decididas no estágio de gerenciamento de requisitos

Identificação de requisitos

Cada requisito deve ser identificado unicamente para poder ser comparado com outros requisitos e usado em avaliações de rastreabilidade

Processo de gerenciamento de mudanças

Conjunto de atividades que avaliam o impacto e o custo das mudanças

Ferramenta de apoio

Ferramentas que podem ser usadas variam desde sistemas especializados em gerenciamento de requisitos até planilhas e sistemas de banco de dados simples

Políticas de rastreabilidade

Definem os relacionamentos entre cada requisito e entre os requisitos e o projeto de
sistema que deve ser registrado

Precisa de apoio automatizado, e as ferramentas de software para esse gerenciamento devem ser escolhidas durante a fase de planejamento

Ferramentas de apoio servem para

Armazenamento de requisitos

Os requisitos devem ser mantidos em um repositório de dados gerenciado e seguro, acessível a todos os envolvidos no processo de engenharia de requisitos

Gerenciamento de mudanças

O processo de gerenciamento de mudanças é simplificado quando as ferramentas ativas de apoio estão disponíveis

Gerenciamento de rastreabilidade

Permitem descobrir requisitos relacionados

Gerenciamento de mudança de requisitos

É essencial, pois é necessário decidir se os benefícios da implementação de novos requisitos justificam os custos de implementação

Estágios do processo de gerenciamento de mudanças

Análise de problema e especificação de mudanças

Analisa-se o problema ou a proposta de mudança a fim de se verificar sua validade

A análise é transmitida a quem solicitou a mudança

que pode responder com uma proposta mais específica de mudança de requisitos

retirar a solicitação

Análise de mudanças e custos

O efeito da mudança proposta é avaliado por meio de informações de rastreabilidadee conhecimentos gerais dos requisitos do sistema

O custo de fazer a mudança é estimado em termos de modificações no documento de requisitos e, no projeto e implementação do sistema.

Quando a análise é concluída decide-se prosseguir ou não com a mudança de requisitos

Implementação de mudanças

O documento de requisitos e, quando necessário, o projeto e implementação do sistema são modificados.

Não se deve modificar o sistema e depois o documento de requisitos, pois pode levar a uma incoerência das informações

O que é

É o processo pelo qual se verifica se os requisitos definem o sistema que o cliente realmente quer

É importante porque erros em um documento de requisitos podem gerar altos custos de retrabalho

Quando descobertos durante o desenvolvimento ou após o sistema já estar em serviço

Tipos de verificação que devem ser efetuados com os
requisitos no documento de requisitos

1. Verificações de validade

Ter maior reflexão e análise mais aprofundada podem identificar funções necessárias, adicionais
ou diferentes

2. Verificações de consistência

Não deve haver restrições contraditórias ou descrições diferentes da mesma função do sistema

3. Verificações de completude

O documento de requisitos deve incluir requisitos que definam todas as funções e as restrições pretendidas pelo usuário do sistema

4. Verificações de realismo

Os requisitos devem ser verificados para assegurar que realmente podem ser implementados

Considerarando o orçamento e o cronograma para o desenvolvimento do sistema

5. Verificabilidade

É necessário ser capaz de escrever um conjunto de testes que
demonstrem que o sistema entregue atende a cada requisito especificado

Técnicas de validação de requisitos

1. Revisões de requisitos

Os requisitos são analisados sistematicamente por uma equipe de revisores que verifica erros e inconsistências

2. Prototipação

Um modelo executável do sistema em questão é demonstrado
para os usuários finais e clientes

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

3. Geração de casos de teste

Os requisitos devem ser testáveis

Se é difícil ou impossível projetar um teste, os requisitos devem ser reconsiderados

O desenvolvimento de testes a partir dos requisitos do usuário antes de qualquer código ser escrito é parte integrante do Extreme Programming

Introdução

Os engenheiros de software trabalham com clientes e usuários finais do sistema para obter informações sobre

Domínio da aplicação

Serviços que o sistema deve oferecer

Desempenho do sistema

Restrições de hardware

Entre outros

Podem envolver diversos tipos de pessoas em uma organização

Descoberta de requisitos

Fase de interação com os stakeholders do sistema para

descobrir

seus requisitos

requisitos de domínio

elaborar a documentação

Classificação e organização de requisitos

Toma a coleção de requisitos não estruturados

Agrupa requisitos relacionados e os organiza em grupos coerentes

Por meio de um modelo de arquitetura do sistema que identifica os subsistemas e associa requisitos a cada subsistema

Priorização e negociação de requisitos

Quando vários stakeholders estão envolvidos, os requisitos entram em conflito

É preciso se reunirem para resolver as diferenças e chegar a um acordo sobre os requisitos

Está atividade está relacionada com

a priorização de requisitos

encontrar e resolver os conflitos

por meio da negociação de requisitos

Especificação de requisitos

Os requisitos são documentados e inseridos no próximo ciclo da espiral

Podem ser documentos

formais

informais

É um processo iterativo, com feedback contínuo de cada atividade para as outras atividades

O processo é um pouco difícil

Os stakeholders costumam não saber o que querem de um sistema computacional

Podem achar difícil articular o que querem que o sistema faça

Podem fazer exigências inviáveis

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

Engenheiros de requisitos, sem experiência no domínio do cliente, podem não entender esses requisitos

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

Engenheiros de requisitos precisam descobrir todas as potenciais fontes de requisitos e descobrir as semelhanças e conflitos.

Fatores políticos podem influenciar os requisitos de um sistema

Os gerentes podem exigir requisitos específicos, porque estes lhes permitirão aumentar sua influência na organização

O ambiente econômico e empresarial no qual a análise ocorre é dinâmico

A importância dos requisitos específicos pode mudar

Novos requisitos podem surgir

Durante o processo, deve se organizar as negociações regulares dos stakeholders

A opinião de todos os stakeholders devem ser consideras

Uma versão inicial do documento de requisitos do sistema pode ser produzida com seções faltantes e requisitos imcompletos

Utilizando

Planilhas

Cartões

Facilitam para os stakeholders lidarem, mudarem e
organizarem os requisitos

Elicitação de requisitos

Responsável por

Reunir informações sobre

Sistemas requeridos

Sistemas existentes

Separar dessas informações os requisitos de

usuário

sistema

Fontes de informações

Documentos

Especificação de sistemas similares

Domínio da aplicação

Sistemas que interagem com o sistema especificado

Stakeholders do sistema

Interação por meio de

observação

entrevista

Utiliza se cenários e protótipos para ajudar os stakeholders a compreenderem o que o sistema vai ser

Variam desde os usuário finais, até os stakeholders externos

Entrevistas

Os stackholders são questionados sobre o sistema que usam, e o que será desenvolvido

Os requisitos surgem a partir das respostas

Tipos

Fechada

Possui um conjunto de perguntas é predefinido

Aberta

Não existe uma agenda predefinida

A equipe explora uma serie de questões com os stackholders do sistema

desenvolvendo uma melhor compreensão de suas necessidades

Na prática, costuma ser um mistura dos dois

Discussões totalmente abertas raramente funcionam bem

É preciso fazer algumas perguntas para começar e manter a entrevista centrada no sistema que será desenvolvido

São boas para a compreensão global sobre

o que os stackholders fazem

como eles podem interagir com o novo sistema

as dificuldades que eles enfrentam com os sistemas atuais

Não é eficaz na elicitação de

Domínio da aplicação

Uso de terminologias e jargões pelos especialistas em aplicações, desconhecido dos engenheiros de requisitos

O conhecimento de domínio é tão familiar aos stakeholders que eles têm dificuldade de explicá-lo ou pensam
que é tão fundamental que não vale a pena mencionar

Conhecimento sobre os requisitos e restrições
organizacionais

A maioria das pessoas é relutante em discutir questões políticas e organizacionais que podem afetar os requisitos

Bons entrevistadores

estão abertos a novas ideias

evitam ideias preconcebidas sobre os requisitos

estão dispostos a mudar de ideia sobre o sistema

estimulam o convidado a participar de discussões

questão-trampolim

uma proposta de requisitos

trabalhando em conjunto em um protótipo do sistema

Informações recolhidas em entrevistas suplementam outras informações sobre o sistema

Para evitar que informações deixem de ser capitadas, deve se usar um conjunto com outras técnicas de elicitação de requisitos

Cenários

Úteis para adicionar detalhes a uma descrição geral de requisitos

Começa com o esboço da iteração

Durante o processo de elicitação, detalhes são adicionados a esse esboço

Podem incluir

Uma descrição do que o sistema e os usuários esperam quando o cenário se iniciar

Uma descrição do fluxo normal de eventos no cenário

Uma descrição do que pode dar errado e como isso é tratado

Informações sobre outras atividades que podem acontecer ao mesmo tempo

Uma descrição do estado do sistema quando o cenário acaba

Na elicitação baseada em cenários, é preciso

identificar o cenário

capturar detalhes que serão incluídos nesses cenários

Podem ser escritos como texto, suplementados por diagramas, telas, etc

Outra possibilidade é uma abordagem mais estruturada, em que cenários de eventos ou casos de uso podem ser usados

Casos de uso

Técnica de descoberta de requisitos introduzida inicialmente no método Objectory

Identifica os atores envolvidos em uma interação e dá nome ao tipo de interação

Suplementada por informações adicionais que descrevem a interação com o sistema

Essa informação pode ser

descrição textual

modelos gráficos

diagramas de sequência

estado UML

Documentados por um diagrama de casos de uso de alto nível

O conjunto de casos de uso representa todas as possíveis interações que serão descritas nos requisitos de sistema

Não há distinção entre cenários e casos de uso que seja simples e rápida

Alguns consideram cada caso de uso um cenário único

Outros encapsulam um conjunto de cenários em um único caso de uso

Identificam as interações individuais entre o sistema e seus usuários ou outros sistemas

Deve ser documentado com uma descrição textual

pode ser ligada a outros modelos UML que desenvolverão o cenário com mais detalhes

Não é eficaz para elicitação

das restrições

dos requisitos de negócios

dos não funcionais em alto nível

descobrir requisitos de domínio

Etnografa

Sistemas de software são usados em um contexto social e organizacional

requisitos de software do sistema podem ser derivados ou restringidos desse contexto

satisfazer a esses requisitos sociais e organizacionais é crítico para o sucesso do sistema

O fracasso de alguns sistemas, é que não levam em conta a forma como o contexto social e organizacional afeta o funcionamento prático do sistema

O que é

É uma técnica de observação que pode ser usada para compreender os processos operacionais e ajudar a extrair os requisitos de apoio para esses processos

Importância

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

Fatores sociais e organizacionais que afetam o trabalho, mas que não são óbvios para os indivíduos, podem ficar claros apenas quando analisados por um observador imparcial.

Eficaz para descobrir dois tipos de requisitos

Requisitos derivados da maneira como as pessoas realmente trabalham, e não da forma como as definições dos processos dizem que deveriam trabalhar

Requisitos derivados da cooperação e conhecimento das atividades de outras pessoas

Pode ser combinada com prototipação

A etnografia informa o desenvolvimento do protótipo, para que menos ciclos de refinamento do protótipo sejam necessários

Não é uma abordagem completa para elicitação

Pode incluir quatro atividades de alto nível

Avaliando se o sistema é útil para a empresa (estudo de viabilidade)

Descobrindo requisitos (elicitação e análise)

Convertendo-os em alguma forma-padrão (especificação)

Verificando se os requisitos realmente definem o sistema que o cliente quer (validação)

As atividades são organizadas em torno de uma espiral

Como um processo iterativo

Tem como resultado um documento
de requisitos de sistema

O tempo gasto em cada atividade depende do

Tipo de sistema que está sendo desenvolvido

Estágio do processo como um todo

Os requisitos são desenvolvidos em diferentes níveis de detelhamento

O número de iterações em torno da espiral pode variar

A espiral pode acabar depois da definição de alguns ou de todos os requisitos de usuário

Os requisitos e a implementação podem ser desenvolvidos em conjunto por meio do desenvolvimento ágil

Análise orientada a objetos

Trata-se de analisar o sistema e desenvolver um conjunto de modelos gráficos do mesmo

Modelos de casos de uso

Servem como uma especificação do sistema

Conjunto de modelos

Descreve o comportamento do sistema

É anotado com informações adicionais

Desempenho

Confiabilidade requerida do sistema

Definição básica

Requisitos Funcionais

Declarações de serviços que o sistema deve fornecer

Reação do sistema a entradas específicas

Comportamento do sistema em determinadas situações

Requisitos não funcionais

Restrições aos serviços ou funções oferecidos pelo sistema

A distinção entre os tipos de requisitos não é tão clara

Requisitos são independentes

Muitas vezes geram ou restringem outros requisitos

O importante é garantir que os serviços e funcionalidades sejam entregues corretamente

Requisitos Funcionais

Descreve o que o sistema deve fazer

Dependem do tipo de software, dos possíveis usuários e da abordagem adotada ao escrever os requisitos

Variam de descrições gerais até requisitos muito específicos

Imprecisão na especificação de requisitos é a causa de muito problemas da engenharia de software

Especificação deve ser

Completa

Definir todos os serviços requeridos pelo usuário

Consistente

Definições dos requisitos não devem ser contraditórias

Em sistemas grandes é quase impossível alcançar completude e consistência

Requisitos não funcionais

Requisitos que não estão diretamente ligados aos serviços específicos oferecidos pelo sistema

Relacionados por exemplo à confiabilidade, tempo de resposta e ocupação de área

Normalmente restringem o sistema como um todo

São frequentemente mais críticos, não atender um requisito pode acarretar em inutilizacao do sistema

Implementação dos requisitos pode ser difundida em todo o sistema

Podem afetar a arquitetura geral do sistema

Um requisito não funcional pode gerar uma série de requisitos funcionais

Tipos de requisitos não funcionais

Requisitos de produto

Especificam ou restringem o comportamento do software

Requisitos organizacionais

Requisitos derivados das políticas e procedimentos da organização do cliente e do desenvolvedor

Requisitos externos

Requisitos que derivam de fatores externos ao sistema e seu processo de desenvolvimento

Sempre que possível, escrever os requisitos quantitativamente

Podem ser objetivamente testados

Verificar se os requisitos estão sendo cumpridos

http://www.ifc-camboriu.edu.br/~catia/IA16/Engenharia_Software_3Edicao.pdf

Na prática, é difícil separar os requisitos funcionais dos não funcionais no documento de requisitos

Uni-los gera um melhor entendimento das relações entre os requisitos

O que é

É o processo de escrever os requisitos de usuário e de sistema em um documento de requisitos

Devem ser: claros, inequívocos, de fácil compreensão, completos e consistentes

Os requisitos de usuário

Devem descrever os requisitos funcionais e não funcionais

Precisa ser compreensível para os usuários do sistema que não tenham conhecimentos técnicos detalhados

Devem especificar somente o comportamento externo do sistema

O documento de requisitos não deve incluir detalhes da arquitetura ou projeto do sistema

Devem escrever os requisitos de usuário em linguagem natural, com tabelas simples, formas e diagramas intuitivos

Os requisitos de sistema

Usados por engenheiros de software como ponto de partida para o projeto do sistema.

São versões expandidas dos requisitos de usuário

Eles podem ser usados como parte do contrato para a implementação do sistema

Eles não devem se preocupar com a forma como o sistema deve ser projetado ou implementado

Pode ser escrito em linguagem natural, em notações com base em formulários, modelos gráficos ou matemáticos de sistema

Devem consistir em uma especificação completa e detalhada de todo o sistema

Especificação em linguagem natural

É expressiva, intuitiva e universal

Os requisitos são escritos em frases numeradas em linguagem natural

Cada frase deve expressar um requisito

Potencialmente vaga, ambígua e seu significado depende do conhecimento do leitor

Diretrizes simples para minimizar os mal-entendidos ao escrever requisitos em linguagem natural

Invente um formato-padrão e garanta que todas as definições de requisitos aderem a esse formato

A padronização do formato torna menos prováveis as omissões e mais fácil a verificação dos requisitos

Use uma linguagem consistente para distinguir entre os requisitos obrigatórios e os desejáveis

"deve" para obrigatórios e "pode" para não essenciais

Use uma forma de destacar as partes fundamentais do requisito (negrito, itálico ou cores)

Não assumir que os leitores compreendem a linguagem técnica da engenharia de software

Especifcações estruturadas

A liberdade do escritor dos requisitos é limitada

Todos os requisitos são escritos em uma forma-padrão

Pode usar construções de linguagem de programação para mostrar alternativas e iteração

Pode destacar elementos-chave pelo uso de sombreamento ou fontes diferentes

Pode definir um ou mais templates para representar esses requisitos como formulários estruturados

A especificação pode ser estruturada em torno dos objetos manipulados pelo sistema, das funções desempenhadas pelo sistema, ou pelos eventos processados pelo sistema

As tabelas são particularmente úteis quando há um número de situações alternativas possíveis e é necessário descrever as ações a serem tomadas para cada uma dela

Quando um formulário-padrão é usado para especificar requisitos funcionais é necessário:

1. A descrição da função ou entidade a ser especificada

2. Uma descrição de suas entradas e de onde elas vieram

3. Uma descrição de suas saídas e para onde elas irão

4. Informações sobre a informação necessária para o processamento ou outras entidades usadas no sistema

5. Uma descrição da ação a ser tomada

6. Se uma abordagem funcional é usada, uma pré-condição define o que deve ser verdade antes que a função
seja chamada, e é chamada uma pós-condição, especificando o que é verdade depois da função

7. Uma descrição dos efeitos colaterais da operação

Vantagens:

Reduz-se a variabilidade na especificação

Os requisitos são organizados de forma mais eficaz

Desvantagens

Difícil escrever os requisitos de forma clara e inequívoca, especialmente quando processamentos complexos (como, por exemplo, calcular a dose de insulina) devem ser especificados

Solução: adicionar informações extras aos requisitos em linguagem natural, usando tabelas ou modelos gráficos do sistema