Minha Visão Sobre a Distinção Feita por Michael Jackson

Essa figura é minha interpretação da distinção entre "Problem Domain" (aqui chamado de Universo de Informações), "Requirements" (Requisitos) e "The Machine" (aqui como uma combinação de hardware e software).

Evolução do UdI

Modelo de Ações Concretas

Observe que as ações concretas ocorrem na Realidade (na organização) e que a Fábrica de Informações produz Saídas (aqui mostradas como $) com base em Entradas (E). O foco da figura é o processo inverso para descobrir o que a Fábrica de Informações deve produzir.

Definições

 

Forma Canônica

 

Sistema de Desenvolvimento de Software

 

Aulas -- 11, 12 e 13

---> Quem não entregou o trabalho final de ER, pode mandar o trabalho por correio
para o endereço jcspleite@yahoo.com com o título "Trabalho de ER". A aula de hoje (terçar-feira) foi cancelada!

----> Aluno(a)s: está havendo um desencontro. Estive duas vezes na sala e vocês não estavam lá. Espero-os no dia 30.

----> Recentemente disponibilizei um pré-livro sobre engenharia de requisitos. Dêem uma olhada aqui.

Aula 11

Nessa aula sobre modelagem falamos sobre a perspectiva intencional. Isso quer dizer que o modelador procura modelar a intencionalidade existente no Universo de Informações. Apresentamos duas linguagens distintas que são orientadas a metas.

A estratégia chamada de Esquema de Requisitos Não Funcionais, utiliza-se de um grafo com dois tipos de nodos: metas flexíveis e operacionalizações e de dois tipos de elos. O primeiro tipo de elo é o elo E/OU e o segundo é o elo de contribuições. Esse grafo é utilizado para que um requisito não funcional, representado por uma meta flexível, seja decomposto em partes, através de elos E/OU. Quando ao final da decomposição essas metas flexíveis são operacionalizadas, isto é transformadas em implementações abstratas dessas metas flexíveis, pode-se usar o elo de contribuição. O elo de contribuição pode ter os seguintes valores (--, - , nulo, +, ++). Esse tipo de elo caracteriza bem a característica de meta flexível, porque introduz o conceito de qualidade, expressa como um conjunto de possíveis 5 valores de gradação.

A Figura abaixo foi retirada da dissertação de Geórgia Maria Carvalho de Souza na Seção 5.2.3 que começa na página 131.




Maiores detalhes sobre o Esquema de Requisitos Não Funcionais podem ser encontrados no texto acima e na tese de doutorado de Luiz Marcio Cysneiros, especialmente na Seção 2.7 (página 37). Vale também ler a Seção 5.3.1 e 5.3.2 (página 85).


A segunda linguagem apresentada, o i*, promove a visão da intencionalidade distribuída. Para essa visão de modelagem o importante é além de identificar as metas, também identificar os atores que tem interesse ou responsabilidade de que as metas sejam alcançadas. Essa linguagem utiliza duas sub-linguagens ou diagramas para explicitar a intencionalidade distribuída.

A primeira sub-linguagem mapeia a intencionalidade distribuída entre os atores. Esta sub-linguagem produz o diagrama de dependências estratégicas. Esse diagrama utiliza o conceito de dependência (interesse/responsabilidade) para mostrar como os atores cooperam para que as metas sejam atingidas. Uma intencionalidade é chamada de elemento de dependência e está ligada a um interessado pelo elo dependente e a um responsável pelo elo de quem se depende. A intencionalidade distribuída pode ser expressa através de metas, metas flexíveis e também por recursos e tarefas. Os recursos e tarefas tornam-se elementos de intencionalidade na medida em que são necessários para que um dos atores alcance uma determinada meta.

Veja abaixo um exemplo de uso da sub-linguagem para dependências estratégicas. Esse exemplo foi retirado do artigo de Sayão e Leite apresentado no WER 05. Note que o o símbolo do D denota o elo do tipo de quem se depende e o D invertido denota o elo do tipo dependente.





