Importância da modelagem de requisistos e a 50

Relação dessa área com demais áreas correlatas.

Possíveis estratégias de ação Resultados esperados 1

Funcionais 45
Tipos 44
Não Funcionais 46
Requisitos de Negócios 47 Requisitos 43
Requisitos de Usuários 48 Niveis de especificação
Requisitos Funcionais 49

Fundamentos 2 Aplicação 3
e Conceitos Notações 4
Estrutura 5 Exemplo de diagrama de casos de uso
Dimensões 6

Descobrir requisitos funcionais 8

Modelagem de Requisitos baseada Escalabilidade 9
em Cenários, Histórias de Usuário Utilização de Casos de Uso 7 Pontos Fortes
e Casos de Uso Simplicidade 10
Casos de Uso
Pontos Fracos 11

Dominio da Aplicação 24
Casos de uso de negócios 13
Objetivo 25 Casos de uso de tarefas 14
Definições fundamentais Tipos de Casos de Uso 12
Requisito 26 Casos de uso de baixo 15
Especificação 27 nível
Objetivos de Obtenção 28 Cenários 16 Cenários X Casos de uso 17 http://3.bp.blogspot.com/_8UAUN_oPgSU/SaoQ8dV9_fI/AAAAAAAAACc/ewA0O_AeILs/s1600-h/Cockburn_adornment.JPG

Objetivos de Término 29
Tipos de Objetivos
Objetivos de Manutenção 30
Objetivos de Não Ocorrência 31
Importância dos Objetivos na 23
Disjunção 33
Engenharia de Requisitos
Conjunção 34
Partterns de Refinamento objetivos Hierarquia de Objetivos 32
Marco 35
Baseado em Casos 36
Principais Utilizações 37
Elicitação 38
Definir objetivos 39

Especificações a partir de Imprecisão na especificação de objetivos / requisitos 19

Derivar requisitos 40
objetivos - Método Dificuldades e problemas 18 Diferentes Stakeholders com 20
Elaborar casos de uso
existentes na área necessidades diferentes e inconsistentes
Elaborar outros arterfatos da UML 41
Volatilidade 21
KAOS - Método a objetivos 42
Escopo 22
Notes
1) Resultados esperados
A expectativa com o resultado deste trabalho é ordenar conceitualmente a atividade descritiva do processo de descoberta de conhecimento,
em etapas sucessivas e complementares, alimentadas de forma recursiva. Especialmente, em promover o espírito crítico e a real
necessidade de se reforçar o domínio do conhecimento do ambiente em estudo e os requisitos. Com isto, além de documentar o processo
descritivo com o foco no problema, propiciar o preenchimento de uma lacuna na fase inicial de extração de requisitos, especificações e o
domínio do conhecimento que não é coberta em sua totalidade pelas metodologias e linguagens de modelagem.

Muitas técnicas auxiliam a documentação, entretanto, o uso adequado de uma ferramenta, não a qualifica como infalível nos critérios de
validação de requisitos de engenharia de software.

2) Fundamentos e Conceitos
Analistas tem dificuldades na decomposição e estruturação de casos de uso para a especificação de software. A modelagem baseada em
objetivos ajuda a guiar o desenvolvimento de casos de uso.

Casos de uso foram introduzidos por Jacobson como parte da metodologia de

desenvolvimento de software OOSE (Object-Oriented Software Engineering) (LARMAN, 2004).
Sua definição original é “Um caso de uso é uma maneira específica de usar um sistema
usando alguma parte da funcionalidade. Constitui um curso completo de interação que
acontece entre um ator e o sistema”.

Por definição, o termo “caso de uso”, introduzido nesta metodologia, não é sinônimo do termo “cenário”. Um cenário deve ser entendido
como uma instância específica de um caso de uso (SOMMERVILLE, 2008), ao passo que o caso de uso é uma coleção de cenários,
representando múltiplos caminhos.

3) Aplicação
Caso de uso é uma técnica de modelagem que pode ser aplicada a qualquer metodologia de desenvolvimento de software, estruturada, ou
OO. A semântica de um modelo de casos de uso relaciona-se fortemente com a de um modelo de objetos (VEODATO, 2003); porém, um
modelo de casos de uso não substitui um de objetos. O modelo de casos de uso é uma visão externa de um sistema; o modelo de objetos é
uma visão
interna do mesmo sistema.
Nos últimos anos, casos de uso têm recebido muita atenção na área de engenharia de requisitos, como meio para elicitar, documentar e
validar requisitos, no entanto, isto não significa que estão limitados a engenharia de requisitos (VEODATO, 2003); eles podem ser usados
ao longo de todo o ciclo de vida do desenvolvimento do software.
Casos de uso são utilizados para diversas finalidades, entre as quais:

