Você está na página 1de 14

UNIVERSIDADE FEDERAL RURAL DO SEMI-

ÁRIDO
CAMPUS ANGICOS/RIO GRANDE DO NORTE
BSI
Componentes: Luan Diego Da Silva Nunes
Raissa Maira Souza Alcantara

MODELAGEM DE REQUISITOS: MÉTODOS


BASEADOS EM CENÁRIOS
SUMÁRIO
• Análise de requisitos ---------------------------3
• Filosofia e objetivos gerais ---------------------------4
• Regras praticas para análise --------------------------- 5
• Análise de domínio --------------------------- 6
• Abordagens de modelagem de requisitos --------------------------- 7
• Modelagem baseada em cenários --------------------------- 8
• criação DE UM CASO USO PRELIMINAR --------------------------- 9
• REFINAÇÃO DE UM CASO DE USO PRELIMINAR ----------------------10
• CRIAÇÃO DE UM CASO DE USO FORMAL --------------------------- 11
• MODELOS UML QUE COMPLEMENTAM O CASO DE USO --------- 12
• DESENVOLVIMENTO DE UM DIAGRAMA DE ATIVIDADES ---------13
• DIAGRAMAS DE RAIAS ----------------------------------------------------- 14
ANÁLISE DE REQUISITOS
• A análise de requisito ela nada mais é que a especifica as necessidades e características das operações do
Software, sendo a mesma principal responsável para coletar dados que o software deve atender determinadas
exigências de seus respectivos clientes. Permitindo também que tanto o engenheiro de Software como o Analista
ou modelador aumentem ainda mais seus conhecimentos durante o levantamento e negociação.

• As modelas podem ser divididas em um ou mais segmentos como: o Modelo baseado em cenários que é
uma coleção de situações do domínio do problema que possibilita a identificação de componentes de design, os
modelos orientados a classes que são a maneira como as classes colaboram entre si para atender os requisitos,
os modelos comportamentais baseados em padrões que são a representação de como o software deve funcionar
de acordos com acontecimentos externos, os modelos de dados que representam a competência em relação ao
domínio de informação para resolução de contratempos, modelos orientados a fluxos representam os elementos
funcionais do sistema e a transformação dos dados à medida que se locomovem pelo sistema.

• Os modelos são inerentes para o projetista do software pois dão informação necessárias para os projetos de
arquitetura, de interface e componentes, graças ao modelo de requisitos o desenvolvedor e o cliente por sua vez
conseguem verificar a qualidade do software programado.
FILOSOFIA E OBJETIVOS GERAIS

• A modelagem de requisito foca no “que” e não no “como” as coisas devem ser feitas, “Que interações
com os usuários devem ocorrem em dadas circunstancias”, “Quais objetos os sistemas manipulam”, “Que
funções o sistema necessitar executar”, “Quais comportamentos os sistemas devem ter para seu
funcionamento”, “Que interfaces são definidas e quais as limitações se aplicam ao mesmo”.

• Deve se levar em conta que o modelo de requisitos deve alcançar três objetivos que são essenciais são
eles, 1º descrever o que o cliente solicita que bastante precisão (Nem sempre o cliente vai saber o quer então
seu dever como desenvolvedor vai estudar a situação em como deixar o cliente satisfeito com o produto), 2º
estabelecer uma base para criação de projeto de software e 3º definir um conjunto de requisitos que possa ser
validado assim que o software estiver construído. O modelo de análise deve preencher uma incógnita entre
uma descrição sistêmica que descreve o sistema ou a funcionalidade de negócio que é atingida aplicando-se
software, hardware, dados pessoais e outros elementos de sistema.

• E valido ressaltar que todos os elementos do modelo de requisitos estão ligados a partes do modelo do
projeto. Nem sempre é possível constituir uma divisão certa das tarefas de análise e de projeto entre duas
importantes atividades de modelagem.
REGRAS PRATICAS PARA ANÁLISE

Arlow e Neustadt surgem com as regras que deveriam ser seguidas na criação do modelo de analise nas quais são:
• O modelo deve se concentrar nos requisitos visíveis no domínio do problema ou do negócio. O nível de abstração
deve ser relativamente elevado.
• Cada elemento do modelo de requisitos deve contribuir para o entendimento geral dos requisitos de software e
fornecer uma visão do domínio de informação, função e comportamento da sistema.
• Postergue considerações de infraestrutura e outras modelos não funcionais até a fase de projeto. Ou seja, talvez
seja preciso um banco de bandos, porém as classes necessárias para sua implementação, as funções
necessárias para acessar o banco de dados e o comportamento que será apresentado à medida que ele for
usado devem ser considerados apenas depois de a análise do domínio do problema ter sido concluída.
• Minimize o acoplamento do sistema. É importante representar as relações entre classes e funções. Entretanto, se
o nível de “interconexão” for extremamente alto, deve-se esforçar para reduzi-lo.
• Certifique-se de que o modelo de requisitos agrega valor para todos os envolvidos. Para cada participante tem
uso próprio para cada um uso próprio para cada modelo. Por exemplo, os envolvidos no negócio devem usar o
modelo para validar os requisitos; os projetista devem usar o modelo como base para o projeto; o pessoal da
Garantia da Qualidade deve usar o modelo para ajudar no planejamento de testes de aceitação.
• Mantenha o modelo o mais simples possível.. Não adicione diagramas quando não acrescentam nenhuma
informação nova. Não utilize formas de notação complexas quando uma lista simples já bastaria.
ANÁLISE DE DOMÍNIO
•Se os padrões são definidos e categorizados de maneira que permita seu reconhecimento e sua
aplicação para resolução de problemas habituais, a criação do melo de análise necessita ser mais precisa, e a
probabilidade de aplicação de padrões de projeto e de componentes de software executáveis cresce
exponencialmente. Isso melhora o tempo de colocação do produto no mercado e reduz os custos.