Mais detalhes sobre a linguagem i* podem ser encontrados no Capítulo 2 da dissertação de Herbet de Souza Cunha (página 18).

---------------------------------------------------------------------------------

Aula 12

Nessa aula voltamos a falar sobre a diferença entre as tarefas de elicitação sem uso de uma perspectiva específica e da elicitação orientada a modelos, ou seja com uma perspectiva pré-selecionada. Ressaltamos que quando utiliza-se uma estratégia de modelagem como guia para a tarefa de elicitação estamos impondo uma perspectiva ao mundo que queremos conhecer. Isso pode ser útil em determinadas situações, mas pode levar a que uma série de conhecimentos do Universo de Informações deixe de ser capturado.

Por outro lado o uso de diferentes métodos de elicitação e suas técnicas, sem um comprometimento com uma perspectiva pré-selecionada permite com que o conhecimento a ser elicitado do Universo de Informações seja mais abrangente e sem o viés de uma perspectiva pré-selecionada. No entanto, esse tipo de elicitação é mais custoso e menos estruturado.

Vale lembrar que vimos diferentes perspectivas de modelagem:
a) perspectiva funcional: digrama de fluxo de dados, sadt, casos de uso, diagrama de atividades
b) perspectiva de dados: sadt, dicionário de dados, mer, digrama de classes
c) perspectiva de estados: statechart, máquinas de estado
d) perspectiva de atores: i*, casos de uso
e) perspectiva situacional: cenários
f) perspectiva intencional: i*, esquema de requisitos não funcionais.

Em algumas das linguagens de modelagem as perspectivas misturam-se como no caso de casos de uso (atores, funcional), i* (intencional, atores), cenários (situacional, atores, funcional, estados) e sadt (funcional, dados). Quanto mais perspectivas abraçar, mais complexa será a linguagem de modelagem.

Nessa aula apresentamos uma outra perspectiva a perspectiva ontológica, através de uma representação chamada de léxico ampliado da linguagem. Nessa perspectiva o importante é modelar a linguagem utilizada no Universo de Informações e não sua funcionalidade ou intencionalidade. O lema dessa perspectiva é “entenda a linguagem do problema antes de tentar entender o problema”.

Veja aqui e aqui material de apoio para o entendimento do LAL. Aproveite e faça você o seu léxico, utilizando o protótipo de editor de léxico.

-------------------------------------------------------------------------------------
Aula 13

Esta aula será sobre Análise. Entendemos análise no processo de definição de requisitos como composto de três atividades: identificação de partes, verificação e validação.

Nessa aula o tema principal é Inspeção. Inspeção foi uma técnica desenvolvida para verificação de programas fontes, mas é hoje utilizada em diferentes tipos de documentos. Leiam a Seção 3, página 6 do artigo “Scenario Inspections” e o artigo "Técnicas de Inspeção de Documentos de Requisitos de Software: Um Estudo Comparativo".

Aulas 11, 12 e 13

Desculpem. Por uma serie de razões o material ainda está no forno.
Desculpem por hoje. Eu estarei amanhã, Terça-Feira, de 18:30 às
19:30 na sala de SI para tirar dúvidas. O material deve estar
pronto amanhã.
Bom Pan!

Aula 10

Conforme ressaltamos em aula: a linguagem de modelagem impõe uma visão de mundo. Cabe ao modelador interpretar os fatos da realidade, oriundos da elicitação de requisitos, conforme as estruturas propostas pela linguagem de modelagem. Ou seja, a linguagem embute regras que orientam, mas cerceia a maneira como os fatos serão expressos no modelo.

Um excelente exemplo, que exercitamos em aula, é a seta de controle dos actigramas SADT. A idéia de que os controles influenciam a maneira como a atividade é conduzida é determinante para que possamos diferenciá-las da entrada. Lembre que nos actigramas a entrada é opcional e o controle é obrigatório. Vimos por exemplo que uma atividade “gerar” pode ter como controle o tamanho da lista e a política de geração, ao passo que a entrada seriam números e a saída uma lista de números. Enquanto o tamanho e a política de geração mantêm-se, os números podem ser entendidos como consumidos pela atividade.

