APS Especificação de Requisitos de Software 6º semestre

Prévia do material em texto

“Especificação de Requisitos de Software”
 	
SÃO PAULO
2013
	Data: 			08 de agosto de 2013
	Última Revisão: 	18 de novembro de 2013
				Descrição do Trabalho:
Trabalho realizado para APS (Atividades Práticas Supervisionadas) do curso de Sistemas de Informação. Turma do 6º semestre sob orientação do Professor Dr. Paulo.
SÃO PAULO
2013
ÍNDICE
Índice ............................................................................................................. 01
Objetivo ......................................................................................................... 02
Abstract ......................................................................................................... 03
Introdução ...................................................................................................... 04
Requisitos de Software e Engenharia de Requisitos..................................... 06
Documentos de requisitos.............................................................................. 10
Conclusão........................................................................................................17
Bibliografia...................................................................................................... 18
Fichas de Atividades Práticas Supervisionadas..............................................19
OBJETIVO
Esse trabalho tem por objetivo elaborar um Documento de requisitos, baseado nas necessidades do cliente (Governo Federal, Ministério da Saúde), para que seja desenvolvido um sitema que atendas as suas necessidades de tratamento das bactérias que são encontradas nos tanques dos navios. O cliente comercializa um determinado tipo de detergente de origem orgânica e deseja um sistema torne mais eficaz o controle endêmico e pandêmico. Esse documento de requisitos deverá fazer com que o desenvolvimento desse sistema tenha o melhor resultado final possível.
Nossa proposta é adquirir todas as informações referentes ao cliente, ao método de trabalho, processos e todas as necessidades e expectativas desejas.
ABSTRACT
This study aims to develop a requirements document, based on customer requirements (Federal Government, Ministry of Health), to develop a system capable of making more effective the treatment process of the bacteria that are found in the tanks of the ships. The client commercializes a particular type of detergent with organic origin and want to make a system more effective control endemic and pandemic. This requirements document should make the development of this system has the best end result possible.
Our proposal is to acquire all the information pertaining to the client, the method of work processes and the needs and expectations wish.
 
INTRODUÇÃO
Este trabalho apresenta uma visão geral e breve sobre o Desenvolvimento de Software, tendo uma boa razão para considerar a atividade de desenvolvimento de software como uma engenharia. Em um nível mais geral, a relação entre software e seu ambiente é claro, porque o software é apresentado ao mundo, a fim de causar certos efeitos e impacto atingindo seus propósitos.
Esta abordagem orientada à solução de registrar os requisitos referentes aos módulos do sistema proposto pelo cliente (Governo Federal, Ministério da Saúde), buscando uma solução computacional para melhorar o controle das informações referentes à prevenção e o controle endêmico e pandêmico no país em que os problemas são bem conhecidos, pois esta classificada e investigada, para alcançar a inovação de novas soluções.
Mas o desenvolvimento de software é um campo com tais características tendo a versatilidade de sua evolução rápida significa que existe um repertório de problemas em constante evolução, e que soluções de software são de enorme importância, pois iremos trabalha com os dados e informações fornecidas pelo cliente para termos uma parametrização para este desenvolvimento.
 
