Please enable JavaScript.
Coggle requires JavaScript to display documents.
Engenharia de Requisitos- Aula 02 (Possível organização de um documento de…
Engenharia de Requisitos- Aula 02
Requisitos
Compreender como os requisitos
podem ser oganizados num documento
de requisitos
Entender porque a gerência de requisitos é necessaária
Compreender as
principais atividade
Análise
Elicitação
Validação
E as relações entre essas aividades
Documento de requisitos de software -Declaração oficial que os desenvolvedores devem imlementar
devem incluir tanto os requisitos de usuários quanto os requisitos de sistema
Não é um documento de projeto - define O QUE o sistema deve fazer e não COMO deverá faze-lô
Métodos ágeis dizem que os requisitos mudam tão rapidamente que produzir um documento de requisitos está ultrapassado
Abordagens como XP coletam os requisitos de usuário de forma incremental e escrevem-nos como estórias de usuários
Isso é prático para sistemas de negócio, mas problemático para sistemas críticos ou desenvolvidos por diferentes equipes( às vezes, localizadas geograficamente distantes )
Documentos de
Requisitos
Possuem um conjunto
diversificado de usuários
Engenheiros do sistema - Usam os requisitos para entender o sistema que será desenvolvido
Engenheiros de teste de sistema - usam os requisitos para desenvolver testes de validação do sistema
Gerentes - Usam o documento de requisitos para planejar uma proposta para o sistema e para planejar o processo de desenvolvimento do sistema
Engenheiros de manutenção do sistema - Usam os requisitos para entender o sistema e os relacionamentos entre suas partes.
Clientes do sistema - Especificam e leem os requisitos para verificar se esse satisfazem as suas necessidades. Os clientes especificam as alteraçõs nos requisitos
O nível de detalhes em um documento de requisitos depende do tipo de sistema em desenvolvimento e o processo usado
Sistemas críticos ou sistemas que estejam sendo desenvolvidos por diferentes empresas devem ter especificações detalhadas e precisas
Sistemas desenvolvidos incrementalmente dentro de uma mesma empresa( e.g. onde a comunicação é rápida e fácil)podem usar um documento menos detalhados.
Possível organização de um documento de requisitos baseada em uma norma IEEE estendida por Sommerville(2011)
Glossário
- Deve definir os termos técnicos usados no documento. Você não deve fazer suposições sobre a experiência ou o conhecimento do leitor.
Definições dos requisitos do usuários
- deve descrever os serviços oferecidos ao usuário. Os requisitos não funcionais de sistema também devem ser descritos nessa seção. Essa descrição pode usar a linguagem natural, diagramas ou outras notações compreensíveis para os clientes. Normas de produto e processos que devem ser seguidos devem ser especificados.
Arquitetura do sistema
- Deve apresentar uma visão geral em alto nível da arquitetura do sistema previsto, mostrando a distribuição de funções entre os módulos do sistema. Componentes de arquitetura que são reusados devem ser destacados
Especificação de requisitos do sistema
- Deve descrever em detalhes os requisitos funcionais e não funcionais. Se necessário, também podem ser adicionados mais detalhes aos requisitos não funcionais. Interfaces com outros sistemas podem ser definidas.
Modelos do sistema
- Pode incluir modelos gráficos do sistema que mostram os relacionamentos entre os componentes do sistema, o sistema e seu ambiente. Exemplos de possíveis modelos são modelos de objetos, modelos de fluxo de dados ou modelos semânticos de dados.
Evolução do sistema
- Deve descrever os pressupostos fundamentais em que o sistema se baseia, bem como quaisquer mudanças previstas, em decorrência da evolução de hardware, de mudanças nas necessidades do usuário etc, essa seção é útil para projetistas de sistemas, pois pode ajudá-los a evitar decisões capazes de restringir possíveis mudanças futuras no sistema.
Introdução
- Deve descrever a necessidade para o sistema. Deve descrever brevemente as funções do sistema e explicar como ele vai funcionar com outros sistemas. Também deve descrever como o sistema atende aos objetivos globais de negócio ou estratégicos da organização que encomendou o software
Apêndices
- Deve fornecer informações detalhadas e específicas relacionadas à aplicação em desenvolvimento, além de descrições de hardware e banco de dados, por exemplo. Os requisitos de hardware definem as configurações mínimas ideais para o sistema. Requisitos de banco de dados definem a organização lógica dos dados usados pelo sistema e os relacionamentos entre esses dados.
Prefácio
- Deve definir os possíveis leitores do documento e descrever sus históricos de versões, incluindo uma justificativa para a criação de uma nova versão e um resumo das mudanças em cada versão
Índice
- Vários índices podem ser incluídos no documento. Pode haver, além de um índice alfabético normal, um índice de diagramas, de funções, entre outros pertinentes.
Especificação
dos Requisitos
Rquisitos de sistema são mais detalhados e podem conter informações mais técnicas
Os requisitos precisam ser compreensíveis para os usuários finais e clientes que não têm formação técnica
Os requisitos podem ser parte de um contrato para o desenvolvimento de um sistema
Portanto é importate que esses sejam tão completos quanto possível
O processo de escrever requisitos de usuário e de sistema em um documento de requisitos
Como escrever um
documento de requisitos?
Linguagem natural estruturada
- Os requisitos são escritos em linguagem natural em um formulário padrão ou template. Cada campo fornece informações sobre um aspecto do requisito
Sentença em linguagem natural
- Os requisitos são escritos em frases numeradas em linguagem natural. Cada frase deve expressar um requisito.
Linguagem de descrição de projeto
- Essa abordagem usa uma linguagem como de programação, mas com características mais abstratas, para especificar os requisitos, definindo um modelo operacional do sistema. Essa abordagem é pouco usada atualmente, embora possa ser útil para as especificações de interface
Notações gráficas
- Para definições de requisitos funcionais para o sistema são usados modelos gráficos, suplementados por anotações de texto; diagramas de caso de uso e de sequência da UML são comumente usados.
Especificações matemáticas
- Essas notações são baseadas em conceitos matemáticos, como máquinas de estado finito ou conjuntos. Embora essas especificações inequívocas possam reduzir a ambiguidade de um documento de requisitos, a maioria dos clientes não entende uma especificação formal. Eles não podem verificar que elas representam o que eles querem e são relutantes em aceitá-las como um contrato de sistema.
Projeto de
Requisitos
Em princípio, os requisitos devem indicar o que os sistema deve fazer e o projeto deve descrever como fazer isso.
Ná prática, os requisitos
e o projeto são inseparáveis
A arquitetura do sistema pode ser projetada para estruturar os requisitos
O sistema pode interoperar com outros sistemas que restringem o projeto e impõem outros requisitos sobre o novo sistema.
O uso de uma arquitetura específica para satisfazer os requisitos não funcionais pode ser um requisito de domínio.
Essa pode ser a consequência de um requisito de um regulador tão completos quanto possível
Especificação em
linguagem natural
Os requisitos são escritos como
sentenças em linguagem natural
complementadas por diagramas
e tabelas.
Isso significa que os requisitos
podem ser entendidos pelos
usuários e pelos clientes.
Usado para escrever os
requisitos, pois é expressivo,
intuitivo e universal.
Diretrizes para
escrever requisitos
Inventar um formato padrão e usá-lo para todos os requisitos.
Usar a linguagem de uma forma consistente.
Usar ‘deve’ para requisitos obrigatórios e ‘pode’ para os requisitos desejáveis.
Usar o realce de texto para identificar as partes fundamentais do requisito.
Incluir uma justificava (lógica) de por que um requisito é necessário.
Evitar o uso de jargões de computador.
Problemas com
a linguagem natural
Confusão de requisitos - Requisitos funcionais e não funcionais tendem a ser misturados.
Amálgama de requisitos - Vários requisitos diferentes podem ser expressos juntos.
Falta de clareza - É difícil conseguir precisão sem tornar o documento difícil de ler
Especificações
estruturadas
Uma abordagem para escrever requisitos em que a liberdade do escritor de requisitos é limitada e os requisitos são em maneira padrão
Isso funciona bem para alguns tipos de requisitos , por exemplo, requisitos para o sistema embutido de controle, mas às vezes é demasiado rígido para escrever os requisitos de sistema de negócios.
Podem conter os
seguintes campos:
Definição da função ou entidade.
Descrição de entradas e de onde eles vêm.
Descrição das saídas e para onde irão.
Informações sobre as informações necessárias para o
processamento e outras entidades usadas.
Descrição da ação a ser tomada.
Pré-pós condições (se for o caso).
Os efeitos colaterais (se houver) da operação.
Especificação
tabular
Particularmente útil quando é necessário definir um número de situações alternativas possíveis.
Por exemplo, o sistema de bomba de insulina, baseia seus cálculos sobre a taxa de mudança de nível de açúcar no sangue e a especificação tabular explica como calcular a necessidade de insulina para diferentes cenários
Usados para complementar a linguagem natural.
Processos de
Engenharia de Requisitos
Os processos usados para a engenharia de requisitos variam muito, dependendo do domínio da aplicação, das pessoas envolvidas e da organização que desenvolve os requisitos
No entanto, existe uma série de
atividades genéricas comuns a
todos os processos
Elicitação de requisitos;
Análise de requisitos;
Validação de requisitos;
Gerenciamento de requisitos.
Na prática, engenharia de requisitos é uma
atividade iterativa em que estes processos
são intercalados
Um visão em espiral do processo
de engenharia de requisitos
Aqui Espiral de requisitos
Elicitação e análise
de requisitos
É a primeira atividade no processo da engenharia de
requisitos
meta mais importante é definir os
problemas que serão resolvidos pelo
sistema e os seus limites
Limites definem onde o sistema sendo produzido vai
se encaixar no ambiente operacional no qual ele será utilizado
Outros passos
importantes são:
Identificação dos stakeholders
Objetivos que o sistema deve alcançar
Os técnicos trabalham juntamente
com os clientes, vão levantar:
Os dados sobre o domínio da aplicação
Os serviços que o sistema deve fornecer
As restrições operacionais do sistema
Algumas técnicas de
elicitação de requisitos
Questionários surveys
Análise
documental
De documentos existentes contendo
a descrição de processos ou manuais
de sistemas existentes
Entrevistas
Formais ou informais com os stakeholders
Individuais ou forma de dinâmica de grupo (grupos
focais)
Cenários
exemplos da vida real de como um sistema pode ser
usado
Podem incluir a descrição da situação atual, do fluxo normal de eventos, do que pode dar errado, do estado final do sistema quando o cenário acaba
Casos de uso
é uma técnica da UML baseada em cenários que identificam os atores em uma interação e que descreve a interação em si.
Etnografia
Um analista gasta um tempo considerável observando e analisando como as pessoas realmente trabalham
Ele pode também participar da atividade (observação
participante)
Modelagem e
análise de requisitos
Modelagem
do negócio
Utilizando modelos
apropriados para isso
BPMN que pode ajudar
na descoberta e no desenho
dos processos de negócio
Modelagem
de dados
Modelo entidade-relacionamento
Modelagem
comportamental
Envolve a modelagem comportamental dos stakeholders
e do sistema, existentes e futuros
Modelagem
do domínio
Descrição abstrata do mundo no qual o sistema irá operar
Validação
de Requisitos
Processo que verifica se os requisitos definem o que o sistema do cliente realmente quer
A validação de requisitos é 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
O custo para consertar um problema de requisitos por meio de
uma mudança no sistema é geralmente muito maior do que o
custo de consertar erros de projeto ou de codificação
Técnicas de
Validação dos
Requisitos
Revisões de requisitos
Análise manual sistemáica dos requisitos.
Prototipação
Usando um modelo executável do sistema para verificar os
requisitos.
Geração de casos de teste
Desenvolvimento de testes para verificar os requisitos
implementados.
Gerenciamento de Requisitos
Requisitos de sistemas de software estão sempre mudando!!!
Refinamento dos requisitos
Mudanças da organização
Requisitos incompletos
Mudanças de gerência
Surgimento de novos requisitos, etc.
Gerenciamento de requisitos é o
processo de compreensão e controle destas
mudanças nos requisitos do sistema
Tanto na engenharia de
requisitos, quanto no
desenvolvimento
do sistema
Estágios do Gerenciamento
de Requisitos
São dois:
Planejamento do
gerenciamento de
requisitos
É o primeiro estágio essencial no processo de gerenciamento de requisitos do sistema e determina o nível de detalhamento necessário no gerenciamento de requisitos
Define soluções como identificação de requisitos, política de rastreamento e ferramentas de apoio
Gerenciamento da
mudança de requisitos
Feito logo após a aprovação do documento de requisitos, o gerenciamento da mudança de requisitos é essencial visto que é necessário se avaliar, a cada modificação, se ela justifica os custos envolvidos
A vantagem de se ter um processo formal de gerenciamento de mudanças é que todas as propostas de mudança são tratadas de forma consistente e as alterações são feitas de maneira controlada
É composta pela (i) análise do problema e especificação de mudanças, (ii) análise de mudança e custos e (iii) a implementação de mudanças
FIM