swebok - facom.ufu.brflavio/esof-files/files/2014-02/06-engenharia... · engenharia de requisitos...

11/26/2014

1

Engenharia de SoftwareProf. Flávio de Oliveira Silva, Ph.D.

Capítulo 4

Engenharia de requisitos

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 290


SWEBOK

Chapter 4 Requirements engineering 291

11/26/2014

2


Tópicos abordados• Requisitos funcionais e não funcionais

• O documento de requisitos de software

• Especificação de requisitos

• Processos de engenharia de requisitos

• Elicitação e análise de requisitos

• Validação de requisitos

• Gerenciamento de requisitos

292


Engenharia de requisitos

• O processo de estabelecer os serviçosque o cliente necessita do sistema e as

restrições sob as quais ele opera e é

desenvolvido.

• Os próprios requisitos são as descriçõesdos serviços do sistema e restriçõesgeradas durante o processo de engenhariade requisitos.

11/26/2014

3


O que é um requisito?• Pode variar de uma declaração abstrata de alto nível de

um serviço ou de uma restrição do sistema para umaespecificação matemática funcional.

• Isso é inevitável quando os requisitos podem servir auma função dupla.

Pode ser a base para a proposta de um contrato ‐portanto, deve ser aberto à interpretação;

Pode ser a base para o contrato em si, portanto,deve ser definido em detalhe;

Ambas as declarações podem ser chamadas derequisitos.


Abstração de requisitos (Davis)"Se uma empresa quer fechar um contrato para um projeto de desenvolvimentode software de grande porte, deve definir as suas necessidades de forma abstratao suficiente para que a solução não seja pré‐definida.

Os requisitos devem ser escritos de forma que vários contratantes possamconcorrer pelo contrato e oferecer diferentes maneiras de atender àsnecessidades da organização do cliente.

Uma vez que um contrato tenha sido adjudicado, o contratante deve escrever parao cliente uma definição mais detalhada do sistema, para que esse entenda e possavalidar o que o software fará.

Ambos os documentos podem ser chamados de documentos de requisitos para osistema. “

11/26/2014

4


Tipos de requisitos

• Requisitos de usuário

Declarações em linguagem natural com diagramas dos serviços que osistema deverá fornecer e suas restrições operacionais. Escrito para osclientes.

• Requisitos de sistema

Um documento estruturado estabelecendo descrições detalhadas dasfunções do sistema, serviços e restrições operacionais. Define o que deveser implementado assim, pode ser parte de um contrato entre o cliente eo empreiteiro.


Requisitos de usuário e de sistema

11/26/2014

5


Leitores de diferentes tipos de especificação de requisitos


Requisitos funcionais e não‐funcionais• Requisitos funcionais

O sistema deve fornecer declarações deserviços, como o sistema deve reagir aentradas específicas e como o sistema devese comportar em determinadas situações.

Pode explicitar o que o sistema não devefazer.

• Requisitos não‐funcionais

Restrições aos serviços ou funções oferecidaspelo sistema, tais como restrições de tempo,restrições no processo de desenvolvimento,padrões.

Muitas vezes se aplica ao sistema como umtodo ao invés de características individuais ouserviços.

11/26/2014

6


Requisitos Funcionais

• Descrever a funcionalidade ou osserviços do sistema.

• Depende do tipo de software, possíveisusuários e o tipo de sistema em que osoftware é usado.

• Requisitos funcionais dos usuáriospodem ser declarações de alto nível arespeito do que o sistema deve fazer.

• Requisitos funcionais do sistema devemdescrever detalhadamente os serviçosdo sistema.


q p

Mental Health Care – PatientManagement System

• Um usuário deve ser capaz depesquisar as listas de agendamentospara todas as clínicas.

• O sistema deve gerar, a cada dia, paracada clínica, uma lista de pacientesesperados para as consultas daqueledia.

• Cada membro da equipe que usa osistema deve ser exclusivamenteidentificado pelo seu número defuncionário de 8 dígitos.

11/26/2014

7


Imprecisão de requisitos• Problemas surgem quando os requisitos não são precisamente definidos.

• Requisitos ambíguos podem ser interpretados de maneiras diferentes pordesenvolvedores e usuários.

• Considere o termo 'pesquisa' no requisito 1

