• Nenhum resultado encontrado

Um Processo de Engenharia de Requisitos para Assessorar na Seleção das Técnicas de Eliciação de Requisitos de Software 2005

N/A
N/A
Protected

Academic year: 2021

Share "Um Processo de Engenharia de Requisitos para Assessorar na Seleção das Técnicas de Eliciação de Requisitos de Software 2005"

Copied!
8
0
0

Texto

(1)

Um Processo de Engenharia de Requisitos para Assessorar na

Seleção das Técnicas de Eliciação de Requisitos de Software

2005

Italo Galetti (UNIP) italogaletti@uol.com.br Mauro Spínola (USP) mauro.spinola@poli.usp.br Resumo

Por sua natureza, o desenvolvimento de um projeto de software consiste de inúmeros processos que exigem um aprimoramento intenso de seu entendimento. O seu maior obstáculo apresenta-se junto à eliciação dos requisitos. Descobrir o que o usuário realmente necessita é uma das tarefas mais difíceis do processo. Muitos artigos escritos divulgam métodos específicos de eliciação, outros apresentam modelos de caráter genérico, porém nenhum modelo de eliciação segue um caminho de regras claramente definidas. Portanto, é necessário que esta fase seja desempenhada de maneira criteriosa. Diversas técnicas podem ser aplicadas e, cada vez mais, as tradicionais convivem com novas técnicas, com o objetivo de aprimorar a identificação dos requisitos e diminuir os problemas decorrentes de uma má eliciação. Este artigo apresenta um processo de engenharia de requisitos que classifica e avalia, através de parâmetros, o contexto, o ambiente, o custo, o tempo e o desempenho das técnicas de eliciação. Os parâmetros propostos elucidam a seleção das técnicas, expondo as condições favoráveis, necessárias, para sua aplicação, aperfeiçoando o entendimento de como essas técnicas são selecionadas auxiliando analistas imaturos a terem o mesmo êxito que muitos analistas experientes.

Palavras chave: Seleção, Técnicas, Eliciação e Requisitos.

1. Introdução

A eliciação de requisitos é geralmente executada por uma metodologia ou uma série de técnicas, com o objetivo comum de dar aos analistas o entendimento necessário sobre um problema (Maiden, 1996). Embora alguns analistas acreditem que uma única metodologia ou técnica possa ser aplicada em todas as situações, vários pesquisadores afirmam que não existe uma única, capaz de suportar a resolução de todas as dificuldades das várias situações de um problema (Galetti, 2003).

Conforme Davis e Hickey (2002), os analistas selecionam uma particular técnica de eliciação por quatro razões básicas: (1) Aplicam a única técnica que conhecem; (2) Aplicam sua técnica favorita em todas as situações; (3) Seguem uma metodologia específica que prescreve uma técnica particular o tempo todo; (4) Não percebem intuitivamente qual a técnica mais adequada para ser aplicada em determinadas circunstâncias.

Claramente a quarta razão demonstra a “maturidade” de um analista. Infelizmente, alguns não possuem o discernimento necessário para uma tomada de decisão, portanto não acreditam nas três primeiras razões. O principal objetivo desse artigo é aperfeiçoar o entendimento do que necessariamente precisa ser feito durante o processo de eliciação, aprimorando a percepção de como as técnicas de eliciação podem ser selecionadas.

(2)

2. A Engenharia de Requisitos

Sommerville (2005) define a ER (Engenharia de Requisitos) como um termo relativamente novo que foi criado para cobrir todas as atividades envolvidas em descobrimento (obtenção), documentação e manutenção de um conjunto de requisitos para um sistema baseado em computador; o uso do termo engenharia implica em técnicas sistemáticas e repetitivas a serem usadas para assegurar que os requisitos dos sistemas sejam completos, consistentes e relevantes.

