engenharia de software análise e desenvolvimento de sistemas janete pereira do amaral [email protected]

Engenharia de SoftwareEngenharia de Software

Análise e Desenvolvimento de Sistemas

Janete Pereira do Amaral [email protected]

Área de Conhecimento (SWEBOK) dividida nos seguintes tópicos:Área de Conhecimento (SWEBOK) dividida nos seguintes tópicos:

• FundamentosFundamentos de Requisitos de Software de Requisitos de Software

• Processo de RequisitosProcesso de Requisitos

• Elicitação de RequisitosElicitação de Requisitos - captura, descoberta, aquisição - captura, descoberta, aquisição

• Análise de RequisitosAnálise de Requisitos - detecção e resolução de conflitos, - detecção e resolução de conflitos, descoberta dos limites e interações do sistema com o ambiente descoberta dos limites e interações do sistema com o ambiente (mapeamento dos requisitos do sistema para requisitos do (mapeamento dos requisitos do sistema para requisitos do software)software)

• Especificação de RequisitosEspecificação de Requisitos - estrutura, qualidade e verificação - estrutura, qualidade e verificação do documento de requisitos do documento de requisitos

• Validação de RequisitosValidação de Requisitos - verificação de omissões, conflitos e - verificação de omissões, conflitos e ambigüidades + adequação às normas de qualidadeambigüidades + adequação às normas de qualidade

• Considerações PráticasConsiderações Práticas - gestão de mudanças, manutenção da - gestão de mudanças, manutenção da consistência com as fases posteriores consistência com as fases posteriores

REQUISITOS DE SOFTWAREREQUISITOS DE SOFTWARE

REQUISITOS: Definição REQUISITOS: Definição É uma propriedade que deve ser exibida no software, para solucionar algum É uma propriedade que deve ser exibida no software, para solucionar algum problema no mundo real. problema no mundo real.

Um problema pode ser:Um problema pode ser: - automatizar parte de uma tarefa de alguém que utilizará o software - automatizar parte de uma tarefa de alguém que utilizará o software - suportar os processos do negócio da organização - suportar os processos do negócio da organização - corrigir saídas de um software existente - corrigir saídas de um software existente - controlar um dispositivo, etc. - controlar um dispositivo, etc.

Os requisitos de software são uma combinação complexa das exigências de Os requisitos de software são uma combinação complexa das exigências de diferentes pessoas, em diferentes níveis numa organização, e do ambiente diferentes pessoas, em diferentes níveis numa organização, e do ambiente em que o software operará. em que o software operará.

Uma propriedade essencial de todos os requisitos de software é que seja Uma propriedade essencial de todos os requisitos de software é que seja verificável. Pode ser difícil ou caro verificar determinados requisitos de verificável. Pode ser difícil ou caro verificar determinados requisitos de software. software. Ex.: A verificação dos requisitos de desempenho de um Call-CenterEx.: A verificação dos requisitos de desempenho de um Call-Center pode requerer o desenvolvimento de um software de simulação. pode requerer o desenvolvimento de um software de simulação.

REQUISITOS DE SOFTWARE - FUNDAMENTOSREQUISITOS DE SOFTWARE - FUNDAMENTOS

Requisitos do UsuárioRequisitos do UsuárioDeclarações em linguagem natural e também em diagramas, sobre as funções Declarações em linguagem natural e também em diagramas, sobre as funções que o sistema deve fornecer e as restrições sobre as quais deve operar.que o sistema deve fornecer e as restrições sobre as quais deve operar.

Problemas encontrados: Falta de clareza / Confusão de requisitos / Problemas encontrados: Falta de clareza / Confusão de requisitos / Fusão de requisitos Fusão de requisitos

Requisitos de SistemaRequisitos de Sistema – Especificação Funcional – Especificação FuncionalEstabelecem detalhadamente as funções e as restrições de sistema. O Estabelecem detalhadamente as funções e as restrições de sistema. O documento de requisitos de sistema, algumas vezes chamado de documento de requisitos de sistema, algumas vezes chamado de especificação funcionalespecificação funcional, deve ser preciso. Ele servirá como um contrato entre , deve ser preciso. Ele servirá como um contrato entre o comprador do sistema e o desenvolvedor do software.o comprador do sistema e o desenvolvedor do software.

Especificação de Projeto de SoftwareEspecificação de Projeto de SoftwareÉ uma descrição abstrata de projeto de software; que é uma base para o É uma descrição abstrata de projeto de software; que é uma base para o projeto e a implementação mais detalhados. Essa especificação acrescenta projeto e a implementação mais detalhados. Essa especificação acrescenta mais detalhes à especificação de requisitos do sistema.mais detalhes à especificação de requisitos do sistema.

REQUISITOS DE SOFTWARE - 3 NÍVEISREQUISITOS DE SOFTWARE - 3 NÍVEIS

SommervilleSommerville

Requisitos FuncionaisRequisitos Funcionais Descrevem as funções que o software deve executar. Descrevem as funções que o software deve executar. Por exemplo: formatar um texto ou modular um sinal. Por exemplo: formatar um texto ou modular um sinal. São conhecidos como capacidades disponíveis no softwareSão conhecidos como capacidades disponíveis no software