Estruturar complexos modelos de objetos, em visões manejáveis;

Capturar, documentar e validar requisitos funcionais de sistemas;

Gerenciar a complexidade de desenvolvimento, focando um aspecto distintopor vez;

Compreender e estabelecer o comportamento desejado do sistema;

Ganhar percepção sobre modelos alternativos de software;

Fornecer uma descrição consistente e clara sobre as responsabilidades a serem cumpridas pelo sistema, funcionando como uma espécie
de contrato;

Facilitar a comunicação entre os envolvidos no desenvolvimento do sistema;

Envolver usuários no desenvolvimento de software;

Verificar e validar a arquitetura de sistemas;

Realizar testes de sistemas;

Servir como fonte para construção de manuais;

Derivar modelos conceituais;

Reengenharia de software.

4) Notações
Existe uma grande variedade de estilos para escrever o conteúdo narrativo de um caso de uso. A abordagem original de casos de uso,
proposta por Jacobson e, posteriormente, adotada na UML, não define precisamente nenhum formato ou template específico para descrever
o conteúdo de um caso de uso. Originalmente, casos de uso
não possuem notação formal; eles são representados na forma de narrativa textual
contínua.
Os problemas deste estilo de narrativa são numerosos. Não há nenhuma separação
clara entre o lado do usuário e o do sistema. A narrativa mistura exigências internas e
externas e salta irregularmente entre perspectivas internas e externas. Os elementos
essenciais à natureza do problema são misturados com decisões de projeto, e a falta de
estrutura força o leitor a seguir o texto inteiro apenas para obter uma idéia geral do caso
de uso [COCKBURN, 2001].
Um outro estilo comum para representar casos de uso é a seqüência numerada; nele, a narrativa é escrita como uma série de etapas
numeradas.

Uma vantagem deste estilo é evidente: a separação em etapas distintas facilita a

leitura do caso de uso para a obtenção de uma visão geral. Todavia, sofre muito dos mesmos problemas do estilo narrativo contínuo.
Apesar da segmentação em etapas discretas, as etapas individuais mesclam ações do sistema e do usuário.
Ambos os estilos de narrativa, textual contínua e seqüência numerada, apresentam abundância de palavras. Devido ao fato de não
possuírem quase nenhuma estrutura, esses estilos de narrativa requerem, para clareza, que a perspectiva seja repetidamente declarada - o
sistema faz isto, o usuário escolhe isso, o sistema termina algo mais -, o que contribui para suas loquacidades. Mesmo assim, o limite entre
o que está dentro do sistema e o que está fora não está explicito e, somente, poderá ser discernido através de uma leitura cuidadosa da
narrativa inteira (COCKBURN, 2001).
A solução simples para isto, é separar completamente da interação o lado do
usuário e o do sistema. Para casos de uso, esta separação foi originalmente sugerida por
Wirfs-Brock, sendo criado o estilo de narrativa com partição (COCKBURN, 2001). Neste
estilo, a narrativa de casos de uso é dividida em duas colunas: ação do usuário e resposta do sistema. Assim, o limite das perspectivas
internas e externas torna-se óbvio e explícito, sem repetição desnecessária.

Casos de uso podem ainda ser representados por pseudocódigos. Embora tais expressões pareçam oferecer precisão e possam ser
confortáveis e familiares aos engenheiros de software, elas, raramente, são compreensíveis aos usuários comuns (COCKBURN, 2001).

5) Estrutura
Em adição aos de casos de uso, Jacobson também introduziu um modo de representá-los graficamente: o diagrama de casos de uso, o qual
também é parte integrante da UML.
Um diagrama de caso de uso exibe uma coleção de casos de uso, atores e seus relacionamentos. Essa notação permite visualizar um caso
de uso em separado de sua realização e no contexto com outros casos de uso (PRESSMAN, 2006).
Graficamente, um caso de uso é representado por uma elipse com linhas contínuas, incluindo um nome que o diferencia dos demais; um
ator é representado por uma figura esquematizada, um “boneco de palitos”; e as associações entre atores e casos de uso são
representadas por linhas. O escopo do sistema é explicitado por uma caixa
que envolve os casos de uso. A figura 1 mostra um exemplo de diagrama de caso de uso.