Requisitos de Software e Engenharia de Requisitos 
A Análise de Requisitos ou Engenharia de Requisitos  é um aspecto importante no Gerenciamento de Projetos, é a responsável por coletar dados indispensáveis, necessários, 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.
A engenharia de requisitos é vital 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 retrabalho.
Dentro deste contexto é importante a comunicação e o envolvimento constante com os usuários do software, pois eles influenciarão no resultado final do produto.
A Engenharia de Requisitos vai consiste em:
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 (Modelagem) – é 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 (Revisão) – 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.
Tipos de requisitos
Requisitos do projeto –  requisitos do negócio, gerenciamento e entrega do produto.
Requisitos do produto – requisitos técnicos, de segurança, de desempenho, etc.
Requisitos funcionais:  eles vão estabelecer como o sistema vai agir, e o que deve fazer as funcionalidades e serviços do sistema, devendo ser descritos detalhadamente. Nesta face, pode-se usar o MER, modelos de casos de uso, fluxogramas, para facilitar o entendimento das funções do sistema.
Requisitos não funcionais: definem as propriedades do sistema e suas restrições. Ex.: a confiabilidade do sistema, o tempo de resposta do programa, o espaço em disco.
Técnicas de Análise de Requisitos
Entrevista – Consiste na investigação direta com os clientes e usuários, fazendo entrevistas para coletar suas expectativas.
Brainstorming– conhecida também como “Tempestade de ideias” essa técnica consiste em coletar ideias, não descartar ou desprezar qualquer tipo de ideia que surja no processo e selecionar a melhor ideia possível podendo ser uma combinação de ideias.
Questionários e pesquisas – podendo ser os questionários com perguntas fechadas no qual caiba apenas às respostas sim ou não, ou perguntas abertas, na qual possibilita a descrição segundo o usuário de suas atividades e possíveis problemas, levando em consideração as opiniões expressas do usuário.
Observação – o analista dispõe de tempo para observar as atividades do usuário, como utiliza o sistema e como se comporta diante de situações problemáticas. Neste contexto há outrastécnicas tais como workshops, mapas mentais, protótipos, etc. A análise de requisitos vai ser o processo a determinar as necessidades e interesses dos steakholders para atingir seus objetivos.
 Das Implementações
Engenharia de Requisitos envolve todas as atividades do ciclo de vida dedicadas a:
A análise de requisitos e negociação para obter requisitos adicionais.
A especificação de requisitos de documentações.
A validação dos requisitos documentados contra as necessidades do usuário.
Assim como os processos que suportam essas atividades. 
Fases de implementação
Do ponto de vista conceitual, as atividades são de cinco tipos, sendo elas:
Obter requisitos, atraves de entrevistas e de comunicação com os clientes internos e externos, para saber quais as suas expectativas.
Analisar os requisitos, detectar e corrigir deficiências de comunicações, transfaormando os requisitos de entrevintas e exigências, em condições adequadas a serem abordados nos projetos.
Documentar requisitos como todas as fases, os requisitos devem ser documentados.
Verificar a elegibilidade sendo o funcionamento correto de uma exigência na aplicação dos requisitos implementados correspondentes ao que foi inicialmente previsto.
Objetivos mensuráveis
As exigências feitas pelos usuários são tomados como objectivos gerais, a longo prazo, e em vez disso, deve ser analisada e outra vez do ponto de vista do sistema para determinar os objetivos críticos do funcionamento interno, em seguida, irá moldar comportamentos apreciável pelo utilizador. Em seguida, estabelecer formas de medir o progresso na construção civil, para avaliar a qualquer momento o quão longe é o projeto.
Protótipos e Casos de Uso
Um protótipo é uma amostra, funcionalidade limitada pequeno, como é que o produto final, uma vez concluído. Eles ajudam a conhecer a opinião dos usuários e corrigir alguns aspectos antes de chegar ao produto acabado.
Um caso de utilização é uma técnica para documentar os requisitos potenciais, traçando a relação do sistema com os utilizadores, ou outros sistemas. Desde que o sistema em si aparece como uma caixa preta, e representa apenas a sua interacção com entidades externas, omitir esses aspectos e identificar realmente correspondem a entidades externas. O objetivo desta prática é melhorar a comunicação entre usuários e desenvolvedores, os primeiros testes de protótipos para minimizar as alterações ao final do projeto e reduzir os custos finais. Esta técnica enfrenta os seguintes perigos potenciais. Para os gestores, uma vez que vêem um protótipo, têm dificuldade em compreender que há muito trabalho a fazer para completar o projeto final.
Designers tendem a reutilizar protótipos código por medo de “perder tempo” para começar de novo.
Os protótipos ajudar principalmente as decisões de design e interface de usuário. No entanto, não preveem explicitamente quais são os requisitos.
Os designers e usuários finais podem se concentrar demais no design da interface do usuário e muito pouco para produzir um sistema que serve o processo de negócio.
Os protótipos incluem: diagramas, aplicações operacionais com funcionalidades sintetizados. Diagramas, nos casos em que o software está previsto para acabar com design gráfico, são feitas em uma variedade de documentos de design gráfico e muitas vezes remove toda a concepção do software cor (ou seja, usar uma variedade de cinza). Isso ajuda a evitar confusão sobre o aspecto final da aplicação.
Especificação de Requisitos de Software
Uma especificação de requisitos de software é uma descrição completa do comportamento do sistema para se desenvolver. Ele inclui um conjunto de casos de uso que descrevem todas as interações que os usuários esperam que o software. Ele também contém requisitos não funcionais (ou adicional). Os requisitos não funcionais são requisitos que impõem restrições sobre o projeto ou operação do sistema (como requisitos de desempenho, padrões de qualidade, ou requisitos de projeto). As estratégias recomendadas para a especificação de requisitos de software são descritos por IEEE 830-1998. Esta norma descreve as possíveis estruturas, conteúdos desejáveis, e as qualidades de especificação de requisitos de software.
Os requisitos são divididos em três partes:
Funcional: são aquelasque ousuário precisa fazer no software, exemplo: o sistema deve emitir um recibo para estabelecer a entrega das mercadorias.
Não funcionais: são os “recursos” para trabalhar sistema de informção (redes, tecnologia), Exemplo: a mídia dearmazenamento utilizados devem ser MySQL.
Negócios ou organizacional: é o quadro contextual em que o sistema será implementado para obter uma lente macro. Por exemplo, os custos de transporte mais baratos. 
Soluções aplicadas
A solução aplicada em problemasde comunicação tem sido empregar especialistas em análise de negócio ou sistema. As técnicas introduzidas na década de 90 tendem a utilizar protótipos, Unified Modeling Language, casos de uso e desenvolvimento de software Agile. Outras ferramentas utilizadas para preencher a lacuna entre os usuários e as organizações, e tecnologia da informação que permitem o teste de aplicações são:
Lousas eletrônicas para esboçar os algoritmos e testar alternativas capacidades de captar a lógica de negócios e dados necessários capacidade de gerar protótipos que imitam fielmente o produto final.
Interatividade a capacidade de adicionar requisitos contextuais e outros comentários capacidade para usuários remotos e distribuídos operar com o protótipo.
Finalmente, são necessárias ferramentas para medir, de forma objectiva, a qualidade de uma especificação de requisitos.
Documentos de Requisitos 
Cliente
	Nome 
	Descrição
	Responsabilidades
	Ministério da Saúde 
	Corresponde ao setor governamental responsável pela administração e manutenção da Saúde pública do país.
	Educação e Saúde Pública.
	Governo Federal
	Possui a atribuição de governar o povo e administrar os interesses públicos, cumprindo fielmente as ordenações legais.
	Interesses da Administração Federal em todo território nacional.