A intenção do usuário – busca pelo nome de um paciente em todos asconsultas em todas as clínicas;

• Interpretação do desenvolvedor – busca pelo nome de um paciente em umaclínica. O usuário escolhe a clínica e em seguida pesquisa.


Integridade e consistência dos requisitos• Em princípio, os requisitos devem ser

completos e consistentes.

• Completos

Eles devem incluir descrições detodos os serviços necessários.

• Consistentes

Não devem haver conflitos oucontradições nas descrições dosrecursos do sistema.

• Na prática, é impossível produzir

documentos de requisitos completose consistentes .

Relevante Irrelevante

Resultado

IncompletoExcesso

11/26/2014

8


Requisitos Não‐funcionais• Esses requisitos definem as

propriedades e as restrições dosistema por exemplo, confiabilidade,

tempo de resposta e ocupação de área.

• As restrições são capacidades dedispositivos de E/S, as representações dosistema, etc.

• Os requisitos de processo também podemser especificados impondo um IDEparticular, linguagem de programação oumétodo de desenvolvimento.

• Os requisitos não‐funcionais podem sermais críticos do que os requisitosfuncionais. Se esses não forem atendidos,o sistema pode ser inútil.


Tipos de requisitos não funcionais

11/26/2014

9


Implementação de requisitos não funcionais

• Requisitos não‐funcionais podem afetar aarquitetura geral de um sistema, em vez decomponentes individuais.

Por exemplo, para assegurar que os requisitosde desempenho sejam cumpridos, você podeter que organizar o sistema para minimizar acomunicação entre os componentes.

• Um único requisito não‐funcional, como umrequisito de proteção, pode gerar uma série derequisitos funcionais relacionados que definem osserviços do sistema que são necessários.

• Ele também pode gerar requisitos que restringem osrequisitos existentes.


Classificações de requisitos não funcionais

• Requisitos de produto

Requisitos que especificam que oproduto entregue deve se comportar deuma maneira particular, por exemplovelocidade de execução, confiabilidade,etc.

• Requisitos organizacionais

Requisitos que são consequência depolíticas e procedimentosorganizacionais, por exemplo padrõesde processo usados, requisitos deimplementação, etc.

• Requisitos externos

Requisitos que surgem de fatoresexternos ao sistema e seu processo dedesenvolvimento, por exemplo,requisitos de reguladores, requisitoslegais, etc.

11/26/2014

10


Exemplos de requisitos não funcionais no MHC‐PMS


Metas e requisitos• Requisitos não‐funcionais podem ser muito

difíceis de se definir precisamente e requisitosimprecisos podem ser difíceis de se verificar.

• Metas

A intenção geral do usuário, facilmenteusável.

• Requisito não‐funcionalmensurável.

Uma declaração usando alguma métrica quepode ser objetivamente testada.

• Metas são úteis para desenvolvedores quandoexprimem as intenções dos usuários do

sistema.

11/26/2014

11


Requisitos de Usabilidade• O sistema deve ser de fácil uso pelo

pessoal médico e deve ser organizadode tal forma que os erros dos usuáriossejam minimizados. (Meta)

• A equipe médica deve ser capaz de usartodas as funções do sistema depois dequatro horas de treinamento.

• Após esse treinamento, o númeromédio de erros cometidos pelosusuários experientes não deve excederdois erros por hora de uso do sistema.(Requisito não‐funcional testável)


Métricas para especificar requisitos não funcionais

11/26/2014

12


Requisitos de domínio

• O domínio operacional do sistema impõe requisitos ao sistema.

Por exemplo, um sistema de controle de trem deve levar em conta ascaracterísticas de frenagem em diferentes condições climáticas.

• Requisitos de domínio criam novos requisitos funcionais, restrições sobre requisitosexistentes ou definem cálculos específicos.

• Se os requisitos de domínio não forem satisfeitos, o sistema pode ser impraticável.

RequisitosFuncionais

RequisitosNão Funcionais

Requisitosde Domínio


Sistema de segurança de trem

Esse é um requisito de domínio de um sistema de segurança de um trem:

• A desaceleração do trem deve ser computada como:

• Dtrain = Dcontrol + Dgradient

