04 - Análise e Projeto de Sistemas - Especificação de requisitos

Prévia do material em texto

Análise e Projeto de Sistemas 	
Vinicius Marinho da S. Marçola
vinicius.marinhosm@hotmail.com
O Ciclo de Vida do Desenvolvimento de Sistemas
(SDLC – Systems Development Life Cycle), conhecido com o “ciclo de vida do software” refere-se aos estágios de concepção, projeto, criação e implementação. 
Levantamento de Necessidades
Manutenção
Implementação
Desenvolvimento
Projeto
Análise de Alternativas
O LEVANTAMENTO DAS NECESSIDADES também chamado de análise de requisitos, identifica as necessidades de informações da organização.
A ANÁLISE DE ALTERNATIVAS consiste na identificação e avaliação de sistemas alternativos.
PROJETO trata da construção das especificações detalhadas para o projeto. Que incluem:
O projeto das interfaces
O banco de dados
Algumas características físicas do sistema (número, tipos e localizações das estações de trabalho, hardware de processamento, o cabeamento e os dispositivos de rede)
	Deve especificar os procedimentos para testar o sistema completo antes da instalação
DESENVOLVIMENTO inclui o desenvolvimento ou aquisição do software, a provável aquisição do hardware e o teste do novo sistema. 
IMPLEMENTAÇÃO ocorre após o sistema ter passado satisfatoriamente por testes de aceitação. 
O sistema é transferido do ambiente de desenvolvimento para o ambiente de produção. 
O sistema antigo (se existir) deve migrar para o novo.
MANUTENÇÃO refere-se a todas as atividades relacionadas a um sistema depois que ele é implementado. 
Deve incluir atividades tais como a correção de software que não funcione corretamente
A adição de novos recursos aos sistemas em resposta às novas demandas dos usuários
Especificação de Requisitos
Elicitação e especificação de requisitos
Para que um projeto de desenvolvimento de software seja considerado de sucesso, uma das premissas é que o produto gerado atenda o que o cliente deseja.
Portanto, há a necessidade de documentação das necessidades do cliente. 
Quando estas descrições não são escritas ou são escritas e não são validadas com o cliente, é comum que no momento da entrega o cliente expresse que o produto não é o que ele havia solicitado anteriormente. 
Um dos grandes erros que os desenvolvedores individuais ou micro empresas de desenvolvimento de software que não se preocupam com requisitos.
Elicitação de requisitos
Os profissionais trabalham diretamente com os clientes e usuários finais do sistema para aprender sobre o domínio da aplicação, quais funcionalidades o sistema deve fornecer, o desempenho esperado e restrições de infraestrutura (hardware, rede...). 
Dada esta diversidade, os envolvidos são denominados através do termo técnico Stakeholder.
Além dos Stakeholders, outras fontes de requisitos são:
Ambiente físico
Documentação (Formulários de cadastro de alunos, por exemplo)
Dados existentes
Recursos existentes
Sistemas legados
Segurança. 
Elicitação de requisitos
Para isso é necessário que seja utilizado um conjunto de técnicas de elicitação. Veja algumas técnicas de levantamento de requisitos e suas descrições:
Entrevista: A equipe de análise de sistemas reúne-se com o(s) stakeholder(s) para uma conversa sobre as necessidades e expectativas em relação ao sistema a ser desenvolvido
Stakeholder
Analista
Elicitação de requisitos
Observação: Consiste na observação do ambiente onde a aplicação irá funcionar a fim de captar informações acerca do funcionamento dos processos da empresa
Elicitação de requisitos
Demonstração de Tarefa: Em algumas tarefas específicas a observação isolada pode não ser suficiente. A técnica de demonstração de tarefa é utilizada quando os stakeholders fazem a demonstração das tarefas aos analistas de sistemas
Stakeholder
Analista
Elicitação de requisitos
Estudo de Documentos: Documentos em papel, como formulários de cadastro e relatórios já utilizados. Podem revelar um conjunto de dados esperado para uma funcionalidade
Substituir o Usuário (Role playing): Quando o domínio da aplicação é cheio de tarefas específicas e complexas. É substituir o usuário pelo analista, assim se repete os passos que o mesmo faria, sendo auxiliado pelo usuário em relação às dúvidas que possam surgir.
Analista
Stakeholder
Elicitação de requisitos
Questionário: Questionário consiste em redigir um conjunto de perguntas que devem ser respondidas pelos usuários. Os questionários auxiliam nas dúvidas existentes em relação aos requisitos já elicitados ou na descoberta de requisitos novos
Elicitação de requisitos
Brainstorming (ou tempestade de ideias): Esta técnica é importante para alinhar a visão de todos os participantes em relação ao sistema que será desenvolvido. A execução desta técnica segue os seguintes passos:
É estabelecido um tempo máximo de reunião e os participantes tem um momento para refletir sobre o tema abordado
Os participantes vão ditando as ideias e todas elas são escritas de modo que todos possam ver; 
É encerrado a sessão e as ideias repetidas são retiradas. As ideias que geraram dúvidas são melhor explicadas; 
As melhores ideias escolhidas coletivamente são analisadas, melhoradas e aproveitadas. 
Prototipação: Consiste na criação de um esboço inacabado do sistema. Este esboço representa a implementação inacabada do sistema, muitas vezes somente a parte de interface gráfica com os formulários com botões e campos de texto; no entanto, sem acesso a banco de dados, tratamento de campos ou processamento de cálculos;
Workshops ou Oficinas de Requisitos: 
	Reúnem todos os envolvidos durante um 
