Capítulo 4 - Engenharia de Requisitossebastiao/Ensino/UBI/2017-2018/ES/Teoricas...Assuntos abordados Requisitos funcionais e não-funcionais Processos de engenharia de requisitos

Capítulo 4 - Engenharia de Requisitos

Capítulo 4 Engenharia de Requisitos 12017/2018

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


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.


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.


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.


Necessidades dos utilizadores e do sistema


Os leitores de diferentes tipos de especificação

de requisitos


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


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.


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.


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

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


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.


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.


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.


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.


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.


Tipos de requisitos não funcionais


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.


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.


Exemplos de requisitos não funcionais no

sistema Mentcare


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.


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)


Métricas para especificar requisitos não

funcionais


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




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.


Uma visão espiral do processo de engenharia de

requisitos




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.





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.


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.


Levantamento de requisitos e processo de

análise


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.


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.


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.


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.


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.


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.





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.


Maneiras de escrever uma especificação de

requisitos do sistema


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.


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.


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.


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.


Exemplo requisitos para o sistema de software

da bomba de insulina


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.


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.


Uma especificação estruturada de um requisito

de uma bomba de insulina


Uma especificação estruturada de um requisito

de uma bomba de insulina


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.


Especificação tabular de cálculo, para uma

bomba de insulina


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.


Os casos de uso para o sistema Mentcare


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.


Os utilizadores de um documento de requisitos


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.


A estrutura de um document de requisitos


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


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.


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?


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.


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.


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?


Mudança de requisitos


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.


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.


Evolução dos requisitos


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.


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.


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.


Gerir a mudança dos requisitos


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.


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.


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.


Documents

Capítulo 4 - Engenharia de Requisitossebastiao/Ensino/UBI/2017-2018/ES/Teoricas...Assuntos abordados Requisitos funcionais e não-funcionais Processos de engenharia de requisitos