Assuntos abordados
Requisitos funcionais e não-funcionais
Processos de engenharia de requisitos
Levantamento de requisitos
Especificação de requisites
Validação de requisites
Mudança dos requisitos
Capítulo 4 Engenharia de Requisitos 22017/2018
Engenharia de requisitos
O processo de definir os serviços que um cliente exige
de um sistema e as restrições sob as quais opera e é
desenvolvido.
Os requisitos de sistema são as descrições dos serviços
do sistema e as limitações que são geradas durante o
processo de engenharia de requisitos.
Capítulo 4 Engenharia de Requisitos 32017/2018
O que é um requisito?
Pode variar de uma declaração abstrata de alto nível deum serviço ou de uma restrição de sistema para umaespecificação matemática funcional.
Os requisitos podem servir uma dupla função
Pode ser a base para uma proposta de um contrato - portanto,deve ser aberto à interpretação;
Pode ser a base para o próprio contrato - portanto deve serdefinido em detalhe;
Ambas as declarações podem ser chamadas requisitos.
Capítulo 4 Engenharia de Requisitos 42017/2018
Requisitos abstração
Capítulo 4 Engenharia de Requisitos 5
“Se uma empresa quer um contrato para um projeto de
desenvolvimento de software de grande porte, deve definir as suas
necessidades de forma suficientemente abstrata. Os requisitos devem
ser escritos de forma que vários contratantes podem concorrer para o
contrato, oferecendo, talvez, diferentes maneiras de atender às
necessidades da organização cliente. Uma vez que um contrato foi
adjudicado, o contratante deve escrever uma definição do sistema para
o cliente com mais detalhes para que o cliente possa entender e validar
o que o software vai fazer. Ambos os documentos podem ser chamados
de documento de requisitos para o sistema “.
2017/2018
Tipos de requisitos
Requisitos do utilizador
Descrições em linguagem natural, mais diagramas de serviços
do sistema e as suas restrições operacionais. Escrito para os
clientes.
Requisitos de sistema
Um documento estruturado, estabelecendo descrições
detalhadas das funções do sistema, serviços e restrições
operacionais. Define o que deve ser implementado, assim pode
ser parte de um contrato entre o cliente e o contratante.
Capítulo 4 Engenharia de Requisitos 62017/2018
Os leitores de diferentes tipos de especificação
de requisitos
Capítulo 4 Engenharia de Requisitos 82017/2018
Stakeholders do sistema
Qualquer pessoa ou organização que é afetada pelo
sistema de alguma maneira e que tem um interesse
legítimo
Tipos de partes interessadas
Utilizadores finais
Gestores do sistema
Os proprietários do sistema
Partes interessadas externas
Capítulo 4 Engenharia de Requisitos 92017/2018
As partes interessadas no sistema Mentcare
Pacientes cujas informações são registadas no sistema.
Médicos que são responsáveis pela avaliação e
tratamento dos pacientes.
Enfermeiros que coordenam as consultas com médicos
e que podem administrar alguns tratamentos.
Recepcionistas que gerem as consultas dos pacientes.
A equipa de TI que são responsáveis pela instalação e
manutenção do sistema.
Capítulo 4 Engenharia de Requisitos 102017/2018
As partes interessadas no sistema Mentcare
Um gerente de ética médica, que deve garantir que o
sistema atende às diretrizes éticas para o atendimento
do paciente.
Gestores de saúde que obtêm informações da gestão do
sistema.
Funcionários de registros médicos que são
responsáveis por garantir que as informações do
sistema podem ser mantidos e preservados, e que os
procedimentos de registos foram correctamente
executadas.
Capítulo 4 Engenharia de Requisitos 112017/2018
Métodos ágeis e requisitos
Muitos métodos ágeis argumentam que a produção de
requisitos detalhados do sistema é um desperdício de
tempo, porque requisitos mudam rapidamente.
Assim, o documento de requisitos está sempre
desatualizado.
Métodos ágeis normalmente usam a engenharia de
requisitos incremental e podem expressar requisitos
como ‘relatos dos utilizadores’.
Isto é prático para os sistemas de negócios, mas
problemático para sistemas que requerem análise de
pré-entrega (por exemplo, sistemas críticos) ou sistemas
desenvolvidos por várias equipas.Capítulo 4 Engenharia de Requisitos 122017/2018
Requisitos funcionais e não-funcionais
Requisitos funcionais
Descrição de serviços que o sistema deve fornecer, como osistema deve reagir a entradas específicas e como o sistemadeve se comportar em situações particulares.
Pode-se apresentar o que o sistema não deve fazer.
Requisitos não funcionais
Constrangimentos sobre os serviços ou funções oferecidas pelosistema, tais como restrições de tempo, as limitações noprocesso de desenvolvimento, padrões, etc..
Muitas vezes se aplicam ao sistema como um todo, em vez derecursos ou serviços individuais.
Requisitos de domínio
Restrições sobre o sistema a partir do domínio de operação
Capítulo 4 Engenharia de Requisitos 142017/2018
Requisitos funcionais
Descrevem funcionalidades ou serviços do sistema.
Dependem do tipo de software, dos utilizadores
esperados e o tipo de sistema onde o software é usado.
Requisitos funcionais do utilizador podem ser descrições
de alto nível do que o sistema deve fazer.
Requisitos funcionais do sistema devem descrever os
serviços do sistema em detalhe.
Capítulo 4 Engenharia de Requisitos 152017/2018
Sistema Mentcare: requisitos funcionais
Um utilizador deve ser capaz de pesquisar as listas de
consultas para todas as clínicas.
O sistema deve gerar todos dia, para cada clínica, uma
lista de pacientes que são esperados para as consultas
naquele dia.
Cada membro da equipa que usa o sistema deve ser
unicamente identificado por seu número de funcionário
de 8 dígitos.
Capítulo 4 Engenharia de Requisitos 162017/2018
Imprecisão nos requisitos
Os problemas surgem quando os requisitos funcionais
não são definidos com rigor.
Requisitos ambíguos podem ser interpretados de
maneiras diferentes pelos programadores e utilizadores.
Considere o termo 'Search' no requisito 1
intenção do utilizador - busca por um nome do paciente em
todas as consultas, em todas as clínicas;
Interpretação do programador - busca por um nome do paciente
em uma clínica individual. O utilizador escolhe a clínica, em
seguida procura.
Capítulo 4 Engenharia de Requisitos 172017/2018
Integridade e consistência dis requisitos
Em princípio, os requisitos devem ser completos e
consistentes.
Completo
Eles devem incluir descrições de todas as instalações
necessárias.
Consistente
Não deve haver conflitos ou contradições nas descrições dos
recursos de sistema.
Na prática, por causa do sistema e complexidade
ambiental, é impossível produzir um documento de
requisitos consistente e completo.
Capítulo 4 Engenharia de Requisitos 182017/2018
Requisitos não funcionais
Estes definem as propriedades do sistema e limitações,por exemplo, fiabilidade, tempo de resposta e osrequisitos de armazenamento. As restrições são I / O dacapacidade do dispositivo, representações de sistema,etc.
Requisitos de processo podem também serespecificados impondo um determinado IDE, linguagemde programação ou método de desenvolvimento.
Os requisitos não-funcionais podem ser mais críticos doque os requisitos funcionais. Se estes não forematendidos, o sistema pode ser inútil.
Capítulo 4 Engenharia de Requisitos 192017/2018
Implementação dos requisitos não-funcionais
Requisitos não funcionais podem afetar a arquitetura
geral de um sistema, em vez de componentes
individuais.
Por exemplo, para garantir que os requisitos são cumpridos,
pode-se ter que organizar o sistema para minimizar a
comunicação entre componentes.
Um requisito não funcional único, como um requisito de
segurança, pode gerar uma série de requisitos
funcionais relacionados que definem os serviços do
sistema que são necessários.
Também pode gerar requisitos que restringem os requisitos
existentes.
Capítulo 4 Engenharia de Requisitos 212017/2018
Classificações não funcionais
Requisitos do produto
Requisitos que especificam como o produto entregue, se deve
comportar por exemplo, velocidade de execução, confiabilidade,
etc.
Requisitos organizacionais
Requisitos que são uma consequência de políticas e
procedimentos organizacionais padrões, por exemplo processos
utilizados, requisitos de aplicação, etc.
Exigências externas
Requisitos que surgem a partir de fatores que são externos para
o sistema e os requisitos de interoperabilidade desenvolvimento
do processo, por exemplo, exigências legislativas, etc.
Capítulo 4 Engenharia de Requisitos 222017/2018
Exemplos de requisitos não funcionais no
sistema Mentcare
Capítulo 4 Engenharia de Requisitos 23
Requisitos do produtoO sistema Mentcare deve estar disponível para todas as clínicas durante o horário normal de trabalho (Seg-Sex, 08:30-17.30). O tempo de inatividade dentro das horas normais de trabalho não deve exceder cinco segundos em qualquer dia.
Requisito organizacionalUtilizadores do sistema Mentcare deve autenticar-se usando o seu cartão de identidade de saúde.
Exigência externaO sistema deve implementar as disposições de privacidade do paciente tal como estabelecido no HStan-03-2006-priv.
2017/2018
Objetivos e requisitos
Requisitos não funcionais podem ser muito difíceis de
definir com rigor e requisitos imprecisos podem ser
difíceis de verificar.
Objetivo
A intenção geral do utilizador tal como facilidade de uso.
Requisito não funcional verificável
Uma descrição usando alguma medida que pode ser
objetivamente testada.
Metas são úteis para programadores quando exprimem
as intenções dos utilizadores do sistema.
Capítulo 4 Engenharia de Requisitos 242017/2018
Os requisitos de usabilidade
O sistema deve ser fácil de usar por pessoal médico e
deve ser organizado de tal forma que os erros dos
utilizadores sejam minimizados. (Objetivo)
A equipa médica deve ser capaz de usar todas as
funções do sistema depois de quatro horas de
treinamento. Após este treinamento, o número médio de
erros cometidos por utilizadores experientes não
excederá dois por hora de uso do sistema. (Requisito
não funcional Testável)
Capítulo 4 Engenharia de Requisitos 252017/2018
Métricas para especificar requisitos não
funcionais
Capítulo 4 Engenharia de Requisitos 26
Propriedade A medida
Rapidez transações processadas / segundo
User / tempo de resposta por evento
tempo de atualização do monitor
Tamanho Mbytes
Número de chips de memória ROM
Fácil de usar Tempo de treino
Número de pedidos de ajuda
Confiabilidade Tempo até a falha
Probabilidade de indisponibilidade
Taxa de ocorrência de falha
Disponibilidade
Robustez Tempo para reiniciar após falha
Percentagem de eventos que levam à insuficiência
Probabilidade de corrupção de dados em caso de falha
portabilidade Percentagem de declarações dependentes
Número de sistemas de destino
2017/2018
Processos de engenharia de requisitos
Os processos utilizados para engenharia de requisitosvariam muito, dependendo do domínio de aplicação, aspessoas envolvidas e da organização que desenvolveos requisitos.
No entanto, há uma série de atividades genéricascomuns a todos os processos
Levantamento de requisitos;
Análise de requisitos;
A validação de requisitos;
A gestão de requisitos.
Na prática, engenharia de requisitos é uma atividadeiterativa em que estes processos são intercalados.
Capítulo 4 Engenharia de Requisitos 282017/2018
Uma visão espiral do processo de engenharia de
requisitos
Capítulo 4 Engenharia de Requisitos 292017/2018
Levantamento de requisitos e análise
Envolve pessoal técnico a trabalhar com os clientes para
descobrir sobre o domínio de aplicação, os serviços que
o sistema deve fornecer e as restrições operacionais do
sistema.
Pode envolver utilizadores finais, gestores, engenheiros
envolvidos na manutenção, especialistas de domínio,
sindicatos, etc. Estes são chamados partes
interessadas.
Capítulo 4 Engenharia de Requisitos 312017/2018
Levantamento de requisitos
Os engenheiros de software trabalham com uma
variedade de stakeholders do sistema para obter
informações sobre o domínio da aplicação, os serviços
que o sistema deve fornecer, o desempenho do sistema
necessárias, as restrições de hardware, outros sistemas,
etc.
Inclui as etapas:
Descoberta de requisitos,
Classificação e organização de requisitos.
Priorização e negociação de requisitos,
Especificação de requisitos.
Capítulo 4 Engenharia de Requisitos 332017/2018
Problemas no levantamento de requisitos
As partes interessadas não sabem o que eles realmente
querem.
Stakeholders expressam requisitos nos seus próprios
termos.
Diferentes partes interessadas podem ter requisitos
conflituantes.
Fatores organizacionais e políticas podem influenciar os
requisitos do sistema.
Os requisitos mudam durante o processo de análise.
Novos stakeholders podem surgir e o ambiente de
negócios pode mudar.
Capítulo 4 Engenharia de Requisitos 342017/2018
atividades de processo
Descoberta de requisitos
Interagir com as partes interessadas para descobrir as suasnecessidades. Os requisitos de domínio também sãodescobertos nesta fase.
Classificação e organização dos requisitos
Grupos de requisitos relacionados, organizam-se em gruposcoerentes.
Priorização e negociação
Priorizar e resolver conflitos de requisitos.
Especificação de requisitos
Os requisitos são documentados.
2017/2018 Capítulo 4 Engenharia de Requisitos 36
Descoberta de requisitos
O processo de recolha de informações sobre os
sistemas necessários e existentes, filtra-se as
necessidades dos utilizadores.
Interação com as partes interessadas do sistema, de
gestores para reguladores externos.
Sistemas normalmente têm uma gama de partes
interessadas.
Capítulo 4 Engenharia de Requisitos 372017/2018
Entrevistar
Entrevistas formais ou informais com as partes interessadas são
parte da maioria dos processos de engenharia de requisitos.
Tipos de entrevista
entrevistas fechadas com base em lista pré-determinada de perguntas.
entrevistas abertas, onde vários assuntos são explorados com as
partes interessadas.
Entrevista eficaz
Ter uma mente aberta, evitar idéias pré-concebidas sobre os requisitos
e sempre dispostos a ouvir as partes interessadas.
Induzir os entrevistados para obter discussões, usar uma pergunta
trampolim, uma proposta de requisitos, ou trabalhar em conjunto em
num sistema protótipo.
Capítulo 4 Engenharia de Requisitos 382017/2018
Entrevistas na prática
Normalmente, uma mistura de entrevistas fechadas eopen-ended.
Entrevistas são boas para obtenção de umentendimento geral do que os stakeholders fazem ecomo eles podem interagir com o sistema.
Entrevistadores precisam ter a mente aberta, sem ideiaspré-concebidas sobre o que o sistema deve fazer
Falar do uso do sistema, sugerir requisitos em vez desimplesmente pedir-lhes o que eles querem.
2017/2018 Capítulo 4 Engenharia de Requisitos 39
Problemas com entrevistas
Os especialistas da aplicação pode usar uma linguagempara descrever o seu trabalho que não é fácil para oengenheiro de requisitos entender.
Entrevistas não são boas para a compreensão derequisitos de domínio
Os engenheiros de requisitos não podem entender aterminologia específica do domínio;
Alguns conhecimentos de domínio são tão familiares que aspessoas acham difícil de articular ou pensam que não vale apena articulação.
Capítulo 4 Engenharia de Requisitos 402017/2018
Histórias e cenários
Cenários e histórias dos utilizadores são exemplos da
vida real de como um sistema pode ser usado.
Histórias e cenários são uma descrição de como um
sistema pode ser usado para uma determinada tarefa.
São baseados numa situação prática, as partes
interessadas podem se relacionar com eles e podem
comentar sobre a situação no que diz respeito à história.
2017/2018 Capítulo 4 Engenharia de Requisitos 45
Cenários
Uma forma estruturada da história do utilizador
Cenários devem incluir
Uma descrição da situação de partida;
A descrição do fluxo normal de eventos;
Uma descrição do que pode dar errado;
Informações sobre outras atividades concorrentes;
A descrição do estado quando o cenário terminar.
Capítulo 4 Engenharia de Requisitos 472017/2018
Especificação de requisitos
O processo de escrita das necessidades dos utilizadores
e do sistema num documento de requisitos.
Necessidades dos utilizadores têm de ser
compreensível por utilizadores finais e clientes que não
têm uma formação técnica.
Os requisitos do sistema são requisitos mais detalhados
e podem incluir mais informações técnicas.
Os requisitos podem ser parte de um contrato para o
desenvolvimento do sistema
Portanto, é importante que estes sejam tão completos quanto
possível.
Capítulo 4 Engenharia de Requisitos 512017/2018
Maneiras de escrever uma especificação de
requisitos do sistema
Capítulo 4 Engenharia de Requisitos 52
Notação Descrição
Linguagem natural Os requisitos são escritos usando frases numeradas em linguagem natural.
Cada frase deve expressar uma exigência.
Linguagem natural
estruturada
Os requisitos são escritos em linguagem natural num formulário padrão ou
modelo. Cada campo fornece informações sobre um aspeto da exigência.
Linguagem de
descrição
Esta abordagem utiliza uma linguagem como uma linguagem de
programação, mas com recursos mais abstratos para especificar os
requisitos através da definição de um modelo operacional do sistema. Esta
abordagem agora é raramente usado, embora possa ser útil para
especificações de interface.
Notações gráficas Modelos gráficos, complementados por anotações de texto, são utilizadas
para definir os requisitos funcionais para o sistema; casos de uso UML e
diagramas de sequência são comumente usados.
Especificações
matemáticas
Estas notações são baseadas em conceitos matemáticos tais como
máquinas de estados finitos ou conjuntos. Embora estas especificações não
ambíguas podem reduzir a ambiguidade em um documento de requisitos, a
maioria dos clientes não entendem uma especificação formal. Eles não
podem verificar se esta representa o que eles querem, assim estão
relutantes em aceitá-lo como um contrato de sistema
2017/2018
Requisitos e projeto
Em princípio, requisitos devem definir o que o sistemadeve fazer e o projeto deve descrever como ele faz isso.
Na prática, requisitos e projeto são inseparáveis
A arquitetura do sistema pode ser concebido para estruturar osrequisitos;
O sistema pode interoperar com outros sistemas que geramrequisitos de projeto;
O uso de uma específica arquitetura para satisfazer osrequisitos não-funcionais, pode ser um requisito de domínio.
2017/2018 Capítulo 4 Engenharia de Requisitos 53
Especificação em linguagem natural
Requisitos são escritos como frases em linguagem
natural complementadas por diagramas e tabelas.
Usado para escrever requisitos porque é expressivo,
intuitivo e universal. Isto significa que os requisitos
podem ser entendidos por utilizadores e clientes.
Capítulo 4 Engenharia de Requisitos 542017/2018
Diretrizes para escrever requisitos
Inventar um formato padrão e usá-lo para todas as
exigências.
Usar uma linguagem de forma consistente.
Use o realce de texto para identificar as partes principais
do requisito.
Incluir uma explicação (lógica) de por que um requisito é
necessário.
2017/2018 Capítulo 4 Engenharia de Requisitos 55
Problemas com linguagem natural
A falta de clareza
A precisão é difícil sem tornar o documento difícil de ler.
Requisitos confusos
requisitos funcionais e não-funcionais tendem a ser confuso.
Fusão de requisitos
Vários requisitos diferentes podem ser expressos em conjunto.
2017/2018 Capítulo 4 Engenharia de Requisitos 56
Exemplo requisitos para o sistema de software
da bomba de insulina
Capítulo 4 Engenharia de Requisitos 57
3.2 O sistema deve medir o açúcar no sangue e injetar insulina,se necessário, a cada 10 minutos.
3.6 O sistema devem executar uma rotina de autoteste a cadaminuto com as condições a serem testadas e as açõesassociadas definidas na Tabela 1. (A rotina de autoteste podedescobrir problemas de hardware e software e alertar outilizador para o fato da operação normal poder serimpossível.)
2017/2018
Especificações estruturadas
Uma abordagem para escrever requisitos, onde a
liberdade da escrita é limitada e os requisitos são
escritos de uma forma padrão.
Isso funciona bem para alguns tipos de requisitos, por
exemplo para sistemas de controle integrado, mas às
vezes é demasiado rígida para escrever requisitos do
sistema empresarial.
Capítulo 4 Engenharia de Requisitos 582017/2018
Especificações baseadas em formulário
Definição da função ou entidade.
Descrição das entradas e de onde eles vêm.
Descrição das saídas e onde eles vão.
Informações sobre as informações necessárias para o
cálculo e outras entidades.
Descrição da ação a tomar.
Condições pré e pós (se for o caso).
Os efeitos colaterais (se for o caso) da função.
2017/2018 Capítulo 4 Engenharia de Requisitos 59
Uma especificação estruturada de um requisito
de uma bomba de insulina
Capítulo 4 Engenharia de Requisitos 602017/2018
Uma especificação estruturada de um requisito
de uma bomba de insulina
Capítulo 4 Engenharia de Requisitos 612017/2018
Especificação tabular
Usado para complementar a linguagem natural.
Particularmente útil quando se tem que definir uma série
de possíveis fluxos de ação alternativos.
Por exemplo, os sistemas de bomba de insulina
baseiam os seus cálculos sobre a taxa de variação do
nível de açúcar no sangue e a especificação tabular
explica como calcular a necessidade de insulina para
diferentes cenários.
2017/2018 Capítulo 4 Engenharia de Requisitos 62
Especificação tabular de cálculo, para uma
bomba de insulina
Capítulo 4 Engenharia de Requisitos 63
Condição Açao
Nível de açúcar baixo (r2 <R1) CompDose = 0
Nível de açúcar estável (R2 = R1) CompDose = 0
Nível de açúcar aumentando e diminuindo a taxa
de aumento
((R2 - r1) <(R1 - r0))
CompDose = 0
Nível de açúcar aumentando e ritmo de aumento
estável ou aumentando
((R2 - r1) ≥ (R1 - r0))
CompDose = volta ((R2 - R1) / 4)
Se arredondado resultado = 0
então
CompDose = MinimumDose
2017/2018
Os casos de uso
Os casos de uso são um tipo de cenário que estão
incluídos no UML.
Os casos de uso identificam os atores numa interação e
descrevem a interação em si.
Um conjunto de casos de uso deve descrever todas as
possíveis interações do sistema.
Diagramas de sequência UML podem ser usados para
adicionar detalhes aos casos de uso, mostrando a
sequência de processamento de eventos no sistema.
Capítulo 4 Engenharia de Requisitos 642017/2018
Documento dos requisitos de software
O documento dos requisitos de software é a declaração
oficial do que é exigido dos programadores do sistema.
Deve incluir tanto uma definição de requisitos de
utilizador, como uma especificação dos requisitos do
sistema.
Não é um documento de design. Na medida do possível,
deve definir o que o sistema deve fazer ao invés de
como ele deve fazer isto.
Capítulo 4 Engenharia de Requisitos 662017/2018
Variabilidade do documento de requisitos
Informações no documento de requisitos dependem do
tipo de sistema e a abordagem de desenvolvimento
usado.
Sistemas desenvolvidos de forma incremental vai,
normalmente, com menos detalhes no documento de
requisitos.
Normas foram concebidas por exemplo, padrão IEEE.
Estes são principalmente aplicável aos requisitos para
grandes projetos de engenharia de sistemas.
Capítulo 4 Engenharia de Requisitos 682017/2018
A estrutura de um document de requisitos
Capítulo 4 Engenharia de Requisitos 69
Capítulo Descrição
Prefácio Isto deve definir o número de leitores esperado do documento e descrever
o seu histórico de versões, incluindo uma justificativa para a criação de
uma nova versão e um resumo das alterações feitas em cada versão.
Introdução Esta secção deve descrever a necessidade do sistema. Deve descrever
brevemente as funções do sistema e explicar como vai funcionar com
outros sistemas. Também deve descrever como o sistema se encaixa nos
objetivos de negócios ou estratégicas globais da organização que pediu o
software.
Glossário Isto deve definir os termos técnicos utilizados no documento. Não deve
fazer suposições sobre a experiência ou conhecimento do leitor.
Definição de requisitos
de utilizador
Aqui, descreve-se os serviços prestados para o utilizador. Os requisitos
não funcionais do sistema também devem ser descritas nesta seção. Essa
descrição pode usar a linguagem natural, diagramas, ou outras notações
que são compreensíveis para os clientes. normas de produtos e processos
que devem ser seguidos devem ser também especificados.
Arquitetura do sistema Este capítulo deve apresentar uma visão geral de alto nível da arquitetura
do sistema previsto, mostrando a distribuição das funções dos módulos do
sistema. Componentes da arquitetura que são reutilizados devem ser
destacadas.
2017/2018
A estrutura de um documento de requisitos
Capítulo Descrição
Especificação de
requisitos do
sistema
Este deve descrever os requisitos funcionais e não-funcionais em mais detalhes.
As interfaces com outros sistemas podem ser também definidos.
Modelos de
sistemas
Isto pode incluir modelos gráficos dos sistemas que mostram as relações entre os
componentes do sistema e o seu ambiente. Exemplos de possíveis modelos são
modelos de objeto, modelos de fluxo de dados, ou modelos de dados
semânticos.
Evolução do
sistema
Este deve descrever os pressupostos fundamentais em que o sistema se baseia,
e quaisquer mudanças previstas, devido à evolução do hardware, mudança das
necessidades dos utilizadores, entre outras. Esta seção é útil para projetistas de
sistemas que possa ajudá-los a evitar decisões de design que restringem futuras
prováveis mudanças no sistema.
Apêndices Estes devem fornecer informações detalhadas, específica que está relacionada
com a aplicação que está a ser desenvolvida; para descrições exemplo, hardware
e base de dados. Definir os requisitos de hardware, as configurações mínimas e
ótimas para o sistema. Requisitos de base de dados definem a organização
lógica dos dados utilizados pelo sistema e as relações entre os dados.
Índice Vários índices no documento podem ser incluídos. Bem como um índice
alfabético normal, pode haver um índice de diagramas, um índice de funções, e
assim por diante.Capítulo 4 Engenharia de Requisitos 702017/2018
A validação de requisitos
Preocupação com o que demonstra que os requisitos
definem o sistema que o cliente realmente quer.
Custos de erros nos requisitos são altos então a
validação é muito importante
Corrigir um erro de requisitos depois da entrega pode custar até
100 vezes o custo de fixação de um erro de implementação.
Capítulo 4 Engenharia de Requisitos 722017/2018
Controlo dos requisitos
Validade. O sistema fornece as funções que melhor
suporte às necessidades do cliente?
Consistência. Há algum conflito de requisitos?
Completude. Estão todas as funções exigidas pelo
cliente?
Realismo. Os requisitos podem ser implementados com
o orçamento e tecnologia disponível.
Verificabilidade. Os requisitos podem ser verificados?
Capítulo 4 Engenharia de Requisitos 732017/2018
Técnicas de validação de requisitos
Revisões de requisitos
Análise manual sistemática dos requisitos.
Prototipagem
Usar um modelo executável do sistema para verificar requisitos.
Geração de casos de teste
Desenvolvimento de testes para requisitos, para verificar a suacapacidade de teste.
Capítulo 4 Engenharia de Requisitos 742017/2018
Revisões de requisitos
Comentários regulares devem ser feitos enquanto a
definição de requisitos está a ser formulada.
Cliente e utilizadores devem ser envolvidos nas
revisões.
Comentários podem ser formais (com documentos
completos) ou informais. Boa comunicação entre
programadores, clientes e utilizadores podem resolver
problemas num estágio inicial.
Capítulo 4 Engenharia de Requisitos 752017/2018
Verificações de revisão
Verificabilidade
É o requisito realista e testável?
Compreensibilidade
É o requisito entendido corretamente?
Rastreabilidade
É claro a origem do requisito?
Adaptabilidade
O requisito de ser alterado sem um grande impacto sobre outrosrequisitos?
Capítulo 4 Engenharia de Requisitos 762017/2018
Mudança dos requisitos
O ambiente de negócios e a técnica do sistema sempre mudam
após a instalação.
Novo hardware pode ser introduzido, pode ser necessário fazer a
interface do sistema com outros sistemas, as prioridades de negócios
pode mudar (com as consequentes alterações no suporte ao sistema),
e nova legislação e regulamentos podem ser introduzidos que o
sistema deve necessariamente respeitar.
As pessoas que pagam para um sistema e os utilizadores do
sistema raramente são as mesmas pessoas.
Clientes do sistema impoêm exigências devido a restrições
organizacionais e orçamentais. Estes podem entrar em conflito com os
requisitos do utilizador final e, após a entrega, novos recursos podem
ter que ser adicionado para suporte ao utilizador.
Capítulo 4 Engenharia de Requisitos 782017/2018
Mudança de requisitos
Sistemas grandes geralmente têm uma comunidade de
utilizadores diversificada, com muitos utilizadores com
diferentes necessidades e prioridades que podem ser
conflituantes ou contraditórios.
Os requisitos finais de sistema são inevitavelmente um
compromisso entre eles e, com a experiência, muitas vezes é
descoberto que o equilíbrio de apoio dado a diferentes
utilizadores tem que ser mudado.
Capítulo 4 Engenharia de Requisitos 792017/2018
A gestão dos requisitos
A gestão dos requisitos é o processo de gestão de
mudanças de requisitos durante o processo de
engenharia de requisitos e desenvolvimento do sistema.
Novos requisitos emergem quando o Sistema está a ser
desenvolvido e depois de ter entrado em uso.
Precisa-se manter o controle das necessidades
individuais e manter ligações entre os requisitos
dependentes para que se possa avaliar o impacto das
mudanças nos requisitos. Precisa-se estabelecer um
processo formal para fazer propostas de mudança e
ligando-os aos requisitos do sistema.
Capítulo 4 Engenharia de Requisitos 812017/2018
Planeamento de gestão de requisitos
Estabelece o nível de detalhe necessário para a gestão de requisitos.
Decisões de gestão de requisitos:
Identifdicação dos requisitos Cada requisito deve ser identificado
exclusivamente para que possa ser cruzada com outros requisitos.
Um processo de gestão de mudança Este é o conjunto de atividades que
avaliam o impacto e o custo de mudanças.
Políticas de rastreabilidade Estas políticas definem as relações entre cada
requisite e entre os requisitos e o projeto do sistema.
Ferramenta de suporte Ferramentas que podem ser utilizadas variam de
sistemas de gestão de requisitos especializados para sistemas de base de
dados simples.
Capítulo 4 Engenharia de Requisitos 822017/2018
Gerir a mudança dos requisitos
Decidir se uma mudança de requisitos devem ser aceite
Análise do problema e especificação da mudança
• Durante esta fase, o problema ou a proposta de mudança é analisada para
verificar se é válido.
Análise e custo da mudança
• O efeito da mudança proposta é avaliada através de informações de
rastreabilidade e conhecimentos gerais sobre os requisitos do sistema. Uma
vez que esta análise é concluída, uma decisão é tomada se deve ou não
prosseguir com a mudança dos requisitos.
Implementação da mudança
• O documento de requisitos e, se necessário, a concepção e implementação
do sistema, são modificados. Idealmente, o documento deve ser organizado
de modo que as mudanças possam ser facilmente implementadas.
Capítulo 4 Engenharia de Requisitos 832017/2018
Pontos chave
Requisitos para um sistema de software definem o que o sistema
deve fazer e definiem os constrangimentos ao seu funcionamento e
implementação.
Os requisitos funcionais são declarações dos serviços que o
sistema deve fornecer ou são descrições de como alguns cálculos
devem ser realizados.
Requisitos não funcionais muitas vezes restringem o processo de
desenvolvimento do sistema que está a ser desenvolvido e/ou está
a ser usado.
Eles muitas vezes se relacionam com as propriedades emergentes
do sistema e, portanto, se aplicam ao sistema como um todo.
Capítulo 4 Engenharia de Requisitos 852017/2018
Pontos chave
O processo de engenharia requisitos é um processo
iterativo que inclui levantamento de requisitos,
especificação e validação.
Levantamento de requisitos é um processo iterativo que
pode ser representado como uma espiral de atividades -
descoberta requisitos, classificação requisitos e
organização, negociação de requisitos e documentação
de requisitos.
Pode-se usar uma variedade de técnicas para
levantamento de requisitos, incluindo entrevistas,
histórias de utilizadores e cenários podem ser
usados para facilitar as discussões.Capítulo 4 Engenharia de Requisitos 862017/2018
Pontos chave
Especificação de requisitos é o processo de
formalmente documentar as necessidades dos
utilizadores e do sistema e criar um documento de
requisitos de software.
O documento de requisitos de software é uma
declaração acordada dos requisitos do sistema. Deve
ser organizado para que os clientes do sistema e
programadores possam usá-lo.
Capítulo 4 Engenharia de Requisitos 872017/2018
Pontos chave
A validação de requisitos é o processo de verificação
dos requisites, de validade, consistência, integridade,
realismo e verificabilidade.
Mudanças no negócios, nas organizações
inevitavelmente levam a mudanças nos requisitos para
um sistema de software. A gestão de requisitos é o
processo de gestão e controlo dessas mudanças.
Capítulo 4 Engenharia de Requisitos 882017/2018