REQUISITOS PERMANENTES: Requisitos estáveis, derivados da atividade principal da organização. Exemplo: Em um hospital sempre haverá requisitos relativos aos pacientes, aos médicos, às enfermeiras e aos tratamentos.
REQUISITOS VOLÁTEIS: Requisitos que se modificam durante o desenvolvimento ou quando o software/sistema está em uso.
Requisitos resultantes de políticas governamentais ou resultantes de regra de negócio da empresa. Exemplo: Plano de saúde; Mudança na política de venda.
CLASSIFICAÇÃO DOS REQUISITOS
Requisitos Mutáveis: Requisitos que se modificam por causa do
ambiente do sistema;
Requisitos Emergentes: Requisitos que surgem à medida que a
Requisitos Consequentes: Requisitos que resultam da introdução do
sistema de computador.
Requisitos de compatibilidade: Requisitos que dependem de outros
sistemas ou processos de negócio específicos dentro da organização.
PLANEJAMENTO DO GERENCIAMENTO DE REQUISITOS
Durante o processo de engenharia de requisitos, será necessário planejar:
IDENTIFICAÇÃO DOS REQUISITOS: Como os requisitos são
individualmente identificados;
PROCESSO DE MUDANÇA DE GERENCIAMENTO: O processo
seguinte à análise de uma mudança de requisito;
POLÍTICAS DE RASTREABILIDADE: quantidade de
informações (histórico) sobre o relacionamento entre requisitos que é mantida. Como rastrear as mudanças de requisitos e seus possíveis impactos.
SUPORTE À FERRAMENTA: suporte à ferramenta necessário
para auxiliar no Gerenciamento de Mudanças de Requisitos.
RASTREABILIDADE
Rastreabilidade preocupa-se com as relações entre requisitos, suas fontes e o projeto do software/sistema.
RASTREABILIDADE DE FONTE: links de requisitos para stakeholders
que propuseram os requisitos;
RASTREABILIDADE DE REQUISITOS: links entre requisitos
dependentes;
RASTREABILIDADE DO PROJETO: links dos requisitos para o
projeto.
SUPORTE À FERRAMENTA:
Armazenamento dos requisitos: Os requisitos devem ser gerenciados em uma memória de dados segura e gerenciada;
Mudança de gerenciamento: O processo de mudança de gerenciamento é um processo de fluxo de trabalho cujos estágios podem ser definidos e o fluxo de informação entre esses estágios parcialmente automatizado.
Gerenciamento de rastreabilidade: Recuperação automática dos links entre requisitos.
Gerenciamento de Mudanças de Requisitos
Gerenciamento de Mudanças de Requisitos: Deve ser feita em: Deve ser feita em qualquer proposta de mudança de requisito.
qualquer proposta de mudança de requisito. PRINCIPAIS ESTÁGIOS:
PRINCIPAIS ESTÁGIOS:
Análise do problema e especificação da mudança. Discute-se osAnálise do problema e especificação da mudança. Discute-se os
problemas com os requisitos e propõe-se mudanças; problemas com os requisitos e propõe-se mudanças;
Análise e custo da mudança. Avalia-se os efeitos da mudança emAnálise e custo da mudança. Avalia-se os efeitos da mudança em
outros requisitos do sistema; outros requisitos do sistema;
Implementação das mudanças. O documento de requisitos eImplementação das mudanças. O documento de requisitos e
outros documentos são alterados de forma a refletir as outros documentos são alterados de forma a refletir as mudanças.
mudanças.
Figura 31
Figura 31 –– Principais Estágios do Gerenciamento de Mudanças de Requi Principais Estágios do Gerenciamento de Mudanças de Requisitos (Fonte:sitos (Fonte: extraído da Web)
extraído da Web)
ETAPAS PARA O RASTREAMENTO ETAPAS PARA O RASTREAMENTO
1.Rastrear requisitos do usuário nos do sistema; 1.Rastrear requisitos do usuário nos do sistema; 2.Rastrear requisitos no projeto;
2.Rastrear requisitos no projeto;
3.Rastrear requisitos nos procedimentos de teste; 3.Rastrear requisitos nos procedimentos de teste; 4.Rastrear requisitos do usuário no plano.
4.Rastrear requisitos do usuário no plano.
Figura 32
EXERCÍCIOS EXERCÍCIOS
1) Assinale a opção correta quanto a requisitos de software.(
1) Assinale a opção correta quanto a requisitos de software.( CESPE - 2010 -CESPE - 2010 -
TRE-MT - Técnico Judiciário - Programação de Sistemas
TRE-MT - Técnico Judiciário - Programação de Sistemas))
a)Requisitos funcionais descrevem as propriedades emergentes do a)Requisitos funcionais descrevem as propriedades emergentes do
sistema, como segurança e tempo de resposta. sistema, como segurança e tempo de resposta.
b)Requisitos não funcionais são descritos de forma qualitativa e não b)Requisitos não funcionais são descritos de forma qualitativa e não
quantitativa quantitativa
c) Requisitos são provenientes de pessoas relevantes para o sistema, e c) Requisitos são provenientes de pessoas relevantes para o sistema, e não de outros sistemas que interagem com o sistema que está sendo não de outros sistemas que interagem com o sistema que está sendo especificado.
especificado.
d)A matriz de rastreabilidade não oferece suporte para requisitos d)A matriz de rastreabilidade não oferece suporte para requisitos
funcionais. funcionais.
e)Revisão de requisitos, prototipação e geração de casos de teste são e)Revisão de requisitos, prototipação e geração de casos de teste são
exemplos de técnicas de validação de requisitos. exemplos de técnicas de validação de requisitos.
2) Segundo Ian Sommerville, existe uma série de técnicas de validação de 2) Segundo Ian Sommerville, existe uma série de técnicas de validação de requisitos que podemser utilizadas em conjunto ou individualmente. requisitos que podemser utilizadas em conjunto ou individualmente. São elas (
São elas (FUNCAB - 2010 - SEJUS-RO - Analista de FUNCAB - 2010 - SEJUS-RO - Analista de SistemasSistemas):):
a) geração de casos de teste, revisões de requisitos, gerenciamento de a) geração de casos de teste, revisões de requisitos, gerenciamento de
mudanças e prototipação. mudanças e prototipação.
b) revisões de requisitos, prototipação, geração de casos de teste e b) revisões de requisitos, prototipação, geração de casos de teste e
análise automatizada da consistência. análise automatizada da consistência.
c) prototipação, análise automatizada da consistência, revisões de c) prototipação, análise automatizada da consistência, revisões de
requisitos e gerenciamento de mudanças. requisitos e gerenciamento de mudanças.
d) gerenciamento de mudanças, análise automatizada da consistência, d) gerenciamento de mudanças, análise automatizada da consistência,
revisões de requisitos e geração de casos de teste. revisões de requisitos e geração de casos de teste.
e) análise automatizada da consistência, prototipação, gerenciamento de e) análise automatizada da consistência, prototipação, gerenciamento de
mudanças e geração de casos de teste. mudanças e geração de casos de teste. 3) No que diz respeito aos sistemas de
3) No que diz respeito aos sistemas de softwaresoftware, teste é um conjunto de, teste é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Um tipo I de teste se refere ao conjunto de atividades sistematicamente. Um tipo I de teste se refere ao conjunto de atividades que garante que o
que garante que o softwaresoftware implementa corretamente uma funçãoimplementa corretamente uma função específica, associado à construção do produto de forma correta ou não, específica, associado à construção do produto de forma correta ou não, enquanto um tipo II se refere a um conjunto de atividades diferente que enquanto um tipo II se refere a um conjunto de atividades diferente que garante que o
garante que o softwaresoftware construído corresponde aos requisitos do cliente, construído corresponde aos requisitos do cliente, associado à construção do produto certo. Esses testes do tipo I e II são associado à construção do produto certo. Esses testes do tipo I e II são denominados, respectivamente (
denominados, respectivamente (FGV - 2010 - FIOCRUZ - Tecnologista emFGV - 2010 - FIOCRUZ - Tecnologista em
Saúde - TI - Sistemas de Informação
Saúde - TI - Sistemas de Informação):): a) Depuração e homologação. a) Depuração e homologação. b) Homologação e aceitação. b) Homologação e aceitação. c) Aceitação e verificação. c) Aceitação e verificação. d) Verificação e validação. d) Verificação e validação. e) Validação e depuração. e) Validação e depuração.
4) Verificação e validação são atividades da análise de
4) Verificação e validação são atividades da análise de software software,, necessárias para se identificar o que o
de uma avaliação do usuário quanto às atividades definidas.
de uma avaliação do usuário quanto às atividades definidas. ((CESPE - 2011 -CESPE - 2011 -
TJ-ES - Técnico de Informática - Específicos
TJ-ES - Técnico de Informática - Específicos)) ___ CERTO
___ CERTO ___ ERRADO___ ERRADO
5) Os produtos de trabalho resultantes da engenharia de requisitos são 5) Os produtos de trabalho resultantes da engenharia de requisitos são avaliados quanto à qualidade durante a etapa de validação de requisitos. avaliados quanto à qualidade durante a etapa de validação de requisitos.
Analise os itens a seguir referentes a essa etapa:
Analise os itens a seguir referentes a essa etapa:
I. Um dos principais mecanismos de validação de requisitos é a avaliação I. Um dos principais mecanismos de validação de requisitos é a avaliação técnica formal.
técnica formal.
II. O modelo de análise pode garantir que os requisitos foram II. O modelo de análise pode garantir que os requisitos foram consistentemente declarados.
consistentemente declarados.
III. É frequentemente útil examinar cada requisito em face de um III. É frequentemente útil examinar cada requisito em face de um conjunto de questões do tipo
conjunto de questões do tipo checklist.checklist.
IV. A equipe de revisão que avalia os requisitos inclui apenas pessoas com IV. A equipe de revisão que avalia os requisitos inclui apenas pessoas com conhecimento técnico na área de TI, como engenheiros de
conhecimento técnico na área de TI, como engenheiros de softwaressoftwares,, desenvolvedores etc.
desenvolvedores etc.
Está correto o que consta em: Está correto o que consta em: a) I, II, III e IV a) I, II, III e IV b) II e IV b) II e IV c) I, II e IV c) I, II e IV d) II, III e IV d) II, III e IV e) I, II e III e) I, II e III
6) Assim como o software, os requisitos também devem ser avaliados 6) Assim como o software, os requisitos também devem ser avaliados quanto à qualidade. A validação, atividade da engenharia de requisitos, é quanto à qualidade. A validação, atividade da engenharia de requisitos, é responsável por garantir que os requisitos tenham sido declarados de responsável por garantir que os requisitos tenham sido declarados de forma clara e precisa. Além disso, a validação busca detectar forma clara e precisa. Além disso, a validação busca detectar inconsistências, erros e omissões, objetivando alinhar os requisitos às inconsistências, erros e omissões, objetivando alinhar os requisitos às normas estabelecidas para o projeto, produto e processo. (
normas estabelecidas para o projeto, produto e processo. (CESPE - 2011 -CESPE - 2011 -
TJ-ES - Analista Judiciário - Análise de Sistemas - Específicos
TJ-ES - Analista Judiciário - Análise de Sistemas - Específicos)) ___ CERTO
M
MAATTR R IIZZ DDEE R R AASSTTR R EEAABBIILLIIDDAADDEE
Matrizes de rastreabilidade são os principais artefatos produzidos na fase de gerência de requisitos. Elas relacionam os requisitos identificados a um ou mais aspectos do sistema ou do seu ambiente, de modo que elas possam ser procuradas rapidamente para entender como uma modificação em um requisito vai afetar diferentes aspectos do sistema.
RASTREABILIDADE
Técnica usada para prover relacionamento entre requisitos, projeto e implementação final do sistema. É uma característica de sistemas nos quais os requisitos são claramente ligados às suas fontes e aos artefatos criados durante o ciclo de vida de desenvolvimento de sistema.
É a habilidade de descobrir a história de toda característica do sistema, dado que os impactos de mudanças nos requisitos podem ser identificados. (Hamilton, 1991)
Figura 33 – Esquema Rastreabilidade
OBJETIVOS
GERENCIAR O PROJETO:
o Acompanhar a evolução dos requisitos ao longo do
o Registrar status de cada requisito em relação ao
desenvolvimento, em relação a modificações aceitas e justificativas associadas;
o Estabelecer uma visão comum entre o cliente e a equipe de
projeto em relação aos requisitos que serão atendidos pelo projeto de software;
ACOMPANHAR AS MUDANÇAS:
o Atualmente tem-se a convicção que mudanças em requisitos ao
longo do processo de desenvolvimento de software fazem parte do processo;
o Motivos: necessidades não identificadas inicialmente, alterações
no contexto, correção de erros ou mesmo novas perspectivas por parte dos stakeholders;
o Alterações em requisitos podem implicar em mudanças em
artefatos de projeto, código, casos de testes, etc.
GARANTIA DE QUALIDADE:
o Aspectos relacionados a qualidade: modelo CMM, CMMI, ISO
9001.
A rastreabilidade auxilia:
ANÁLISE DE COMPLETUDE NA ALOCAÇÃO DE REQUISITOS A
COMPONENTES DO SOFTWARE: A avaliação dos links de rastreabilidade de requisitos a artefatos de design e implementação identifica requisitos ainda não alocados ou implementados;
RESOLUÇÃO DE REQUISITOS EM CONFLITO: diferentes representantes
do cliente ou usuário trazem suas necessidades em relação ao sistema. Essas necessidades irão gerar requisitos que podem ser conflitantes. A rastreabilidade possibilita identificar rapidamente as origens dos requisitos em conflito, para solução do problema detectado;
VERIFICAÇÃO: na análise de cobertura de requisitos nos testes, a
rastreabilidade entre requisitos e casos de testes permite identificar requisitos ou funcionalidades para os quais foram previstos casos de testes;
CORREÇÃO DE DEFEITOS (BUGS): após a identificação do componente
que originou o erro, a análise do problema pode indicar que a origem do defeito não está no código propriamente dito, mas nos requisitos ou em artefatos de design. Os links indicarão quais artefatos deverão ser revistos e corrigidos, incluindo testes;
VALIDAÇÃO: a etapa final de validação do sistema criado junto ao
conjunto de clientes e usuários se beneficia da rastreabilidade, permitindo mostrar a completude da implementação em relação aos requisitos acordados entre clientes e desenvolvedores;
ANÁLISE DE IMPACTO NA EVOLUÇÃO DO SISTEMA: a existência de
links de rastreabilidade entre requisitos e componentes possibilita identificar rapidamente quais componentes serão afetados por mudanças em um requisito ou mesmo por inclusão de novos requisitos; PREVISÃO DE CUSTOS E PRAZOS: quando uma nova funcionalidade deve ser incluída no sistema em implementação ou quando uma mudança num requisito já implementado é solicitada, o gerente de projeto necessita de estimativas confiáveis para poder negociar custos e prazos junto ao cliente;
GERENCIAMENTO DE RISCOS: a rastreabilidade apoia a identificação
de artefatos atingidos por cada fator de risco, possibilitando a elaboração de estratégias para tratamento ou mitigação dos riscos (por exemplo, riscos associados a custos e cronograma);
UPGRADE DE HARDWARE E/OU AMBIENTE OPERACIONAL: em sistemas
embarcados ou em software utilitário existem relacionamentos fortes entre componentes do hardware e do software. Na mudança de versão do ambiente operacional ou na troca de hardware, links de rastreabilidade possibilitam identificar rapidamente componentes atingidos;
REUSO DE COMPONENTES: obter ativos reusáveis a partir de sistemas
existentes tem incrementado o reuso na indústria; uma abordagem que propicia este incremento utiliza a recuperação de links de rastreabilidade entre código e documentos escritos em linguagem natural.