Diagramas de caso de uso fornecem um modo de descrever a visão externa do sistema e suas interações com o mundo exterior,
representando uma visão de alto nível de funcionalidade intencional, mediante o recebimento de um tipo de requisição de usuário
(FOWLER, 2000). Esses diagramas definem a total funcionalidade do sistema e são importantes principalmente, para organização e
modelagem de comportamento do
sistema (VEDOATO, 2003).

6) Dimensões
Em (VEDOATO, 2003), encontra-se um estudo onde é apontado que as diversas
definições de casos de uso diferem sobre quatro dimensões:

Propósito: casos de uso podem ter o propósito de descrever histórias dos usuários ou especificar requisitos;

Conteúdo: o conteúdo de um caso de uso pode ser contraditório ou consistente; quando consistente, pode estar na forma de narrativa
textual ounotação formal;

Pluralidade: casos de uso podem ser apenas um cenário ou conter múltiplos cenários;

Estrutura: uma coleção de casos de uso pode ser representada através de umaestrutura formal, uma estrutura informal, ou, simplesmente,
através de um conjunto não estruturado.

7) Utilização de Casos de Uso

Casos de uso são um mecanismo simples compreensivel para capturar objetivos e requisitos de sistemas. Vistos de modo informal, eles são
narrativas que mostram como usar um sistema para atingir objetivos.

8) Descobrir requisitos funcionais

A essência dos casos de uso é descobrir e registrar requisitos funcionais, escrevendo narrativas de uso de um sistema que ajudem a
satisfazer os objetivos dos vários interessados.

9) Escalabilidade
Capacidade de escalabilidade para cima ou para baixo em termos de sofisticação ou formalidade, dependendo do que seja necessário.

Tipos de Formalidade:

resumido: resumo sucinto de um paragrafo, geralmente o cenário de sucesso principal.

informal: Multiplos paragráfos cobrem diversos cenários

completo: O mais elaborado. Todos os passos e variantes são escritos em detalhes e há seções de suporte.

10) Simplicidade
O casos de usos tem o propósito de especificar requisitos, com o conteúdo na forma de uma narrativa textual consistente, contendo
múltiplos cenários e possuindo uma estrutura semiformal

11) Pontos Fracos

A definição original de casos de uso proposta por Jacobson e, posteriormente, adotada na UML, tem o propósito de especificar requisitos,
com o
conteúdo na forma de uma narrativa textual consistente, contendo múltiplos cenários e
possuindo uma estrutura semiformal.Entretanto, o conceito de casos de uso ainda é vago e confuso, e existem vários aspectos
problemáticos que precisam ser tratados. Abordagens apontam que casos de uso apresentam problemas conceituais, alguns deles são
destacados e mostrados a seguir (VEODATO, 2003):

Notação e conteúdo: O que exatamente casos de uso contém? Como sãoorganizados os conteúdos? O que significam os conteúdos?

Expressões idiomáticas: Qual linguagem é usada para expressar os conteúdosque definem um caso de uso?

Granularidade: O tamanho e o nível de detalhamento de cada caso de uso éescolhido arbitrariamente?

Cobertura: Casos de uso podem garantir apenas uma cobertura parcial de todos possíveis usos do sistema?

Contexto: Casos de uso ocorrem sobre quaisquer situações ou sobre condições específicas?

Interseção: Casos de uso são independentes ou podem sobrepor-se total ouparcialmente? Como modelar os relacionamentos?

Concorrência: Como modelar as concorrências internas e entre casos de uso?

12) Tipos de Casos de Uso

Reconhecemos três tipos comuns de casos de uso, com base em seus atores e no uso de declarações de especificação ( Larman, 2004)

13) Casos de uso de negócios

Casos de uso de negócios incluem atores de múltiplas organizações, com o foco no fluxo de informações entre as organizações. Cada
declaração no caso de uso é um objetivo ou um requisito, conforme definido na introdução. Um caso de uso de workflow inter-organizacional
é um exemplo típico.

14) Casos de uso de tarefas

Casos de uso de tarefa incluem atores de uma única organização, com o foco no estabelecimento do processamento de informação
necessário para fornecer valor aos atores. Cada declaração no caso de uso ou é um objetivo ou um requisito. Um caso de uso de interface
do usuário é um exemplo típico.

15) Casos de uso de baixo nível

Casos de uso de baixo nível resultam da decomposição ou organização de casos de uso de tarefa; as declarações desse caso de uso  são 
especificações, na medida em que se referem a propriedades do sistema e não a propriedades do domínio. Um caso de uso de serviço do
sistema, como persistência de dados, é exemplo típico.

16) Cenários
É uma sequencia especifica de ações e interações entre atores e o sistema em discussão, é também chamado de instância de casos de
uso. É uma história particular de uso do sistema ou de um caminho por meio do caso de uso.

