Análise de Sistemas
Orientada a Objetos
Aula 03 – Documentação de Requisitos
Engenharia de Requisitos – Documentação
• Um engenheiro de software é um profissional que deve ter a habilidade de antecip...
Engenharia de Requisitos – Documentação
• Os principais problemas no desenvolvimento de um sistema de software decorrem:
•...
Engenharia de Requisitos – Documentação
• O engenheiro de software, desempenhando o papel de engenheiro de
requisitos, dev...
Engenharia de Requisitos – Documentação
• O engenheiro de software, desempenhando o papel de engenheiro de requisitos, dev...
Engenharia de Requisitos – Documentação
• O engenheiro de software está preocupado em levantar, entender, analisar e, por ...
Engenharia de Requisitos – Documentação
• É importante ressaltar a necessidade de definir o ‘limite’, ou também denominado...
Engenharia de Requisitos – Documentação
• O documento de requisitos delimita o escopo do conjunto de funcionalidades que u...
Engenharia de Requisitos – Documentação
• É elaborado pelo engenheiro de software e compreende o conjunto de requisitos do...
Engenharia de Requisitos – Documentação
• O documento de requisitos de um projeto tem o objetivo de documentar o escopo do...
Engenharia de Requisitos – Documentação
A seguir, itens considerados imprescindíveis em um documento de requisitos:
• A re...
Engenharia de Requisitos – Documentação
1. Introdução

Contém uma descrição dos objetivos do documento, o
público ao qual ...
Engenharia de Requisitos – Documentação
2. Requisitos Funcionais

Esta seção descreve, de maneira sumarizada, as principai...
Engenharia de Requisitos – Documentação
3. Requisitos Não-Funcionais

Apresenta-se uma descrição geral de outros
requisito...
Engenharia de Requisitos – Documentação
5. Documentação Complementar

Exemplos desses documentos compreendem atas
de reuni...
Próximos SlideShares
Carregando em…5
×

Análise de Sistemas Orientado a Objetos - 03