Requisitos Não-FuncionaisRequisitos Não-Funcionais São aqueles que atuam restringindo a solução. São aqueles que atuam restringindo a solução. São chamados de restrições ou requisitos de qualidade. São chamados de restrições ou requisitos de qualidade. São os requisitos inerentes à performance, manutenibilidade, segurança, São os requisitos inerentes à performance, manutenibilidade, segurança, confiabilidade, etc.confiabilidade, etc.

REQUISITOS FUNCIONAIS E NÃO-FUNCIONAISREQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS

Requisitos Requisitos Não Não

FuncionaisFuncionais

Requisitos Requisitos do do

ProdutoProduto

Requisitos Requisitos Organiza-Organiza-

cionaiscionais

Requisitos Requisitos ExternosExternos

Requisitos Requisitos Facilidade Facilidade

de Usode Uso

Requisitos Requisitos de de

PortabilidadePortabilidade


ConfiabilidadeConfiabilidade


EficiênciaEficiência


Desempenho-Desempenho-


EspaçoEspaço

RequisitosRequisitosde de

EntregaEntrega


PadrõesPadrões


Implemen-Implemen-taçãotação


Intero-Intero-perabilidadeperabilidade

Requisitos Requisitos LegaisLegais

Requisitos Requisitos ÉticosÉticos


PrivacidadePrivacidade


SegurançaSegurança

REQUISITOS NÃO-FUNCIONAISREQUISITOS NÃO-FUNCIONAIS

CategoriaCategoria FuncionalidadeFuncionalidade((FunctionalityFunctionality))

Conjuntos de recursos / Habilidades / SegurançaConjuntos de recursos / Habilidades / Segurança

UsabilidadeUsabilidade(Usability)(Usability)

Fatores humanos / Estética / Consistência na interface do usuário / Ajuda Fatores humanos / Estética / Consistência na interface do usuário / Ajuda on-line e contextual / Assistentes e agentes / Documentação do usuário / on-line e contextual / Assistentes e agentes / Documentação do usuário / Materiais de treinamentoMateriais de treinamento

ConfiabilidadeConfiabilidade(Reliability)(Reliability)

Freqüência e gravidade de falha / Possibilidade de recuperação / Freqüência e gravidade de falha / Possibilidade de recuperação / Possibilidade de previsão / Exatidão / Tempo médio entre falhas (MTBF)Possibilidade de previsão / Exatidão / Tempo médio entre falhas (MTBF)

DesempenhoDesempenho(Performance)(Performance)

Velocidade / Eficiência / Disponibilidade / Exatidão / Taxa de transferência / Velocidade / Eficiência / Disponibilidade / Exatidão / Taxa de transferência / Tempo de resposta / Tempo de recuperação / Uso de recursosTempo de resposta / Tempo de recuperação / Uso de recursos

SuportabilidadeSuportabilidade(Supportability)(Supportability)

Possibilidade de teste / Extensibilidade / Adaptabilidade / Manutenibilidade / Possibilidade de teste / Extensibilidade / Adaptabilidade / Manutenibilidade / Compatibilidade / Possibilidade de configuração / Possibilidade de serviço / Compatibilidade / Possibilidade de configuração / Possibilidade de serviço / Possibilidade de instalação / Possibilidade de localização Possibilidade de instalação / Possibilidade de localização (internacionalização)(internacionalização)

DEFINIÇÃO DE REQUISITOS - Modelo FURPS+ (RUP)DEFINIÇÃO DE REQUISITOS - Modelo FURPS+ (RUP)(Functionality, Usability, Reliability, Performance e Supportability) (Functionality, Usability, Reliability, Performance e Supportability)

"+" em FURPS+ inclui ainda os requisitos: restrições de design, requisitos de "+" em FURPS+ inclui ainda os requisitos: restrições de design, requisitos de implementação, requisitos de interface e requisitos físicosimplementação, requisitos de interface e requisitos físicos

SistemaSistema significa uma combinação de elementos para realizar um significa uma combinação de elementos para realizar um objetivo definido. objetivo definido. Inclui hardware, software, firmware, pessoas, informações, Inclui hardware, software, firmware, pessoas, informações, técnicas, funcionalidades, serviços e outros elementos de suportetécnicas, funcionalidades, serviços e outros elementos de suporte

Requisitos de SistemaRequisitos de Sistema são requisitos para o sistema como um todo. são requisitos para o sistema como um todo. Compreende requisitos do usuário, requisitos de outros Compreende requisitos do usuário, requisitos de outros patrocinadores (tais como agências reguladoras) e requisitos sem patrocinadores (tais como agências reguladoras) e requisitos sem fonte humana identificável.fonte humana identificável.

Num sistema contendo componentes de software, os Num sistema contendo componentes de software, os Requisitos de Requisitos de SoftwareSoftware são derivados dos requisitos de sistema são derivados dos requisitos de sistema

REQUISITOS DE SISTEMA E REQUISITOS DE SOFTWARE REQUISITOS DE SISTEMA E REQUISITOS DE SOFTWARE

REQUISITOS DE DOMÍNIOREQUISITOS DE DOMÍNIO

São requisitos que se originam do domínio da aplicação do São requisitos que se originam do domínio da aplicação do sistema e que refletem características deste domínio. sistema e que refletem características deste domínio.

Podem ser requisitos funcionais e não-funcionaisPodem ser requisitos funcionais e não-funcionais

Modelos de Processo de RequisitosModelos de Processo de Requisitos• Não é uma atividade discreta do início do ciclo de vida do software, mas um processo Não é uma atividade discreta do início do ciclo de vida do software, mas um processo