Publico Alvo
Os clientes que solicitaram o sistema uma vez que, através das funcionalidades aqui descritas, os mesmos poderão verificar e tornar mais eficaz a prevenção e o controle endêmico e pandêmico de enfermidades nas populações do mundo inteiro.
Objetivos Gerais do Sistema 
O sistema POWER BEE é uma ferramenta para o processo de desenvolvimento de software. Fornece uma maneira intuitiva e eficiente para definir ações adequadas.
Utilizando a ferramenta o usuário identificará a quantidade do produto utilizada e o nível de agentes químico presentes na água, ficarão registradas as paradas de cada navio e o setor público onde pessoas já “infectadas” poderão ser vacinadas.
Requisitos Funcionais 
	NOME 
	DESCRIÇÂO
	Logar no Sistema
	O Sistema deve obrigar o usuário a se logar.
	Selecionar Região 
	O sistema deve permitir a seleção da região onde usuário se encontra.
	Calcular taxa de agente químico
	Usuário deverá registrar corretamente quantidade utilizada de detergente e a quantidade de água a ser utilizada no reservatório.
 
 SE
	Não utilizável
	Usuário deve apertar F1, abrirá a lista de endereço dos setores públicos.
	Utilizável
	 Liberação do tanque está ok
	Lista de Setor Público
	Sistema deve fazer uma busca no Banco de Dados por região, informando endereço e distancia do setor.