Distinguir controle e entrada é uma das dificuldades que o modelador encontra na interpretação de fatos. No entanto, o entendimento da semântica da seta de controle, com a prática, leva a que o modelador diferencie entre essas duas perspectivas.

Falamos também de uma linguagem de modelagem chamada “cenários”. Vimos que a perspectiva utilizada por cenários é baseada na idéia de que o UdI é composto de um conjunto de situações, e um cenário descreve uma situação.

Vejam a descrição da linguagem de cenários usando a própria linguagem de cenários. Não deixem de ler o artigo que define a linguagem de cenários e o seu processo de construção. Nesse artigo o SADT é usado para descrever o processo de modelagem de cenários.

Aula 9

Nessa aula falamos do processo de modelagem. O resultado desse processo são modelos. A maneira como construímos esses modelos é função da linguagem que utilizamos para descrevê-lo. Vimos que cada modelo e sua linguagem de descrição apresentam uma determinada perspectiva de representação.

Lembrem da diferença entre: modelagem, modelo, linguagem e perspectiva.

Mostramos os exemplos do MER (modelo entidade relacionamento) que representa uma perspectiva de dado. Mostramos que o DFD (diagrama de fluxo de dados), apesar do nome é uma perspectiva de processo.

Mostramos ainda, nessa aula, que o SADT (structured analysis and design technique) é uma linguagem que é composta de duas perspectivas: dados (datagramas) e atividades (actigramas).

Desenhamos, juntos, um actigrama para representar o controle de uma biblioteca. Vimos a diferença entre a modelagem SADT e a modelagem DFD. Enfatizei o papel do controle e sua diferença da entrada. O SADT tem quatro tipos de setas: entrada, controle, saída e mecanismo. Lembramos, que o SDS, que vimos na aula 4, é um datagrama.

Em particular, enfatizamos que: o processo de modelagem, de certa maneira, impõe
uma forma de elicitação na medida que conduz o engenheiro de software para o “preenchimento” do modelo, segundo as regras lingüísticas (sintaxe e semântica) da linguagem de descrição do modelo.

No momento, indicarei o seguinte material (veja aqui), mas, na aula, fornecerei o material definitivo.

Aula 8

Nessa aula começamos a tratar de modelagem.

Modelos são fundamentais na definição de requisitos e muitas vezes são utilizados
como guias para a elicitação. .

São vários os tipos de modelos que vem sendo propostos para auxiliar o engenheiro de requisitos.

Hoje destaca-se o uso da UML. A UML é na verdade um conjunto de linguagens, capazes cada uma de prover um modelo com diferentes perspectivas. Falamos do caso de uso, do diagrama de classes (semelhante ao modelo Entidade Relacionamento), do diagrama de atividades e do diagrama de fluxo de dados. Sobre o DFD veja aqui.


Porque o DFD?

Quatro razões:

1) DFD expõe claramente o sentido de contexto.

2) DFD é uma linguagem relativamente simples.

3) É mais um exemplo da filosofia de sistemas (hierarquia - decomposição).

4) É orientada a fluxo — transformação e portanto serve como contraponto a linguagem do SADT (que veremos a seguir).

Vimos que a visão de fluxo - transformação proporcionou uma decomposição inicial diferente da vista para o SADT, onde o importante é o relacionamento entre as partes.

Vimos que as entradas foram transformadas em saídas. Essas entradas e saídas são informações que estão contextualizadas no diagrama do nível 0, ou diagrama de contexto, porque são oriundas ou destinam-se a entidades externas e portanto fora do sistema que queremos descrever.

Vale a pena exercitar o processo de decomposição do nível 1 para o nível 2. No caso, escolham um dos processos do nível 1 e façam a decomposição. Se tiverem dúvidas falem comigo. É um ótimo exercício para a prova. Prestem atenção no uso das regras de preservação de entradas e saídas, que permitem, utilizando-se procedimentos de enumeração e casamento de padrões, a identificação de problemas na decomposição.