O termo em inglês para realizar a atividade de obtenção de requisitos é elicitation, um neologismo ainda não oficializado pela academia e que vem causando uma discrepância em seu uso. Alguns autores traduzem para “elicitar” enquanto outros, para “eliciar”. No Dicionário Aurélio Século XXI o termo é descrito como: “Elicitar” [Do lat. Elicitus: ‘extrair’, ‘tirar de’]; “Eliciar” [Do lat. Elicere: ‘Fazer sair’, ‘expulsar’, ‘Extrair uma resposta ou reação de’, ‘Extrair enunciados ou julgamentos lingüísticos de (informante)’]. Assim, o termo adequado em português, e que será adotado neste artigo para “elicitation” é “eliciação”.

3. Abordagens da Engenharia de Requisitos

Entende-se por abordagem um estilo particular de realizar um processo de ER, podendo englobar diferentes métodos e técnicas. Durante este processo devem ser considerados vários aspectos do domínio de um problema, de modo que o resultado desta atividade seja o mais proveitoso possível na satisfação da sua solução. Ao analisar com atenção esses aspectos, Rocha (2000) encontrou dois grupos: 1) técnico/tecnológicas; e 2) sócio-organizacionais. Com base nesta constatação, foram identificados três tipos de abordagens, que julga serem capazes de caracterizar os diferentes tipos de processos de engenharia de requisitos:

1) Abordagens Tecnológicas: aquelas que realçam a visão objetiva (enfatiza a importância de características pessoais tais como a posição organizacional e tarefas do usuário como um requisito do usuário determinante, ou a existência objetiva de porção da realidade a ser modelada) dos requisitos e os aspectos técnicos/tecnológicos dos sistemas de informação. Englobam os conhecidos métodos "hard", tradicionais ou estruturados.

2) Abordagens Sócio-organizacionais: aquelas que enfatizam a visão intersubjetiva (vê os requisitos como sendo primeiramente determinados pelas características pessoais dos usuários, seus quadros de referências, estilos cognitivos etc.) dos requisitos e os aspectos sociais e organizacionais dos sistemas de informação. Englobam os métodos que vulgarmente são conhecidos por métodos "soft", interpretativas ou construtivistas. 3) Abordagens Sócio-tecnológicas: aquelas em que há uma situação intermédia, em que existe uma combinação de algo de cada uma das duas abordagens anteriores. Geralmente focam-se primeiro nas questões sócio-organizacionais, deixando as questões técnico/tecnológicas para uma segunda fase.

Considerando as orientação do CMMI, a última abordagem é a mais adequada e coadunada com atividades de ER. Assim, o caminho em direção a uma maturidade superior é aquele que leva a práticas de ER sobretudo assentes numa abordagem sócio-tecnológica. A Tabela 1 resume as características principais das abordagens tecnológicas, tecnologicas e sócio-organizacionais no que respeita aos seus princípios, enfoque, técnicas, estratégias, papel dos engenheiros de requisitos e dos usuários, potencialidades e fraquezas (Rocha, 2000).

(3)

Tecnológicas Sócio-Tecnológicas Sócio-Organizacionais Princípios Positivistas e objetivas + Interpretativa e subjetivas

- Positivistas e objetivas

Interpretativa e subjetivas

Enfoque Sistema formal; dados + Sistema informal

- Formal Sistema informal; informação; conhecimento

Tipos de

Técnica Estruturadas e rígidas + Interativas e flexíveis - Estruturadas e rígidas Etnográficas, interativas e flexíveis

Estratégia Divide um problema em partes para análise

individual

Vê um problema como um todo que pode ser melhorado

e divide em partes p/ análise

Vê um problema como um todo

que pode ser melhorado

Papel dos

Analistas Decisão e condução Decisão, condução e facilitadores Facilitadores

Papel dos

Usuários Consultivo e passivo - Consultivo e passivo + Participativo Participativo, decisório e de comprometimento

Ponto Forte Resultados previsíveis Resultados previsíveis Proporcionam ou potenciam a reengenharia e inovação de

sistemas Fonte: Adaptado de Rocha (2000)