Requisitos Não Funcionais
Operacionais
- O sistema será operado em ambiente Windows e Macintosh.
- Interface WEB: O usuário utilizará o sistema através de um web browser.
Visando criar um produto com maior flexibilidade, deve se adotar como linguagem principal de desenvolvimento Java seguindo cuidadosamente as técnicas de orientação a objetos. Entretanto, outras linguagens também poderão ser usadas quando indicações técnicas recomendem.
O uso da linguagemJava permite não especificar qual será o sistema operacional e a máquina em que o programa irá executar. No entanto, essa máquina deverá se comunicar com um sistema de banco de dados.
Desempenho
- Os tempos de resposta das consultas não devem ultrapassar 5 segundos
- O banco de dados do sistema deve ser atualizado a cada 5 dias.
Segurança
- O sistema deverá restringir o acesso às informações dos usuários.
- Facilidade de Uso: O usuário do sistema deve ter facilidade de uso do sistema, ou seja, realizar tarefas (preenchimento e consulta ) com menos de 30 minutos de treinamento. Para confirmação disso, será realizado um teste de usabilidade.
O sistema terá uma interface amigável ao usuário primário sem se tornar cansativa aos usuários mais experientes. Em especial, o módulo de publicação HTML.
Métodos de Comunicação 
Conduzir uma sessão de Brainstorming
Brainstorming é uma pequena sessão em grupo em que todos podem dizer o que sentem ser mais importante para o tópico em discussão. Depois, um facilitador lidera o grupo na organização e priorização dos resultados. As seguintes regras básicas para brainstorming asseguram melhores resultados:
Iniciamos declarando claramente o objetivo da sessão de Brainstorming.
Gerar tantas idéias quantas forem possíveis.
Deixa a imaginação viajar.
Não permitir críticas ou debates enquanto você está obtendo informações.
Uma vez que a informação seja obtida, remodelar e combinar as idéias.
Entrevistar usuários
Contato face - a - face com usuários durante entrevistas individuais é a fonte primária de requisitos e um meio importante para você obter e validar requisitos. Desenvolver um repertório de estilos para se adequar a diferentes situações. A menos que você mesmo vá fazer uso do sistema, você precisará de um esforço extra para entender e experimentar o problema do usuário para descrevê-lo claramente e corretamente.
Enviar questionários
Se encontros face - a - face forem possíveis, eles sempre serão preferíveis, porque eles fornecem melhores meios de descobrir o problema atrás do problema. Algumas vezes, no entanto, encontros face - a - face com stakeholders não são possíveis. Enviar um conjunto de questões, possivelmente com respostas de múltipla escolha, para os stakeholders relevantes, e peça que respondam e o retornem a você. Dicas de sucesso: mantenha - o pequeno e estabeleça prazos.
Esta técnica possui a vantagem de fornecer bastante informação para análise estatística. Entretanto, as questões devem ser formuladas para serem claras e evitar as ditas "perguntas direcionadas" que influenciam as respostas.
Examinar sugestões e relatórios de problemas
Requisitos podem se originar de sugestões e problemas de usuários. Uma maneira direta de encontrar requisitos é olhar as sugestões e problemas descritos primeiramente. Muitas organizações possuem alguma forma de relatar problemas ou defeitos em sistemas. Organize - os em grupos para poder identificar as áreas chave que estão incomodando os usuários. Faça perguntas aos usuários sobre essas áreas para clarificar as reais necessidades dos usuários.
Conversar com equipes de suporte
A maioria das organizações de vendas possui um help desk que mantém uma lista de problemas e soluções, e engenheiros de suporte que solucionam os problemas. Muitas organizações possuem estruturas similares para suportar suas próprias operações. Conversar com o pessoal de help desk e engenheiros de suporte pode lhe dar boas direções aos requisitos, e economizar tempo. Converse também com a equipe de treinamento e equipes de instalação sobre o que usuários acham mais problemático.
Estudar melhorias feitas pelos usuários
Esta é uma excelente fonte de requisitos. Usuários de uma planilha padrão da companhia podem ter adicionado alguns campos, ou relacionado planilhas diferentes, ou desenhado gráficos que satisfazem as suas necessidades individuas. Você só precisa perguntar: Por que você adicionou isso? As respostas deles o ajudam a chegar ao coração do requisito real. Isso se aplica também a hardware e dispositivos não - computacionais. Por exemplo, um operador de torno mecânico pode ter manufaturado uma braçadeira especial ou um braço que não permite movimento da ferramenta além de certo ponto. Modificações desse tipo apontam algo errado com o produto existente, o que faz disso um requisito válido para a nova versão.
Observar usos não intencionados
As pessoas freqüentemente usam coisas para propósitos que elas não foram projetadas. Essa é uma boa maneira de obter novas idéias e pensar em inovações. Por exemplo, um gerente de produto atento notou que um engenheiro ficava no escritório até mais tarde para usar um sistema de design auxiliado por computador para projetar uma nova cozinha para sua casa.
Demonstrar protótipos aos stakeholders
Protótipos nos permitem ver imediatamente alguns aspectos do sistema. Mostrar aos usuários um protótipo simples pode provoca-los a fornecer boas informações de requisitos ou mudar de idéia sobre requisitos existentes. As técnicas descritas aqui o ajudam a obter idéias para requisitos. Protótipos e modelos são excelentes maneiras de apresentar idéias a usuários. Eles podem ilustrar como uma abordagem pode funcionar, ou dar aos usuários uma visão do que eles podem ser capazes de fazer. Mais requisitos podem emergir quando usuários vêem o que você está sugerindo.
Uma apresentação pode usar uma seqüência de slides, roteiro, uma impressão de um artista ou mesmo uma animação para aos usuários a visão das possibilidades. Quanto a prototipação do software, faça um rascunho das telas da interface com o usuário enfatizando que não há código e que o sistema não foi projetado nem especificado ainda (alerta: perigoso para os desavisados).
Essa prototipação objetiva fazer usuários expressar requisitos (faltantes). Você não está tentando vender aos usuários uma idéia ou produto, você está descobrindo o que eles querem realmente. Ver um protótipo, que invariavelmente está errado em alguns aspectos e correto em outros,  é um poderoso estímulo para usuários começarem a dizer o que eles querem. Eles podem apontar vários problemas com o protótipo! Isso é excelente porque cada problema leva a um novo requisito.
Conclusão
Após coletadas todas as informações pertinentes, de todos os setores que estarão envolvidos no projeto, podemos então agora começar a definição do escopo do sistema. Definir todas as funções necessárias, reunir a equipe de desenvolvimento para que se apresente toda documentação e que seja transmitido para os desenvolvedores todos os requisitos já estabelecidos para desenvolvimento do sistema.
Foram verificadas todas as necessidades do nosso cliente. Nossa equipe de análise de requisitos conseguiu reunir com êxito todas as funcionalidades exigidas, e ainda expôs algumas ideias de melhorias referentes as ideias apresentadas pelo patrocinador.
Foram respeitadas nesse projeto todas as regras imprescindíveis, e seguidas todas as especificações técnicas conforme consta no PMI/PMBOK.
Será definido a apartir de agora em quais ordens serão desenvolvidos os módulos que deverão ser desenvolvidos e testados fase a fase no laboratório e no ambiente do cliente. Todos os testes devidamente documentados no âmbito de teste e também em suas respectivas entregas.
BIBLIOGRAFIA
McConnell, Steve (1996). Desenvolvimento Rápido: domesticar Silvestres Horários Software, 1 ª ed, Redmond, WA:. Microsoft Press. ISBN 1-55615-900-5.
Wiegers, Karl E. (2003). Requisitos de Software 2: técnicas práticas de recolha e gestão de requisitos ao longo do ciclo de desenvolvimento de produtos, 2 ª ed, Redmond:. Microsoft Press. ISBN 0-7356-1879-8.
Andrew Stellman e Jennifer Greene (2005). Aplicada em Gerenciamento de Projetos de Software. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8.
IEEE Std 830-1998 IEEE Prática Recomendada para Especificações de Requisitos de Software-Inscrição
Landgraf, Katja (2011) Gerenciamento deRequisitos no Desenvolvimento de Produtos, Symposion Publishing ISBN 978-3-939707-8