ES_Template_Requisitos

Prévia do material em texto

UNIVERSIDADE FEDERAL DE MINAS GERAIS
Escola de Engenharia
Curso de Graduação em Engenharia de Sistemas
VISÃO GERAL DO PROJETO
E
LEVANTAMENTO DE REQUISITOS
Trabalho Prático
DESENVOLVIDO PELA EQUIPE: <Nome da equipe>
<Listar nomes dos componentes da equipe>
< Incluir a data de entrega no formato dd/mm/aaaa>
1 Histórico
	Data
	Versão
	Responsável
	Alteração
	<dd/mm/aaaa>
	<X.01>
	<Nome>
	<Criação do documento>
	
	
	
	
2 Informações Gerais do Documento
	Objetivos:
· <Relacionar os objetivos deste documento>
	Público Alvo:
· <Relacionar os perfis para os quais este documento foi / está sendo elaborado>
	Referências:
[1] <Relacionar outros documentos e materiais relacionados a este documento>
[2] 
3 Glossário
	Termo
	Descrição
	Requisitos
	Características que definem os critérios de aceitação de um produto. 
	Requisitos funcionais
	Características que representam comportamentos que o sistema deve apresentar diante de certas ações ocorridas
	Requisitos não funcionais
	Características que restringem o sistema e/ou que quantificam aspectos comportamentais (ex: tempo de resposta, tempo médio entre falhas)
	<Termo>
	<Descrição do termo, para termos específicos que forem relevantes>
	
	
	
	
4 Dados Gerais do Projeto
	Sigla – Nome do Projeto:
	<Sigla – Nome do Projeto>
	Sigla – Nome do Cliente:
	<Sigla – Nome do Cliente, se aplicável>
	Objetivos:
· <Relacionar objetivos a serem atingidos com a execução do projeto>
· 
	Benefícios Esperados:
· <Relacionar benefícios que justifiquem a execução do projeto>
5 Posicionamento Geral
5.1 Descrição do Problema
 <Fornecer uma descrição resumindo o problema que está sendo resolvido pelo projeto. Uma boa maneira é usar o formato abaixo>
	O problema de
	<descrever o problema>
	afeta
	<relacionar os envolvidos afetados pelo problema>
	cujo impacto é
	<identificar o impacto gerado pelo problema>
	uma boa solução seria
	<citar uma potencial boa solução e seus potenciais benefícios>
5.2 Posicionamento do Produto / Serviço Resultante
<Fornecer uma sentença geral resumindo, em nível mais alto, a posição exclusiva que o produto / serviço pretende ocupar no mercado. Uma sentença de posicionamento do produto / serviço comunica seu objetivo e a importância do projeto para todo o pessoal envolvido Uma boa maneira é usar o formato abaixo>
	Para
	<indicar cliente ou organização alvo>
	Que
	<indicar a necessidade ou oportunidade a ser atendida>
	O <nome do prod/serv>
	é um(a) <categoria do produto / serviço>
	Que
	<indicar o principal benefício, ou seja, uma razão convincente que motiva a sua realização>
	Ao contrário de
	<indique a principal alternativa da concorrência>
	Nosso produto/serviço
	<indique a(s) principal(is) diferença(s) e/ou vantagem(ns)>
5.3 Alternativas Iniciais e da Concorrência
<Analisar o produto / serviço pretendido em relação a outros produtos semelhantes. Identificar alternativas de desenvolvimento consideradas disponíveis. Entre elas, podem estar incluídas: a compra e/ou a adaptação de um ou mais produtos / componentes de mercado; a compra de um produto / componente de um concorrente; a terceirização do desenvolvimento de um ou mais produtos/ componentes; a criação completa de uma solução local; a evolução / ajuste de um produto / componente pré-existente. Procure listar todas as opções identificadas internamente, que a concorrência oferece ou que podem se tornar disponíveis. Identifique os principais pontos fortes e pontos fracos de cada concorrente segundo o ponto de vista do envolvido ou do usuário final>
	Id
	Alternativa
	Avaliação Inicial
	<Nr>
	<Descrição da alternativa>
	<Avaliar pontos + e – >
	
	
	