17) Cenários X Casos de uso

Fazendo uso do conceito de níveis de abstração e partindo do enfoque de cenários serem instâncias concretas de casos de uso, podem-se
combinar os propósitos e usos complementares de ambas as técnicas. De fato, cenários têm sido utilizados com uma base comum entre
diferentes tipos de modelagem. Um método de construção que
integrasse as duas técnicas seria útil; pois permitiria uma busca integrada da qualidade
interna e externa dos sistemas e, conseqüentemente, o desenvolvimento de sistemas interativos úteis e usáveis.
A integração destes conceitos às metodologias de desenvolvimento de software é também um importante aspecto a ser considerado. Em
alguns casos, os conceitos são usados informalmente; em outros, fazem parte do processo de desenvolvimento; e, num ponto de destaque,
quando suas potencialidades são exploradas mais efetivamente, são eles utilizados ao longo de todo o ciclo de vida do software, guiando o
processo de desenvolvimento.
Todavia, não se podem representar através de casos de uso todos os requisitos de um sistema. Casos de uso são mais adequados para
representar os requisitos comportamentais e os requisitos funcionais. Demais requisitos não funcionais (RNFs), como formato de dados,
requisitos de performance, regras de negócio e fórmulas complexas, devem ser representados em outros formatos. Porém, casos de uso
funcionam como uma estrutura central capaz de conectar vários tipos de requisitos, podendo ser ligadas a casos de uso informações
associativas. Utilizando a metáfora da roda na figura 2, considera-se casos de uso como o eixo de uma roda que conecta outras
informações, associadas aos raios, levando a diferentes direções (COCKBURN, 2001).
Esta é uma das razões pelas quais muitos consideram casos de uso como o elemento
central na engenharia de requisitos e no processo de desenvolvimento, como um todo.
 

18) Dificuldades e problemas existentes na área

O engenheiro de requisitos deve gerenciar os seguintes problemas:

administração de conflitos de interesses e de poder;

definição do que é prioritário no interesse da organização;

delimitação da fronteira de aplicação da solução;

conhecimento do universo de stakeholder atual e futuro;

gerenciamento continuado da dinâmica dos requisitos para alinhamento às mudanças organizacionais;

restrições de recursos de produção quer sejam humanos, financeiros ou tecnológicos?

19) Imprecisão na especificação de objetivos / requisitos

A imprecisão na especificação de requisitos é o motivo de muitos problemas de engenharia de software. É natural que um desenvolvedor de
sistema interprete um requisito ambiguo de modo a simplificar sua implementação. Frequentemente, no entanto, isso não é o que o cliente
quer. Novos requisitos precisam ser definidos e mudanças devem ser feitas no sistema. Naturalmente isso atrasas a entrega do sistema e
aumenta os custos do projeto (LARMAN).

Em princípio, a especificação de requisitos de um sistema deve ser completa e consistente. Completeza siginifica que todos os serviços
exigidos pelo usuário devem ser definidos. Consistência siginifica que os requisitos não devem ter definições contraditórias. Na prática, em
sistemas grandes e complexos, é praticamente impossível atingir a consistência e a completeza de requisitos (SOMMERVILLE).

20) Diferentes Stakeholders com necessidades diferentes e inconsistentes

O universo de pessoas envolvidas no processo produtivo, também denominado stakeholder abrange aqueles que, direta ou indiretamente,
influenciam ou são afetados pelo software. Ou seja, o pessoal envolvido com os processos de definição, criação, desenvolvimento,
gerenciamento, comercialização, bem como o pessoal identificado como cliente e usuário demandante do produto ou simplesmente
qualquer usuário compulsório.

É fácil cometer erros e omissões quando se redigem especificações para sistemas grandes e complexos. Outra razão é que diferentes
stakeholders no sistema tem diferentes e inconsistentes necessidades. Essas inconsistências podem não ser obvias quando os requisitos
são especificados inicialmente, de modo que requisitos inconsistentes sejam incluídos na especificação (SOMMERVILLE).

É evidente que satisfazer necessidades ou desejos vai depender da vontade de solução do problema pelo demandante. Nem sempre o
produto resultante é um novo software. Pode simplesmente ser uma característica adicional, uma substituição para uma versão mais eficaz
da solução existente. O software produto com certeza deve ser adequado à demanda de quem irá utilizá-lo.

21) Volatilidade
O cliente vive em um ambiente de contínuas mudanças, que podem ser traduzidas em oportunidades de negócios ou agregação de novos
problemas e restrições. Portanto, a solução de software atual nem sempre estará adequada a demandas futuras. Conseqüentemente, a
mudança será inevitável.

