Descrição do trabalho

Projeto da Disciplina Processo de Engenharia de Software I
Parte 2: Especificação de Requisitos e Modelagem
Orientada a Objeto
Professor: Carlos José Maria Olguín
Data de Entrega:
Especificação de Requisitos e Modelagem
Orientada a Objeto
É esperado que vocês preparem a especificação de requisitos e análise
orientada a objetos para o projeto de um sistema de informação que esteja
relacionado com uma organização existente. Este projeto tem como objetivo
dar a você a prática na captura de informação e na análise de requisitos para
um sistema de informação organizacional. O projeto é para ser executado
pelas mesmas equipes do projeto da disciplina.
Passos para execução do Projeto
1. Identifique um problema dentro de uma organização existente.
2. Familiarize-se com o problema escolhido. Encontre o que a organização
faz agora, como ela funciona, quais sistema(s) de informação elas estão
usando, quais problemas eles estão tendo com o sistema existente, o que
elas estão tentando alcançar. Capture informações. Entreviste pessoas
chaves envolvidas no problema, ex.: peritos no domínio. Estude
documentos relacionados; observe e investigue.
3. Capture requisitos funcionais, não funcionais e organizacionais de um
sistema que poderia solucionar o problema que você está tratando.
4. Modele o sistema proposto usando as notações i* e NFR Framework,
Diagramas de Use Case e Diagramas de Classes.
5. Faça um trabalho escrito que liste os requisitos e discuta os diagramas e
artefatos que você tem produzido na sua análise. Escolha alguns dos
requisitos para expandir os use cases.
O que deve ser entregue
O sistema proposto deve incluir a seguinte informação:
1. Uma introdução descrevendo a organização que você escolheu para
estudar, o problema que você identificou, e o processo que você seguiu
durante seu estudo. (Não omita isso, pensando que o leitor tenha visto
seu relatório de estudo de viabilidade).
2. Os requisitos funcionais, não funcionais e organizacionais do sistema
de informação no domínio do problema. (Lembre-se de numerar todos
os requisitos desde que isso facilita o rastreamento quando você fizer o
projeto). As informações essenciais que devem ser consideradas na
descrição dos requisitos são: identificação, descrição textual do mesmo,
prioridade, solicitante.
3. Modelagem organizacional usando a notação i*: Deve incluir os
modelos de dependência estratégica e o modelo de razões estratégicas.
4. Modelagem de requisitos não funcionais usado o NFR Framework:
Deve mostrar os refinamentos dos requisitos não funcionais, explicitar
interdependências entre eles, mostrar operacionalizações.
5. Diagrama de Use Case: Deve incluir descrições textuais de todos os use
cases e um diagrama de use case mostrando o relacionamento estrutural
entre esses use cases e os atores que interagem com eles.
6. Diagrama de Classe: Seu diagrama deve incluir todas as classes e
relacionamentos identificados (incluindo generalização, associação,
agregação, etc. se apropriado), com atributos e operações atribuídas as
classes relevantes. Atributos e operações devem também serem
especificadas. Cada classe no seu Diagrama de Classe deve também ter
uma breve descrição textual incluída no seu trabalho. Além disso, o
diagrama de classe deve ser consistente com o Modelo de Use Case.
7. Uma conclusão que resuma o conteúdo de seu trabalho.
8. Um ou mais apêndices que os diagramas, dicionário de dados e outros
artefatos contenham, tais como entrevistas, revisões do material escrito,
detalhes da organização, nome e números da pessoas que você
entrevistou, detalhes de qualquer análise que você conduziu.
Requisitos para Apresentação
O trabalho que você entregar não deve exceder o tamanho de 25 páginas sobre
a análise de requisitos que foi conduzida (não contando referências, apêndices,
figuras e tabelas). Assuma que o relatório está sendo preparado para o
gerenciamento. Isso significa que você precisa ser claro e conciso, e que você
deveria apresentar as idéias básicas sem informações insignificantes.
Seu trabalho deve ser digitado no formato A4. (210 x 297mm). Figuras devem
ser claras e legíveis. Lembre-se de colocar uma página de capa indicando o
nome de todos os membros da equipe, título do trabalho, curso, data e nome
do instrutor. Entre outras coisas, os projetos serão julgados tanto pela
aparência visual, corretude gramatical e qualidade da escrita quanto pelos seus
conteúdos. O texto do seu projeto deve estar bem estruturado, usando
parágrafos com sentenças completas, e todas as outras características de uma
apresentação bem escrita. Tamanho da fonte de texto deve ser de 12 pontos.
Avaliação
A avaliação do projeto dependerá dos fatores e artefatos listados abaixo. Nem
todos os itens na lista são necessários ou igualmente importantes. A lista é
fornecida para lhe dar uma idéia de como o trabalho será avaliado em cada
categoria.