Tabela 1 - Principais características das abordagens tecnológicas e sócio-organizacionais

Em conformidade com os aspectos apresentados para justificar a predominância de um pendor tecnológico na condução da ER, bem como as características de cada uma das três abordagens consideradas neste artigo, são apresentadas na Tabela 2 argumentos e indicadores passíveis de serem usados no desenvolvimento de um modelo de avaliação da abordagem seguida pelas organizações na condução da ER.

Argumentos Tecnológicas Sócio-Tecnológicas Sócio-Organizacionais Quem Conduz Engenheiro de

Software Engenheiro de Requisitos Engenheiro de Sistemas / Negócios

Objetivo Construção de sistemas informáticos

Desenvolvimento do sistema de informação

Desenvolvimento organizacional

Papel dos Usuários Passivo/consultivo Representativo Participativo/decisório

Visões Consideradas Objetiva Subjetiva Inter-subjetiva

Métodos / Técnicas Análise estruturada Análise de dados Análise de decisões Análise de objetos Análise de textos Entrevistas estruturadas Reutilização … Observação do comportamento Prototipagem Entrevistas abertas Mapeamento cognitivo Análise de variâncias Relatórios de matrizes Cenários Análise futura Sessões de JAD Diagrama de Fluxo de Dados …

Aprendizagem com o usuário Brainstorming

Rich Pictures

Fonte: Adaptado de Rocha (2000)

Tabela 2 - Argumentos passíveis de serem usados na identificação da abordagem à ER

Um sistema de informação é, em todo o sentido do termo, um sistema que engloba simultaneamente as abordagens tecnológicas, sócio-organizacionais e sócio-tecnológicas. Não

(4)

(1999) afirmam que a componente social e organizacional é muitas vezes negligenciada nos processos de engenharia de requisitos de sistemas de informação, sendo os requisitos determinados com uma abordagem de pendor tecnológico, quando o ideal seria haver um equilíbrio entre a componente tecnológica e sócio-organizacional (Wastell e Newman 1996, Vidgen 1997, Flynn e Jazi 1998).

4. Parâmetros Propostos para Seleção das Técnicas de Eliciação

Conforme os autores Belgamo e Martins (2000), Rocha (2000), Galetti e Pessoa (2003), Batista (2003) e Kotonya e Sommerville (1998 e 2003) são identificados os seguintes parâmetros para a seleção das técnicas de eliciação e posteriormente avaliados conforme a Tabela 3:

1) Grupo/Indivíduo: indica se a técnica é aplicada em grupo ou individualmente; 2) Contexto: se a técnica leva em conta o ambiente onde está se realizando a eliciação; 3) Caráter de interação: se o usuário e o analista sentem-se à vontade, num clima de

estímulo e de aceitação mútua;

4) Usa lado introspectivo: se a técnica faz com que o analista volte-se para si e pense como será o serviço;

5) Confiabilidade: se as informações colhidas são confiáveis para o projeto;

6) Custo da técnica: O custo abordado neste trabalho é relativo ao tempo e esforços empregados no uso da técnica e não o custo financeiro na aplicação da técnica. Um dos aspectos-chave que o analista deve considerar é quanto irá custar o esforço e o tempo gastos no uso de cada técnica (Sutcliffe e Ryan, 1998). Baixo, Médio ou Alto; 7) Qualidade: se na técnica há democracia, aprendizado mútuo e resolução de conflito; 8) Padronização: se a técnica possui uma regra para seu uso;

9) Produtividade: se a técnica faz com que aumente a produtividade;

10) Compartilhamento de informações: se todos os indivíduos do grupo compartilham as informações;

11) Tempo: tempo despendido para a eliciação de requisitos;

12) Promove cooperação: se a técnica promove a cooperação do grupo;

13) Facilitador: se a técnica pressupõe a existência de uma pessoa com a função de guiar, levantar questões e conduzir discussões num grupo;

14) Validar requisitos com os usuários: se a técnica valida os requisitos;