Estou indicando dois sítios que me parecem boa referência sobre a UML. O primeiro, em Português, está relacionado a uma ferramenta, livre, para edição de diagramas das várias sub-linguagens da UML. Incentivo que procurem instalar e usar esse software. Outro, em Inglês, é um tutorial fornecido pela Borland e provê mais detalhes sobre os aspectos sintáticos de várias das sub-linguagens.

Um dos problemas ao aprender UML é que, apesar de ser um padrão (vide aqui o grupo regulador do padrão) tem tido diferentes interpretações por diferentes autores. Não se deixe confundir por essa confusão. Na dúvida, o sítio oficial da UML deve ser consultado."

Quem quizer ter uma visão geral de um projeto de software descrito utilizando a UML, veja o simulador de caixa eletrônico preparado por Russel Bjork.

Centraremos nossa atenção em uma classe de modelos, os que são orientados a linguagem natural. Em particular veremos cenários e léxicos.

Aula 7

Ao apresentar a técnica de Participação Ativa do Usuário fiz uma analogia com o XP. A idéia de que clientes participam junto com engenheiros de software no desenho de um sistema é advogada por alguns profissionais e autores. Falei que o JAD, visto na última aula, é também um exemplo de participação ativa do usuário.

Vimos a importância da técnica de leitura de documentos. Lembrei que alguns livros, simplesmente mencionam que devemos pinçar frases e substantivos para identificar objetos. É uma maneira simplista de ver o problema, mas ajuda a entender o quanto é importante ter acesso a documentos existentes no Universo de Informações. Lembro que esses documentos podem ser de diversos tipos, tais como: livros, manuais, leis, demandas, ...). Vejam uma nota sobre mineração de textos.

Falamos também das técnicas de Engenharia Reversa, que permitem com que representações mais abstratas sejam produzidas a partir de código legado.

Falamos também do papel da reutilização, principalmente sob a ótica de seleção de COTS. Sobre COTS: procurem em WERpapers artigos sobre esse tema.

Aula 6

Vale a pena lembrar que na lista da última aula deve-se acrescentar a técnica “Participação Ativa de Usuários”.

Nessa aula falamos das seguintes técnicas:
• Questionário
• Reunião
• Observação
• Etnografia (Antropologia)

É importante ressaltar que as técnicas de Questionário e Reunião são bastante diferentes da técnica de entrevista. No entanto, alguns autores misturam essas duas técnicas como se fossem tipos distintos de entrevistas.

Uma reunião pode englobar um ou mais atores no papel de engenheiro de requisitos. Os participantes de uma reunião de elicitação de requisitos são os interessados no sistema de software. Eventualmente um moderador de reuniões pode estar presente para ajudar a condução da reunião. A existência de um moderador dependerá do tipo de reunião a ser conduzida, tendo em vista que alguns métodos de reunião demandam o papel de moderador.

Reuniões permitem que requisitos sejam elicitados de uma maneira participativa, já que são vários os interessados, além dos engenheiros de requisitos, presentes a uma reunião. Essa maneira participativa apresenta vantagens e desvantagens que precisam ser bem exploradas e controladas. Sob a ótica da vantagem tem-se que várias opiniões podem ser contrastadas de modo a enriquecer o conhecimento sendo elicitado. No que diz respeito à desvantagem, é preciso ter cuidados para que não se perca o foco da reunião, nem que divergências não-fucionais, aqueles referentes a aspectos pessoais dos participantes, sobressaiam.

Citamos em aula as técnicas: “JAD” e “Brainstorm”. A última é uma técnica de reunião onde enfatiza-se a opinião livre sobre determinados assuntos em pauta, principalmente sob a ótica de aplicação de novas idéias para a resolução de problemas. Esse tipo de técnica, quando bem conduzido e com pessoas criativas podem muitas vezes resolverem problemas de uma forma original e criativa. Na elicitação de requisitos a técnica precisa ter uma boa moderação de maneira a evitar a perda de foco, já que uma reunião de elicitação de requisitos não destina-se a resolução de um problema, mas de aprofundar o conhecimento sobre determinado tópico. Veja aqui uma descrição sobre “brainstorm”.