onde Dgradient é 9.81ms2 * gradiente / alfa compensado e onde os valoresde 9.81ms2 / alpha são conhecidos para diferentes tipos de trem.

• É difícil para um não‐especialista entender as implicações desse requisito e decomo ele interage com outros requisitos.

11/26/2014

13


Problemas de requisitos de domínio

• Compreensibilidade

Requisitos são expressos na linguagem do domínio da aplicação;

O que geralmente não é compreendido pelos engenheiros de softwareque desenvolvem o sistema.

• Especialistas de domínio compreendem tão bem essa área que eles nãopensam em tornar explícitos os requisitos de domínio.


Pontos importantes

• Os requisitos para um sistema de software estabelecem o que o sistema devefazer e definir restrições sobre o seu funcionamento e implementação.

• Os requisitos funcionais são declarações dos serviços que o sistema devefornecer ou são descrições de como alguns processamentos devem serrealizados.

• Muitas vezes os requisitos não‐funcionais, limitam o sistema a serdesenvolvido e o processo de desenvolvimento a ser usado.

• Muitas vezes eles se relacionam com as diversas propriedades do sistema e, portanto, seaplicam ao sistema como um todo.

11/26/2014

14


O documento de requisitos de software

• O documento de requisitos de software éa declaração oficial do que é demandadodos desenvolvedores do sistema.

• Deve incluir ambas, uma definição derequisitos do usuário e uma especificaçãode requisitos do sistema.

• NÃO é um documento de projeto. Namedida do possível, deve definir O QUE osistema deve fazer ao invés de COMOdeve fazê‐lo.


Requisitos e Métodos ágeis

• Muitos métodos ágeis argumentam quea produção de um documento derequisitos é um desperdício de tempopois esses mudam rapidamente.

• Portanto, o documento estará sempredesatualizado.

• Métodos ágeis, tais como XP usam aengenharia de requisitos incrementais eexpressam os requisitos como “estóriasde usuário" .

• Prático para os sistemas de negócios,mas problemático para sistemas queexigem várias análises pré‐entrega (porexemplo, sistemas críticos) ou sistemasdesenvolvidos por várias equipes.

11/26/2014

15


Usuários de um documento de requisitos


Usuários de um documento de requisitos

11/26/2014

16


Variabilidade do documento de requisitos

• As informações no documento de requisitosdependem do tipo de sistema e da abordagem dedesenvolvimento usada.

• Normalmente, os sistemas desenvolvidos deforma incremental terão menos detalhes nodocumento de requisitos.

• Os padrões dos documentos de requisitos foramconcebidos, tendo como exemplo, a norma IEEE.

• Esses são aplicáveis, principalmente, aosrequisitos para projetos de engenharia desistemas de grande porte.


A estrutura de um documento de requisitos

11/26/2014

17


A estrutura de um documento de requisitos


• O processo de escrever os requisitos deusuário e de sistema em um documentode requisitos.

• Os requisitos precisam ser compreensíveispara usuários finais e clientes que não têmformação técnica.

• Requisitos de sistema são mais detalhadose podem incluir informações mais técnicas.

• Os requisitos podem ser parte de umcontrato para o desenvolvimento dosistema.

Portanto, é importante que essessejam tão completos quanto possível.

Especificação de requisitos

11/26/2014

18


Formas de escrever uma especificação de requisitos de sistema


• Em princípio, os requisitos devem indicar o que osistema deve fazer e o projeto deve descrever comofazer isso.

• Na prática, os requisitos e o projeto são inseparáveis

A arquitetura do sistema pode ser projetada paraestruturar os requisitos;

O sistema pode interoperar com outros sistemasque restringem o projeto e impõem requisitossobre o novo sistema;

O uso de uma arquitetura específica parasatisfazer os requisitos não funcionais pode ser umrequisito de domínio.

Projeto e requisitos

11/26/2014

19


• Os requisitos são escritos comosentenças em linguagem naturalcomplementadas por diagramas etabelas.

• Usado para escrever os requisitos, poisé expressivo, intuitivo e universal.

• Isso significa que os requisitos podemser entendidos pelos usuários e pelosclientes.

Especificação em linguagem natural


• DEFINIR um formato padrão e usá‐lo paratodos 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 aspartes fundamentais do requisito.

• Evitar o uso de jargões de computador.