período curto, mas intensivo e focado. 
Elicitação de requisitos
Os requisitos podem ser classificados:
RF – Requisitos Funcionais
RNF - Requisitos Não Funcionais
Especificação de requisitos
Os requisitos funcionais (RF) são as definições de todas as funções e serviços para o desenvolvimento do projeto, nela contém todas as informações levantadas para a elaboração do sistema.
Um exemplo de requisitos deste tipo seria: “O sistema deve realizar o cadastro de Produtos”
Especificação de requisitos
Identificação: contém a nomenclatura do requisito funcional (RF seguido de uma numeração crescente); 
Nome: determina o nome dado ao requisito; 
Descrição: define uma prévia descrição da função ou serviço que será desenvolvido; 
Usuário: indica quem será usuário da página desenvolvida; 
Essencial / Importante / Desejável: informa o grau de necessidade do usuário para o sistema. 
Especificação de requisitos
Os requisitos não-funcionais (RNF) estão associados com o estado do sistema, todos os aspectos internos que são compreendido pelo desenvolvedor tais como usabilidade, segurança, confiabilidade, desempenho, hardware e software, assim demonstrando a qualidade de todas as funções e serviços que estão disponíveis para o usuário.
Especificação de requisitos
Identificação: contém a nomenclatura do requisito não-funcional (RNF seguido de uma numeração crescente); 
Nome: determina o nome dado ao requisito; 
Descrição: define uma prévia descrição da função ou serviço que será desenvolvido; 
Essencial / Importante / Desejável: informa o grau de necessidade do usuário para o sistema. 
Especificação de requisitos
Exercício 01 – Especificação de Requisitos
Exercício Projeto
Crie uma planilha com os requisitos funcionais e não funcionais.
Referências Bibliográficas
Bezzera E. Princípios de Análise e Projeto De Sistemas com UML, Rio de Janeiro: Editora Campus, 2013. 2º Edição
WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação Orientados a Objetos, Campus, 2004.
RUMBAUGH, James e BLAHA, Michael. Modelagem e projetos baseados em objetos com UML 2. Campus, 2006.
MEDEIROS, Ernani. Desenvolvendo Software com UML 2.0 Definitivo. Makron Books, 2004.
TAFNER, Malcon A. & Carlos Henrique Correia. Análise Orientada a Objetos. 2 Ed., Visual Books, 2006.
MELO, Ana Cristina. Exercitando Modelagem em UML. Brasport, 2006.
BEZERRA, Eduardo. Princípio de Análise e Projetos de Sistemas com UML. Elsevier - Campus, 2006.
OLIVEIRA, L. V. UML – Diagramas de Sequência. 2013. Disponível em: <http://www.theclub.com.br/restrito/revistas/201308/umld1308.aspx>.Acesso em: 06 ago. 2018.
BOOCH, G.; RUMBAUGH, J; JACOBSON, I. UML: guia do usuário. 12. ed. Rio de Janeiro: Elsevier, 2012.
Enyo José Tavares Gonçalves, Mariela Inés Cortés, Análise e Projeto de Sistemas, 2015 - 3ª edição Editora da Universidade Estadual do Ceará – EdUECE
image1.jpeg
image2.png
image3.png
image4.png
image5.jpeg
image6.png
image7.png
image8.jpeg
image9.jpeg
image10.jpeg
image11.jpeg
image12.jpeg
image13.png
image14.png