15) Resolução de conflito entre stakeholders: se a técnica provê um meio para lidar com conflitos em grupo;

16) Atividade prematura de projeto: se a técnica evita que os analistas pensem prematuramente que todos os requisitos já foram eliciados e que o projetista já pode começar a elaboração do sistema.

17) Papel exercido pelo usuário no uso das técnicas: Consultivo, Representativo, Decisório e Apoio Geral.

18) Fontes de obtenção dos requisitos: Indivíduo; Grupos; Mista; Documentos e Observação.

(5)

19) Técnicas aplicáveis às diferentes fases da ER: Eliciação, Análise e Negociação, Especificação, Modelagem, Validação e Gerência de Requisitos.

20) Nível de treinamento / conhecimento do analista na técnica: Baixo, Médio e Alto 21) Habilidades exigidas do analista: Possuir habilidades analíticas para facilitar, por

exemplo, a análise da situação organizacional.

22) A Finalidade da informação coletada pela técnica: Uma técnica normalmente pode ser útil para capturar requisitos tanto para um sistema novo como para outro já existente. Entretanto, algumas oferecem melhores condições para um ou outro caso; a maioria das técnicas é útil para compreender o sistema atual, mas a análise de documentos e a observação são geralmente menos úteis para projetar um novo sistema. De uma maneira geral, os questionários podem ser úteis para sistemas novos, mas não no mesmo grau de entrevistas ou sessões de JAD (Wessels, 2002). O tipo de informação coletado pela técnica é indicado para: Sistema novo, Sistema atual ou Ambos.

23) A Quantidade de informação coletada pela técnica: As entrevistas e as sessões de JAD produzem muita informação em profundidade, enquanto que análise de documentos e a observação são úteis em extrair fatos, mas não em muita profundidade. Por outro lado, questionários e análise de documentos conseguem capturar efetivamente uma grande quantidade de informações de diversas áreas. Uma técnica pode produzir informações em: Profundidade ou Largura

24) O nível de participação do usuário: Em geral, uma grande participação do usuário dá uma exatidão maior, mas a um custo significativo. O tipo de participação abordado neste trabalho é a presencial nas reuniões ou sessões. Na observação, por exemplo, o usuário participa muito pouco, contudo, ele é intensamente observado. A participação exigida dos usuários pode ser: Baixa, Média ou Alta.

25) Distância física entre analistas e usuários: Posição geográfica nas disposições dos

stakeholders.

26) Permissão de acesso aos usuários finais: Dificuldade de acesso a cargos da alta administração.

27) Metodologia de desenvolvimento adotada: Ágeis, Convencionais ou Ambas; isto não significada que a técnica escolhida não possa ser aplicada a uma determinada metodologia. O objetivo desse item é obter uma melhor performance da técnica tendo como base às características da metodologia adotada.

28) Custo financeiro da técnica: Gastos para aplicação da técnica. 5. Exemplificando a Avaliação dos Parâmetros Propostos

Para exemplificar a avaliação do processo, propomos as técnicas identificadas por Kotonya e Sommerville (1998) como as mais aplicadas para a engenharia de software: “Etnografia”, “Prototipagem”, “Brainstorming” e “Cenário”.

Etnografia (Observação do Comportamento): Consiste em simplesmente observar os usuários em seu ambiente natural de trabalho, enquanto executam tarefas específicas, sem qualquer tipo de interferência do engenheiro de requisitos. Geralmente envolve o registro de anotações detalhadas pelo engenheiro de requisitos enquanto observa (Kotonya e Sommerville, 1998). O valor da etnografia é que ela ajuda a descobrir requisitos de sistema implícito, que refletem os processos reais, em vez de os processos formais, em que os

(6)

Parâmetros Técnicas de Eliciação

Prototipagem Brainstorming Cenários Etnografia

Grupo / Indivíduo Indivíduo Grupo Grupo Indivíduo

Contexto Sim Não Sim Sim

Caráter de Interação Médio Alto Alto Médio