486 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
486
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
25
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Análise de Sistemas Orientado a Objetos - 03

  1. 1. Análise de Sistemas Orientada a Objetos Aula 03 – Documentação de Requisitos
  2. 2. Engenharia de Requisitos – Documentação • Um engenheiro de software é um profissional que deve ter a habilidade de antecipar e gerenciar mudanças de requisitos de um produto de software. • Ele precisa saber se expressar e comunicar-se bem a fim de capturar e registrar adequadamente o documento de requisitos.
  3. 3. Engenharia de Requisitos – Documentação • Os principais problemas no desenvolvimento de um sistema de software decorrem: • do entendimento errado entre engenheiro de software (produtor), responsável em apresentar o documento de requisitos, e usuário (consumidor). • Um documento de requisitos de software precisa ser claro, consistente e completo, porque esse documento servirá de referência aos desenvolvedores, gerente de projeto, engenheiros de software (responsáveis pelos testes e manutenção do sistema), além de servir de base para definir o escopo das funcionalidades a serem registradas num contrato. • Os requisitos compreendem o cerne de qualquer produto e mudanças sobre eles podem ocorrer ao longo do ciclo de vida de um software.
  4. 4. Engenharia de Requisitos – Documentação • O engenheiro de software, desempenhando o papel de engenheiro de requisitos, deve executar duas atividades essenciais para a elaboração do documento de requisitos: • Elicitação de requisitos – atividade na qual os requisitos do sistema a ser desenvolvido são levantados; • Análise de requisitos – atividade na qual os requisitos são analisados e confirmados pelos principais interessados do projeto (isto é, os stakeholders) que incluem cliente, usuário final e gerente de projetos, dentre outros.
  5. 5. Engenharia de Requisitos – Documentação • O engenheiro de software, desempenhando o papel de engenheiro de requisitos, deve executar duas atividades essenciais para a elaboração do documento de requisitos: • Elicitação de requisitos – atividade na qual os requisitos do sistema a ser desenvolvido são levantados; • Análise de requisitos – atividade na qual os requisitos são analisados e confirmados pelos principais interessados do projeto (isto é, os stakeholders) que incluem cliente, usuário final e gerente de projetos, dentre outros. • Considera-se ainda que a elicitação de requisitos objetiva definir características do sistema sob a perspectiva do cliente, enquanto que a análise de requisitos visa obter a especificação de requisitos, do ponto de vista técnico, conforme entendimento dos desenvolvedores.
  6. 6. Engenharia de Requisitos – Documentação • O engenheiro de software está preocupado em levantar, entender, analisar e, por fim, documentar os requisitos. • Para tanto, ele deve concentrar-se nas características do sistema e atributos de qualidade, e não em como obtê-los. • É preciso identificar quais requisitos fazem parte ou não do escopo do sistema a ser desenvolvido, ou em outras palavras, entender a interface do sistema considerado e o ambiente externo.
  7. 7. Engenharia de Requisitos – Documentação • É importante ressaltar a necessidade de definir o ‘limite’, ou também denominado escopo do sistema, a fim de tratar os requisitos funcionais e não funcionais do sistema. • Além disso, quando da elaboração do documento de requisitos, o engenheiro de software deve levar em consideração os diferentes pontos de vistas dos stakeholders de modo que o documento resultante possa comunicar adequadamente o conjunto de requisitos do sistema a ser construído.
  8. 8. Engenharia de Requisitos – Documentação • O documento de requisitos delimita o escopo do conjunto de funcionalidades que um sistema deve prover • Descreve os atributos de qualidade que devem ser suportados. • Este documento deve ser elaborado de maneira precisa, completa, consistente e, principalmente, compreensível aos stakeholders (isto é, os principais interessados no sistema). • O documento de requisitos será lido por várias pessoas interessadas no projeto como, por exemplo, cliente, gerente de projeto, engenheiro de testes e programadores, e, portanto, precisa comunicar com clareza os requisitos do sistema.
  9. 9. Engenharia de Requisitos – Documentação • É elaborado pelo engenheiro de software e compreende o conjunto de requisitos do sistema a ser desenvolvido; • Deve ser analisado e confirmado pelos stakeholders; • Integra e relaciona um conjunto de perspectivas dos interessados do projeto; • Serve como mecanismo de comunicação para os stakeholders (i.e. as partes interessadas do projeto); • Captura e documenta os requisitos do projeto e serve de referência para testes, manutenção e evolução do sistema.
  10. 10. Engenharia de Requisitos – Documentação • O documento de requisitos de um projeto tem o objetivo de documentar o escopo do sistema a ser desenvolvido. Nesse sentido, o documento de requisitos deve conter: • Introdução e visão geral do documento • Descrição de requisitos funcionais • Descrição de requisitos não-funcionais • Escopo não contemplado (de funcionalidades) • Documentação de apoio
  11. 11. Engenharia de Requisitos – Documentação A seguir, itens considerados imprescindíveis em um documento de requisitos: • A relação de itens mencionados não pressupõe a intenção de ser completo, mas de apontar os itens considerados como obrigatórios num documento de requisitos. • Cabe destacar que os itens sugeridos para compor um documento de requisitos, conforme nas próximas páginas, leva em consideração as recomendações de documento padrão IEEE-Std 830-1998 recomendado pelo IEEE.
  12. 12. Engenharia de Requisitos – Documentação 1. Introdução Contém uma descrição dos objetivos do documento, o público ao qual ele se destina e, em linhas gerais, o propósito e escopo do projeto a ser desenvolvido. Pode adicionalmente conter termos e abreviações usadas, tipos de prioridades atribuídas aos requisitos, além de informar como o documento deve evoluir.
  13. 13. Engenharia de Requisitos – Documentação 2. Requisitos Funcionais Esta seção descreve, de maneira sumarizada, as principais funcionalidades que o sistema de software irá realizar. Por exemplo, num sistema de biblioteca, esta seção deveria conter uma descrição das funcionalidades de autenticação de usuário e controle de acesso. Observe que o sumário das funcionalidades de um sistema se faz necessário para permitir o entendimento das funcionalidades do sistema pelos diversos stakeholders. O engenheiro de software deve organizar o conjunto de funcionalidades do sistema de modo a torná-las mais compreensíveis aos clientes e demais stakeholders. Vale ainda ressaltar que o documento de requisitos pode ser complementado por outro documento como, por exemplo, especificações de casos de uso.
  14. 14. Engenharia de Requisitos – Documentação 3. Requisitos Não-Funcionais Apresenta-se uma descrição geral de outros requisitos do produto que limitam opções de desenvolvimento do sistema. Isto inclui a descrição de requisitos de segurança, confiabilidade, timeout de sessão de usuário, usabilidade, dentre outros. Esta seção considera os requisitos do produto, do processo, da interface gráfica e da plataforma tecnológica empregada. 4. Escopo Não-Contemplado Contém descrição das funcionalidades não contempladas no escopo do sistema a ser desenvolvido. Outra denominação dada a esta seção é escopo negativo. Isto visa garantir às partes interessadas no sistema (isto é, cliente e equipe de desenvolvimento) quais funcionalidades fazem parte ou não do conjunto a ser implementado.
  15. 15. Engenharia de Requisitos – Documentação 5. Documentação Complementar Exemplos desses documentos compreendem atas de reuniões nas quais ocorrerão levantamento e validação de requisitos, bem como o plano de projeto. 6. Apêndice Trata-se de uma seção que pode conter, por exemplo, levantamento de perfil de usuários do sistema a ser desenvolvido e descrição do problema a ser automatizado pelo sistema de software. É importante observar que o apêndice não é parte do documento de requisitos e serve apenas como informação de apoio para os leitores do documento.

×