22) Escopo
As restrições são limitações que delineiam o espaço de solução do problema. As mais comuns referem-se às limitações para o
conhecimento e acesso ao universo de fonte de informação, atual e o potencial futuro.

Um dos fatores restritivos mais complexos é que a solução de negócio passa muitas vezes por uma necessidade de novos procedimentos
de trabalho, de reestruturação organizacional e por mudanças no relacionamento entre clientes e fornecedores.

23) Importância dos Objetivos na Engenharia de Requisitos

Objetivos estimulam a elaboração de requisitos na medida que fornecem uma justificativa para o requisito, ou seja, um requisito existe
devido a algum objetivo subjacente (ROBISON).

Objetivos estimulam a elaboração de requisitos sendo a sua base além de que proporcionam um critério para a integralidade da
especificação dos requisitos -  a especificação é completa se todos os objetivos declarados são obtidos pela especificação

Os objetivos fornecem uma justificação para a exigência de requisitos - um requisito existe devido a algum objetivo subjacente que fornece
uma base para o mesmo e ainda representam as raízes para a detecção de conflitos entre requisitos e para a resolução  eventual dos
mesmos.

Em resumo, requisitos "implementam" objetivos da mesma forma como programas implementam especificações de projeto (design).

24) Dominio da Aplicação

Em cada atividade de desenvolvimento de software, o contexto do problema tem, ao menos, dois domínios distintos: o domínio da aplicação
(o ambiente ou o mundo real ou matéria julgada) e o software. O domínio da aplicação é onde os requisitos do cliente existem; o software
sustenta uma solução para o problema por interação em alguns caminhos com o domínio da aplicação. Pode-se pensar do domínio da
aplicação como o que é dado e o domínio do software como o que será construído (SOMMERVILLE, 2006).

A aplicação das técnicas de descrição são evidenciadas no detalhamento do domínio da aplicação ou ambiente, nos requisitos e nas
especificações de interface ambiente x software e nos programas de software.

25) Objetivo
Propriedade desejada do ambiente. Objetivos estimulam a elaboração de requisitos sendo sua base. A especificação é completa se todos
os objetivos declarados são obtidos pela especificação.

Um requisito existe devido a algum objetivo que fornece a base para o mesmo, tanto que requisito é uma condição ou capacidade
necessária para um cliente resolver um problema ou realizar um objetivo;

26) Requisito
Requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais. Esses requisitos refletem
as necessidades dos clientes de um sisteman que ajuda a resolver algum problema.

A engenharia de requisitos fornece oi mecanismo apropriado para entender o que o cliente deseja, analisando as necessidades,
especificando a solução de modo não ambíguo, validando a especificação e gerindo os requisitos à medida que eles são transformados em
um sistema.

27) Especificação
As especificações dos fenômenos de interface entre o domínio da aplicação e o sistema de software referem-se aos procedimentos de
entrada de informações para o software e aos resultados processados pelo software.

É um tipo especial de requisito que tem somente a ver com as propriedades do sistema.

Especificação é uma propriedade, dirigida a ser implementável para suportar a satisfação do requisito.

A terminologia de desenvolvimento de software não é padronizada e o conceito de especificação é um dos elementos que fazem parte do
universo do contexto da engenharia de software. Dentre eles o (PRESSMAN, 2006) selecionou a que mais se aproxima e restringe a forma
de pensar.

Especificações são coisas difíceis. Embora sejam requisitos de um tipo, podem não serem vistas para fazer sentido óbvio no ambiente. Isto
porque são derivados dos requisitos do cliente por um número de passos de raciocínio. Especificações representam a resposta das
questões:

Qual comportamento que a especificação de interface poder produzir os efeitos que são requeridos no ambiente?

O que poderá a máquina requerer para produzir uma saída particular em resposta a determinada entrada?

Qual comportamento para a especificação de interface deve o programa produzir?...

28) Objetivos de Obtenção

Objetivos de Obtenção requerem que algumas propriedades nem sempre prevalecem, por exemplo, "Somente depois da entrega de um
pedido, o sistema envia uma fatura para o cliente"

29) Objetivos de Término

Objetivos de Término requerem que algumas propriedades  eventualmente não prevaleçam, por exemplo, "Depois que uma conta devida
seja paga na sua totalidade, o sistema deve parar de enviar notificações de cobranças ao cliente."

30) Objetivos de Manutenção