O “JAD” (“Joint Application Design) tem por objetivo fazer com que os clientes e usuários participem, por intermédio de reuniões, na discussão sobre a definição de um sistema de software. O “JAD” tem formulários e processos bem definidos que ajudam os interessados na representação e discussão do conteúdo de um artefato de software. Vejam, aqui e aqui, textos sobre essa estratégia.

É recomendável a leitura do trabalho de mestrado de Cecilia Camacho sobre reuniões. Nele ela faz uma evolução de um método criado na PUC-Rio para aumentar o nível de conflito funcional em uma reunião.

Questionário é uma técnica voltada para a coleta de informações onde é grande o número de interessados a serem ouvidos. O questionário, ao contrário da entrevista e da reunião, é uma técnica onde o engenheiro de requisitos não tem um contato direto com o ator que fornece informações. De uma maneira geral questionários podem ser entendidos como um conjunto de perguntas que são respondidas por interessados sem uma interação direta com os engenheiros de requisitos.

Questionários podem ser qualitativos ou quantitativos. A grande vantagem de questionários qualitativos é a possibilidade do uso de técnicas de estatística para sua análise. Claro que também sua automação é facilitada. No entanto a criação de questionários quantitativos de qualidade é um grande desafio, tendo em vista que precisamos redigir não só as perguntas, mas esquematizar as respostas de tal maneira que possam ser tratadas estatisticamente. Normalmente temos questionários binário, ternário, de cinco respostas ou de sete respostas. De uma maneira geral os questionários com os números de respostas 2, 5 e 7 usam uma gradação de” + “para “—“ com um elemento neutro. O uso desse esquema com o objetivo da pergunta é o ponto chave da construção de perguntas eficazes para a elicitação de informação a partir de questionários.

Questionários, além de serem úteis para coletar informações de um número maior de interessados, permitem também, se bem desenhados, o trato da diversidade de opiniões. O questionário qualitativo é adequado para explorar essa diversidade de opiniões. No entanto, o questionário qualitativo demanda um esforço manual para sua análise, tendo em vista a dificuldade do trato automático de respostas livres. Não obstante técnicas de mineração de textos podem auxiliar nesta tarefa.

Um questionário de qualidade deve deixar claro o objetivo e a razão de cada pergunta, de maneira a facilitar ao respondente no sentido de prover a melhor resposta. Leiam a dissertação de Paulo Bastos Júnior sobre questionários.

A observação é uma técnica onde o engenheiro de software procura explorar o espaço geográfico em conjunto com o conjunto de atores que ali atuam. Observar é uma técnica de elicitação onde se ouve, vê-se e pouco se pergunta. É uma técnica importante, principalmente para que o engenheiro de requisitos inicie seu conhecimento do universo de informações. Um engenheiro de requisitos com experiência pode utilizar essa técnica para fazer metáforas ou analogias com situações previamente estudadas. No entanto, há que sempre ter em conta que o uso de metáforas ou analogias sem a devida confirmação pode levar à entendimentos enganosos.

A etnografia é uma técnica desenvolvida por antropólogos que busca fazer com que o investigador integre-se com o ambiente que é alvo de estudo. A etnografia é uma técnica de imersão no ambiente de tal maneira que o investigador (engenheiro de requisito) adquira o conhecimento de um nativo. A adaptação dessa técnica à Engenharia de Requisitos foi estudada na Universidade de Lancaster na Inglaterra.

Na aula ressaltamos que em todas essas técnicas de elicitação é de extrema importância o conhecimento das perguntas conhecidas como 5W1 ou 5W2H.

Outro ponto que ressaltamos é sobre a opção entre entrevista, questionário e reunião. Tanto entrevistas como reuniões incorrem em custos altos. Questionário tem o custo amortecido em razão de sua população, podendo ser tratados automaticamente. Lembrei que hoje, é comum em algumas páginas que questionários de satisfação sejam utilizados para o aprimoramento do uso desses sistemas. Entrevista é uma técnica própria para elicitação de requisitos de sistemas customizados, nesses casos enfatizamos que a identificação do “dono” do sistema é particularmente importante.

