Sem resumo de edição
Sem resumo de edição
 
(14 revisões intermediárias por 4 usuários não estão sendo mostradas)
Linha 1: Linha 1:
* Fundamentos de Requisitos de Software
* '''Fundamentos de Requisitos de Software'''
** Fundamentos básicos:
*** Elicitação: onde ocorre o levantamento por meio de técnincas de identificação
*** Detalhamento da documentação, isto é, descrição por meio de linguagem natural e modelos formais
*** Validação e negociação, onde ocorre uma garantia de  qualidade, a resolução dos conflitos e consistência das informações;
** Software: é um programa que utilizando a parte física da máquina(computador, celular, sistema embarcado) executa diferentes tarefas para o processamento de dados.
** Software: é um programa que utilizando a parte física da máquina(computador, celular, sistema embarcado) executa diferentes tarefas para o processamento de dados.
** Tipos de software:  
** Tipos de software:  
Linha 6: Linha 10:
*** Podem ser software aplicativo, como por exemplo: processador de texto,planilhas,banco de dados,correio eletrônico,razão, entrada de pedidos,folha de pagamentos
*** Podem ser software aplicativo, como por exemplo: processador de texto,planilhas,banco de dados,correio eletrônico,razão, entrada de pedidos,folha de pagamentos
** Sistema operacional: tem a função de fazer a máquina funcionar sendo a interface de comunicação entre o hardware e software
** Sistema operacional: tem a função de fazer a máquina funcionar sendo a interface de comunicação entre o hardware e software
** Funções: gerenciamento de processos, memória, sistema de arquivos e entrada e saída de dados
** Funções:  
*** Gerenciamento de processos
*** Memória
*** Sistema de arquivos  
*** Entrada e Saída de dados
** Fases:  
** Fases:  
*** é concebido para tentar atender a uma necessidade
*** é concebido para tentar atender a uma necessidade
Linha 15: Linha 23:
*** é retirado de operação ao final de sua vida útil.
*** é retirado de operação ao final de sua vida útil.
** Abaixo está um fluxograma, contendo todas as etapas e do "ciclo de vida do software":
** Abaixo está um fluxograma, contendo todas as etapas e do "ciclo de vida do software":
*** http://www.devmedia.com.br/imagens/engsoft/artigo1/image01.gif (figura I)
*** http://www.devmedia.com.br/imagens/engsoft/artigo1/image01.gif
** Pode se inferir com esse fluxograma que o software passa por muitos processos até ser concluído, dentre essas tarefas temos:  
** Pode se inferir com esse fluxograma que o software passa por muitos processos até ser concluído, dentre essas tarefas temos:  
*** requisitos
*** Requisitos
*** analíse
*** Analíse
*** desenho
*** Desenho
*** testes
*** Testes
*** implementação
*** Implementação
*** desenho detalhado
*** Desenho detalhado
*** testes de unidade
*** Testes de unidade
*** codificação
*** Codificação
*** integração
*** Integração
*** implantação
*** Implantação
*** operação.
*** Operação.
<br>
 
Requisitos de funcionamento de software:
 
Levantamento de Requisitos
 
Os requisitos do sistema são obtidos através de consultas aos stakeholders, documentação do sistema, conhecimento do domínio e estudos de mercado. Este processo é também conhecido como aquisição de requisitos ou descoberta de requisitos.
 
 
Análise e Negociação de Requisitos
 
 
Os requisitos são analisados em detalhe e os diferentes stakeholders negociam para decidirem que requisitos serão aceitos. Este processo é necessário visto que é inevitável o aparecimento de conflitos entre requisitos de diferentes fontes, existência de informação incompleta ou então os requisitos podem ser incompatíveis com o orçamento disponível para o desenvolvimento do sistema. Existe, no entanto, alguma flexibilidade na negociação dos requisitos para que seja possível concordar acerca de conjunto de requisitos para o sistema.
 
 
Documentação de Requisitos
 
 
Os requisitos acordados durante o processo de negociação são documentados com um nível de detalhe apropriado. Em geral, é necessário existir um documento de especificação de requisitos que seja compreendido por todos os stakeholders. Isto significa que os requisitos devem ser detalhados utilizando linguagem natural e diagramas. Podem também ser produzidos documentos de sistema mais detalhados tais como modelos de sistema.
 
Validação de Requisitos
 
Todos os requisitos obtidos nas actividades anteriores devem ser cuidadosamente verificados para apurar se estão completos e são consistentes. Este processo tem como finalidade detectar potenciais problemas no documento de especificação de requisitos antes que este seja utilizado como base para o desenvolvimento do sistema.
 