• Incluir uma justificativa (lógica) de por queum requisito é necessário.

Diretrizes para escrever requisitos

11/26/2014

20


• Falta de clareza

É difícil conseguir precisão sem tornar odocumento de difícil leitura.

• Confusão de requisitos

Requisitos funcionais e não funcionais tendema ser misturados.

• Amálgama de requisitos

Vários requisitos diferentes podem serexpressos juntos.

Problemas com a linguagem natural


Exemplo de requisitos para o sistema de software de bomba de insulina

11/26/2014

21


• Uma abordagem para escrever requisitos em que a liberdade do escritor derequisitos é limitada e os requisitos são escritos de uma maneira padrão.

• Isso funciona bem para alguns tipos de requisitos, por exemplo, requisitos parao sistema embutido de controle, mas às vezes é demasiado rígido paraescrever os requisitos de sistema de negócios.

Especificações estruturadas


• 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ções baseadas em formulários

11/26/2014

22


Uma especificação estruturada de um requisito para uma bomba de insulina


• Usados para complementar a linguagem natural.

• Particularmente útil quando é necessário definir um número de situaçõesalternativas possíveis.

• Por exemplo, o sistema de bomba de insulina baseia seus cálculos sobre a taxade mudança de nível de açúcar no sangue e a especificação tabular explicacomo calcular a necessidade de insulina para diferentes cenários.

Especificação tabular

11/26/2014

23


Especificação tabular de processamento para uma bomba de insulina


• Os processos usados para a engenharia de requisitos variam muito,dependendo do domínio da aplicação, das pessoas envolvidas e da organizaçãoque desenvolve os requisitos.

• No entanto, existe uma série de atividades genéricas comuns a todos osprocessos

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 estesprocessos são intercalados.

Processos de engenharia de requisitos

11/26/2014

24


Uma visão em espiral do processo de engenharia de requisitos


• Às vezes chamada de elicitação oudescoberta de requisitos.

• Envolve técnicos trabalhando com osclientes para levantar dados sobre odomínio da aplicação, os serviços que osistema deve fornecer e as restriçõesoperacionais do sistema.

• Pode envolver usuários finais, gerentes,engenheiros envolvidos na manutenção,especialistas de domínio, sindicatos, etc.

• Esses são chamados stakeholders.

Elicitação e análise de requisitos

11/26/2014

25


• Engenheiros de software trabalham com

uma gama de stakeholders do

sistema para descobrir sobre• o domínio da aplicação,

• os serviços que o sistema deve fornecer,

• o desempenho do sistema necessários,

• restrições de hardware,

• outros sistemas, etc.• Os stakeholders não sabem o que realmente querem.

• Os stakeholders expressam requisitos em seus próprios termos.

• Diferentes stakeholders podem ter requisitos conflitantes.

• Fatores políticos e organizacionais podem influenciar os requisitos desistema.

• Os requisitos mudam durante o processo de análise. Novosstakeholders podem surgir e o ambiente de negócios pode mudar.

Elicitação e análise de requisitos


O processo de elicitação e análise de requisitos

11/26/2014

26


• O processo de coleta de informações sobreos sistemas necessários e os existentes, eseparar os requisitos do usuário e sistemadessas informações.

• A interação é com os stakeholders dosistema desde os gerentes até os reguladoresexternos.

• Normalmente, os sistemas têm váriosstakeholders.

Descoberta de requisitos


• Pacientes cujas informações são registradas no sistema.

• Médicos que são responsáveis por avaliar e tratar os pacientes.

• Enfermeiros que coordenam as consultas com médicos e administram alguns tratamentos.

• Recepcionistas dos médicos que gerenciam as consultas dos pacientes.

• A equipe de TI responsável pela instalação e manutenção do sistema.

• Um gerente de ética médica, que deve garantir que o atual sistema atenda às diretrizes éticas parao cuidado do paciente.

• Gerentes de cuidados de saúde que obtiverem informações de gerenciamento do sistema.

• Registros médicos, equipes responsáveis por garantir que as informações do sistema possam sermantidas e preservadas, e que a manutenção de registros foi executada corretamente.

Stakeholders no MHC‐PMS

11/26/2014

27


• Entrevistas formais ou informais com os stakeholders fazem parte da maioriados processos de engenharia de requisitos.