Aula 4 -- Aula 5

Nessa aula falamos da qualidade do software e o papel dos requisitos. Vimos que é fundamental termos requisitos bem definidos para obtermos qualidade na produção de software.

Ressaltamos que os requisitos podem ser descritos por uma taxonomia. Uma das taxonomias mais usais é a que distingue entre requisitos funcionais, requisitos não funcionais e requisitos inversos. Veja slide 12 aqui.

Mostramos também uma taxonomia geral da engenharia de software. A figura abaixo ilustra essa taxonomia utilizando a linguagem SADT, em particular um datagrama SADT. Nessa visão uma organização que produz software é composta de 5 entidades conectadas por diferentes ações. Ressaltei a importância do conceito de retro-alimentação presente no diagrama.


Enfatizei que tanto a taxonomia de requisitos como a taxonomia do processo de criação de software, vistas sob a perspectiva de dado são fruto de um determinado entendimento. Com a facilidade dos software chamados “social software” poderemos ver surgir uma nova modalidade de criação de taxonomias, talvez mais centradas na experiência e menos numa visão teórica. O uso de etiquetas nesses software sociais pode ser uma maneira como faremos taxonomias no futuro.

Lembrem-se do esquema de elicitação de requisitos. Vimos uma lista de técnicas que ajudam a coleta de fatos. São elas:

• entrevista
• reunião
• observação
• questionário
• etnografia (antropologia)
• engenharia reversa
• reutilização

Ressaltamos que uma entrevista pode ser estruturada, semi-estruturada ou não-estruturada.

Essa taxonomia reflete o quanto a equipe de elicitação preparou-se para a entrevista. Uma entrevista estruturada requer um prévio conhecimento sobre o contexto onde aplica-se a entrevista. Um entrevista não-estruturada é aplicada quando inicia-se o contato com o Universo de Informação, é uma maneira de começar a adquirir informações sobre o contexto.

Ressaltamos que muitas vezes a equipe pode usar perguntas preparadas por outros atores, mas é comum que os entrevistadores sejam aqueles que elaboram as perguntas.

Falamos de perguntas de controle que usam de redundância para identificar problemas ou levam a um questionamento das respostas.

Falamos das técnicas de interação com os entrevistados. É importante ressaltar que o uso de técnicas de comunicação como sumarização e confirmação são extremamente importantes. Também é importante o uso de analogias para bem estreitar pontos comuns entre entrevistados e entrevistadores.

Aponto aqui 4 endereços que apresentam diferentes visões sobre entrevistas. Vale a pena conferir. O primeiro tem uma visão jornalística, o segundo apresenta uma visão do ponto de vista social, a terceira mostra o esquema de um curso sobre entrevistas e o quarto mostra um procedimento padrão para entrevistas de auditoria.

Aula 3

Nessa aula falamos sobre a charge do Dilbert. É importante ressaltar que os dois personagens têm razão, apesar do evidente conflito. Isso é verdadeiro porque eles têm pontos de vista diferentes. O ponto de vista do personagem feminino é o de um desenvolvedor, de um técnico em informática. O ponto de vista do personagem masculino é o de cliente, de alguém que quer escolher um produto para ajudá-lo a atingir seus objetivos.

Essa percepção, de que há pontos de vista distintos e de que o cliente raramente fornecerá uma lista completa de suas necessidades, é fundamental para entendermos os desafios que enfrenta o engenheiro de requisitos.

Falamos também das partes que compõe o processo de definição de requisitos. É importante ressaltar que não se pode modelar, sem que antes saibamos do que estamos falando. Para isso devemos proceder com as tarefas de elicitação.

Vimos que elicitação é uma palavra nova na língua portuguesa. Ela quer ressaltar a importância da aquisição do conhecimento, por parte do engenheiro de requisitos, dos conhecimentos do mundo do cliente. Já vimos que esse conhecimento reside no Universo de Informações.