Modelos de Ciclo de Vida
 
Os modelos existentes(como na Figura I) possuem diferentes graus de sofisticação e complexidade. Para projetos que envolvem uma equipe de desenvolvimento pouco numerosa e experiente, o mais adequado será provavelmente um processo simples. No entanto, para sistemas maiores que envolvem equipes de dezenas ou centenas de elementos e milhares de utilizadores, um processo simples não é suficiente para oferecer a estrutura de gestão e disciplina necessárias à engenharia de um bom produto de software.


------------------------------------------------------------------------
------------------------------------------------------------------------


* Processo de Requisitos
* '''Requisitos de Produto e de Processo'''
**
** “A parte mais árdua na construção de um software consiste exatamente em identificar o que construir. Nenhuma outra fase compromete tanto o resultado do trabalho se elaborada de forma incorreta. Nenhuma outra parte dificulta tanto as correções posteriores”, citação de Frederick P Brooks , famoso e bem sucedido engenheiro de software.
** Requisitos de Produto:
*** Requisitos sobre o software a ser desenvolvido
*** Por exemplo: “O software deve verificar se um aluno cumpriu os pré-requisitos antes de aceitar a sua matrícula numa disciplina”;
** Requisitos de Processo:
*** são essencialmente restrições impostas ao desenvolvimento do software tais como linguagem de programação, processos e técnicas de desenvolvimento
*** Podem ser implícitos ou explícitos
*** Podem ser impostos:
**** pela organização desenvolvedora
**** pelo cliente
**** por terceiros
**** pelo professor


------------------------------------------------------------------------
------------------------------------------------------------------------
Linha 81: Linha 73:
------------------------------------------------------------------------
------------------------------------------------------------------------


* Análise de Requisitos
* '''Análise de Requisitos'''
**A Análise de Requisitos de software  é um aspecto importante no gerenciamento de projetos, é a parte responsável por coletar dados indispensáveis e exigências de que o usuário necessite para solucionar um problema e alcançar seus objetivos. Assim como determinar as suas expectativas de um usuário para determinado produto. Segundo a IEEE (1990) a análise de requisitos é um processo que envolve o estudo das necessidades do usuário para se encontrar uma definição correta ou completa do sistema ou requisito de software, essa análise de requisitos é essencial para o desenvolvimento do sistema, ela vai determinar o sucesso ou o fracasso do projeto. Os requisitos colhidos devem ser quantitativos, detalhados e relevantes para o projeto, pois eles fornecerão a referência para validar o produto final, estabelecerão o acordo entre cliente e fornecedor sobre o que e o software fará e consequentemente reduzirão os custos de desenvolvimento, pois requisitos mal definidos implicam num trabalho maior.
**A análise de requisitos de software  é um aspecto importante no gerenciamento de projetos, é a parte responsável por coletar dados indispensáveis e exigências de que o usuário necessite para solucionar um problema e alcançar seus objetivos. Assim como determinar as suas expectativas de um usuário para determinado produto. Segundo a IEEE (1990) a análise de requisitos é um processo que envolve o estudo das necessidades do usuário para se encontrar uma definição correta ou completa do sistema ou requisito de software, essa análise de requisitos é essencial para o desenvolvimento do sistema, ela vai determinar o sucesso ou o fracasso do projeto. Os requisitos colhidos devem ser quantitativos, detalhados e relevantes para o projeto, pois eles fornecerão a referência para validar o produto final, estabelecerão o acordo entre cliente e fornecedor sobre o que e o software fará e consequentemente reduzirão os custos de desenvolvimento, pois requisitos mal definidos implicam num trabalho maior.
**'''Passos de Análise de Requisitos:'''
**'''Passos de Análise de Requisitos:'''
***'''Reconhecer o problema''' – nesta fase encontra-se a especificação do sistema, o planejamento, o contato do analista com o cliente com a intenção de entender a visão do cliente com relação ao problema.
***'''Reconhecer o problema''' – nesta fase encontra-se a especificação do sistema, o planejamento, o contato do analista com o cliente com a intenção de entender a visão do cliente com relação ao problema.
Linha 92: Linha 84:
------------------------------------------------------------------------
------------------------------------------------------------------------