Identificação do Problema (10%) Quão bem você pesquisou o
problema, e o tipo de empresa que você está tratando através de
conversas com pessoas, leitura de documentos, etc. Artefatos (nem
todos são requeridos) que o avaliador pode avaliar:
1. sinopse
2. descrição de como o sistema é e seus problemas,
3. evidência de contatos com pessoas na organização,
4. evidência de leitura de documentos, formulários da companhia,
5. entrevistas, questionários, observações
6. gráfico da organização, gráfico da hierarquia gerencial.

Especificação de Requisitos (35%) Quão completo e bem organizado
está a apresentação dos requisitos? Pontos que o avaliador irá
considerar:
1. Os requisitos funcionais estão completos?
2. Eles estão bem numerados e bem organizados?
3. Os requisitos não funcionais (performance, operacionais,
plataforma e interface) estão completos?
4. Eles estão bem descritos e organizados usando o NFR
Framework?
5. Os requisitos organizacionais estão completos?
6. Eles estão bem descritos e organizados usando a notação i*?
Grade / Planilha de Avaliação
0-39%
40-49%
50-69%
Alguma
Todas as
tentativa
descrições de
Descrição válida foi
alto nível dos
pobre feita para
requisitos
Identificaç poucos
identificar
funcionais
ão dos
requisitos os requisitos
estão
requisitos funcionais funcionais.
documentada
funcionais são
Talvez
s. Talvez
identificado algumas
algumas
s.
falhas ou
estejam
omissões
impróprias.
séries.
i*
Descrição
pobre poucos
elementos
(atores,
objetivos,ta
refas,
recursos,
etc) são
identificado
s e
apropriados
. Modelos
(SD e SR)
Alguma
tentativa
Alguns
válida foi
elementos
feita na
estão
tentativa de
tratados.
descrever os
Talvez
modelos.
algumas
Talvez
dependências
algumas
estejam
falhas ou
impróprias.
omissões
séries.
70-79%
80 - 100%
Pes
o
Descrição
detalhada dos
Boa
requisitos
descrição
funcionais.
dos
Documentaçã
requisitos
5
o bem
funcionais
%
estruturada e
do sistema.
relacionament
Alguns erros
os
secundários.
consistentes
entre
requisitos.
Quase todos
elementos
relevantes
estão
incluídos e
adequadame
nte tratados.
Alguns erros
secundários
nos
modelos.
Descrição
detalhada dos
modelos e
tratamento
consistente
15
das
%
dependências
e
relacionament
os
incompletos
.
Descrição
pobre poucos
requisitos
não
funcionais
NFR
são
Framewor descritos.
k
Não mostra
as
operacional
izações e
interdepend
ências entre
eles.
Quase todos
os requisitos
Alguma
não
tentativa
Alguns
funcionais
válida foi requisitos
relevantes
feita para não
foram
descrever os funcionais
incluídos e
requisitos foram bem
refinados,
não
descritos .
com alguns
funcionais. Talvez
erros
Talvez
algumas
secundários.
algumas
operacionaliz
Poucas
falhas ou
ações estejam
interdependê
omissões
impróprias
ncias
sérias.
identificadas
.
Tratamento
exaustivo dos
requisitos não
funcionais,
identificação
de todos as
possíveis
15
interdependên
%
cias e
operacionaliza
ções,
decisões
consistentes e
bem
justificadas.