6 Descrição das Partes Envolvidas
6.1 Perfis de Usuários
<Relacionar de forma resumida todos os perfis de usuário identificados>
	Perfil de Usuário
	Envolvimento
	Cuidados para o Uso
	<Especificar um nome para o perfil de usuário>
	<Relacionar seus principais interesses e responsabilidades em relação ao produto e/ou serviço – ex: percebe os detalhes; elabora relatórios; coordena o trabalho; ...>
	<Relacionar itens relevantes para que ocorra uso adequado – ex: treinamentos requeridos; elaboração de manuais; ...>
	
	
	
6.2 Equipe Interna
	Papel
	Envolvimento
	Responsabilidades
	<Especificar um nome para a parte envolvida>
	<Relacionar seus principais interesses em relação ao produto e/ou serviço – ex: manutenção operacional; prospecção de mercado; patrocínio; ...>
	<Relacionar suas principais responsabilidades em relação ao produto e/ou serviço – ex: assegurar estrutura para manutenção; assegurar que haverá uma demanda de mercado; prover/aprovar recursos; ...>
	
	
	
6.3 Demais Partes Envolvidas
<Há uma série de envolvidos que se interessam pelo produto e/ou serviço, mas nem todos eles são usuários finais. Apresentar uma lista resumida das partes envolvidas que não são usuários>
	Parte Envolvida
	Envolvimento
	Responsabilidades
	<Especificar um nome para a parte envolvida>
	<Relacionar seus principais interesses em relação ao produto e/ou serviço – ex: manutenção operacional; prospecção de mercado; patrocínio; ...>
	<Relacionar suas principais responsabilidades em relação ao produto e/ou serviço – ex: assegurar estrutura para manutenção; assegurar que haverá uma demanda de mercado; prover/aprovar recursos; ...>
	
	
	
7 Necessidades Identificadas
<É relevante compreender a importância relativa exercida pelo usuário ou pelo envolvido na resolução do problema. Assim, as necessidades identificadas podem ser classificadas como:
[E] Essencial - é a necessidade imprescindível, sem a qual o sistema não faz sentido; [I] Importante - é a necessidade sem a qual o sistema entra em funcionamento (poderá ser implantado e usado), mas de forma restrita e não satisfatória; [D] Desejável - é a necessidade que não compromete o funcionamento básico do sistema (o sistema pode funcionar de forma satisfatória sem ela, que pode ser deixada para versões posteriores do sistema, caso não haja tempo hábil para implementá-la)>
	Id
	Necessidade a ser Atendida
	Prioridade
	Parte(s) Envolvida(s)
	1
	<Relacionar as necessidades identificadas que afetam a parte envolvida, ou seja, os principais problemas com as soluções existentes sob o seu ponto de vista – explorar: quais são as causas deste problema? como ele está sendo resolvido agora? que soluções a parte deseja?>
	<Essencial, Importante, Desejável>
	<Nome da(s) parte(s) que possui(em) a necessidade>
	2
	
	
	
	3
	
	
	
8 Visão Geral do Produto / Serviço
8.1 Contexto do Produto / Serviço
	Contexto Geral do Produto / Serviço
<Descrever e/ou incluir um diagrama contendo o produto / serviço de interesse, destacando a sua fronteira externa, bem como outros produtos / serviços com os quais ele possui interface, sejam estes de apoio ou externos. Se o produto for um componente de um sistema maior, mostrar como eles interagem e identificar as interfaces relevantes existentes. Uma maneira fácil de exibir os principais componentes do sistema maior, suas interconexões e interfaces externas é utilizando um diagrama de bloco>
	Visão Geral das Interfaces Externas
<Se o produto / serviço for independente e totalmente auto-suficiente, expor isso aqui. Se o produto for um componente de um sistema maior, descrever como ele interage com as demais partes existentes, identificando questões relevantes de interface entre eles>
	Visão Geral do Ambiente do Produto