* Especificação de Requisitos
* '''Especificação de Requisitos'''
**A especificação de Requisitos deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. Erros nesse estágio produzem problemas posteriores no projeto e na implementação do sistema. E esses requisitos são classificados em Funcionais e Não-Funcionais.
**A especificação de Requisitos deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. Erros nesse estágio produzem problemas posteriores no projeto e na implementação do sistema. E esses requisitos são classificados em Funcionais e Não-Funcionais.
***Requisitos '''Funcionais''': São as funções que se espera que o software faça pode ser também as funções que se espera que o software não faça.
***Requisitos '''Funcionais''': São as funções que se espera que o software faça pode ser também as funções que se espera que o software não faça.
***Requisitos '''Não-Funcionais''': São as qualidade e restrições relacionadas com o desenvolvimento, manutenção, custo, uso, entre outros.
***Requisitos '''Não-Funcionais''': São as qualidade e restrições relacionadas com o desenvolvimento, manutenção, custo, uso, entre outros.
Levaremos como exemplo um software que analisa a rede elétrica em uma residência.
**Requisitos Funcionais:
***Receber dados de corrente e tensão.
***Calcular potência.
***Calcular rendimento.
***Plotar gráfico do rendimento.
**Requisitos Não-Funcionais:
***Plataforma em que o código do software será "escrito".
***É um software embarcado.


------------------------------------------------------------------------
------------------------------------------------------------------------


* Validação de Requisitos
* '''Validação de Requisitos'''
** A validação de requisitos consiste em verificar se os requisitos definidos no documento realmente define o que o cliente deseja, ou seja, garantir que o software em questão cumpre as especificações do mesmo. Dentre as verificações necessárias a se fazer, destacam-se:
** A validação de requisitos consiste em verificar se os requisitos definidos no documento realmente define o que o cliente deseja, ou seja, garantir que o software em questão cumpre as especificações do mesmo. Dentre as verificações necessárias a se fazer, destacam-se:
*** '''Verificação de validade:''' Garantir que o sistema possua funções que supra as necessidades de todos os clientes. Deve-se ratificar que os mesmo verifiquem e aprovem as mesmas.
*** '''Verificação de validade:''' Garantir que o sistema possua funções que supra as necessidades de todos os clientes. Deve-se ratificar que os mesmo verifiquem e aprovem as mesmas.

