Relatório de Especificação de Requisitos 1. Introdução
|
|
- Wilson Franca Prado
- 7 Há anos
- Visualizações:
Transcrição
1 Relatório de Especificação de Requisitos 1. Introdução 1.1 Objectivo Indicar o objectivo e destinatários do RER 1.2 Âmbito Identificar o produto de software a desenvolver pelo respectivo nome. Explicar brevemente o que o produto vai fazer e, se necessário, não vai fazer. Descrever como e onde vai ser aplicado o produto, indicando benefícios relevantes objectivos. Explicar se faz parte de um sistema mais vasto. 1.3 Definições, acrónimos e abreviaturas Definir termos, acrónimos e abreviaturas requeridos para interpretar adequadamente o RER. 1.4 Referências Listar todos os documentos referenciados no RER, indicando o seu título, identificador (se aplicável), data, organização que o publicou e fonte onde o mesmo pode ser obtido (e.g., URL). 1.5 Visão geral Descrever sumariamente o conteúdo do resto do RER e explicar a forma como está organizado. 2. Descrição geral Apresentar informação de background importante para ajudar a perceber os requisitos a especificar posteriormente. 2.1 Contexto do produto Indicar se o produto é auto-contido ou se é um componente de um sistema maior e, nesse caso, apresentar a arquitectura geral (com principais componentes, inter-conexões e interfaces externos) e requisitos gerais desse sistema. Indicar as várias interfaces do produto: interfaces com o utilizador, interfaces de hardware, interfaces de software (interfaces com outros produtos), interfaces de comunicação, etc. Caracterizar o ambiente de operação do produto e eventuais restrições associadas a esse ambiente. 2.2 Funções do produto Sumariar as funções principais que o sistema vai realizar.
2 2.3 Características dos utilizadores Descrever as características dos utilizadores a que se destina o produto, incluindo nível de educação, experiência e conhecimentos técnicos. 2.4 Restrições Descrição geral de quaisquer outros itens que possam limitar as opções dos developpers. 2.5 Pressupostos e dependências Por exemplo sobre o ambiente de operação do sistema. 3. Requisitos específicos 3.1 Requisitos de interfaces externos Incluir as seguintes secções, se aplicáveis: Interfaces com utilizadores Interfaces de hardware Interfaces de software Interfaces de comunicação 3.2 Requisitos funcionais Os requisitos funcionais serão aqui descritos de diferentes formas complementares: sob a forma de User Stories, facilmente compreensíveis pela equipa técnica e pelo cliente; e sob a forma de casos de utilização, mais formal. Ambas as formas devem ter referências cruzadas para facilitar a rastreabilidade User Stories Enumeração das várias user stories do projecto em mãos, sucintamente descritas em 1-3 parágrafos que possam ser facilmente compreendidos por todos envolvidos no projecto. As user stories podem eventualmente ser organizadas em grupos para facilitar a sua apresentação Modelo de Casos de Utilização O objectivo é capturar requisitos funcionais, focando no valor para os utilizadores (actores). Os casos de utilização devem ser descritas nesta secção de forma sucinta, começando por uma visão geral, organização em módulos/sub-módulos (packages) e a descrição individual de cada caso de utilização.
3 Visão geral Com um ou mais diagramas de casos de utilização e uma descrição genérica que passa superficialmente pelos casos de utilização e actores mais importantes. Se existirem muitos casos de utilização, apresentar um primeiro diagrama com a sua divisão em módulos (pacotes de casos de utilização) e depois um diagrama de casos de utilização para cada pacote. Em alguns casos, pode-se mostrar o encadeamento de casos de utilização através de um ou mais diagramas de actividades (descrevendo processos de negócio em que surgem os casos de utilização) Actores Descrever sumariamente cada um dos actores Módulo 1 (pacote de casos de utilização) Descrever sumariamente as funcionalidades englobadas neste módulo e depois descrever cada um dos seus casos de utilização Caso de utilização 1 Cada caso de utilização descreve as funcionalidades pretendidas ou requisitos funcionais. Deve-se usar uma secção/página wiki para cada caso de utilização, com a sua descrição detalhada. Identificador: wiki name, nome curto. Nome: Nome longo. Descrição sumária: Uma ou duas frases curtas, que ficaria bem numa tabela de resumo dos casos de utilização, tornando evidente o objectivo/utilidade. Actores: Indicar os vários actores intervenientes e o seu papel, tornando evidente quem inicia a interacção. Prioridade: Indicar a prioridade do caso de utilização (essencial, desejável, opcional). Sequência de funcionamento / Fluxo de eventos: Por definição, um caso de utilização é "uma sequência de acções que...". Descrever as sequências de funcionamento normais e alternativas ou excepcionais. Indicar as acções realizados pelos actores e pelo sistema. Tornar evidentes os dados de entrada (introduzidos pelos actores) e de saída (fornecidos pelo sistema). Tornar evidente como é que se inicia o caso de utilização (exemplo: o caso de utilização inicia-se quando o utilizador pretende... e já fez... ). Pode-se acompanhar a descrição textual por diagramas dinâmicos (diagramas de sequência ou diagramas de actividades) para facilitar a comunicação e remover ambiguidades. Interface com o utilizador: Apresentar esboços ou imagens do protótipo da interface com o utilizador (ver adiante). Se se justificar (no caso de não ser óbvio), pode-se descrever o significado de cada elemento que aparece na interface (campo, botão, etc.). Pré-condições e restrições (Preconditions): Uma pré-condição é uma restrição nos dados de entrada e estado inicial do sistema. Exemplo, no levantamento em ATM: a conta tem saldo suficiente; a máquina ATM tem stock suficiente
4 Pós-condições (Posconditions): Uma pós-condição é uma condição que relaciona os dados de saída e estado final do sistema com os dados de entrada e o estado inicial do sistema. Traduz o efeito/resultado do caso de utilização. Exemplo, no levantamento em ATM: o cliente recebeu o dinheiro; o saldo da conta foi actualizado. Pressupostos (Assumptions) Referências/fontes (References): Fontes de informação consideradas (entrevistas, sites, etc.). Se forem iguais para todos os casos de utilização, basta indicar no fim do documento. Classes participantes (Participating classes): Listar as classes do modelo de domínio (ver adiante) relevantes para o caso de utilização ou, se a complexidade o justificar, apresentar um diagrama de classes parcial, com as classes, atributos e relações relevantes. 3.3 Requisitos de informação Organizar o vocabulário do domínio do problema (utilizado na descrição dos casos de utilização). Organizar e relacionar termos que estão definidos num glossário ou num dicionário de dados. Capturar os requisitos de informação. Que informação é mantida no sistema e trocada com o ambiente? Opcionalmente, especificar as transacções do negócio (por operações). Normalmente encontram-se três tipos de classes: Classes que modelam o estado interno persistente e partilhado do sistema, como atributos e ligações de entidades do negócio são as classes mais importantes (também chamadas entidades informacionais). Classes que modelam a estrutura de documentos trocados entre o sistema e o seu ambiente. Classes que modelam tipos de dados (usados nos atributos e operações das classes anteriores). Esta secção deve ser estruturada da seguinte forma: Uma secção de visão geral, com diagrama de classes e descrição textual que passa superficialmente pelas várias classes. Uma secção/página para cada classe com a sua descrição detalhada (pode ser o texto do Javadoc): o explicando o que é (ou não é) uma instância da classe o tabela com nome e descrição de cada atributo e o que significam, se tal não for evidente pelo seu nome e descrição o descrever eventuais restrições informalmente o Relações: explicar as relações, se tal não for evidente pelo seu nome e descrição o Operações: não é necessário definir nesta fase, mas pode-se já indicar aquelas que se consideram essenciais. Se forem definidas, devem corresponder às transacções (e consultas) fundamentais do negócio, e não a todas as operações elementares que se podem imaginar. o Ciclo de vida: diagrama de estados mostrando o ciclo de vida de um objecto da classe, acompanhado eventualmente de uma pequena descrição. Só
5 quando se justifica. Estados devem corresponder a condições nos valores de atributos e ligações. Nesta fase, eventos devem corresponder a casos de utilização, podendo ter parâmetros 3.4 Requisitos suplementares Listar e descrever sumariamente requisitos transversais aos vários módulos do sistema ou aos vários casos de utilização deste módulo. Para cada requisitar indicar: Identificador Descrição sumária Prioridade (exemplo: essencial, desejável, opcional) Referências/fontes (como se faz nos casos de utilização) Incluem-se aqui tipicamente requisitos de qualidade do produto (usabilidade, eficiência, segurança, etc.) Apêndices Glossário definindo termos do vocabulário do domínio Protótipo da Interface com o Utilizador Diz a norma IEEE que: Prototypes are useful for the following reasons: a) The customer may be more likely to view the prototype and react to it than to read the SRS (Software Requirements Specification) and react to it. Thus, the prototype provides quick feedback. b) The prototype displays unanticipated aspects of the systems behavior. Thus, it produces not only answers but also new questions. This helps reach closure on the SRS. c) An SRS based on a prototype tends to undergo less change during development, thus shortening development time. Nesta fase, interessa um protótipo da interface com o utilizador, também chamado protótipo horizontal, cobrindo as interfaces mais importantes. Muitos autores recomendam a elaboração de protótipos de deitar fora (em vez de evolutivos), para garantir o foco nos requisitos (em vez de questões de implementação). A forma mais simples pode ser fazer esboços em papel/lápis ou quadro branco e digitalizar. Em alternativa, pode-se usar um programa de desenho com capacidade para desenho de GUIs (ex: Dia ou Microsoft Visio). No caso de interfaces Web, podem-se construir páginas HTML estáticas. Os protótipos podem incluir dados de exemplo (coerentes entre as várias imagens) As imagens de ecrãs podem ser organizadas em sequências como nas histórias aos quadradinhos (storyboards). Plano de Testes de Aceitação O plano de testes de aceitação define um conjunto de casos de teste de aceitação das funcionalidades descritas como user stories.
6 As principais vantagens são: Garantir que os requisitos especificados são verificáveis se não for possível definir casos de teste concretos correspondentes a um requisito, é porque este não está bem definido. Clarificar a especificação de requisitos os casos de teste são exemplos do comportamento pretendido do sistema; escrever casos de teste concretos obriga a interpretar os requisitos, podendo nesse processo ser descobertas ambiguidades ou omissões. Servir como contrato concreto entre o fornecedor e o cliente. Os mesmos dados de exemplo usados nos protótipos podem ser usados nos testes de aceitação. Numa abordagem baseada em user stories ou casos de utilização, os teste de aceitação relativos aos requisitos funcionais devem ser baseados em cenários de utilização. As user stories definem funcionalidades que têm que poder ser avaliadas de forma objectiva, com dados reais fornecidos pelos futuros utilizadores. Os casos de utilização permitem também definir cenários (sequências específicas de funcionamento) que por sua vez permitem definir casos de teste. Estrutura da definição de um caso de teste: Identificador Item ou itens que são objecto do teste: caso de utilização, cenário, requisito (para rastreabilidade em relação aos requisitos) Condição específica a testar Dados de entrada e condições iniciais Dados de saída e condições finais Procedimento de teste (se necessário) Como estabelecer as condições iniciais Passos a seguir na execução do teste (normalmente é seguir o cenário) Como verificar as condições finais Precedências Para organizar casos de teste em sequências, por exemplo, fazer testar uma inserção e depois uma consulta Referências e leituras recomendadas Kurt Bittner, Ian Spence; Use Case Modelling, Addison-Wesley, IEEE recommended practice for software requirements specifications (IEEE Std ) Disponível em Gerald Kotonya and Ian Sommerville, Requirements Engineering: Processes and Tecnhiques, 1998
Laboratório de Desenvolvimento de Software
Laboratório de Desenvolvimento de Software FEUP/MIEIC, 2010/11 Nuno Flores nuno.flores at fe.up.pt Rosaldo Rossetti rossetti at fe.up.pt Filipe Correia filipe.correia at fe.up.pt http://paginas.fe.up.pt/~nflores/dokuwiki/doku.php?id=teaching:1011:ldso
Leia maisProfessor Emiliano S. Monteiro
Professor Emiliano S. Monteiro To-Do Doing Done Conhecer os processos de desenvolvimento habilita o aluno a realizar uma melhor escolha de processo para uso em projetos futuros. A vantagem de conhecer
Leia maisengenharia de requisitos
4. documentação 1 o processo de modelo de actividades de alto nível identificação, descoberta de requisitos análise e negociação de requisitos documento de requisitos documentação de requisitos validação
Leia maisIntrodução à Engª de Requisitos
Análise e Concepção de Sistemas de Informação Introdução à Engª de Requisitos Adaptado a partir de Gerald Kotonya and Ian Sommerville 1 Objectivos Introduzir as noções requisitos de sistema e processo
Leia maisSOFTWARE REQUIREMENTS
SOFTWARE REQUIREMENTS Ian Sommerville, 8º edição Capítulo 6 Aula de Luiz Eduardo Guarino de Vasconcelos O que é um requisito? Pode variar de uma declaração abstrata de alto nível de um serviço ou de uma
Leia maisPadrão para Especificação de Requisitos de Produto de Multimídia
Padrão para Especificação de Requisitos de Produto de Multimídia 1 Introdução 1.1 Escopo do documento Sugere-se aqui uma estrutura para a Especificação de Requisitos de Produto de Multimídia (ERPM). Esta
Leia maisUML - Diagramas de Casos de Utilização (Use Case Diagrams)
UML - Diagramas de Casos de Utilização (Use Case Diagrams) 1 Objectivo Um diagrama de casos de utilização de um sistema mostra actores (tipos de utilizadores), casos de utilização e relações entre eles
Leia maisDS: notação. Falta-nos apenas dar exemplos de DSS que contenham a criação de objectos temporários e sua posterior destruição.
DS: notação Falta-nos apenas dar exemplos de DSS que contenham a criação de objectos temporários e sua posterior destruição. Martins 2008 147 DS: notação Martins 2008 148 DS: notação Mensagem condicional
Leia maisUML Visão Geral UML Visão geral v.1.1, Novembro de 2001
UML Visão Geral 1 Índice Introdução Diagramas O que é a UML? Diagrama de casos de utilização Valor da UML Diagrama de classes Origens da UML Diagrama de objectos Parceiros da UML Diagrama de componentes
Leia mais3. Engenharia dos requisitos de software
Renato Cardoso Mesquita Departamento de Eng. Elétrica da UFMG renato@cpdee.ufmg.br Engenharia de Software 3. Engenharia dos requisitos de software.......... 3.1. Visão Geral O fluxo de Requisitos reúne
Leia maisEngenharia de Requisitos
Engenharia de Requisitos Criado: mar/2001 Atualizado: set/2005 Tópicos Definição de Requisitos Participantes Processo Documento de Requisitos (SRS) Evolução dos Requisitos 2 Referência I.Sommerville. Sw
Leia maisO Fluxo de Requisitos
O Fluxo de 1 Finalidade do fluxo de requisitos A finalidade deste fluxo é: Chegar a um acordo com o cliente e o usuário sobre o que o sistema deve fazer. Oferecer ao desenvolvedor um melhor entendimento
Leia maisUFU-FACOM Documento de Requisitos <Nome do Sistema>
UFU-FACOM Documento de Requisitos Versão - de Documento de Requisitos Ficha Técnica Equipe Responsável pela Elaboração
Leia maisDiagramas de Use Case Resumo
0 Diagramas de Use Case Resumo Os diagramas de Use Case permitem definir os requisitos funcionais de um sistema: que serviços deve fornecer; a quem os deve fornecer. Notação diagramática facilita o diálogo
Leia maisQualidade. Ana Madureira
Qualidade Ana Madureira Qualidade da Informação A qualidade de uma informação é apreciada em função da sua pertinência (adaptação às necessidades do sistema de gestão). Três características permitem medir
Leia mais06/02/2014. Engenharia de requisitos. Requisitos de Software. Capítulo 6. O que é um requisito? Objetivos. Abstração de requisitos (Davis)
Engenharia de requisitos Requisitos de Software O processo de estabelecer os serviços que o cliente requer a partir de um sistema e as restrições sob as quais ele opera e é desenvolvido. Os próprios requisitos
Leia maisRequisitos de Software
Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais
Leia maisDiagramas de Use Case
86/170 Diagramas de Use Case Sumário Definição de requisitos. Diagramas de Use Case I conceitos base Diagramas de Use Case II conceitos avançados Resumo Exercícios Definição de Requisitos 87/170 Definição
Leia maisCadeira: Engenharia de Software
Cadeira: Engenharia de Software Aulas 9, 10 15/08/15 Docente: Cláudia Ivete F. Jovo cifjovo@gmail.com or cjovo@up.ac.mz M.Sc. Cláudia Jovo 2017/DI 0 Definição de Eng. Software; Eng. Software Tecnologia
Leia mais4/14/11. Processos de Engenharia de Requisitos. Engenharia de requisitos. Elicitação e análise. A espiral de requisitos
Processos de engenharia de requisitos Processos de Engenharia de Requisitos Os requisitos e as formas de obtê-los e documentálos variam drasticamente de um projeto para o outro Contudo, existe uma série
Leia maisDiagramas. Abordaremos agora cada um destes tipos de diagrama: 1. Diagrama Use-Case. 2. Diagrama de Colaboração. 3. Diagrama de Sequência
Diagramas Os diagramas utilizados pela UML são compostos de nove tipos: diagrama de use case, de classes, de objecto, de estado, de sequência, de colaboração, de actividade, de componente e o de instalação/execução.
Leia maisDMS - DOCUMENTO DE MODELAGEM DE SISTEMA VERSÃO: [NOME DO SISTEMA] [SIGLA] [AUTORES]
DMS - DOCUMENTO DE MODELAGEM DE SISTEMA Este documento foi criado seguindo as recomendações e orientações do livro UML na Prática Do Problema ao Sistema e do modelo PRISM do MPDS (Modelo Prático para Desenvolvimento
Leia maisEngenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos. Prof. Bruno Moreno
Engenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos Prof. Bruno Moreno bruno.moreno@ifrn.edu.br Engenharia de Requisitos É, talvez, o maior problema da indústria de SW; Está relacionada
Leia maisSOCIEDADE PARANAENSE DE ENSINO E TECNOLOGIA SPET PROGRAMA DE EVOLUÇÃO CONTÍNUA DE QUALIDADE. ES 60 DISCIPLINA: Engenharia de Software II
ES 60 DISCIPLINA: Engenharia de Software II AULA NÚMERO: 6 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar, discutir e exercitar a visão de um sistema a ser projetado. Os principais
Leia maisMetodologia Simplified. António Rocha
Metodologia Simplified António Rocha - 2003 Metodologias As empresas precisam de uma metodologia simples e eficaz para realizarem o seu primeiro projecto OO Uma metodologia tem mais probabilidades de ser
Leia maisDocumento de Requisitos*
* Rosana T. Vaccare Braga *slides adaptados a partir do material da Profa Ellen Francine Barbosa Processo de Engenharia de Requisitos Documento de requisitos Processo de Engenharia de Requisitos Estudo
Leia maisUML - Diagramas de Sequência
UML - Diagramas de Sequência 1 Objectivo Um diagrama de sequência mostra uma interacção, isto é, uma sequência de mensagens trocadas entre vários objectos num determinado contexto (caso de utilização,
Leia maisComo escrever um relatório. Ana Filipa Pereira Ramos
Como escrever um relatório Ana Filipa Pereira Ramos Índice Função do relatório... 2 Normas e regras... 2 Capa e página de rosto... 3 Resumo e Palavras-chave... 4 Agradecimentos... 4 Índice... 5 Pág. 1
Leia maisModelação. Diagramas de Sequencia
Modelação Diagramas de Sequencia References: - A practical guide to SysML (chapter 8) - Systems Engineering with SysML/UML, Modeling, Analysis, Design (Chapter 3) Gabriel Pestana (gabriel.pestana@inesc-id.pt)
Leia mais3. Modelação Evolução histórica
3. Modelação 3.1. Evolução histórica 1 2 Evolução histórica Antes de serem abordados os modelos Ambiental e Comportamental, é importante observar o quadro seguinte, que apresenta a evolução histórica dos
Leia maisObjetivo. Diagramas de Caso de Uso. História. Diagramas de Caso de Uso. Atores. Atores
Objetivo Diagramas de Caso de Uso História Atores Casos de Uso Diagramas Estruturação (Generalização, Inclusão, Extensão) Dicas 2001 Jaelson Castro Levantamento de Requisitos 1 2001 Jaelson Castro Levantamento
Leia maiselaboração da aplicação, estamos dependentes do software usado pelo Helpdesk. Por exemplo, como usam activamente o sistema operativo Linux,
Este documento contém os requisitos do projecto #FF0000. Esta secção descreve de forma resumida em que consiste o projecto e o que pode ser encontrado neste documento. 1.1 Objectivo Este documento fornece
Leia maisIntrodução a UML (Unified Modeling Language)
Introdução a UML (Unified Modeling Language) O que é a UML? Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário
Leia maisProf. Dr. Thiago Jabur Bittar
Prof. Dr. Thiago Jabur Bittar Uma representação abstrata e simplificada do processo de desenvolvimento software, tipicamente mostrando as principais atividades e dados usados na produção e manutenção de
Leia maisUML (Unified Modelling Language)
UML (Unified Modelling Language) Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Booch, G. et al. The Unified Modeling Language User Guide
Leia mais15/03/2018. Professor Ariel da Silva Dias Modelos de Processo de Software
Professor Ariel da Silva Dias Modelos de Processo de Software Conjunto de atividades que leva à produção de um produto de Software [Sommerville,2011]; Podemos contar com ferramentas de apoio com o objetivo
Leia maisProcessos de software
Processos de software 1 Processos de software Conjunto coerente de atividades para especificação, projeto, implementação e teste de sistemas de software. 2 Objetivos Introduzir modelos de processos de
Leia maisDicas sobre o Relatório de Estágio
Dicas sobre o Relatório de Estágio Rui Pedro Paiva Fevereiro de 2008-2011 Índice Modelo 1. Introdução (apenas lendo a introdução, o leitor deve obter uma resposta clara e sucinta a 3 questões fundamentais:
Leia maisGere Com Saber. Universidade do Minho Licenciatura em Engenharia Informa tica
Universidade do Minho Licenciatura em Engenharia Informa tica Disciplina de Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/10 Gere Com Saber Andre Barbosa - no 49357 David Leal - no 49321
Leia maisAnálise de Requisitos
Análise de Requisitos Análise de Requisitos O tratamento da informação é um requisito que fundamenta o processo de desenvolvimento de software antes da solução de tecnologia a ser aplicada. Cada projeto
Leia maisDOCUMENTO DE REQUISITOS
DOCUMENTO DE REQUISITOS ID documento: Data: / / Versão : Responsável pelo documento: ID Projeto: HISTÓRICO DE REVISÕES Data de criação/ atualização Descrição da(s) Mudança(s) Ocorrida(s) Autor Versão do
Leia maisNotas de Aula 03: Introdução a Orientação a Objetos e a UML
Notas de Aula 03: Introdução a Orientação a Objetos e a UML Objetivos da aula: Introduzir os conceitos da Orientação à Objetos (O.O) Introduzir os conceitos da UML Relacionar os processos às ferramentas
Leia maisRequisitos de Software
Engenharia de requisitos Requisitos de Software Estabelece os serviços que o cliente requer de um sistema e as restrições sob as quais tal sistema operará e será desenvolvido. Tais serviços e restrições
Leia maisIntrodução ao RUP Rational Unified Process
Introdução ao RUP Rational Unified Process UML Diagramas de Classes v.1.1, João Pascoal Faria, 2001 1 O que é Um processo (de engenharia) de software é a definição de um conjunto completo de actividades
Leia maisDesenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto
Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2006 Profa. Dra. Itana Gimenes RUP: Projeto Artefatos Modelo de Projeto: Lista de classes de
Leia maisDelimitar claramente o escopo do projeto Estimar custo, tempo e retorno do investimento (feasibility)
FASE DE CONCEPÇÃO CONCEPÇÃO LANÇA O PROJETO Realizar o business case inicial Delimitar claramente o escopo do projeto Estimar custo, tempo e retorno do investimento (feasibility) Formular a arquitetura
Leia maisConcepção lança o projeto
FASE DE CONCEPÇÃO Concepção lança o projeto Realizar o business case inicial Delimitar claramente o escopo do projeto Estimar custo, tempo e retorno do investimento (feasibility) Formular a arquitetura
Leia maisCurso Especializado de UX
Curso Especializado de UX PROGRAMA O Curso Especializado de User Experience introduz técnicas e métodos de análise e desenho com o objectivo de auxiliar o desenvolvimento de sites e aplicações que apresentem
Leia maisAnálise e modelação de sistemas. Classe T13: Passando da análise ao Desenho
Análise e modelação de sistemas Classe T13: Passando da análise ao Desenho 2 Programa Organizando os diagramas Da análise ao desenho Pacotes Estereó;pos Classes de análise vs classes de desenho Estereó;pos
Leia maisDesenho de Software. Sumário
(QJHQKDULDGD3URJUDPDomR Desenho de Software Carla Ferreira Carla.Ferreira@dei.ist.utl.pt Sumário Objectivos Problemas Qualidades Técnicas Avaliação e Validação Casos Notáveis Exemplo Conclusões Desenho
Leia maisPlano de testes. Norma ANSI/IEEE para Documentação de Teste de Software define plano de testes como:
Plano de testes Norma ANSI/IEEE 829-1998 para Documentação de Teste de Software define plano de testes como: Um documento que define o âmbito, abordagem, recursos e escalonamento (planeamento) das atividades
Leia maisBANCO DE DADOS I. Prof. Luiz Antônio Vivacqua C. Meyer
BANCO DE DADOS I Prof. Luiz Antônio Vivacqua C. Meyer Projeto de Banco de Dados Etapas do Desenvolvimento de um Projeto de Sistemas: 1. Levantamento de Requisitos a. Requisitos Funcionais b. Requisitos
Leia maisEngenharia de Software
Instituto Superior Politécnico de Ciências e Tecnologia Engenharia de Software Prof Pedro Vunge www.pedrovunge.com I Semestre de 2018 Capítulo 1 Introdução SUMÁRIO Engenharia de Software Definição; Objectivos
Leia maisS15 - Engenharia de Requisitos continuação cap.6
S15 - Engenharia de Requisitos continuação cap.6 ENGENHARIA DE SOFTWARE PRESSMAN, 2011 Gilberto Wolff UTFPR Roteiro Análise de requisitos Modelagem baseada em cenários Modelos UML que complementam o Caso
Leia maisGestão de Requisitos Desenvolvimento de Requisitos. Rodolfo S F Resende
Gestão de Requisitos Desenvolvimento de Requisitos Rodolfo S F Resende Coloquial: o requisito é Uma necessidade, um desejo, uma expectativa Algo necessitado, desejado Uma condição necessitada, desejada
Leia maisDiagramas de Sequência Exemplo
217 Diagramas de Sequência Exemplo Seja um sistema de gestão de contéudos. A especificação do use case Criar Conta de Blog vai ser detalhada, no que concerne à descrição da colaboração, num diagrama de
Leia maisEngenharia de Software
Sumário Engenharia de Software Modelos de desenvolvimento de software Fases de desenvolvimento Programação modular Abordagem top-down e bottom-up Linguagens de programação: Compilação / Interpretação Aplicação
Leia maisDefinição. Arquitecturas de Software. Modelo de Referência. Estilo Arquitectural. Arquitecturas de Software
Arquitecturas de Software Arquitecturas de Software António Rito Silva Rito.Silva@inesc-id.pt Definição A arquitectura de software de um programa ou sistema computacional é a estrutura ou estruturas do
Leia maisMANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO
MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO Sumário PREFÁCIO...3 MODELO DA DOCUMENTAÇÃO...3 1. INTRODUÇÃO AO DOCUMENTO...3 1.1. Tema...3 2. DESCRIÇÃO
Leia maisNormalização de dados
1 Normalização de dados Vantagens da normalização A normalização permite: Agrupar os atributos de uma entidade de forma a reduzir o número de dependências funcionais existentes entre os dados numa base
Leia maisMODELAGEM DE PROCESSOS MÓDULO 9
MODELAGEM DE PROCESSOS MÓDULO 9 Índice 1. Processo de Desenvolvimento de Sistemas - Continuação..3 1.1. Diagramas de Casos de Uso... 3 2 1. PROCESSO DE DESENVOLVIMENTO DE SISTEMAS - CONTINUAÇÃO 1.1. DIAGRAMAS
Leia maisIntrodução. Enquadramento. Descrição
Interfaces Homem Máquina 07/08 Grupo 4 Projecto: G sm Relatório Final Introdução O nosso projecto consiste no desenvolvimento de uma aplicação de gestão de mesadas. A aplicação pretende ser uma ferramenta
Leia maisSistemas Embebidos I , Tiago Miguel Dias ISEL, ADEETC - Secção de Eletrónica e Telecomunicações e de Computadores
Sistemas Embebidos I Licenciatura em Eng. de Electrónica e Telecomunicações e de Computadores Licenciatura em Engenharia Informática e de Computadores Mestrado em Engenharia de Electrónica e Telecomunicações
Leia maisALM Aplicações em Linguagem de Montagem. Introdução. A produção de Software é uma atividade build and fix. build. fix
Introdução A produção de Software é uma atividade build and fix. 1 Introdução build 2 Introdução fix 3 1 Introdução 4 P s Só pessoas motivadas e comprometidas com o projeto garantem o respectivo sucesso;
Leia maisMODELAGEM DE SISTEMAS. Introdução a Computação e Engenharia de Software. Profa. Cynthia Pinheiro
MODELAGEM DE SISTEMAS Introdução a Computação e Engenharia de Software Profa. Cynthia Pinheiro Introdução Modelagem de Sistemas: A modelagem de um sistema auxilia o analista a entender a funcionalidade
Leia maisUML Aula I Diagramas de Caso de Uso. Ricardo Argenton Ramos
UML Aula I Diagramas de Caso de Uso Ricardo Argenton Ramos Engenharia de Software II 2016.1 25/04/2016 Um Exercício Como você pode representar? Uma casa de 2 andares, 4 quartos, 2 banheiros, 1 sala, 1
Leia maisAula 01 - Introdução
Disciplina: Projeto de Redes I Professor: Jéferson Mendonça de Limas 4º Semestre Aula 01 - Introdução 2014/2 18/08/14 1 2 de O que é Projeto de Redes? Ementa da Disciplina Fundamentos de Projetos de Redes
Leia maisAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas Prof. Dr. Ronaldo C. de Oliveira ronaldo.co@ufu.br www.facom.ufu.br/~ronaldooliveira FACOM - 2017 Requisitos do Sistema Introdução O que são requisitos de um software? Serviços
Leia mais1. INTRODUÇÃO A MODELAGEM DE DADOS
1. INTRODUÇÃO A MODELAGEM DE DADOS Para se construir uma casa ou um prédio de qualidade, é essencial fazer um planejamento detalhado, com a finalidade de pensar sobre as formas de construção, fazer estimativas
Leia maisÁreas de Conhecimento, Técnicas de Análise de Negócio e Conceitos-Chave
Primeiro Módulo: Parte 3 Áreas de Conhecimento, Técnicas de Análise de Negócio e Conceitos-Chave AN V 3.0 [60] Rildo F Santos (@rildosan) rildo.santos@etecnologia.com.br www.etecnologia.com.br http://etecnologia.ning.com
Leia maisUML Diagramas de Pacotes (Packages) e Modelação da Arquitectura Lógica. UML Diagramas de Pacotes v.1.1, João Pascoal Faria, 2001
UML Diagramas de Pacotes (Packages) e Modelação da Arquitectura Lógica 1 Pacotes Um pacote (package) em UML é um mecanismo de agrupamento genérico Notação: pasta com o nome no interior ou na pega No caso
Leia maisUML Diagrama de Casos de Uso (Use Case)
CBSI Curso de Bacharelado em Sistemas de Informação UML Diagrama de Casos de Uso (Use Case) Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Análise e Projeto de Sistemas Faculdade
Leia maisSistemas de Informação
Sistemas de Informação Escola Superior de Tecnologia e Gestão de Felgueiras Engenharia Informática 3º ano - 2003/2004 Ana Maria Madureira Informação Informação informatióne conjunto de dados em princípio
Leia maisDepartamento de Engenharia Electrotécnica. Espaço reservado a gráficos. Máquina de Lavar Orientada para Objectos. Nuno Simão João Valente
Departamento de Engenharia Electrotécnica Espaço reservado a gráficos Máquina de Lavar Orientada para Objectos Nuno Simão João Valente Trabalho Final de Curso do 2º Ciclo Em Engenharia Electrónica e Computadores
Leia maisQUALIDADE DE SOFTWARE DEFINIÇÕES / RESUMO. Apostilas de NORMAS, disponíveis no site do professor. Prof. Celso Candido ADS / REDES / ENGENHARIA
DEFINIÇÕES / RESUMO Apostilas de NORMAS, disponíveis no site do professor. 1 NORMAS VISÃO GERAL Qualidade é estar em conformidade com os requisitos dos clientes; Qualidade é antecipar e satisfazer os desejos
Leia maisUML e seus diagramas
UML e seus diagramas A UML Unified Modeling Language (Linguagem de Modelagem Unificada), como o próprio nome já diz, é uma linguagem para modelagem de objetos do mundo real, usada para especificar, construir,
Leia maisas fases contemplam todas as etapas do ciclo de desenvolvimento (requisitos, análise, projeto, implementação, teste e validação);
Título : B2 Processo de desenvolvimento de Sistemas Conteúdo : A UML estabelece uma abordagem para a construção, o desenvolvimento e a manutenção de software. Atualmente, metodologias utilizadas no desenvolvimento
Leia maisAnalista de Sistemas S. J. Rio Preto
Engenharia de Requisitos - análise A engenharia de requisitos (no contexto da engenharia de software) é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos
Leia maisINF1013 MODELAGEM DE SOFTWARE
INF1013 MODELAGEM DE SOFTWARE Departamento de Informática PUC-Rio Ivan Mathias Filho ivan@inf.puc-rio.br Programa Capítulo 1 O Paradigma Orientado a Objetos A Linguagem UML Descrição da Arquitetura 1 Programa
Leia maisSistemas e software Proposta de especificação de software O fluxo de Requisitos Padrão para Especificação
2EQUISITOS ) 2EQUISITOS ) Sistemas e software Proposta de especificação de software O fluxo de Requisitos Padrão para Especificação 1999 Wilson de Pádua Paula Filho 1 3ISTEMAS E Conceito de sistema de
Leia maisIntrodução ao Catalysis
Introdução ao Catalysis Tópicos Avançados de Engenharia de Software João Bosco jbapf@cin.ufpe.br Roteiro Dificuldades Motivação Componentes Desenvolvimento Baseado em Componentes (DBC) Catalysis jbapf@cin.ufpe.br
Leia maisCASOS DE TESTE PALESTRANTE: MARCIA SILVA MARCIA.SILVA@DATASUS.GOV.BR WWW.EMERSONRIOS.ETI.BR
CASOS DE TESTE PALESTRANTE: MARCIA SILVA MARCIA.SILVA@DATASUS.GOV.BR WWW.EMERSONRIOS.ETI.BR CONCEITOS BÁSICOS - TESTES O que é Teste de Software? Teste é o processo de executar um programa com o objetivo
Leia maisUML. Trabalho Análise e Projeto de Sistemas. Aluna: Luana Alves Businaro
Curso Técnico Integrado de Informática 2 Ano Projeto Integrador Formação Profissional Trabalho Análise e Projeto de Sistemas UML Aluna: Luana Alves Businaro-1614193 Maio de 2017 Sumário 1 Introdução...
Leia maisAnálise de Requisitos. Tema 4. Análise de Requisitos Profa. Susana M. Iglesias
Análise de Requisitos Tema 4. Análise de Requisitos Profa. Susana M. Iglesias Análise e uma ponte entre a engenharia de sistemas e o desenho do software Engenharia de Sistema Análise de Requisitos de Software
Leia maisI Análise de Sistemas
I Análise de Sistemas Dados e Informação Dados São elementos concretos utilizados como base para discussão, decisão, cálculo ou medição. São valores utilizados como matéria-prima de informação, representada
Leia maisRequisitos de Software
Requisitos de Software Engenharia de requisitos Estabelece os serviços que o cliente requer de um sistema e as restrições sob as quais tal sistema operará e será desenvolvido. Tais serviços e restrições
Leia maisMODELAGEM DE SISTEMA Apresentação
MODELAGEM DE SISTEMA Apresentação Prof Daves Martins Msc Computação de Alto Desempenho Email: daves.martins@ifsudestemg.edu.br Análise de Requisitos Processo de descobrir, analisar, documentar e verificar
Leia maisContratos O diagrama de sequência não menciona a funcionalidade das operações. Isto é, o comportamento do sistema Contrato é um documento que
Contratos Contratos O diagrama de sequência não menciona a funcionalidade das operações. Isto é, o comportamento do sistema Contrato é um documento que descreve o que uma operação promete cumprir As pré-
Leia maisModelagem de Sistemas. Análise de Requisitos. Modelagem
Modelagem de Sistemas Teoria Geral de Sistemas TADS 2. Semestre Prof. André Luís Para abordarmos de forma mais profunda os conceitos de Modelagem de Sistemas de Informação, precisamos também falar na Engenharia
Leia maisPRODUCT BACKLOG. Aula de Luiz Eduardo Guarino de Vasconcelos
PRODUCT BACKLOG Aula de Luiz Eduardo Guarino de Vasconcelos Product Backlog Introdução O PO é a única pessoa responsável por gerir o Product Backlog e assegurar o valor do trabalho feito pelo Team. Este
Leia maisUML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos
UML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos joao.queiroz@ifrn.edu.br Roteiro A importância da UML para projetar sistemas. Principais características do diagrama de classes e de sequência.
Leia maisProcesso de desenvolvimento de sistema de informação - DSI
- DSI Fases do processo de Desenvolvimento de Sistemas Informação Estudo da viabilidade Engenharia de requisitos Desenho (Modelagem) Codificação Testes e Implantação Estudo da viabilidade Estudo preliminar
Leia maisDescrição Textual de Casos de Uso. Resumo
Descrição Textual de Casos de Uso Rui Gomes Instituto Politécnico de Viana do Castelo, Escola Superior de Tecnologia e Gestão Apartado 574, 4900 Viana do Castelo, Portugal email: rgomes@estg.ipvc.pt Resumo
Leia maisRelatório de Análise de Requisitos (24/05/2002 Versão 2.0) Gestão de Beneficiários P7
Relatório de Análise de Requisitos (24/05/2002 Versão 2.0) Gestão de Beneficiários P7 Eduardo Abreu ei98020@fe.up.pt Miguel David ei98019@fe.up.pt Nuno Ferreira ei98003@fe.up.pt Tiago Silva ei98015@fe.up.pt
Leia maisModelagem de Sistemas Web. Modelagem de BD
Modelagem de Sistemas Web Aula 9 Modelagem de BD OBS: Pré-requisito: noções intermediárias em BD e de modelo ER Fonte: Proj. e Mod. BD 4/E Capítulo: Análise de Req. E Mod. Dados Conceit. - Toby Teorey
Leia maisAnálise de sistemas. Engenharia de Requisitos
Análise de sistemas Engenharia de Requisitos Análise de Requisitos Processo de descobrir, analisar, documentar e verificar serviços requeridos para um sistema e suas restrições operacionais. 2 O que é
Leia maisENGENHARIA DE SOFTWARE
ENGENHARIA DE SOFTWARE Teste de Software Verificação e validação Testes de desenvolvimento Testes de release Testes de usuário Desenvolvimento dirigido a testes Kele Teixeira Belloze kelebelloze@gmail.com
Leia maisEngenharia de Software
Engenharia de Software Requisitos de Software Professor: Charles Leite Engenharia de requisitos Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços que oferece e as restrições
Leia mais