iniciado no começo do projeto e que continua sendo refinado durante todo o ciclo.iniciado no começo do projeto e que continua sendo refinado durante todo o ciclo.• Identifica os requisitos de software como itens de configuração e gerencia estes itens Identifica os requisitos de software como itens de configuração e gerencia estes itens

usando as mesmas práticas de gerência de configuração, como os demais produtos usando as mesmas práticas de gerência de configuração, como os demais produtos do processo do processo

• Necessita ser adaptado para a organização e para o contexto do projetoNecessita ser adaptado para a organização e para o contexto do projeto

Compreende as atividades de Compreende as atividades de elicitação, análise, especificação e elicitação, análise, especificação e validaçãovalidação que são configuradas para diferentes tipos de projetos e que são configuradas para diferentes tipos de projetos e restrições. restrições.

Inclui também atividades que fornecem entrada para o processo de Inclui também atividades que fornecem entrada para o processo de requisitos, tais como requisitos, tais como marketing e estudo de viabilidademarketing e estudo de viabilidade..

PROCESSO DE REQUISITOS PROCESSO DE REQUISITOS

Estudo de ViabilidadeEstudo de Viabilidade

O processo de Engenharia de Requisitos deve começar com um O processo de Engenharia de Requisitos deve começar com um estudo de viabilidade. estudo de viabilidade.

É um estudo breve, direcionado, que se destina a responder a É um estudo breve, direcionado, que se destina a responder a algumas perguntas:algumas perguntas:-O sistema contribui para os objetivos gerais da organização?O sistema contribui para os objetivos gerais da organização?-O Sistema pode ser implementado com a utilização da tecnologia O Sistema pode ser implementado com a utilização da tecnologia atual dentro das restrições de custo e de prazo?atual dentro das restrições de custo e de prazo?-O Sistema pode ser integrado com outros sistemas em operação?O Sistema pode ser integrado com outros sistemas em operação?

Depois do Estudo de Viabilidade, o próximo estágio do processo é a Depois do Estudo de Viabilidade, o próximo estágio do processo é a Elicitação e a Análise de RequisitosElicitação e a Análise de Requisitos


Atores do ProcessoAtores do Processo - O - O papel dos que participam do processo de requisitos papel dos que participam do processo de requisitos

- UsuáriosUsuários – Aqueles que operam o software. É frequentemente um grupo – Aqueles que operam o software. É frequentemente um grupo heterogêneo, compreendendo pessoas com diferentes papéis e requisitosheterogêneo, compreendendo pessoas com diferentes papéis e requisitos

- Clientes- Clientes – Aqueles que adquirem o software ou que representam o mercado-alvo do – Aqueles que adquirem o software ou que representam o mercado-alvo do softwaresoftware

- Analistas de Mercado- Analistas de Mercado – Um produto de massa não tem um cliente específico. As – Um produto de massa não tem um cliente específico. As pessoas de marketing necessitam estabelecer o que o mercado necessita, e agir pessoas de marketing necessitam estabelecer o que o mercado necessita, e agir como um interlocutor dos clientes como um interlocutor dos clientes

- ReguladoresReguladores – Muitos tipos de aplicação, tais como aplicações bancárias e – Muitos tipos de aplicação, tais como aplicações bancárias e aplicações para transportes públicos são regulamentadas. Software nestes aplicações para transportes públicos são regulamentadas. Software nestes domínios devem obedecer aos requisitos impostos pelas autoridades reguladorasdomínios devem obedecer aos requisitos impostos pelas autoridades reguladoras

- Engenheiros de SoftwareEngenheiros de Software – Estes indivíduos têm interesse na lucratividade do – Estes indivíduos têm interesse na lucratividade do desenvolvimento de software, por meio do reuso de componentes. Se o cliente desenvolvimento de software, por meio do reuso de componentes. Se o cliente possui um requisito que compromete o potencial para reuso, o engenheiro de possui um requisito que compromete o potencial para reuso, o engenheiro de software deve ponderar seus objetivos em relação aos objetivos do cliente software deve ponderar seus objetivos em relação aos objetivos do cliente

Nem sempre é possível atender perfeitamente aos requisitos de todos os Nem sempre é possível atender perfeitamente aos requisitos de todos os envolvidos. O trabalho do engenheiro de software é negociar um meio envolvidos. O trabalho do engenheiro de software é negociar um meio termo que seja aceitável para os principais patrocinadores, dentro das termo que seja aceitável para os principais patrocinadores, dentro das restrições orçamentárias, técnicas, legais e outras.restrições orçamentárias, técnicas, legais e outras.


Seu objetivo é identificar a origem dos requisitos e como os Seu objetivo é identificar a origem dos requisitos e como os Engenheiros de Software podem coletá-loEngenheiros de Software podem coletá-lo

É o primeiro estágio na construção do entendimento do problema É o primeiro estágio na construção do entendimento do problema que o software deverá solucionar. É fundamentalmente um que o software deverá solucionar. É fundamentalmente um atividade humana. atividade humana.

A elicitação de requisitos é também chamada de A elicitação de requisitos é também chamada de captura de captura de requisitos, descoberta de requisitos e aquisição de requisitos requisitos, descoberta de requisitos e aquisição de requisitos

