O documento discute a engenharia de requisitos, definindo-a como o processo de coleta, análise, documentação e gerenciamento de requisitos ao longo do ciclo de vida de um software. Detalha os principais conceitos como requisito, stakeholder e as atividades-chave da engenharia de requisitos: elicitação, documentação, validação e gerenciamento. Também aborda tipos de requisitos, desafios da análise de requisitos e a importância de um processo eficiente de engenharia de requisitos.
PROJETO DE EXTENSÃO I - TERAPIAS INTEGRATIVAS E COMPLEMENTARES.pdf
Requisitos ER e tipos de requisitos
1. Universidade Federal da Paraíba - UFPB
Programa de Pós Graduação em Informática- PPGI
Engenharia de Software
Mestrado – UFPB
Mestranda
Stephany Vitório
Capítulo 04 do livro de Sommerville Ed. 9
Engenharia de Requisitos
2. Roteiro
O que é Requisito, Engenharia de Requisitos e Stakeholder?
Importância da Engenharia de Requisitos
Atividades principais da ER
Requisitos
Tipos de Requisitos
Requisitos de Qualidade
Características Importantes
3. O que é requisito?
Uma descrição do que o sistema tem que fazer.
“Condição que se deve satisfazer para alcançar um objetivo”
4. O que é requisito?
Condição para satisfazer um contrato, um padrão, especificação ou outro
documento formalmente imposto.
“Exigência que deve ser cumprida para atingir um objetivo”
5. O que é Engenharia de Requisitos?
“É o processo pelo qual os requisitos de um produto de software são
coletados, analisados, documentados e gerenciados ao longo de todo o
ciclo de vida do software.”
“É a ciência que estuda a criação, construção, análise, desenvolvimento
e manutenção dos requisitos que devem ser cumpridos por um sistema.”
6. O que é Engenharia de Requisitos?
Engenharia de requisitos é uma abordagem sistemática e disciplinada
para a especificação e gerenciamento de requisitos com os seguintes
objetivos:
Conhecer os requisitos pertinentes, alcançar um consenso entre os
stakeholders sobre esses requisitos, documentando-os de acordo com
as normas dadas e gerenciando-as sistematicamente.
Compreender e documentar os desejos e necessidades dos
stakeholders, que especifica o gerenciamento de requisitos para
minimizar o risco de entregar um sistema que não atende os desejos
das partes interessadas.
7. O que é Stakeholder?
“É uma pessoa ou uma organização que tem algum impacto direto ou
indireto sobre os requisitos do sistema.”
Interessados Envolvidos
8. Importância da Engenharia de
Requisitos
“A parte mais árdua na construção de um software consiste exatamente
em identificar o que construir . Nenhuma outra fase compromete tanto o
resultado do trabalho se elaborada de forma incorreta. Nenhuma outra
parte dificulta tanto as correções posteriores.” Frederick P. Brooks
Problemas com requisitos levam a:
- Clientes insatisfeitos;
- Altos custos;
- Perda de reputação;
- Compreensão do “problema incorreto”;
- Efeito cascata nas demais fases de desenvolvimento de software.
11. Problemas de Comunicação
Quando conversar com um colega
de trabalho ou um cliente, lembre-
se de que a comunicação
transcende as palavras .” Mari
Geuer
Omissão de Requisitos
12. Sintomas e Causas de uma ER
inadequada
Pressão do cliente para uma
construção rápida do sistema
“Temos que nos acostumar com a
pressão. Mais além, toda vez que
sentirmos pressão, mentalizar que
isso nos ajuda a alcançar nossos
objetivos. Dá-nos mais gás para agir
em direção à nossa meta.” Lauro
Valente
Requisitos Incorretos
13. Sintomas e Causas de uma ER
inadequada
Suposição incorreta, por parte dos
stakeholders, de que muito do
assunto é evidente
“Geralmente as pessoas falham em
serem bons ouvintes. Elas
simplesmente presumem que
sabem o que a outra pessoa esta
dizendo ou simplesmente porque
elas já ouviram isso antes adotam a
ideia de que aquela pessoa é igual
a outra “
Requisitos Ambíguos
15. Elicitação
Para a etapa de identificação,
levantamento e detalhamento de
requisitos, podem ser utilizadas
diversas técnicas, como, entrevista,
estudo arqueológico, JAD,
brainstorming, dentre outros.
O engenheiro de requisitos precisa
extrair, sugar todas as informações
possíveis dos stakeholders e
identificar requisitos através de
pesquisas.
16. Documentação
Para documentar requisitos podem
ser utilizadas a linguagem natural e
modelos formais, utilizando UML,
como por exemplo, diagrama de
estado, sequência, casos de uso e
especificações de casos de uso.
É importante registrar as
informações coletadas e
identificadas na etapa de
levantamento de requisitos de
forma adequada.
17. Validação e Negociação
Para negociar e validar os
requisitos é importante ter a
avaliação de um especialista, de
modo que possa ser verificado se o
que foi levantado condiz com o
que foi solicitado.
Deve ser garantida a qualidade
dos requisitos, validando se estão
corretos. Para isso é importante
negociar com o cliente o que
realmente é necessário para o
produto.
18. Gerenciamento
Gerenciar consiste em manter os dados
consistentes, com qualidade garantindo
que eles possam ser implementados. É
uma etapa ortogonal as outras 3 visto
que trabalha garantindo a execução
destas.
Compreende todas as medidas que são
necessárias às exigências de estrutura
para que as outras 3 etapas da ER possa
ocorrer.
19. Tipos de Requisitos de Sistema
Requisitos Funcionais
- Descrevem os serviços que se espera que o sistema deve oferecer.
- Especificam as funcionalidades do sistema.
Requisitos Não Funcionais
- Descrevem aspectos de qualidade que o software deverá apresentar, ou as
restrições a serem atendidas.
- Os requisitos não funcionais referem-se às condições nas quais deve funcionar
o sistema.
- Podem estar relacionados a propriedades do sistema, tais como,
confiabilidade, desempenho, etc.
20. Como especificar requisitos funcionais?
Linguagem Natural
- Os requisitos funcionais
podem ser descritos em
linguagem natural em nível
macro.
Casos de uso
- Um modelo de casos de uso
é utilizado para representar
as funcionalidades do
sistema de forma detalhada.
- Um modelo de casos de uso
identifica quem ou o que
interage com o sistema e o
que sistema deve fazer.
- Casos de uso são técnicas
baseadas em cenários onde
são identificados atores e
sua interação com o
sistema.
22. TIPOS DE REQUISITOS NÃO FUNCIONAIS
(Sommerville)
Requisitos de produtos
- São os requisitos que especificam o comportamento do produto.
- Exemplo: requisitos de desempenho, que especificam com que rapidez o sistema
deve operar.
Requisitos organizacionais
- São procedentes de políticas e procedimentos nas organizações do cliente e do
desenvolvedor.
- Entre os exemplos estão os padrões de processos que devem ser utilizados, os
requisitos de implementação, como a linguagem de programação ou a
metodologia de processo de desenvolvimento.
Requisitos externos
- Abrange todos os requisitos procedentes de fatores externos ao sistema e ao seu
processo de desenvolvimento.
- Exemplo: requisitos de interoperabilidade, requisitos legais, requisitos éticos.
23. Desafios da Análise de Requisitos
Como descobrir os requisitos;
Como comunicar os requisitos para as outras fases ou equipes do projeto;
Como lembrar dos requisitos durante o desenvolvimento e verificar se
foram todos atendidos
Como gerenciar a mudança
24. Conclusão
Um processo de engenharia de requisitos eficiente evita uma
compreensão incorreta dos requisitos.
25. Universidade Federal da Paraíba - UFPB
Programa de Pós Graduação em Informática- PPGI
Engenharia de Software
Mestrado – UFPB
Mestranda
Stephany Vitório
Capítulo 04 do livro de Sommerville Ed. 9
Engenharia de Requisitos
Hinweis der Redaktion
Requisitos de um sistema são descrições dos serviços que devem ser fornecidos por esse sistema e as suas restrições operacionais
(SOMMERVILLE, 2007).
Um requisito de um sistema é 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).
Requisito é (são):
“Descrições das funções e das restrições de um sistema” “Definição detalhada, matematicamente formal, de uma função do sistema” Sommerville p. 82
“uma descrição dos principais recursos de um produto de software, seu fluxo de informações, comportamento e atributos. Fornece uma estrutura básica para o desenvolvimento de um produto de software. O grau de compreensibilidade, precisão e rigor da descrição fornecida por um documento de requisitos de software tende a ser diretamente proporcional ao grau de qualidade do produto resultante”
Engenharia de Requisitos é:
“Estabelecer quais funções são requeridas pelo sistema e as restrições sobre a operação e o desenvolvimento do sistema” Sommerville p. 46
Atores no Processo de Engenharia de Requisitos: Stakeholders Quem são os “interessados no sistema”? São as pessoas que serão afetadas pelo sistema e que têm uma influência direta ou indireta na elaboração dos requisitos: usuários finais, gestores e outros envolvidos nos processos organizacionais que o sistema influencia, responsáveis pelo desenvolvimento e manutenção do sistema, clientes da organização que possam vir a usar o sistema, organismos de regulação e certificação, etc.
Documentação: Descrição Linguagem natural Modelos formais
Elicitação: Levantamento Técnicas de identificação Detalhamento
Validação: Garantia de qualidade Resolução de Conflitos Consistência das informações
Entrevistas e questionários Workshops, Brainstorming Storyboard Casos de Uso Representação (role playing) Construção de protótipos Análise de textos
Exemplos de Requisitos Funcionais:
O sistema deve permitir o cálculo dos gastos diários, semanais, mensais e anuais com o pessoal.
O sistema deve permitir consultar informações gerenciais operacionais da empresa.
Exemplos de Requisitos Não Funcionais:
O tempo de resposta do sistema não deve ultrapassar 30 segundos.
O software deve ser operacionalizado no sistema Linux..
O sistema deve ter uma disponibilidade 24x7.
Requisitos funcionais correspondem à listagem de todas as coisas que o sistema deve fazer;
Requisitos não funcionais são restrições e qualidades que se coloca sobre como o sistema deve realizar seus requisitos funcionais;
Todos os Requisitos Funcionais devem ser satisfeitos, mas se os Requisitos Não-Funcionais forem negligenciados, o sistema falhará.
Usabilidade:requisitos que selecionam ou afetam a usabilidade do sistema. Exemplos incluem a facilidade de uso e a necessidade ou não de treinamento dos usuários.
Confiabilidade: Tratamento de falhas, possibilidade de previsão, não erros de programação;
Desempenho: Velocidade, eficiência, precisão, tempo de recuperação, tempo de resposta, uso de recurso, etc;
Configurabilidade: O que pode ser configurado pelos usuários do sistema;
Portabilidade:restrições sobre a plataforma de hardware e de software nas quais o sistema será implantado e sobre o grau de facilidade para transportar o sistema para outras plataformas.
Segurança: Permissões de usuários do sistema;