• Tipos de entrevista

Entrevistas fechadas com base em uma lista de perguntas pré‐determinada.

Entrevistas abertas, em que várias questões são exploradas com osstakeholders.

• Entrevistar eficazmente

Ter a mente aberta, evitar ideias pré‐concebidas sobre os requisitos e estardisposto a ouvir os stakeholders.

Induzir os entrevistados a discutir usando uma questão trampolim, umaproposta de requisitos, ou trabalhando em conjunto em um sistemaprotótipo.

Entrevistas


• Normalmente, uma mistura de entrevistas fechadas e abertas.

• Entrevistas são boas para a obtenção de um entendimento geral do que osstakeholders fazem e como eles podem interagir com o sistema.

• Entrevistas não são boas para a compreensão dos requisitos de domínio:

Engenheiros de requisitos não podem entender a terminologia específicade domínio;

Algum conhecimento de domínio é tão familiar que as pessoas achamdifícil articular ou pensam que não vale a pena articular.

Entrevistas, na prática

11/26/2014

28


• Cenários são exemplos da vida real de como um sistema pode ser usado.

• Eles devem incluir:

A descrição da situação inicial;

A descrição do fluxo normal de eventos;

A descrição do que pode dar errado;

Informações sobre outras atividades concorrentes;

A descrição do estado do sistema quando o cenário acaba.

Cenários


Cenário para a coleta do histórico médico em MHC‐PMS

11/26/2014

29


Cenário para a coleta do histórico médico em MHC‐PMS ‐ CONTINUAÇÃO


• Casos de uso é uma técnica da UML baseada em cenários que identificam osatores em uma interação e que descreve a interação em si.

• Um conjunto de casos de uso deve descrever todas as possíveis interações como sistema.

• Modelo gráfico de alto nível complementado por uma descrição tabular maisdetalhada.

• Diagramas de sequência podem ser usados para adicionar detalhes aos casosde uso, mostrando a sequência de processamento de eventos no sistema.

Casos de uso

11/26/2014

30


Casos de uso para o MHC‐PMS


• Um analista gasta um tempo considerável

observando e analisando como aspessoas realmente trabalham.

• As pessoas não precisam explicar ou articular seutrabalho.

• Podem ser observados fatores sociais e organizacionaisde importância.

• Estudos etnográficos têm mostrado que o trabalhogeralmente é mais rico e complexo do que o sugeridopelos modelos simples de sistemas.

Etnografia

11/26/2014

31


• Requisitos que são derivados da maneira como as pessoas realmentetrabalham e não da maneira como as definições de processo sugerem que elasdeveriam trabalhar.

• Requisitos que são derivados da cooperação e conscientização das atividadesdas outras pessoas.

Consciência do que outras pessoas estão fazendo leva a mudanças nomodo como fazemos as coisas.

• A etnografia é eficaz para a compreensão dos processos existentes, mas nãopode identificar novos recursos que devem ser adicionados a um sistema.

Âmbito da etnografia


• Preocupados em demonstrar se osrequisitos definem o sistema que ocliente realmente quer.

• Os custos de erros de requisitos sãoaltos, logo, a validação é muitoimportante.

Corrigir um erro de requisitosapós a entrega pode custar até100 vezes o custo de corrigir umerro de execução.

Validação de requisitos

11/26/2014

32


• Validade. O sistema fornece as funções quemelhor atendem às necessidades do cliente?

• Consistência. Existe algum conflito de requisitos?

• Completude. Estão incluídas todas as funções erestriçoes requeridas pelo cliente ?

• Realismo. Os requisitos podem serimplementados com o orçamento e a tecnologiadisponíveis?

• Verificabilidade. Os requisitos podem serverificados?

Verificação de requisitos


• Revisões de requisitos

Análise manual sistemática 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.

Técnicas de validação dos requisitos

11/26/2014

33


• Revisões periódicas devem ser feitas enquantoa definição dos requisitos está sendoformulada.

• Ambos, cliente e fornecedor, devem serenvolvidos nas revisões.

• Os comentários podem ser formais (comdocumentos completos) ou informais.

• Uma boa comunicação entre osdesenvolvedores, clientes e usuários poderesolver os problemas numa fase inicial.

Revisões de requisitos