Um dos princípios da Engenharia de Software é estabelecer uma Um dos princípios da Engenharia de Software é estabelecer uma boa comunicação entre Usuários e Engenheiros de Software. Antes boa comunicação entre Usuários e Engenheiros de Software. Antes de começar o desenvolvimento de um software, o especialista em de começar o desenvolvimento de um software, o especialista em requisitos deve fazer a ponte para esta comunicação. Eles devem requisitos deve fazer a ponte para esta comunicação. Eles devem mediar entre o domínio dos usuários e o mundo técnico dos mediar entre o domínio dos usuários e o mundo técnico dos engenheiros de softwareengenheiros de software

ELICITAÇÃO DE REQUISITOSELICITAÇÃO DE REQUISITOS

Num software, os requisitos podem ter várias fontes. É essencial Num software, os requisitos podem ter várias fontes. É essencial que todas elas sejam avaliadas quanto a seu impacto no que todas elas sejam avaliadas quanto a seu impacto no software: software:

1.1. ObjetivosObjetivos - Refere-se aos objetivos de alto nível do software. Fornecem a - Refere-se aos objetivos de alto nível do software. Fornecem a motivação para o software, mas frequentemente eles são vagamente motivação para o software, mas frequentemente eles são vagamente formulados. Engenheiros de Software necessitam dar atenção à formulados. Engenheiros de Software necessitam dar atenção à determinação das prioridades e custos dos objetivos. determinação das prioridades e custos dos objetivos.

Um Um estudo de viabilidadeestudo de viabilidade é um instrumento considerado de baixo custo é um instrumento considerado de baixo custo para realizar esta avaliação.para realizar esta avaliação.

2.2. Conhecimento do DomínioConhecimento do Domínio – O Engenheiro de Software necessita – O Engenheiro de Software necessita adquirir ou ter disponível conhecimento sobre o domínio da aplicação. adquirir ou ter disponível conhecimento sobre o domínio da aplicação.

Este conhecimento permite ao Engenheiro de Software inferir o Este conhecimento permite ao Engenheiro de Software inferir o conhecimento tácito (não articulado) dos patrocinadores e determinar o conhecimento tácito (não articulado) dos patrocinadores e determinar o trade-offstrade-offs necessário entre os requisitos conflitantes, podendo muitas necessário entre os requisitos conflitantes, podendo muitas vezes ser necessário tomar decisões.vezes ser necessário tomar decisões.

FONTES DE REQUISITOSFONTES DE REQUISITOS

3. Patrocinadores3. Patrocinadores -- Muitos softwares tornam-se insatisfatório porque levam em Muitos softwares tornam-se insatisfatório porque levam em conta apenas os requisitos de um grupo de patrocinadores. Quando o conta apenas os requisitos de um grupo de patrocinadores. Quando o software é disponibilizado observa-se a dificuldade em seu uso a software é disponibilizado observa-se a dificuldade em seu uso a inadequação à estrutura cultural e política dos clientes da organização. O inadequação à estrutura cultural e política dos clientes da organização. O Engenheiro de Software necessita identificar, representar e gerenciar os Engenheiro de Software necessita identificar, representar e gerenciar os pontos de vista dos diferentes tipos de patrocinadores. pontos de vista dos diferentes tipos de patrocinadores.

4. O Ambiente Operacional4. O Ambiente Operacional – Requisitos são derivados do ambiente em que o – Requisitos são derivados do ambiente em que o software será executado. Por exemplo: restrições de tempo para software de software será executado. Por exemplo: restrições de tempo para software de tempo real ou restrições de interoperabilidade em ambientes de escritório. tempo real ou restrições de interoperabilidade em ambientes de escritório. Isto deve ser bem analisado, porque poderá afetar os custos, a viabilidade, Isto deve ser bem analisado, porque poderá afetar os custos, a viabilidade, além de restringir as escolhas do projeto.além de restringir as escolhas do projeto.

5. O Ambiente Organizacional5. O Ambiente Organizacional – Software é frequentemente requerido para – Software é frequentemente requerido para fornecer suporte a um processo de negócio, o qual está condicionado pela fornecer suporte a um processo de negócio, o qual está condicionado pela estrutura, cultura e políticas internas da organização. O Engenheiro de estrutura, cultura e políticas internas da organização. O Engenheiro de Software necessita estar sensível a isto, uma vez que o novo software não Software necessita estar sensível a isto, uma vez que o novo software não deve forçar mudanças não planejada nos processos de negócio.deve forçar mudanças não planejada nos processos de negócio.

FONTES DE REQUISITOSFONTES DE REQUISITOS

Uma vez que as fontes de requisitos foram identificadas, o Engenheiro de Software Uma vez que as fontes de requisitos foram identificadas, o Engenheiro de Software pode iniciar a elicitação dos requisitos.pode iniciar a elicitação dos requisitos.

São técnicas para os patrocinadores articularem seus requisitos. O Engenheiro de São técnicas para os patrocinadores articularem seus requisitos. O Engenheiro de Software necessita ser sensibilizado para o fato de que usuários podem ter dificuldade Software necessita ser sensibilizado para o fato de que usuários podem ter dificuldade em descrever suas tarefas, podem deixar de prestar informações importantes ou não em descrever suas tarefas, podem deixar de prestar informações importantes ou não estarem dispostos à cooperar.estarem dispostos à cooperar.