Objetivos de Manutenção requerem  que alguma propriedade sempre prevaleça, por exemplo, "O sistema deve sempre registrar o nível
atual de estoque de  cada produto."
31) Objetivos de Não Ocorrência
Objetivos de Não Ocorrência requerem que algumas propriedades nunca ocorram, por exemplo, "Um usuário não autorizado nunca deve
acessar qualquer conta de um cliente."

32) Hierarquia de Objetivos

Em softwares grandes e complexos existem muitos objetivos que se relacionam uns comos outros resultando em uma hierarquia
estruturada de objetivos.

Na hierarquia o objetivo mais abstrato é mostrado na parte superior e os objetivos mais especificos são obtidos em refinamentos do objetivo
mais geral, sendo que os subobjetivos devem ser satisfeitos como meio para cumprir um objetivo.

33) Disjunção
Simplemente especifica alternativas para satisfazer um objetivo

34) Conjunção
Detalha a descrição de um objetivo

35) Marco
Decompõem o que se obtém num conjunto de etapas intermediárias, a soma das quais satisfazem o objetivo global.

36) Baseado em Casos

Detalha o resultado num conjunto de casos, que se somam para satisfazer o objetivo total.

37) Principais Utilizações

Cockburn é frequentemente citado como tendo introduzido objetivos  na análise orientada a objeto (Cockburn 1997). Ele define casos de
uso para satisfazer os objetivos: Ele vê  cinco possibilidades para o uso de objetivos:

(1) atribuir requisitos não-funcionais a objetivos

(2) acompanhar o projeto pelos objetivos

(3) obter  requisitos diferentes  a partir do não alcance dos objetivos

(4) utilização objetivos associados a design das suas realizações

(5) casar objetivos do usuário com conceitos operacionais.

Mais recentemente, Bock demonstrou  como objetivos podem auxiliar na escolha de parâmetros a partir de  modelos de objeto (Bock 2001).

38) Elicitação
Os analistas trabalham com os clientes e usuários finais do sistema para aprender sobre o dominio da aplicação, quais serviços o sistema
deve oferecer, o desempenho esperado do sistema, restrições de hardware etc...

As informações podem ser obtidas pela utilização de diversas tecnicas, como entrevistas, coleta de documentos etc...

39) Definir objetivos

Proporcionam descrições de alto nível, funcionais e não funcionais, descrições compreensiveis do que o sistema deve fazer, sem a
complexidade de descrever como o sistema funciona.

40) Derivar requisitos

Os analistas definem as propriedades desejadas do ambiente, ou objetivos, baseados nas necessidades dos stakeholders. Sendo
definições baseadas no ambiente, os objetivos, não limitam  explicitamente o comportamento do software; que é a função dos requisitos. Os
analistas detalham os objetivos, adicionando detalhes, informações, que por sua vez restringem  o software. Assim, os requisitos  podem ser
derivados dos objetivos por refinamento.

41) Elaborar outros arterfatos da UML

Construir de acordo com as necessidades outros componentes da UML a partir dos casos de uso elaborados.

Podem ser utilizados qualque um dos diagramas disponiveis na UML, como, diagramas de sequencia, de colaboração etc...

42) KAOS - Método a objetivos

Definimos  um método para obter especificações de UML a partir de objetivos. O método é uma síntese dos  métodos comuns com UML,
tais como o Rational Unified Process [Kruchten 2000], e os métodos de análise de requisitos orientados a objetivos, tais como KAOS
[Dardenne 1993]. O método consiste em cinco atividades:

1. Elicitar o contexto do sistema. Informações sobre o sistema proposto, e de seu contexto, são adquiridos por meio de entrevistas, coleta de
documentos, observação, etc
2. Definir os objetivos do sistema. Baseado no contexto do sistema,  um analista define os objetivos do sistema.
3. Derivar requisitos. Objetivos  são refinados ao nivel de requisitos.
4. Derivar casos de uso. Casos de uso organizacionais, de sistema e de baixo nível  são derivados a partir dos requisitos.
5. Derivar modelos UML. Outros modelos UML, tais diagramas de classe e seqüência, são derivados dos requisitos  ou casos de uso

43) Requisitos
Engenharia de Requisitos é um amplo campo de pesquisa para a Engenharia de Software. Como área específica de atuação, apresenta
avanços tecnológicos e meios próprios voltados para pesquisa em terminologia, métodos, linguagens e ferramentas que compõem o esforço
de pôr em prática o campo de conhecimento gerado