Evidências de suporte (45%) Refere-se a figuras, diagramas e
discussões que levam ao leitor acreditar que os requisitos que você tem
especificado são de fatos completos e apropriados para o sistema
proposto. Artefatos que o avaliador pode procurar são:

Diagrama de Use Case, incluindo versões de alto nível e versões
expandidas dos use case.

Diagrama de Classe.

Para todos os diagramas, inclua um relatório relevante derivado do
dicionário de dados.

Uma discussão desses artefatos e como eles se relacionam com os
requisitos.
.
Grade / Planilha de Avaliação
0-39%
Use Case
Seleção
40-49%
Alguma
50-69%
Todas as
70-79%
Quase toda
80 - 100%
Pes
o
20
pobre tentativa
poucos use válida foi
cases são
feita na
apropriados. identifica
ção dos
Use
Cases.
Talvez
algumas
falhas ou
omissões
séries.
Alguma
tentativa
válida foi
Seleção
feita na
pobre identifica
Identificaçã
poucos Use r classes.
o de Classes
Cases são Talvez
apropriados. algumas
falhas ou
omissões
séries.
Relacionam
entos de
classes
(generalizaç
ão,
associação,
composição,
etc)
Pouca ou
nenhuma
tentativa
para
mostrar os
relacioname
ntos, ou
realmente
não entende
Alguma
tentativa
válida foi
feita na
estruturaç
ão.
Talvez
algumas
falhas ou
descrições versão
de alto
expandida
nível foram relevante
documenta de use
das. Talvez cases estão
algumas
incluídas.
estejam
Alguma
impróprias. estruturaçã
o sensata
dos Use
Cases.
Alguns
erros
secundário
s.
Algumas
decisões
sensatas
foram
documenta
s.
Talvez
algumas
estejam
impróprias
Alguma
estruturaçã
o sensata.
Talvez
alguma
estruturaçã
o essencial
esteja
imprópria
Tratamento %
exaustivo
dos Use
Cases, toda
a versão
expandida
dos Use
Cases
incluída.
Todos os
relacionam
entos bem
estruturado
se
consistênci
a com os
requisitos
funcionais.
Quase
todas
Tratamento
decisões
exaustivo
relevantes
das
incluídas e
questões,
adequadam
10
completam
ente
%
ente
justificadas
consistente
. Alguns
e
erros
justificados
secundário
s.
Quase toda Todos os
estruturaçã relacionam
o foi bem entos foram
projetada. bem
10
Navegabili estruturado
%
dade
s.
completam Consistente
ente
com o
justificada. estudo de
a
omissões ou errada.
estruturação sérias.
Algum uso
de
navegabili
dade,
multiplicid
ade,
papéis, etc.
Alguma
tentativa
Seleção
Razoavelm
válida foi
pobre ente
feita, mas
poucos
completo.
apenas os
atributos e
Talvez
atributos
Atributos & operações
alguns são
e
Operações identificada
desnecessá
operações
s e alguns
rios,
mais
são
impróprios
óbvios
inapropriad
ou
são
os.
omitidos.
mostrado
s.

Inclui a
caso e bem
colocação justificado.
apropriada
de
multiplicid
ade,
papéis, etc.
Sensato e
completo.
Inclui
atributos
derivados,
tipos de
atributo e
assinatura
das
operações.
Todos os
relacionam
entos foram
bem
estruturado
s.
5%
Consistente
com o
estudo de
caso e bem
justificado.
Apresentação (10%): O estilo de sua apresentação, incluindo
linguagem, gramática, clareza da apresentação, organização dos
apêndices, etc.
o
5% - Linguagem (Dedução de 0.5% para cada erro ortográfico ou
erro gramatical até o máximo de 5%)
o
5% - Estilo e clareza (Dedução de 0.5% para cada figura sem
legenda ou ponto de confusão ou falta de elementos de estilo (por
exemplo, índice, paginação, introdução, conclusão, apêndices,
etc.).
------------------------------------------------------------------------------------------------------------Formulário do Relatório da Equipe
(deve ser submetido com tarefas)
Descrição de papéis e contribuições de cada membro
da equipe:
Nome
equipe
% Esforço da
Assinatura
____________________________________________________
____________________
____________________________________________________
____________________
____________________________________________________
____________________