É importante entender que a elicitação não é uma atividade passiva, e mesmo que os É importante entender que a elicitação não é uma atividade passiva, e mesmo que os patrocinadores sejam cooperativos e articulados, o Engenheiro de Software ainda terá patrocinadores sejam cooperativos e articulados, o Engenheiro de Software ainda terá que trabalhar duramente para elicitar a informação correta.que trabalhar duramente para elicitar a informação correta.

Existem várias técnicas para elicitação de requisitos, tais como:Existem várias técnicas para elicitação de requisitos, tais como:

• Entrevista / QuestionárioEntrevista / Questionário• Observação DiretaObservação Direta• Cenários Cenários • ProtótiposProtótipos• Reuniões facilitadas / JADReuniões facilitadas / JAD• Pontos de VistaPontos de Vista• UML - Casos de UsoUML - Casos de Uso• Inspeção Inspeção

TÉCNICAS DE ELICITAÇÃO DE REQUISITOSTÉCNICAS DE ELICITAÇÃO DE REQUISITOS

EntrevistaEntrevista - É um meio tradicional de elicitar requisitos. É importante - É um meio tradicional de elicitar requisitos. É importante entender as vantagens e limitações das entrevistas e como elas devem ser entender as vantagens e limitações das entrevistas e como elas devem ser conduzidas.conduzidas.

CenáriosCenários - É um valoroso meio para fornecer contexto a elicitação de - É um valoroso meio para fornecer contexto a elicitação de requisitos. Ele permite o Engenheiro de Software fornecer um framework requisitos. Ele permite o Engenheiro de Software fornecer um framework para questões sobre tarefas do usuário permitindo serem feitas questões do para questões sobre tarefas do usuário permitindo serem feitas questões do tipo ‘e se’ e ‘como isto é feito’. O exemplo mais comum de cenários é o tipo ‘e se’ e ‘como isto é feito’. O exemplo mais comum de cenários é o Casos de UsoCasos de Uso

ProtótipoProtótipo - É uma ferramenta de muito valor para a clarificação de - É uma ferramenta de muito valor para a clarificação de requisitos. Eles podem agir numa forma similar aos cenários, fornecendo requisitos. Eles podem agir numa forma similar aos cenários, fornecendo aos usuários um contexto que permite melhor entender quais informações aos usuários um contexto que permite melhor entender quais informações eles necessitam fornecer. Há uma grande variedade de técnicas de eles necessitam fornecer. Há uma grande variedade de técnicas de prototipação, que vai desde o projeto de telas em papel até versões beta-prototipação, que vai desde o projeto de telas em papel até versões beta-teste de produtos de software teste de produtos de software


Reuniões FacilitadasReuniões Facilitadas - O propósito é obter um esforço conjunto, partindo-se da - O propósito é obter um esforço conjunto, partindo-se da hipótese que um grupo de pessoas pode trazer mais hipótese que um grupo de pessoas pode trazer mais insightsinsights para os requisitos de para os requisitos de software que pessoas isoladas. Nestas reuniões podem ser realizados software que pessoas isoladas. Nestas reuniões podem ser realizados brainstormsbrainstorms e refinamento de idéias que nem sempre é possível realizar em outras técnicas.e refinamento de idéias que nem sempre é possível realizar em outras técnicas. Uma outra vantagem é que os requisitos conflitantes emergem mais rapidamente, Uma outra vantagem é que os requisitos conflitantes emergem mais rapidamente, permitindo que os patrocinadores vejam onde se encontra o conflito. Esta técnica permitindo que os patrocinadores vejam onde se encontra o conflito. Esta técnica pode resultar num mais rico e consistente conjunto de requisitos.pode resultar num mais rico e consistente conjunto de requisitos.

Estas reuniões necessitam serem cuidadosamente manuseadas para prevenir Estas reuniões necessitam serem cuidadosamente manuseadas para prevenir situação não desejáveis.situação não desejáveis.

Observação direta -Observação direta - A importância do contexto do software dentro do ambiente A importância do contexto do software dentro do ambiente organizacional tem levado à adaptação de técnicas de observação para a elicitação organizacional tem levado à adaptação de técnicas de observação para a elicitação de requisitos. Engenheiros de Software aprendem sobre as tarefas dos usuários de requisitos. Engenheiros de Software aprendem sobre as tarefas dos usuários imergindo no ambiente e observando como os usuários interagem com o software, imergindo no ambiente e observando como os usuários interagem com o software, e com os demais usuários. Estas técnicas são relativamente caras, mas permitem e com os demais usuários. Estas técnicas são relativamente caras, mas permitem mostrar que muitas tarefas dos usuários e os processos de negócios são muito mostrar que muitas tarefas dos usuários e os processos de negócios são muito complexos para seus atores descreverem facilmente.complexos para seus atores descreverem facilmente.


Objetivo:Objetivo:• Detectar e resolver conflitos entre os requisitos Detectar e resolver conflitos entre os requisitos • Descobrir os limites do software e como ele deve interagir com seu ambiente Descobrir os limites do software e como ele deve interagir com seu ambiente • Elaborar os requisitos do sistema para derivar os requisitos do softwareElaborar os requisitos do sistema para derivar os requisitos do software Cuidado deve ser tomado para descrever requisitos precisamente para ser Cuidado deve ser tomado para descrever requisitos precisamente para ser

possível validar os requisitos, verificar sua implementação e estimar seus possível validar os requisitos, verificar sua implementação e estimar seus custos custos