<Descrever características gerais (nr usuários, perfis de usuários, plataforma, tecnologias, ciclo/tempo de uso, ...) e restrições (ambientais, de uso, ...) relacionadas ao ambiente no qual o produto / serviço está inserido>
8.2 Informações Básicas do Produto / Serviço
	Escopo do(s) Produto(s) e/ou Serviço(s) a ser(em) Obtido(s):
· <Relacionar itens a serem entregues, sejam eles produto(s) e/ou serviço(s), junto com características e funções gerais que o descrevem – o que o produto e/ou serviço irá fazer (a mais que o(s) atualmente existente(s))?>
	Premissas Relacionadas:
· <Relacionar conceitos ou fatos iniciais de que se partepara formar a ideia do(s) produto(s) e/ou serviço(s) descrito(s) acima, bem como para a definição das atividades do projeto. Uma premissa é um fator que, para fins de planejamento, é considerado verdadeiro, real ou certo, que não necessita prova ou demonstração. Podem também apontar aqui itens que não fazem parte do escopo>
	Restrições / Limitações Relacionadas:
· <Relacionar restrições / limitações aplicáveis, tanto internas quanto externas, que afetarão os resultados obtidos no âmbito do(s) produto(s) e/ou do(s) serviço(s). Ex: leis, orçamento, tempo, pessoal, tecnologia, leis da física e de propriedade de dispositivos e materiais, uso de itens disponíveis no mercado, ... >
	Critérios de Sucesso Relacionados:
· <Relacionar os critérios de sucesso para o(s) produto(s) e/ou serviço(s) – ex: desempenho, qualidade, fatores humanos, custo, segurança, ambiente de operação, meio ambiente (cercanias), interface com outros sistemas, logística, confiabilidade, disponibilidade, facilidade de conserto/manutenção, estética, ...>
9 Requisitos do Produto / Serviço
< Os requisitos aqui colocados serão a base fundamental para a definição detalhada do produto, bem como para o gerenciamento do escopo e do projeto>
9.1 Requisitos Funcionais
<Relacionar e descrever brevemente os recursos (funcionalidades) do produto. Trata-se dos recursos de nível macro do sistema que são necessários para propiciar benefícios aos usuários. Cada recurso é um serviço desejado externamente, que em geral exige uma série de entradas para alcançar os resultados desejados. Como na prática este documento é revisado por uma ampla variedade de pessoas envolvidas, o nível de detalhamento terá que ser genérico o bastante para que todos possam compreendê-lo. No entanto, devem estar disponíveis detalhes suficientes para fornecer à equipe as informações necessárias para criar posteriormente uma solução física e lógica (a arquitetura da solução). 
Cada recurso poderá ser externamente percebido por usuários, operadores e outros sistemas externos. Esses recursos deverão incluir uma descrição da funcionalidade e de todas as questões de usabilidade relevantes que deverão ser consideradas. 
Diretrizes gerais: mantenha as descrições dos recursos em um nível geral, concentre-se nos recursos necessários - em “o que” e no “porquê” (e não em “como”) eles deverão ser implementados; inclua características e/ou valores de referência associados, se existirem.
A prioridade dos requisitos pode ser classificada como: [E] Essencial - é o requisito imprescindível, sem o qual o sistema não faz sentido; [I] Importante - é o requisito sem o qual o sistema entra em funcionamento (poderá ser implantado e usado), mas de forma restrita e não satisfatória; [D] Desejável - é o requisito que não compromete o funcionamento básico do sistema (pode funcionar de forma satisfatória sem o requisito, que pode ser deixado para versões posteriores do sistema, caso não haja tempo hábil para implementá-lo).
Da mesma forma, a complexidade pode ser classificada como: [A] Alta - exige um esforço significativo e/ou o conhecimento de profissional especialista no assunto (sênior); [M] Média - exige um esforço grande e/ou o conhecimento de profissional com fluência no assunto (pleno); [B] Baixa - exige um esforço moderado e/ou um conhecimento básico no assunto (profissional júnior)>
	Id: <RFxxx>
	Nome: <Nome de identificação do requisito>
	Descrição:
<Explicação e detalhamento do requisito, conforme necessário>
	Alocação: <Componente do produto / serviço resultante que o requisito se aplica>
	Prioridade:
	[ ] E [ ] I [ ] D
	Complexidade:
	[ ] A [ ] M [ ] B
	Id: <RFxxx>
	Nome: <Nome de identificação do requisito>
	Descrição:
<Explicação e detalhamento do requisito, conforme necessário>
	Alocação: <Componente do produto / serviço resultante que o requisito se aplica>
	Prioridade:
	[ ] E [ ] I [ ] D
	Complexidade:
	[ ] A [ ] M [ ] B
	Id: <RFxxx>
	Nome: <Nome de identificação do requisito>
	Descrição:
<Explicação e detalhamento do requisito, conforme necessário>
	Alocação: <Componente do produto / serviço resultante que o requisito se aplica>
	Prioridade:
	[ ] E [ ] I [ ] D
	Complexidade:
	[ ] A [ ] M [ ] B
9.2 Requisitos Não Funcionais
<Relacionar e descrever brevemente padrões aplicáveis, requisitos de hardware ou de plataforma, requisitos de desempenho, requisitos ambientais, de estados e modos, de recursos, de projeto, físicos, bem como outras qualidades necessárias. Definir as faixas de qualidade para desempenho, robustez, tolerância a erros, usabilidade e características semelhantes que não são capturadas no conjunto de funcionalidades e recursos. Observar quaisquer restrições de projeto, restrições externas ou outras dependências. Definir quaisquer requisitos de documentação específicos, incluindo requisitos de manuais do usuário, ajuda on-line, instalação, rotulação e de embalagem.
Classificar a Prioridade e a Complexidade utilizando os mesmos critérios definidos para requisitos funcionais>
	Id: <RNFxxx>
	Nome: <Nome de identificação da restrição aplicável>
	Descrição:
<Explicação e detalhamento da restrição, conforme necessário. Incluir faixas de valores ou valores específicos aplicáveis>
	Alocação: <Componente do produto / serviço resultante que a restrição se aplica>
	Prioridade:
	[ ] E [ ] I [ ] D
	Complexidade:
	[ ] A [ ] M [ ] B
	Id: <RNFxxx>
	Nome: <Nome de identificação da restrição aplicável>
	Descrição:
<Explicação e detalhamento da restrição, conforme necessário. Incluir faixas de valores ou valores específicos aplicáveis>
	Alocação: <Componente do produto / serviço resultante que a restrição se aplica>
	Prioridade:
	[ ] E [ ] I [ ] D
	Complexidade:
	[ ] A [ ] M [ ] B
9.3 Requisitos de Interface
<Descrever interfaces com usuário e demais interfaces externas existentes, bem como interfaces internas relevantes. Sugere-se utilizar as seguintes técnicas:
- Descritivo: tem o objetivo de apresentar as entradas e saídas que a interface possuirá. Constitui em um texto que lista os componentes presentes, sem se preocupar com o layout desses componentes na interface;
- Esboços: tem os mesmos objetivos do Descritivo, porém representado de forma gráfica, já trazendo alguma informação a respeito de layout. Constitui em um desenho que demonstre, sem riqueza de detalhes, os principais componentes de entrada e saída da interface;
- Protótipos: tem como objetivo não apenas mostrar os elementos presentes na interface mas também enfatizar quesitos de layout, tais como: estilo, cores, fontes, etc. O nível de riqueza e de comprometimento com a solução final dependerá das necessidades do projeto, podendo ser utilizadas para sua construção tanto ferramentas de desenho quanto de desenvolvimento>
	Id: <RIxxx>
	Nome: <Nome de identificação do requisito de interface>
	Descrição:
<Explicação e detalhamento do requisito de interface, conforme necessário>
	Alocação: <Componente do produto / serviço resultante que a restrição se aplica>
	Prioridade:
	[ ] E [ ] I [ ] D
	Complexidade:
	[ ] A [ ] M [ ] B
	Id: <RIxxx>
	Nome: <Nome de identificação do requisito de interface>
	Descrição:
<Explicação e detalhamento do requisito de interface, conforme necessário>
	Alocação: <Componente do produto / serviço resultante que a restrição se aplica>
	Prioridade:
	[ ] E [ ] I [ ] D
	Complexidade:
	[ ] A [ ] M [ ] B
9.4 Relacionamento entre Requisitos e Necessidades
	Requisito
	N1
	N2
	N3
	N4
	N5
	...
	...
	...
	<RFxxx>
	<X>
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	<RNFyyy>
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	<RIzzz>
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
9.5 Verificação dos Requisitos
	Itens a Serem Verificados – Requisitos Identificados
	Sim
	Não
	Os requisitos são relevantes para o negócio ou produto?
	
	
	Os requisitos estão alinhados com as leis e restrições aplicáveis?
	
	
	Os requisitos estão identificados de forma única?
	
	
	Os requisitos estãodescritos de forma clara e não ambígua?
	
	
	Os requisitos estão consistentes entre si?
	
	
	Os requisitos estão cobrindo todo o escopo definido para o produto?
	
	
	<Incluir outras questões que considerarem relevantes>
	
	
	Laudo: [ ] Aprovado [ ] Aprovado com ressalvas [ ] Não Aprovado
Observações: <Caso a verificação possua ressalvas ou não tenha sido aprovada, relacionar o que precisa ser modificado>
10 Soluções Gerais Propostas
10.1 <Nome da Alternativa A>
	Alternativa A: <Nome da solução>
	Descrição Geral da Solução
<Elaborar um texto descrevendo a Alternativa A e, se possível, um desenho esquemático (diagrama de blocos) dos principais componentes e suas interfaces>
	Pontos Favoráveis
<Relacionar os pontos positivos da Alternativa A>
	Pontos Desfavoráveis
<Relacionar os pontos negativos da Alternativa A>
10.2 <Nome da Alternativa B>
	Alternativa B: <Nome da solução>
	Descrição Geral da Solução
<Elaborar um texto descrevendo a Alternativa B e, se possível, um desenho esquemático (diagrama de blocos) dos principais componentes e suas interfaces>
	Pontos Favoráveis
<Relacionar os pontos positivos da Alternativa B>
	Pontos Desfavoráveis
<Relacionar os pontos negativos da Alternativa B>
10.3 <Nome da Alternativa C>
	Alternativa C: <Nome da solução>
	Descrição Geral da Solução
<Elaborar um texto descrevendo a Alternativa C e, se possível, um desenho esquemático (diagrama de blocos) dos principais componentes e suas interfaces>
	Pontos Favoráveis
<Relacionar os pontos positivos da Alternativa C>
	Pontos Desfavoráveis
<Relacionar os pontos negativos da Alternativa C>
11 Avaliação das Soluções Propostas
11.1 Critérios Utilizados
	Id
	Critério
	Valores - Interpretação
	Peso
	1
	<Descrever critério>
	<Descrever como interpretá-lo e como atribuir um valor de referência
	<Peso>
	2
	
	
	
	3
	
	
	
	4
	
	
	
11.2 Escolha da Solução
	Critério
	Avaliação das Alternativas
	Id
	Peso
	Alternativa A
	Alternativa B
	Alternativa C
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	Resultado
	
	
	
	Decisão final
	<Incluir aqui justificativas, comentários e consequências da escolha de uma determinada alternativa em detrimento das demais>
12 Aprovações
	Nome
	Assinatura
	Data
	<Nome do aprovador>
	<Assinatura do aprovador>
	<dd/mm/aaaa>
	
	
	
PAGE 
<Nome da Equipe>
Página 1