•O “domínio de aplicação especifico” pode ir da aviônica a sistemas bancários, de games a software


embarcado em equipamentos médicos. O objetivo da análise de domínio é clara: encontrar ou criar as classes
de análise ou padrões de análise amplamente aplicáveis de modo que possam ser reutilizados .
ABORDAGENS DE MODELAGEM DE REQUISITOS
•A análise estruturada considera necessariamente os dados e os processos que transformam os
dados como entidades separadas. Os objetos de dados são modelados de maneira a definir sues
atributos e relações. Processos que manipulam objetos de dados são modelados para mostrar como
transformam os dados com a medida que o objetos de dados vão por todo sistema.

•Outra abordagem da análise, chamada de análise orientada a objetos, concentra-se na definição de


classes e na maneira como colaboram entre si para entender a atender as necessidades impostas pelos
clientes a UML e o processo unificado são predominantemente orientados a objetos.
MODELAGEM BASEADA EM CENÁRIOS
• A modelagem de cenários têm vindo a ser usados ao longo do tempo em diversas áreas,
nomeadamente em interação homem computador, engenharia de requisitos, desenho
orientado a objetos, planejamento estratégicos, uma vez que facilitam bastante a criação e
utilização de casos de uso, de uma forma simples e flexível. A utilização desta aproximação
em engenharia de requisitos é baseada na hipótese de que a integração desta técnica permite
melhorar o processo de especificação de requisitos através de um maior envolvimento dos
utilizadores do mesmo. Esta técnica descreve os requisitos numa linguagem fácil de entender
e validar para todas as pessoas relacionadas com o projeto, motivando-as a discutir e
participar, obtendo assim um maior feedback sobre o que se está a fazer.
CRIAÇÃO DE UM CASO USO PRELIMINAR
• O caso de uso descreve um cenário de possível interação com um utilizador ou um outro sistema.
Devem ser os mais claros possíveis para que todos os eventuais leitores de diferentes campos
possam entendê-los de igual modo, devendo-se assim evitar os termos técnicos ou obscuros que
possam dificultar a compreensão inequívoca da funcionalidade descrita. Cada caso de uso deve
descrever somente uma funcionalidade ou objetivo do sistema. É então comum, para os sistemas
minimamente complexos, serem necessários muitos casos de uso para uma correta e completa
descrição de todas as funcionalidades requeridas pelo sistema.
REFINAÇÃO DE UM CASO DE USO
PRELIMINAR
• A descrição de interações alternativas é essencial para um completo entendimento da função
a ser descrita por um caso de uso, por exemplo; cada etapa no cenário primário é avaliada
fazendo-se as seguintes perguntas: • O ator pode fazer algo diferente neste ponto?
• sequências de ações alternativas ao desenvolver um caso de uso?
• • Existe a possibilidade de o ator encontrar alguma condição de erro neste ponto? Em caso
positivo, qual seria?
• • Existe a possibilidade de o ator encontrar algum outro tipo de comporta- mento neste ponto
(por exemplo, comportamento que é acionado por algum evento fora do controle do ator)?
Em caso positivo, qual seria?
• As respostas a essas perguntas levam à criação de um conjunto de cenários secundários
que fazem parte do caso de uso original, mas representam comportamento alternativos.
CRIAÇÃO DE UM CASO DE USO FORMAL
Ás vezes, os casos de uso informais apresentados são suficientes para a
modelagem de requisitos. Entretanto, quando um caso de uso envolve uma
atividade critica ou descreve um conjunto complexo de etapas com um
número significativo de exceções, daria uma abordagem mais formal aonde
seria mais desejável.
MODELOS UML QUE COMPLEMENTAM O
CASO DE USO
Ocorrem em diversas ocasiões da modelagem de requisito em que um modelo
baseado em texto, pode não entregar as informações de maneira precisa e
correta, nesses momentos o ideal é optar por uma vasta variedade de modelos
gráficos da UML.
DESENVOLVIMENTO DE UM DIAGRAMA DE
ATIVIDADES
• Assim como o fluxograma, um digrama de atividades utiliza de retângulos de cantos arredondados para a
representação da função do sistema, setas para representar o fluxo através do sistema, losangos de
decisão para representar a decisão com ramificação, e linhas horizontais indicam as atividades paralelas
que estão acontecendo, é valido ressaltar que o diagrama de atividade adiciona outros detalhes que não
são mencionados pelo caso de uso, um exemplo é disso é que um usuário ao tentar colocar seu login de
usuário e senha um numero limitado de vezes.
DIAGRAMAS DE RAIAS

• Um diagrama pista de natação é
um diagrama criado usando uma ou mais
pistas de natação, incluindo o conteúdo das
pistas. Por exemplo: Uma piscina é
composto de uma ou mais faixas de natação
combinadas como uma única forma
agrupada. Ou seja as raias podem ser
identificadas com rótulos de textos.