Nessa aula falamos também da idéia de marcação, ou geração de etiquetas. Por favor leiam o que escrevi sobre isso, assim como consultem minhas anotações no delicious.

Por motivos alheios as minhas vontades, só nos veremos no dia 14 de Maio. Até lá por favor leiam, além do material sobre marcação, o seguinte artigo sobre qualidade de software.

Aula 2

Lembraramos que, uma tabela de decisão já apresenta detalhes de como algo irá ser feito em função da combinação de condições. Dessa forma, poderíamos entender que a tabela de decisão estaria entre os desejos dos clientes (atores) e o código executável. Dessa maneira, caracterizamos a tabela de decisão como uma representação relacionada a especificação. Uma implemetação do conceito de tabela de decisão em Excel pode ser visto aqui.

Deixamos claro que, de uma maneira geral, podemos entender um processo de construção de na seguinte forma canônica: definição, especificação e implementação. Todos os processos de software embutem de alguma maneira essas três categorias.

O processo de definição é também conhecido como o processo de construção de requisitos, para o qual é importante seguirmos os preceitos da Engenharia de Requisitos. Nesse contexto é importante ressaltar a diferença entre requisitos e especificação.



Veja aqui a figura de Dilbert que coloca a Engenharia de Requisitos de uma forma paradoxal.

Veja aqui e aqui como definimos o processo de definição de requisitos.

Aula 1

Falamos de uma técnica, mapeamento de decisão, útil para quando fazemos documentos de especificação. A técnica em si pode ser expressa tanto na linguagem tabular (vista em aula), quanto na lingugem de grafos (árvore).

Em aula vimos uma descrição de políticas para aceitação de segurado. Com o exemplo feito em aula, descrito no quadro, tentamos mapear as condições envolvidas e as ações a serem tomadas. Esse exemplo serviu para apresentarmos a tabela de decisão. Vimos que essas representações ajudam a fazer um mapa entre uma descrição informal para uma descrição mais sistematizada, possibilitando assim uma análise mais bem fundamentada. Veja um exemplo de uso de uma tabela de decisão dentro de um programa.

Falei que as tabelas de decisão ajudam a que regras de negoócio sejam mapeadas, de uma maneira a facilitar o entendimento das condições que levam com que essas regras sejam utilizadas.

Ressaltei que a técnica de tabela de decisão é principalmente uma técnica de especificação, que ajuda na organização da solução. Ressaltei que é imporante saber sobre os desejos dos clientes, quais são eles? De onde surgem?

Portanto, antes de fazer as tabelas de decisão, por exemplo, é ncessário que possamos descobrir quais as regras do negócio. É aqui que reside o papel principal do engenheiro de requisitos.

Aula 32

Hoje é nossa última aula. Gostaria de agradecer a todos, creio que
nossas leituras ajudaram a que possam ter uma visão mais ampla do
que é engenharia de requisitos.

Lembro que os elos para seus resumos foram importantes. Deixo-os aqui:

Carlos Eduardo Potela Serra de Castro, Edson Moraes, Paolo

Fecharemos o semestre com o artigo de Goldin e Berry. É um excelente
artigo por várias razões, desde do tópico, da novidade que apresenta, mas
principalmente pela retórica utilizada. Considero um artigo perfeito sob a ótica de
argumentação.

Espero que parte da turma possa continuar com nosso projeto para o WER.

--> Aula 30

Aula 30

Por sugestão do Carlos Eduardo vamos ler o
artigo:

"A selective review of knowledge-based approaches to database design"

Para Quarta Feira iremos ler um artigo sobre Rastreabilidade de Requisitos.
Antes porem, é conveniente ler a seguinte nota, que postei em "Amazing".

Atenção: não teremos aula hoje. As leituras ficam para a próxima Quarta.

--> Aula 29

Aula 29

O artigo que mencionei está comentado e referenciado em uma
nota em Amazing.

--> Aula 28