Classificação de RequisitosClassificação de Requisitos• Se os requisitos são funcionais ou não-funcionaisSe os requisitos são funcionais ou não-funcionais• Se os requisitos são derivados de um ou mais requisitos de alto nível ou de Se os requisitos são derivados de um ou mais requisitos de alto nível ou de

uma propriedade emergente ou está sendo imposto diretamente por um uma propriedade emergente ou está sendo imposto diretamente por um patrocinador ou alguma outra fontepatrocinador ou alguma outra fonte

• Se o requisito é do produto ou do processo. Requisitos do processo podem Se o requisito é do produto ou do processo. Requisitos do processo podem restringir a escolha da empresa a ser contratada, o processo de Engenharia restringir a escolha da empresa a ser contratada, o processo de Engenharia de Software ou os padrões a serem adotados. de Software ou os padrões a serem adotados.

ANÁLISE DE REQUISITOSANÁLISE DE REQUISITOS

A Prioridade dos RequisitosA Prioridade dos Requisitos Em geral, os requisitos de maior prioridade e os mais essenciais são aquele que atingem Em geral, os requisitos de maior prioridade e os mais essenciais são aquele que atingem os objetivos do software. A prioridade é frequentemente classificada numa escala fixa, os objetivos do software. A prioridade é frequentemente classificada numa escala fixa, como obrigatória, altamente desejável, desejável e opcional. A prioridade tem que ser como obrigatória, altamente desejável, desejável e opcional. A prioridade tem que ser balanceada em relação aos custos de desenvolvimento e de implementação.balanceada em relação aos custos de desenvolvimento e de implementação.

O Escopo dos RequisitosO Escopo dos Requisitos Refere-se à extensão na qual o requisito afeta o software e seus componentes. Alguns Refere-se à extensão na qual o requisito afeta o software e seus componentes. Alguns requisitos, como os não-funcionais, têm um escopo global e sua satisfação não pode ser requisitos, como os não-funcionais, têm um escopo global e sua satisfação não pode ser alocada a um componente específico. Um requisito com escopo global pode afetar a alocada a um componente específico. Um requisito com escopo global pode afetar a arquitetura do software e o projeto de muitos componentes, enquanto aqueles com o arquitetura do software e o projeto de muitos componentes, enquanto aqueles com o escopo mais estreito pode oferecer uma variedade de opções de projeto e têm pouco escopo mais estreito pode oferecer uma variedade de opções de projeto e têm pouco impacto na satisfação de outros requisitos.impacto na satisfação de outros requisitos.

Volatilidade/Estabilidade Volatilidade/Estabilidade Alguns requisitos mudam durante o ciclo de vida do software, e até mesmo durante o Alguns requisitos mudam durante o ciclo de vida do software, e até mesmo durante o processo de desenvolvimento. É importante prever a probabilidade das mudanças de processo de desenvolvimento. É importante prever a probabilidade das mudanças de requisitos acontecerem. requisitos acontecerem. Identificar os requisitos potencialmente voláteis pode auxiliar na elaboração de um Identificar os requisitos potencialmente voláteis pode auxiliar na elaboração de um projeto que seja mais tolerante a falhas.projeto que seja mais tolerante a falhas.


Modelagem ConceitualModelagem Conceitual

O desenvolvimento de modelos dos problemas do mundo real é o ponto chave para a O desenvolvimento de modelos dos problemas do mundo real é o ponto chave para a análise de requisitos. análise de requisitos. Seu propósito é auxiliar no entendimento do problema antes do início do projeto da Seu propósito é auxiliar no entendimento do problema antes do início do projeto da solução. Modelos conceituais compreendem modelos das entidades do domínio do solução. Modelos conceituais compreendem modelos das entidades do domínio do problema configurados para refletir os relacionamentos e dependências do mundo real.problema configurados para refletir os relacionamentos e dependências do mundo real.

Vários tipos de modelos podem ser elaborados. Tais como fluxos de controle e de Vários tipos de modelos podem ser elaborados. Tais como fluxos de controle e de dados, modelos de estado, trace de eventos, interações dos usuários, modelos de dados, modelos de estado, trace de eventos, interações dos usuários, modelos de objetos, modelos de dados e muitos outrosobjetos, modelos de dados e muitos outros

Dentre os fatores que influenciam a escolha de um modelo incluem: Dentre os fatores que influenciam a escolha de um modelo incluem: 1- A natureza do problema.1- A natureza do problema.Alguns software demandam certos aspectos a serem analisados rigorosamente. Ex.: Alguns software demandam certos aspectos a serem analisados rigorosamente. Ex.: modelos de controle de fluxo e de estado são mais apropriados para software de tempo modelos de controle de fluxo e de estado são mais apropriados para software de tempo real que para software de gerenciamento de informações. O oposto se dá para modelos real que para software de gerenciamento de informações. O oposto se dá para modelos de dados.de dados.

2- A experiência do Engenheiro de Software2- A experiência do Engenheiro de Software É frequentemente mais produtivo adotar a notação de modelagem ou o método que o É frequentemente mais produtivo adotar a notação de modelagem ou o método que o Engenheiro de Software tenha mais experiência.Engenheiro de Software tenha mais experiência.


3- O Processo de Requisitos do Cliente3- O Processo de Requisitos do Cliente Clientes podem impor sua notação, seu método favorito, ou proibir aquele que não lhe Clientes podem impor sua notação, seu método favorito, ou proibir aquele que não lhe seja familiar. seja familiar.