Usa lado Introspectivo Não Sim Sim Sim

Confiabilidade Alto Médio Alto Médio

Custo da Técnica Médio Baixo Médio Baixo

Qualidade Alto Médio / Alto Alto Médio / Alto

Padronização Médio / Baixo Médio Alto Baixo

Produtividade Sim Sim Sim Sim

Compartilhamento da Informação

Médio / Baixo Alto Alto Baixo

Tempo Alto Médio Médio Médio

Promove Cooperação Médio Alto Alto Baixo

Facilitador Não Sim Sim Não

Valida Requisito com Usuários

Alta Baixo Média Baixo

Resolução de conflito entre stakeholders

Alta Alto Média Baixo

Atividade Prematura de Projeto

Média Média / Alta Alta Baixo

Papel Exercido pelo Usuário

Decisório Consultivo Apoio Geral Representativo

Fontes Obtenção dos Requisitos

Mista Grupos Mista Indivíduos

Técnicas Aplicadas as Dif. Fases ER

Validação Entendimento Domínio Especificação/

Entendimento Domínio

Entendimento Domínio

Nível de Treinamento Alto Baixo Médio Baixo

Habilidades Exigidas do Analista

Desenvolvimento de Software

Trabalhar em Grupo Trabalhar em Grupo Bom observador

Finalidade da Informação Coletada

Sistema Novo Ambos Ambos Ambos

Quantidade da Informação Coletada

Profundidade Largura Largura Largura

Nível de Participação do Usuário

Alto Médio Alto Baixo

Distância Física entre os stakeholders Inviabiliza a Aplicação da Técnica Inviabiliza a Aplicação da Técnica Inviabiliza a Aplicação da Técnica Inviabiliza a Aplicação da Técnica Permissão de Acesso ao Usuário Final Inviabiliza a

Aplicação da Técnica Indiferente Indiferente Inviabiliza a Aplicação da Técnica

Metodologia Aplicada Ágeis Ambas Ambas Convencionais

Custo Financeiro Alto Baixo Médio Baixo

Tabela 3 – Avaliação dos Parâmetros Propostos para Seleção das Técnicas de Eliciação

Prototipagem (Descoberta por Experimentação): Envolve o desenvolvimento rápido de uma versão piloto executável, de alguma parte ou aspecto de um sistema, e suas modificações subseqüentes até ser aprovado pelos usuários. Durante a análise de requisitos, a prototipagem dá forma concreta aos requisitos e assiste a sua clarificação e determinação (Sommerville, 2003). Os protótipos são modelos que visam a permitir: (1) que o projetista analise certas características do projeto que as especificações escritas no papel não são capazes de mostrar; (2) que o modelo seja testado sem o risco de comprometer toda uma produção em larga escala

(7)

ou nas proporções reais; e (3) que o futuro usuário entenda mais facilmente o produto que está sendo gerado.

A prototipação tem como objetivos: (1) estabelecer um diálogo intensivo entre usuários e analistas/projetistas; (2) encurtar ao máximo o ciclo "concepção – implementação – utilização - avaliação" do sistema; (3) possibilitar a evolução do sistema através de vários ciclos ou refinamentos sucessivos; (4) avaliar constantemente o sistema.

Brainstorming: Facilita a criatividade e resolução de problemas através de encontros de livre

geração de idéias numa situação de grupo. Tem por intenção alargar as fronteiras do espaço do problema dos participantes e obter soluções não convencionais (pelas manipulações de “quadros de experiência” individuais ou definições internas contextuais de eventos e situações) para permitir aceder a informação e idéias de outra forma indisponível por causa de seus “quadros” da situação atual (Pressman, 2001).