Edição atual tal como às 01h08min de 20 de novembro de 2013

  • Fundamentos de Requisitos de Software
    • Fundamentos básicos:
      • Elicitação: onde ocorre o levantamento por meio de técnincas de identificação
      • Detalhamento da documentação, isto é, descrição por meio de linguagem natural e modelos formais
      • Validação e negociação, onde ocorre uma garantia de qualidade, a resolução dos conflitos e consistência das informações;
    • Software: é um programa que utilizando a parte física da máquina(computador, celular, sistema embarcado) executa diferentes tarefas para o processamento de dados.
    • Tipos de software:
      • Podem ser de uso pessoal ou aplicado na empresa ou em grupo de trabalho
      • Podem ser básicos, como os sistemas operacionais de computador pessoal e "workstation", sistemas operacionais de rede, e sistemas operacionais de computador
      • Podem ser software aplicativo, como por exemplo: processador de texto,planilhas,banco de dados,correio eletrônico,razão, entrada de pedidos,folha de pagamentos
    • Sistema operacional: tem a função de fazer a máquina funcionar sendo a interface de comunicação entre o hardware e software
    • Funções:
      • Gerenciamento de processos
      • Memória
      • Sistema de arquivos
      • Entrada e Saída de dados
    • Fases:
      • é concebido para tentar atender a uma necessidade
      • é especificado, quando essas necessidades são traduzidas em requisitos viáveis
      • é desenvolvido, transformando-se em um conjunto formado por código e outros itens, como modelos, documentos e dados
      • passa por algum procedimento de aceitação e é entregue a um cliente
      • entra em operação, é usado, e sofre atividades de manutenção, quando necessário
      • é retirado de operação ao final de sua vida útil.
    • Abaixo está um fluxograma, contendo todas as etapas e do "ciclo de vida do software":
      • image01.gif
    • Pode se inferir com esse fluxograma que o software passa por muitos processos até ser concluído, dentre essas tarefas temos:
      • Requisitos
      • Analíse
      • Desenho
      • Testes
      • Implementação
      • Desenho detalhado
      • Testes de unidade
      • Codificação
      • Integração
      • Implantação
      • Operação.

  • Requisitos de Produto e de Processo
    • “A parte mais árdua na construção de um software consiste exatamente em identificar o que construir. Nenhuma outra fase compromete tanto o resultado do trabalho se elaborada de forma incorreta. Nenhuma outra parte dificulta tanto as correções posteriores”, citação de Frederick P Brooks , famoso e bem sucedido engenheiro de software.
    • Requisitos de Produto:
      • Requisitos sobre o software a ser desenvolvido
      • Por exemplo: “O software deve verificar se um aluno cumpriu os pré-requisitos antes de aceitar a sua matrícula numa disciplina”;
    • Requisitos de Processo:
      • são essencialmente restrições impostas ao desenvolvimento do software tais como linguagem de programação, processos e técnicas de desenvolvimento
      • Podem ser implícitos ou explícitos
      • Podem ser impostos:
        • pela organização desenvolvedora
        • pelo cliente
        • por terceiros
        • pelo professor

  • Levantamento de Requisitos
    • O levantamento de requisitos desempenha um papel importante no desenvolvimento de um software. É nesta etapa que o engenheiro de requisitos descobre as necessidades do cliente.
    • Se esta etapa não obter uma atenção especial, provavelmente obstáculos serão encontrados no caminho do desenvolvimento do produto, ou este não atenderá totalmente as necessidades.
    • Além disso, algumas das razões para o baixo grau de satisfação dos usuários estão na fase de levantamento de requisitos do projeto: as vezes não é utilizada uma técnica adequada para extrair os requisitos do sistema ou há uma falha do engenheiro de requisitos e/ou usuário em não descrever os requisitos de modo claro, sem ambiguidades.
    • Entre as dificuldades encontradas na fase de levantamento de requisitos estão:
      • 1. Os usuários muitas vezes não sabem o que querem, a não ser em termos muito gerais: podem achar difícil articular o que desejam do sistema, fazendo pedidos não realistas.
      • 2. Os usuários expressam os requisitos em seus próprios termos e com conhecimento implícito de sua área de atuação.
      • 3. Diferentes usuários tem em mente diferentes requisitos e podem expressá-los de maneira distinta.
      • 4. O ambiente econômico e de negócios é dinâmico e se modifica durante o processo de análise (a importância dos requisitos pode mudar e novos requisitos podem surgir) .
    • As técnicas de levantamento de requisitos possuem um conceito próprio e podem ser utilizadas em conjunto, caso seja necessário. A seguir serão apresentadas de forma resumida algumas dessas técnicas.
      • Entrevista: é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê margem ao entrevistado para expor as suas ideias. É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados.
      • Questionário: elaboram-se pesquisas específicas de acompanhamento com um grande número de usuários selecionados, pois não seria prático entrevistar todas as pessoas em todos os locais. Na fase de preparação, deve ser indicado o tipo de informação que se deseja obter com o questionário. As questões devem possuir forma simples, clara e concisa e estarem organizadas de forma a minimizar o tempo gasto na resposta.
      • Brainstorming: é uma técnica para geração de ideias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem ideias. Essa técnica contém duas fases - a fase de geração, onde as ideias são coletadas, e a fase de avaliação, onde as ideias coletadas são discutidas. Na fase de geração, as ideias não devem ser criticadas nem avaliadas. Cada ideia pode levar a novas ideias.
      • JAD (Joint Application Design): é uma técnica para promover cooperação, entendimento e trabalho em grupo entre os desenvolvedores. A técnica JAD é composta de duas etapas principais: planejamento, que tem por objetivo elicitar e especificar os requisitos; e projeto, em que se lida com o projeto de software. Cada etapa consiste em três fases: adaptação, sessão e finalização. A fase de adaptação consiste na preparação para a sessão, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construído e preparar o material. Na fase de sessão é realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde os requisitos são desenvolvidos e documentados. A fase de finalização tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos).
      • Prototipagem: Protótipo de um sistema é uma versão inicial do sistema que está disponível no início do processo de desenvolvimento. Protótipos de sistemas de software são frequentemente utilizados para ajudar a obter e validar requisitos do sistema. O protótipo é indicado para estudar as alternativas de interface do usuário; problemas de comunicação com outros produtos; e a viabilidade de atendimento dos requisitos de desempenho.

  • Análise de Requisitos
    • A análise de requisitos de software é um aspecto importante no gerenciamento de projetos, é a parte responsável por coletar dados indispensáveis e exigências de que o usuário necessite para solucionar um problema e alcançar seus objetivos. Assim como determinar as suas expectativas de um usuário para determinado produto. Segundo a IEEE (1990) a análise de requisitos é um processo que envolve o estudo das necessidades do usuário para se encontrar uma definição correta ou completa do sistema ou requisito de software, essa análise de requisitos é essencial para o desenvolvimento do sistema, ela vai determinar o sucesso ou o fracasso do projeto. Os requisitos colhidos devem ser quantitativos, detalhados e relevantes para o projeto, pois eles fornecerão a referência para validar o produto final, estabelecerão o acordo entre cliente e fornecedor sobre o que e o software fará e consequentemente reduzirão os custos de desenvolvimento, pois requisitos mal definidos implicam num trabalho maior.
    • Passos de Análise de Requisitos:
      • Reconhecer o problema – nesta fase encontra-se a especificação do sistema, o planejamento, o contato do analista com o cliente com a intenção de entender a visão do cliente com relação ao problema.
      • Avaliar o problema e a síntese da solução – tem-se o entendimento do problema, e faz-se a identificação das informações que serão necessárias ao usuário, identificação das informações que serão necessárias ao sistema e a seleção da melhor solução possível dentro das soluções propostas.
      • Modelar – é um recurso usado para o suporte da síntese da solução, o modelo vai apresentar ferramentas que facilitarão o entendimento do sistema, como as funcionalidades, informações e comportamento do sistema.
      • Especificar os requisitos – consolida funções, interfaces, desempenho, o contexto e as restrições do sistema.
      • Revisar – Juntos, cliente e analista, avaliarão o objetivo do projeto com o intuito de eliminar possíveis redundâncias, inconsistências e omissões do sistema, obtendo uma mesma visão.

  • Especificação de Requisitos
    • A especificação de Requisitos deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. Erros nesse estágio produzem problemas posteriores no projeto e na implementação do sistema. E esses requisitos são classificados em Funcionais e Não-Funcionais.
      • Requisitos Funcionais: São as funções que se espera que o software faça pode ser também as funções que se espera que o software não faça.
      • Requisitos Não-Funcionais: São as qualidade e restrições relacionadas com o desenvolvimento, manutenção, custo, uso, entre outros.