4- A Disponibilidade de Métodos e Ferramentas4- A Disponibilidade de Métodos e FerramentasNotações ou métodos que não são bem suportados por treinamento ou por ferramenta Notações ou métodos que não são bem suportados por treinamento ou por ferramenta podem não obter larga aceitação, mesmo se ele for apropriado para determinado tipo de podem não obter larga aceitação, mesmo se ele for apropriado para determinado tipo de problemaproblemaNa maioria dos casos, é útil iniciar construindo um modelo de contexto. O contexto do Na maioria dos casos, é útil iniciar construindo um modelo de contexto. O contexto do software fornece a conexão entre o software e seu ambiente externo. É importante software fornece a conexão entre o software e seu ambiente externo. É importante entender o contexto do software em seu ambiente operacional e identificar suas entender o contexto do software em seu ambiente operacional e identificar suas interfaces com este ambiente.interfaces com este ambiente.

Negociação de RequisitosNegociação de RequisitosUm outro termo para negociação de requisitos é resolução de conflitos. Um outro termo para negociação de requisitos é resolução de conflitos. Na resolução de problemas com requisitos onde ocorrem conflitos entre patrocinadores Na resolução de problemas com requisitos onde ocorrem conflitos entre patrocinadores requerendo caraterísticas incompatíveis requerendo caraterísticas incompatíveis


O termo O termo “Especificação dos Requisitos de Software”“Especificação dos Requisitos de Software” refere-se à produção de um refere-se à produção de um documento que deve ser sistematicamente revisado, avaliado e aprovado. documento que deve ser sistematicamente revisado, avaliado e aprovado.

Para sistemas complexos três diferentes tipos de documentos devem ser produzidos: Para sistemas complexos três diferentes tipos de documentos devem ser produzidos: - Definição do sistema, Definição do sistema, - Requisitos do Sistema e Requisitos do Sistema e - Requisitos de Software. Requisitos de Software.

Para software simples, somente um destes três é requerido. Para software simples, somente um destes três é requerido.

1. Documento de Definição do Sistema1. Documento de Definição do Sistema Registra os requisitos do sistema numa perspectiva de alto nível. Dentre seus leitores Registra os requisitos do sistema numa perspectiva de alto nível. Dentre seus leitores estão os representantes dos usuários do sistema e clientes. Seu conteúdo deve ser estão os representantes dos usuários do sistema e clientes. Seu conteúdo deve ser apresentado com termos do domínio do problema.apresentado com termos do domínio do problema.O documento lista os requisitos do sistema com informações sobre os objetivos globais O documento lista os requisitos do sistema com informações sobre os objetivos globais do sistema, o ambiente alvo, restrições, definições e requisitos não funcionais.do sistema, o ambiente alvo, restrições, definições e requisitos não funcionais.Ele também pode incluir modelos conceituais para ilustrar o contexto do sistema, Ele também pode incluir modelos conceituais para ilustrar o contexto do sistema, cenários e entidades do domínio, bem como dados, informações e fluxos de trabalho.cenários e entidades do domínio, bem como dados, informações e fluxos de trabalho.

ESPECIFICAÇÃO DE REQUISITOSESPECIFICAÇÃO DE REQUISITOS

2. Especificação de Requisitos do Sistema2. Especificação de Requisitos do SistemaSeparam a descrição dos requisitos do sistema da descrição dos Separam a descrição dos requisitos do sistema da descrição dos requisitos do software.requisitos do software.Nesta visão, os requisitos do sistema é especificado, os requisitos do Nesta visão, os requisitos do sistema é especificado, os requisitos do software são derivados dos requisitos do sistema e os requisitos para os software são derivados dos requisitos do sistema e os requisitos para os componentes do software são especificados. componentes do software são especificados.

3. Especificação de Requisitos de Software3. Especificação de Requisitos de Software A especificação dos requisitos de software estabelecem as bases para o A especificação dos requisitos de software estabelecem as bases para o acordo entre clientes e fornecedores sobre o que o produto software deve acordo entre clientes e fornecedores sobre o que o produto software deve fazer, como também o que não é esperado que seja feito.fazer, como também o que não é esperado que seja feito.

Para leitores não técnicos, o documento de especificação de requisitos é Para leitores não técnicos, o documento de especificação de requisitos é frequentemente acompanhado pelo documento de definição de requisitosfrequentemente acompanhado pelo documento de definição de requisitos

Requisitos de software são frequentemente escritos em linguagem natural, Requisitos de software são frequentemente escritos em linguagem natural, mas na especificação de requisitos de software, isto pode ser mas na especificação de requisitos de software, isto pode ser suplementado por descrições formais e semi-formaissuplementado por descrições formais e semi-formais

ESPECIFICAÇÃO DE REQUISITOSESPECIFICAÇÃO DE REQUISITOS

O documento de requisitos deve ser submetido ao procedimento de validação de O documento de requisitos deve ser submetido ao procedimento de validação de verificação.verificação.

O requisitos devem ser validados para assegurar que o Engenheiro de Software O requisitos devem ser validados para assegurar que o Engenheiro de Software entendeu os requisitos. É importante que o documento de requisitos esteja em entendeu os requisitos. É importante que o documento de requisitos esteja em conformidade com os padrões da empresa e seja entendível, consistente e conformidade com os padrões da empresa e seja entendível, consistente e completo.completo.Notações formais oferecem uma vantagem importante de permitir que as Notações formais oferecem uma vantagem importante de permitir que as propriedades sejam provadas.propriedades sejam provadas.Os patrocinadores, incluindo representantes dos clientes e desenvolvedores, Os patrocinadores, incluindo representantes dos clientes e desenvolvedores, devem revisá-losdevem revisá-los