Cenários: Um cenário pode ser definido como uma descrição de um possível conjunto de eventos que podem previsivelmente ocorrer. O objeto principal do desenvolvimento de cenário é “estimular pensamento” acerca de ocorrências possíveis, suposições relacionadas com essas ocorrências, oportunidades e riscos, bem como cursos de ações possíveis. Essa técnica fornece aos usuários visões ou formas concretas do seu ambiente ou sistema futuro e ajuda-os a alargar seu pensamento para além da fronteira do problema e sistema existente. Pode ser aplicada a nível geral e abstrato para identificar metas e oportunidades futuras para um sistema ou organização e o meio de as atingir, ou pode ser aplicada em um nível mais específico para identificar requisitos detalhados. Os cenários facilitam a identificação de processos chave e dos seus requisitos de informação bem como suportam um entendimento comum entre engenheiros de requisitos e usuários a cerca dos requisitos presentes e futuros (Sommerville, 2003).

6. Considerações Finais

A Engenharia de Requisitos é uma atividade crítica no processo de desenvolvimentos de sistemas. Por ser uma etapa inicial, qualquer falha acarretará inúmeros efeitos em cadeia nas etapas subseqüentes, assim como, no produto final. As principais causas que podem levar a este insucesso são: (1) Falhas de entendimentos entre engenheiros de requisitos e usuários; (2) A noção de completude é problemática. Não há maneira de se descobrir, se disseram tudo aos engenheiros de requisitos; (3) Requisitos não são estáveis; (4) Requisitos são expressos em linguagem natural, que facilita seu entendimento, mas carrega ambigüidades inerentes, levando a interpretações múltiplas; (5) Nenhuma técnica de Engenharia de Requisitos é capaz de articular todas as necessidades de um sistema.

O processo proposto tem como, principal, objetivo prover aos analistas de sistemas dos recursos essenciais para subsidiar a seleção das técnicas de eliciação, minimizando as situações problemáticas relacionadas acima.

O risco de optar por uma técnica em detrimento a outra por limitação dos analistas em aplicarem a única que conhecem ou aplicarem sua técnica favorita em todas as situações, podem transformar pequenos obstáculos em barreiras quase que intransponíveis. Alertando que nestes casos, o ambiente entre os stakeholders tende a ficar proceloso e deve ser considerado como um risco para o projeto.

Os parâmetros propostos elucidam a seleção das técnicas de eliciação, expondo as condições favoráveis, necessárias, para sua aplicação. Para que o analista obtenha o máximo de proveito do processo proposto, o mesmo deve conhecer um número significativo de técnicas, ou seja, a boa performance do processo está associada, diretamente proporcional, à quantidade de

(8)

Todas as técnicas mencionadas são eficazes e alcançam sua melhor performance quando são respeitados o contexto de sua aplicação e suas limitações, contudo, independente da técnica a ser aplicada, o envolvimento de usuários é um tópico crítico em todo o processo de desenvolvimento de sistemas de informação. O seu nível de participação tem um impacto direto, positivo e significativo; quanto maior for sua participação no projeto, maior será a sua satisfação como usuário final.

7. Referências

ANDRIOLE, S. (1996) - Managing Systems Requirements: methods, tools and cases, McGraw-Hill. BATE, R. (1998) - "Do systems engineering? Who, me?”- IEEE Software, Julho/Agosto, pp. 65-66”.

BATISTA, E. (2003) - Uma Taxonomia Facetada para Técnicas de Eliciação de Requisitos. Dissertação de Mestrado, Instituto de Computação, UNICAMP, Campinas.

BELGAMO, A. & MARTINS, L. (2000) - Um Estudo Comparativo sobre as Técnicas de Eliciação de Requisitos do Software, XIX CTIC (Concurso de Trabalhos de Iniciação Científica) no XX Congresso Brasileiro da Sociedade Brasileira de Computação, Curitiba.

DAVIS, A. M. & HICKEY A, M. (2002) - Requirements Elicitation and Elicitation Technique Selection: A Model for Two Knowledge-Intensive Software Development Processes - Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03) IEEE.

FLYNN, D. & JAZI D. (1998) - "Constructing user requirements: a social process for a social context", Information Systems Journal, 8 , pp. 53-83.

