Você está na página 1de 7

Título do Sistema

Nome Aluno 11, Nome Aluno 21, Nome Aluno 31, Nome Aluno 41, Nome Aluno 51

Orientador: Profa. Msc. Jacilane de Holanda Rabelo


(Engenharia de Software)

¹Engenharia da Computação – CMN08S1 Commented [jr1]: Alterar com os dados da turma


Centro Universitário do Norte (UNINORTE) – Manaus – AM – Brasil
e-mail dos alunos
jacilane.rabelo@uninorte.com.br
Resumo. Escrever o resumo do trabalho em até 10 linhas. Aqui deve ser
descrito do que se trata do trabalho e quais suas principais características

1. Introdução
Descrever o propósito do documento.
Descrever o objetivo do documento de forma clara
“Este documento tem por objetivo apresentar os requisitos que o sistema deve atender
em diferentes níveis de detalhamento. Dessa forma, serve como acordo entre as partes
envolvidas – cliente e analista/desenvolvedor.”

1.1 Definições, Glossário, Acrônimos e Abreviações

Fornecer as definições de todos os termos, acrônimos e abreviações necessárias para


interpretar de modo apropriado os requisitos descritos no documento.

<Esta subseção deve descrever as convenções, termos e abreviações necessários para


interpretar apropriadamente este documento. As explicações necessárias podem ser
fornecidas diretamente nesta seção ou através de referências para outros documentos ou
para apêndices deste documento. Complete e/ou adapte o texto abaixo para fornecer essas
informações.>
A correta interpretação deste documento exige o conhecimento de algumas convenções e
termos específicos, que são descritos a seguir.

Identificação dos Requisitos


Por convenção, a referência a requisitos é feita através do nome da subseção onde eles
estão descritos, seguido do identificador do requisito, de acordo com o esquema abaixo:
[nome da subseção.identificador do requisito]
Por exemplo, o requisito [Recuperação de dados.RF016] está descrito em uma subseção
chamada “Recuperação de dados”, em um bloco identificado pelo número [RF016]. Já o
requisito não funcional [Confiabilidade.NF008] está descrito na seção de requisitos não
funcionais de Confiabilidade, em um bloco identificado por [NF008].

Prioridades dos Requisitos


Para estabelecer a prioridade dos requisitos foram adotadas as denominações “essencial”,
“importante” e “desejável”.
 Essencial é o requisito sem o qual o sistema não entra em funcionamento.
Requisitos essenciais são requisitos imprescindíveis, que têm que ser
implementados impreterivelmente.
 Importante é o requisito sem o qual o sistema entra em funcionamento, mas de
forma não satisfatória. Requisitos importantes devem ser implementados, mas, se
não forem, o sistema poderá ser implantado e usado mesmo assim.
 Desejável é o requisito que não compromete as funcionalidades básicas do
sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos
desejáveis são requisitos que podem ser deixados para versões posteriores do
sistema, caso não haja tempo hábil para implementá-los na versão que está sendo
especificada.

1.2 Visão Geral do Documento

Descrever o conteúdo do documento.


Explicar a organização do documento.
“O Capítulo 2 fornece uma descrição .... No Capítulo 3, ....”

2. Descrição do Projeto
Descrever o sistema que será desenvolvido.
Indicar qual é o problema que será resolvido, porque este problema é relevante, o que será
desenvolvido (tipo de sistemas, características particulares) e os benefícios esperados do
uso deste sistema.
 Identificar o(s) produto(s) de software a ser(em) produzido(s) pelo nome.
 Explicar o quê o(s) produto(s) de software fará(ão) e, se necessário, o quê não
fará(ão).

3. Ciclo de Vida do Projeto


Definir um ciclo de vida para desenvolver o sistema. Verificar os modelos utilizados e
estudados em sala de aula para identificar qual o mais adequado para o projeto aplicado.

2
Descrevam o que será feito em cada etapa do ciclo e os papéis da engenharia de software
utilizado.

4. Identificação das Necessidades


4.1 Técnicas Escolhidas
Descrever como funcionam as técnicas escolhidas para elicitação de requisitos (usar pelo
menos duas técnicas). Indicar porque estas técnicas foram escolhidas.
4.2 Aplicação das Técnicas
Documentar o uso das técnicas. Colocar os artefatos aplicados/preparados.

Figura 1. Exemplo de Artefato utilizado com a técnica proposta Commented [JDR2]: atualizar

4.3 Resultados Obtidos