Talvez o maior problema que enfrentamos no desenvolvimento de sistemas desoftware grandes e complexos seja o da engenharia de
requisitos. Ela está relacionada com a definição do que o sistema deve fazer, suas propriedades emergentes desejáveis e essenciais e as
restrições quanto à operação do sistema e quanto aos processos de desenvolvimento de software. A engenharia de requisitos é, portanto, o
processo de comunicação entre os clientes e os usuários de software e os desenvolvedores de software (SOMMERVILLE).

O domínio do problema é, portanto, o ambiente de atuação do software. Neste ambiente principiam as atividades da engenharia de
software, a definição das necessidades do software. É tarefa dos engenheiros de requisitos entender o problema, na cultura e linguagem
dos
usuários, e definir um sistema que atenda às suas necessidades [LARMAN]. Para tal, o engenheiro
de requisitos deve descobrir e estabelecer o universo de informações, de onde obtém os recursos na tarefa de elucidação do problema.

Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e suas restrições operacionais. Esses requisitos refletem
as necessidades dos clientes de um sistema que ajuda a resolver algum problema (PRESSMAN).

Requisitos são capacidades e condições às quais o sistema ou projeto deve atender. Um desafio básico de determinar os requisitos é
encontrar,comunicar e registrar o que realmente é necessário, expressando isso de forma clara para o cliente e os membros da equipe
dedesenvolvimeto.(LARMAN)

A modelagem de requisitos não é somente um processo técnico. Os requisitos do sistema são influenciados pelas preferências, recusas e
preconceitos dos usuários, além das questões politicas e organizacionais. Esses fatores são caracteristicas humanas fundamentais e novas
tecnologias, como casos de uso, cenários e métodos formais, não nos ajudam muito na resolução desses difíceis problemas
(SOMMERVILLE).

Conhecer sobre o que trata o assunto em questão e quais os fenômenos presentes no ambiente são as condições fundamentais para a
descrição de requisitos. Portanto, é necessário:

conhecer o domínio da aplicação, o ambiente onde os requisitos dos clientes são encontrados, a definição do alvo do problema e a
abrangência do domínio da solução;

identificar o problema a resolver, promovendo o entendimento, a especialização e o domínio do conhecimento, compreendendo: o quê, com
quê, para quê e para quem;

delimitar o contexto do negócio do cliente, estabelecendo objetivos, dominando assuntos organizacionais, fatores políticos, conflitos de
poder, relações de influência, entendendo o histórico e estrutura organizacional e a organização do conhecimento acerca da organização;

identificar qual o universo de fonte de informação (stakeholder);

identificar as exigências e condições para satisfação das necessidades ou desejos do ponto de vista dos stakeholder;

validar as informações obtidas e o relacionamento entre elas e compatibilizar idéias;

administrar, revisar e negociar conflitos de interesse no atendimento às necessidades;

priorizar a demanda pela solução dos problemas;

planejar a ordem de implementação e compatibilizar emergência de requisitos;

documentar os requisitos, com recuperação acessível do ciclo de vida;

aperfeiçoar o processo de comunicação;

gerenciar as mudanças nos requisitos.

44) Tipos
Os requisitos de sistema de software são, frequentemente classificados em requisitos funcionais e requisitos não funcionais apesar de que
alguns autores desaprovam essa generalização ampla, mas ela é bastante usada.

45) Funcionais
Requisitos funcionais são declarações de serviços que o sistema deve fornecer,como o sistema deve reagir a entrada especificas e como o
sistema deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem também estabelecer
explicitamente o que o sistema não deve fazer.

Os requisitos funcionias são comumentes explorados e registrados no modelo de casos de uso.

46) Não Funcionais

São restrições sobre os serviços ou as funções oferecidos pelo sistema. Os requisitos não funcionais estão raramente associados às
caracteristicas individuais do sitema. Pelo contrário, esses requisitos especificam ou restringem as propriedades emergentes de sistema.
Portanto podem especificar desempenho, segurança, disponibilidade e outras propriedades.

Isso significa que os requisitos não funcionais geralmente são mais importantes do que os requisitos funcionais individuais. Os usuários do
sistema em geral encontram meios de contornar uma função do sistema que não atenda suas necessidades. Contudo, uma falha no
atendimento de um requisito não funcional pode significar que todo o sistema é inutil.

47) Requisitos de Negócios

Os requisitos do negócio identificam os benefício primários que o sistema proverá aos clientes. São objetivos de alto nível ou requisições do
cliente para o sistema de software.

48) Requisitos de Usuários

 

Os requisitos do usuário são tarefas que os usuários serão habilitados a realizar com o sistema de software. Em geral, são capturados
segundo abordagens de casos de uso e descrição de cenários