GALETTI, I. (2003) - Proposta de um Modelo de Engenharia de Requisitos com Práticas de RUP e XP. Dissertação de Mestrado, Engenharia de Produção Universidade Paulista, São Paulo.

GALETTI, I. & PESSOA, M. (2003) - Técnicas de Eliciação da Engenharia de Requisitos, 4. CBGDP (Congresso Brasileiro de Gestão de Desenvolvimento de Produto), organizado pela UFRGS - Gramado, RS. HANSETH, O. & MONTEIRO, E. (1996) - "Navigation future research: judging the relevance of information systems development research", Accounting, Management and Information Technologies, 6, 1-2, pp. 77-85. HOOKS, I. (1999) - Writing good requirements, artigo apresentado ao Fourth INCOSE Symposium.

KOTONYA, G. & SOMMERVILLE, I. (1998) - Requirements Engineering - Processes and Techniques, 1ed. New York, Ed. John Wiley & Sons.

MAIDEN, N. & RUGG, G. (1996) - ACRE: Selecting Methods for Requirements Acquisition, Software Engineering Journal, 11, 5, pp. 183-192.

PRESSMAN, R.S. (2001) - Software Engineering, 2ed. New York, Ed. McGraaw-Hill Professi – 1056p.

ROCHA, A. (2000) - Influência da Maturidade da Função Sistema de Informação na Abordagem à Engenharia de Requisitos. Tese de Doutorado em Tecnologia e Sistemas de Informação, Universidade do Minho, Guimarães, Portugal.

SOMMERVILLE, I. (2003) - Engenharia de Software, 1.ed.,São Paulo, Ed. Pearson Education, – 608p.

SOMMERVILLE, I. (2005) - Innovation in Requirements Engineering - Integrated Requirements Engineering: A Tutorial – IEEE p16 - 23

SUTCLIFFE, A. & RYAN M. (1998) - “Experience with SCRAM, a Scenario Requirements Analysis Method,” Third International Conference on Requirements Engineering, IEEE Computer Society Press, pp. 164-171. VIDGEN, R. (1997) - "Stakeholders, soft systems and technology: separation and mediation in the analysis of information systems requirements", Information Systems Journal, 7, 1, pp. 21-46.

WASTELL, D. & NEWMAN, M. (1996) - "Information system design, stress and organizational change in the ambulance services: a tale of two cities", Accounting, Management and Information Technologies, 6, 4, pp. 283-300.

WESSELS, D. (2002) - Requirements and analysis. Lectures Notes for Systems Analysis - Computing Science Department, Faculty of Science and Technology Malaspina University-College, 2002. Disponível em

Referências

Documentos relacionados

São muitos os problemas ambientais causados pelo crescimento urbano, o poder público não acompanha esse crescimento com investimentos em obras de infraestrutura, são ocupados

As propostas devem ser apresentadas por autores(as)vinculados(as) as Instituições de Ensinosuperior e/ou Pesquisa, Academias de Letras, Centros depesquisa Desenvolvimento

O objetivo do curso foi oportunizar aos participantes, um contato direto com as plantas nativas do Cerrado para identificação de espécies com potencial

Os resultados evidenciam a elevada eficiência do TiO 2 , comprovada também em vários trabalhos na literatura; também indicam, porém, que é possível obter um

A partir dos fatores citados como predisponentes e determinantes criam-se perturbações hemodinâmicas locais que podem desencadear os fatores condicionantes,

Este artigo de revisão bibliográfica objetivou discutir o percurso histórico da loucura e do crime para entender como se deu o processo de constituição da unidade de saúde

A estabilidade do corpo docente permanente permite atribuir o conceito muito bom, segundo os parâmetros da área, para o item 2.2 (pelo menos 75% dos docentes permanentes foram

Curvas de rarefação (Coleman) estimadas para amostragens de espécies de morcegos em três ambientes separadamente (A) e agrupados (B), no Parque Estadual da Ilha do Cardoso,