Descrever como foi feita a análise dos resultados e como se chegou em um conjunto
inicial de requisitos do sistema.
Listar pelo menos 10 requisitos funcionais do Sistema. Commented [jr3]: Colocar os requisitos conforme template

Tabela 1. Requisitos Funcionais do Sistema

Código Descrição Prioridade


RF01 O sistema deve... Escolher uma das
opções: importante,
essencial ou desejável
RF02 O Sistema deve permitir incluir, editar dados de Escolher uma das
médicos profissionais, tais como: CRM, nome e opções: importante,
endereço essencial ou desejável

3
Listar pelo menos 5 requisitos não funcionais do Sistema. Commented [jr4]: Colocar os requisitos já revisados do trabalho
da 1ARE
Tabela 2. Requisitos Não-Funcionais do Sistema
Trazer a lista do Capítulo 3 para essa parte
Código Descrição Categoria Prioridade
RNF01 O sistema deve... Escolher uma das Escolher uma das
opções: usabilidade, opções: importante,
confiabilidade, essencial ou
segurança, desejável
desempenho,
implementação
RNF02 O sistema deve... Escolher uma das Escolher uma das
opções: usabilidade, opções: importante,
confiabilidade, essencial ou
segurança, desejável
desempenho,
implementação
RNF03 O software deve responder a Eficiência Essencial
qualquer requisição no
máximo em 5 segundos.

5. Documentação dos Atores do Sistema


5.1 Atores
Deve estar conforme os diagramas do sistema. Não existe limite de atores.
Tabela 3. Atores do Sistema

# Ator Definição
1 Nome do ator 1 Descrição do que ele fará no sistema.
2 Nome do ator 1 Descrição do que ele fará no sistema.
N Nome do ator N Descrição do que ele fará no sistema.

6. Processo de Desenvolvimento do Projeto


Definam um processo para as atividades realizadas para este trabalho. Descrevam as
atividades realizadas (semelhantes a atividade de definição de processo da dinâmica do
quebra-cabeça)
Detalhar pelo menos duas atividades do Processo conforme template definido em sala de
aula.
Tabela 4. Detalhamento da Atividade X

Nome

4
Descrição

Responsáveis

Participantes

Pré-atividade

Artefatos
Requeridos

Artefatos
Gerados

Ferramentas

Tabela 5. Detalhamento da Atividade Y

Nome

Descrição

Responsáveis

Participantes

Pré-atividade

Artefatos
Requeridos

5
Artefatos
Gerados

Ferramentas

Exemplo de Detalhamento de Atividade do Processo


Nome
Identificar/Entender Requisitos do Cliente e Requisitos do Software
Descrição
Identificar/entender os requisitos do cliente e requisitos funcionais e
não-funcionais do software...
Responsáveis Analista de Sistemas
Participantes Cliente
Pré-atividade -
Artefatos Solicitação de Serviço; Levantamento Requisitos; Proposta de
Requeridos Desenvolvimento; Proposta Técnica e Comercial;
Artefatos Gerados Levantamento de Requisitos; Modelo de Análise e Projeto; Ata de
reunião;
Ferramentas MS Word; Enterprise Architect

7. Conclusões
Resumir as lições aprendidas do trabalho. Explicar como os conceitos aprendidos podem
ser aplicados na vida de um profissional da ciência da computação ou sistema de
informação. Deve haver uma conclusão geral como grupo.
Além disso, cada aluno deverá ter um trecho identificado relatando sua percepção. Commented [JDR5]: Colocar em detalhes o que cada aluno fez
no trabalho.
7.1 Percepção do Aluno 1:
Os alunos podem colocar toda sua experiência (o que aprendeu, dificuldades...)

7.2 Percepção do Aluno 2:


....

8. Ata de Reunião

N. da Reunião: 1ª. Reunião


Data e horário 09/04/2018. Tarde (15h)

6
Tipo Presencial/whatsapp/skype
Participantes: João, Maria e José
Atividade: A equipe reuniu-se pela primeira vez para definir o aplicativo
que seria testado, os
usuários que passariam pelos testes e as tarefas que estes iriam
realizar. Além disso, foi discutido
como seria construído o relatório.

9. Referências
Listar as referências utilizadas no trabalho, aplicando o formato APA.
Exemplos:
Lee, K., Kang, K. C., & Lee, J. (2002, April). Concepts and guidelines of feature
modeling for product line software engineering. In International Conference on Software
Reuse (pp. 62-77). Springer, Berlin, Heidelberg.
Van Lamsweerde, A. (2009). Requirements engineering: From system goals to UML
models to software (Vol. 10). Chichester, UK: John Wiley & Sons.

Você também pode gostar