49) Requisitos Funcionais

Os requisitos funcionais definem a funcionalidade que o software deve prover a fim de capacitar os usuários a realizar suas tarefas,
satisfazendo os requisitos do negócio.

50) Importância da modelagem de requisistos e a Relação dessa área com

demais áreas correlatas.
Segundo pesquisa do Standish Group, as razões principais que levam a problemas de projeto são identificadas na tabela abaixo:
Fatores de Projetos Críticos
% de Respostas

1. Falta de Especificação do Usuário

12.8%

2. Requisitos Incompletos

12.3%

3. Mudança de Requisitos

11.8%

4. Falta de Apoio Executivo

7.5%

5. Tecnologia Imatura

7.0%

6. Falta de Recursos

6.4%

7. Expectativas irreais

5.9%

8. Objetivos obscuros

5.3%

9. Tempo irreal

4.3%

10. Tecnologia nova

3.7%

11. Outros

23.0%

Juntando com os dados de projetos da Força Aérea Americana sobre o levantamento da fonte de erro por fase do ciclo de vida do software,
relatados no gráfico abaixo:

Avaliando os dados da tabela das razões principais de problemas de projeto com o gráfico de fonte de erro por fase do ciclo de vida, sob o
foco do quadro abaixo de custo relativo de reparo por fase do ciclo de vida, originado por estudos independentes das empresas GTE, TRW
e IBM em meados da década de 1970 [1];

Podemos concluir que identificar um erro na fase de manutenção tem um custo relativo 200 vezes maior em relação à descoberta do
mesmo erro na fase de análise de requisitos, a etapa inicial do ciclo de vida. Devemos, então, orientar nossos esforços na definição e
melhoramento contínuo de processos formais a serem executados durante esta fase, como forma de aumentarmos a qualidade do software
desenvolvido, bem como, minimizar o custo deste desenvolvimento.

No final da década de 80, com a incumbência de definir processos formais para orientar o estudo da descoberta do problema e do
levantamento dos requisitos do software a ser construído, surgiu a engenharia de requisitos.

Muitos autores descrevem diferentes atividades para o cumprimento da fase inicial do ciclo de vida, conhecida como análise de requisitos.
Segundo Roger Pressman (PRESSMAN, 2009), as atividades a serem desenvolvidas são as seguintes:

Extração de requisitos – etapa onde os requisitos são descobertos através de consultas aos envolvidos, documentos, domínio do
conhecimento e estudos de mercado;

Análise e negociação – os requisitos são analisados em detalhe e recusados ou aceitos;

Documentação – onde os requisitos aceitos são documentados em um nível apropriado de detalhe;

Validação – os requisitos são checados cuidadosamente para verificação de consistência e completeza.

Gerenciamento – onde os requisitos são controlados em função da dinâmica das mudanças ambientais.

Como o mundo dos negócios está a cada dia mais ágil, mudanças nos requisitos são uma constante. Isto significa que o processo de
tratamento de requisitos é iterativo durante todo o ciclo de vida do software.

Após a etapa de validação dos requisitos, temos como resultado o documento formal dos requisitos, que passa a ser o acordo entre os
envolvidos no projeto e deve refletir as necessidades que o software deve atender. Este documento norteará todos os esforços das fases
seguintes do ciclo de vida. É por este motivo que requisitos bem definidos antes do início do projeto lógico podem evitar retrabalho,
minimizando custo e esforço de implementação.

A dificuldade de comunicação é o fator crucial dos problemas com requisitos. Uma citação que reflete este problema pode ser encontrada
no livro de Engenharia de Software de Roger Pressman (PRESSMAN, 2006), a seguir:

A contribuição fundamental para a pesquisa na área de engenharia de requisitos é a visão conceitual da descrição como arte e técnica no
descobrimento e na documentação do conhecimento e representação de requisitos. Deve ser utilizada extensiva e intensivamente até
exaurir possibilidades de dúvida e discordâncias e, especialmente, ambigüidades. A descrição é uma tarefa árdua, trabalhosa e complexa,
muitas vezes incompreendida por pessoas alheias ao processo de engenharia de software, especificamente o cliente contratante da solução
do problema, cuja expectativa de resultado é imediatista.

O processo de análise dos requisitos não deve ser uma fato posterior à extração de requisitos e sim concomitante. A ordem não é
representar, modelar, para depois ver para que serve e sim, descrever o mais detalhadamente possível os fenômenos do ambiente que
caracterizam o problema e, moldar uma solução de sistema de software com critérios de viabilidade de implementação, antes do início do
desenvolvimento do software.