• Verificabilidade

A exigência é realmente testável?

• Compreensibilidade

O requisito é adequadamente compreendido?

• Rastreabilidade

A origem do requisito é clara?

• Adaptabilidade

O requisito pode ser alterado sem causar um grande impacto sobre outrosrequisitos?

Avaliação da revisão

11/26/2014

34


• Após o sistemas começar a ser usado, surgemnovos requisitos.

• É preciso manter o controle das necessidadesindividuais e manter ligações entre osrequisitos dependentes para que você possaavaliar o impacto das mudanças nos requisitos.

• É necessário estabelecer um processoformal para fazer propostas de mudança

e ligar essas aos requisitos de sistema.

Gerenciamento de requisitos


• O ambiente técnico e de negócios do sistema sempre muda após a instalação.

Um novo hardware pode ser introduzido, pode ser necessário para ainterface do sistema com outros sistemas, as prioridades do negóciopodem mudar (com as consequentes alterações no sistema de apoionecessário) e, podem ser que o sistema deve, necessariamente, respeitar.

• As pessoas que pagam por um sistema e os usuários desse sistema raramentesão as mesmas pessoas.

Clientes do sistema impõem requisitos devido a restrições orçamentais eorganizacionais. Esses podem entrar em conflito com os requisitos dousuário final e, após a entrega, pode ser necessário adicionar novosrecursos para suporte ao usuário, caso o sistema seja para atender a seusobjetivos.

Mudanças nos requisitos

11/26/2014

35


• Sistemas de grande porte costumam ter uma comunidade de usuáriosdiversos, com muitos usuários tendo necessidades diferentes e prioridades quepodem ser conflitantes ou contraditórias.

Os requisitos do sistema final são, inevitavelmente, um compromisso entreeles e, a experiência mostra que, muitas vezes se descobre que o balançode apoio dado aos diferentes usuários precisa ser mudado.

Mudanças nos requisitos


Evolução dos requisitos

11/26/2014

36


• Estabelece o nível de detalhamento necessário para o gerenciamento derequisitos. Decisões do gerenciamento de requisitos:

Identificação de requisitos. Cada requisito deve ser identificadoexclusivamente para que ele possa ser comparado com outros requisitos.

Processo de gerenciamento de mudanças. Esse é o conjunto de atividadesque avaliam o impacto e o custo das mudanças. Esse processo é discutidoem mais detalhes na seção seguinte.

Políticas de rastreabilidade. Essas políticas definem as relações entre cadarequisito e entre os requisitos e o projeto do sistema que deve serregistrado.

Ferramentas de suporte. As ferramentas de suporte que podem serusadas variam desde sistemas especialistas, sistemas de gerenciamento derequisitos até planilhas e sistemas de banco de dados simples.

Planejamento de gerenciamento de requisitos


• Análise de problema e especificação de mudanças

Durante essa fase, o problema ou a proposta de mudança é analisada para verificar se éválida. O feedback dessa análise é devolvido para o solicitante, que pode responder com umaproposta mais específica de mudança dos requisitos, ou decidir retirar o pedido.

• Análise de mudanças e custos

O efeito da mudança proposta é avaliado por meio de informações de rastreabilidade econhecimento geral dos requisitos do sistema. Uma vez que essa análise é concluída, toma‐sea decisão de prosseguir ou não com a mudança de requisitos.

• Implementação de mudanças

O documento de requisitos e, se necessário, o projeto e implementação do sistema, sãomodificados. Idealmente, o documento deve ser organizado de modo que as mudançaspossam ser facilmente implementadas.

Gerenciamento de mudança de requisitos

11/26/2014

37


• Você pode usar uma variedade de técnicas para a elicitação de requisitos,incluindo entrevistas, cenários, casos de uso e etnografia.

• A validação dos requisitos é o processo de verificação da validade, consistência,completude, realismo e verificabilidade dos requisitos.

• Mudanças organizacionais e técnicas, e de negócios, inevitavelmente levam amudanças nos requisitos de um sistema de software.

• O gerenciamento dos requisitos é o processo de gerenciamento e controle

dessas mudanças.

Pontos importantes

swebok - facom.ufu.brflavio/esof-files/files/2014-02/06-engenharia... · engenharia de requisitos...

Documents