Levaremos como exemplo um software que analisa a rede elétrica em uma residência.

    • Requisitos Funcionais:
      • Receber dados de corrente e tensão.
      • Calcular potência.
      • Calcular rendimento.
      • Plotar gráfico do rendimento.
    • Requisitos Não-Funcionais:
      • Plataforma em que o código do software será "escrito".
      • É um software embarcado.

  • Validação de Requisitos
    • A validação de requisitos consiste em verificar se os requisitos definidos no documento realmente define o que o cliente deseja, ou seja, garantir que o software em questão cumpre as especificações do mesmo. Dentre as verificações necessárias a se fazer, destacam-se:
      • Verificação de validade: Garantir que o sistema possua funções que supra as necessidades de todos os clientes. Deve-se ratificar que os mesmo verifiquem e aprovem as mesmas.
      • Verificação de consistência: Os requisitos presentes no documento não podem ser conflitantes.
      • Verificação de completeza: Todas as funcionalidades, exceções, restrições exigidas pelo cliente devem estar presentes e claras no documento.
      • Verificação de realismo: Dadas as funcionalidades do projeto, o mesmo deve ser implementável, isto é, tecnologicamente, financeiramente e temporalmente viável.
      • Conformidade com normas: Todo as especificações e o próprio documento devem obedecer às normas da empresa (cliente e/ou fornecedor).
    • Com o intuito de facilitar a verificação e deixá-la mais eficaz, é possível utilizar algumas técnicas, como:
      • Revisão dos requisitos: Os requisitos são analisados sistematicamente por uma equipe de revisores. A mesma pode ser informal, sendo através de uma conversa ou conferência envolvendo um número maior de representantes do(s) cliente(s) ou formal, onde a equipe se reúne junto ao(s) cliente(s) para confirmar se o documento e os requisitos cumprem os critérios de verificação (validade, consistência, completeza...).
      • Prototipificação: Implementação de um protótipo, como a interface ou um executável, que ao ser mostrada ao(s) cliente(s) seja possível verificar se o programa atenderá todas as necessidades.
      • Geração de casos de teste: Tomando-se a base de que todos os requisitos devem ser testados, deveria ser possível desenhar os mesmos e, caso não seja possível realizar o desenho, é sinal que o requisito deve ser reconsiderado.
      • Análise de consistência automática: Se os requisitos forem expressos em uma linguagem formal, pode-se usar ferramentas automatizadas para verificar os requisitos e encontrar inconsistências.