Documentos de requisitos devem ser tratados como nas práticas de gerência de Documentos de requisitos devem ser tratados como nas práticas de gerência de configuração, ou seja, como qualquer artefato do processo de desenvolvimento de configuração, ou seja, como qualquer artefato do processo de desenvolvimento de softwaresoftwareÉ normal que seja especificado um ou mais pontos no processo de requisitos nos É normal que seja especificado um ou mais pontos no processo de requisitos nos quais os requisitos serão validados.quais os requisitos serão validados.O objetivo é identificar qualquer problema antes dos recursos serem alocados para O objetivo é identificar qualquer problema antes dos recursos serem alocados para atender o requisitoatender o requisito

VALIDAÇÃO DE REQUISITOSVALIDAÇÃO DE REQUISITOS

Revisão dos RequisitosRevisão dos RequisitosValidação por inspeção ou revisão dos documentos de requisitos.Validação por inspeção ou revisão dos documentos de requisitos.

Um grupo de revisores é designado para procurar erros, falhas de definição, falta Um grupo de revisores é designado para procurar erros, falhas de definição, falta de clareza e desvios dos padrões.de clareza e desvios dos padrões.A composição do grupo que conduz a revisão é importante e deve ser guiado por A composição do grupo que conduz a revisão é importante e deve ser guiado por um check-list. um check-list.

REVISÃO DOS REQUISITOSREVISÃO DOS REQUISITOS

PrototipaçãoPrototipaçãoPrototipação é um meio para a validação da interpretação do requisitos do software, Prototipação é um meio para a validação da interpretação do requisitos do software, bem como para elicitação de novos requisitos.bem como para elicitação de novos requisitos.A vantagem dos protótipos é que eles podem tornar mais explícita a interpretação das A vantagem dos protótipos é que eles podem tornar mais explícita a interpretação das decisões do Engenheiro de Software, e quando necessário, fornecer feedback ou decisões do Engenheiro de Software, e quando necessário, fornecer feedback ou explicitar o porque eles estão erradosexplicitar o porque eles estão erradosVárias pessoa recomendam o uso de protótipo que evitam software, devido ao custo de Várias pessoa recomendam o uso de protótipo que evitam software, devido ao custo de seu desenvolvimento. Entretanto, se na construção do protótipo for evitado gastos de seu desenvolvimento. Entretanto, se na construção do protótipo for evitado gastos de recursos causado pela tentativa de satisfazer requisitos errôneos, eles podem ser mais recursos causado pela tentativa de satisfazer requisitos errôneos, eles podem ser mais facilmente justificadosfacilmente justificados

Validação do ModeloValidação do Modelo É necessário validar a qualidade dos modelos desenvolvidos durante a análise. É necessário validar a qualidade dos modelos desenvolvidos durante a análise. Ex.: No modelos de objetos -> fazer a análise estática para verificar o fluxo de Ex.: No modelos de objetos -> fazer a análise estática para verificar o fluxo de comunicação entre os objetos.comunicação entre os objetos.

Testes de AceitaçãoTestes de AceitaçãoUma propriedade dos requisitos de um software é que deve ser possível validá-lo para Uma propriedade dos requisitos de um software é que deve ser possível validá-lo para saber se o produto final satisfará. saber se o produto final satisfará. Requisitos que não podem ser validados são considerados “desejos”. Uma tarefa Requisitos que não podem ser validados são considerados “desejos”. Uma tarefa importante é planejar como verificar cada requisito. importante é planejar como verificar cada requisito. Identificar e projetar teste de aceitação pode ser difícil para requisitos não funcionais. Identificar e projetar teste de aceitação pode ser difícil para requisitos não funcionais. Para serem validados, deve ser observado se eles podem ser quantificadosPara serem validados, deve ser observado se eles podem ser quantificados

VALIDAÇÃO DE REQUISITOSVALIDAÇÃO DE REQUISITOS

• ComunicaçãoComunicação• Domínio de aplicação mal definidoDomínio de aplicação mal definido• InconsistênciasInconsistências• Falta de completezaFalta de completeza• AmbigüidadeAmbigüidade• Falta de métricasFalta de métricas

PROBLEMAS NA ÁREA DE REQUISITOSPROBLEMAS NA ÁREA DE REQUISITOS

• Combinar diferentes Técnicas de ElicitaçãoCombinar diferentes Técnicas de Elicitação• Definir métricasDefinir métricas• Criar ferramentas para automatizar o processo de requisitos Criar ferramentas para automatizar o processo de requisitos • Desenvolver métodos (ou adaptar os já existentes) para Processos Desenvolver métodos (ou adaptar os já existentes) para Processos

ÁgeisÁgeis• Pesquisar Requisitos de Software Livre e similaresPesquisar Requisitos de Software Livre e similares

TEMAS DE PESQUISA TEMAS DE PESQUISA

engenharia de software análise e desenvolvimento de sistemas janete pereira do amaral [email protected]

Documents

requisitos requisitos

software requisitos

funcionais requisitos

requisitos verificao

segurana requisitos

desempenho requisitos

eficincia requisitos

uso requisitos