Gestão de Requisitos PDF

O PAPEL DA GESTO DE REQUISITOS EM PROJETOS DE AMBIENTES CONSTRUDOS: UM ESTUDO DE CASO THE ROLE OF REQUIREMENTS MANAGEMENT IN THE DESIGN OF BUILT
ENVIRONMENTS: A CASE STUDY Camila Pegoraro* E-mail: camila_pegoraro@yahoo.com.br Tarcsio Abreu Saurin* E-mail: saurin@ufrgs.br Istefani Carsio de Paula* E-mail: istefani@producao.ufrgs.br
* Universidade Federal do Rio Grande do Sul, UFRGS, Porto Alegre, RS
Resumo: Frente s j conhecidas dificuldades na gesto dos projetos de ambientes construdos, pesquisadores e profissionais tm continuamente desenvolvido e aplicado boas prticas de reas como a gesto de projetos (GP). Contudo, ainda h carncias a serem supridas, como a dificuldade em acompanhar dinamicamente a evoluo dos requisitos dos envolvidos. Na tentativa de suprimir esta lacuna, o artigo objetiva analisar se a gesto de requisitos (GR) pode ser integrada GP de ambientes construdos, e quais as principais vantagens e desvantagens desta integrao. A pesquisa contou com uma reviso terica que trouxe conceitos bsicos da GP e da GR, contando esta ltima com contribuies da engenharia de software. Tambm foi realizado um estudo de caso em uma empresa construtora, atravs de entrevistas semi-estruturadas. A pesquisa permitiu concluir que a utilizao da GR vantajosa, apesar de no solucionar todas as dificuldades dos projetos, e que a adequada estruturao dos projetos um condicionante para o sucesso da GR. A principal contribuio uma proposta genrica e sistemtica para integrar as etapas da GR aos projetos. Palavras-chave: Gesto de requisitos. Gesto de projetos. Ambientes construdos. Abstract: Due to the known difficulties on managing the design process of built environments, researchers and entrepreneurs have continuously developed and implemented best practices from areas such as Project Management (PM). However, there are still gaps to be filled, such as difficulties on monitoring the stakeholders requirements and their dynamics. In attempt to eliminate this gap, this paper aims to analyze if requirements management (RM) can be integrated to PM and which are the main advantages and disadvantages of this integration. The research includes a literature review which presents PM and RM concepts, the last one based on software engineering approach. Moreover, a case study was performed in a construction company, using semi-structured interviews. The research showed that the use of RM is advantageous, even not solving all the projects difficulties, and that the proper structuring of the projects is a condition for the success of RM implementation. The main contribution is a generic and systematic proposal for integrating the stages of the RM to the projects. Keywords: Requirements management. Project management. Construction.
Revista Produo Online. Florianpolis, SC, v.11, n. 4, p. 965-994, out./dez. 2011. 965
1 INTRODUO As empresas que desenvolvem projetos de edificaes enfrentam problemas relativamente bem conhecidos no meio acadmico e profissional, tais como as dificuldades na coordenao dos interesses dos intervenientes, no planejamento das atividades, na administrao de recursos e no controle dos prazos (MELHADO, 2005; TZORTZOPOULOS, 2004). Considerando que melhorias nestes aspectos so essenciais para tais empresas se adequarem s exigncias do mercado (PEKTAS e PULTAR, 2006), a partir da dcada de 90, mais enfaticamente, pesquisas tem buscado referncias tericas e prticas em outros setores. Alguns exemplos so a gesto de projetos (GP) (ROMANO, 2003) e a gesto de requisitos (GR) (MIRON, 2002, HUOVILA, 2005). A GP consiste no planejamento e controle de uma srie de tarefas que pretendem atingir os objetivos de todas as partes interessadas em um projeto (KERZNER, 2002). Muitos mtodos so disponveis na literatura (Methodware; TenSetp; PRINCE2 Project in Controlled Enviroment, por exemplo) tendo eles alcanado nas ltimas dcadas patamares altos de detalhamento e disseminao em diferentes reas (TURNER, 2010). Contudo, algumas carncias ainda esto presentes nestes mtodos, como a dificuldade em gerenciar as incertezas e mudanas (ATKINSON; CRAWFORD; WARD, 2006). Em projetos de ambientes construdos as incertezas e mudanas de requisitos so inevitveis, por motivos como o longo tempo de desenvolvimento, quantidade de intervenientes e complexidade do produto (SUN et al., 2005; SENARATNE; SEXTON, 2008). Frente carncia de prticas que acompanhem dinamicamente a evoluo destes requisitos, os quais podem ser includos, excludos, transformados ou desdobrados em cada fase do projeto, este artigo explora a GR como uma fonte de prticas para suprir esta lacuna. Mesmo j tendo sido estudado no contexto da construo (SHEN et al., 2004; MIRON, 2008) o problema relacionado ao dinamismo dos requisitos ainda no est suprido. Diante disso, parte da reviso terica foi feita sobre a produo de autores da engenharia de software, rea na qual se pode encontrar conceitos e prticas de GR mais bem desenvolvidos. Para autores desta rea, a GR objetiva viabilizar a
identificao, anlise, priorizao, especificao e validao de requisitos ao longo do desenvolvimento dos projetos (WIEGERS, 2003; SOMMERVILLE, 2007), e, com isso, minimizar os impactos negativos das mudanas. Os mesmos autores afirmam que a GR traz benefcios aos projetos ao proporcionar o acompanhamento dos requisitos e acusao das incertezas, possibilitando a discusso e um melhor controle sobre as mudanas. Ainda, importante destacar que, apesar de softwares serem produtos significativamente diferentes de edifcios em aspectos como custo e ciclo de vida, existe uma caracterstica comum importante relacionada aos requisitos: tanto os softwares como os edifcios so produtos nicos, desenvolvidos sob medida sob determinadas circunstncias, para determinados clientes. Compreendido o contexto e o problema de pesquisa - a carncia de prticas na GP que acompanhem dinamicamente a evoluo dos requisitos - este artigo objetiva explorar se GR pode ser integrada GP em projetos de ambientes construdos, e quais as principais vantagens e desvantagens desta integrao. A principal contribuio uma proposta genrica e sistemtica para integrar as etapas essenciais da GR s da GP para suprir algumas dificuldades durante o desenvolvimento do projeto, como a rastreabilidade e o controle das mudanas dos requisitos. 2 REVISO TERICA Esta seo apresenta as principais informaes encontradas na etapa de reviso terica. Dentro de dois temas principais, a GP e a GR, foram estudados conceitos e prticas de autores da construo civil, e tambm de outras reas, a fim de enriquecer as bases tericas para o desenvolvimento desta pesquisa. 2.1 Gesto de projetos (GP) Dentre outras definies, o PMBoK (PMI, 2004) afirma que um projeto esforo temporrio empreendido para criar um produto, um servio ou um resultado. Um projeto uma atividade que implica um prazo limitado, uma data definida para a concluso e um resultado diferente daquele produzido no curso da rotina
operacional de uma organizao (KEELING, 2002). Este autor define algumas caractersticas e benefcios trazidos pela GP, dentre as quais se destacam: Simplicidade: metas e objetivos de fcil entendimento; Controle independente: pode ser protegido do mercado ou de outras flutuaes que afetam as operaes rotineiras; Maior facilidade de medio: o andamento do projeto pode ser medido por meio da comparao com metas e padres definidos de desempenho; Flexibilidade de emprego: pode empregar ou agregar especialistas e peritos por perodos limitados; til ao desenvolvimento individual: trabalhar com uma equipe de projetos eficiente favorece ao desenvolvimento acelerado e a capacitao pessoal. Meredith e Mantel Jr. (2002) complementam a definio com mais algumas caractersticas: Desmembramento: Ao longo da execuo, o projeto , geralmente, desmembrado em subtarefas, buscando atingir os objetivos aos poucos, mas com mais eficcia; Interdependncias: h uma interao freqente entre os projetos de uma mesma organizao, os quais tambm acabam interagindo com as atividades de rotina; Unicidade: todo projeto possui elementos nicos, alguns projetos podem ser similares, mas nunca iguais; Conflito: caracterstica inerente ao projeto, quando h a necessidade de concorrer com os departamentos funcionais por recursos. Segundo o PMI (2004) a gesto de um projeto envolve a execuo de processos gerenciais de (a) iniciao, (b) planejamento, (c) execuo, (d) monitoramente e controle e (e) encerramento, os quais esto resumidamente descritos a seguir e tm uma atuao no projeto conforme a Figura 1.
Figura 1 - Interao de grupos de processos em um projeto
Fonte: PMI (2004)
a) Iniciao: fase na qual definido o propsito do projeto e as necessidades para execut-lo. b) Planejamento: nessa fase definido e refinado o objetivo do projeto, as aes necessrias para atingir os objetivos so planejadas e tambm determinado o escopo para o qual se prope o projeto. Nessa fase so desenvolvidos planos auxiliares para gesto do projeto (qualidade, comunicao, riscos, por exemplo). c) Execuo: integra as pessoas e os outros recursos para colocar em prtica o plano do projeto. geralmente nessa fase em que ocorre a maior parte do esforo e dispndio do projeto. d) Monitoramento e Controle: ocorre em paralelo ao processo de execuo. Mede, monitora e controla o progresso para identificar variaes em relao ao planejado, para que aes corretivas sejam disparadas quando necessrio. e) Encerramento: formaliza a aceitao do projeto, servio ou resultado. Analisa a evoluo do projeto para que erros no se repitam no futuro. Encerra formalmente as relaes entre os envolvidos. Para implementar projetos, o PMI (2004) prope ao logo das fases a ao integrada de nove reas de conhecimento: gesto do escopo, tempo, custos,
qualidade, recursos humanos, comunicao, riscos, aquisies e integrao. Estas aes so gerenciadas pelo gerente de projetos, que a pessoa responsvel pela realizao das atividades e atendimento dos objetivos (GUSMO et al., 2006). de sua competncia a identificao das necessidades; o estabelecimento de objetivos claros e alcanveis; a aprovao de trade-offs; a alocao de pessoal e a adaptao dos planos diante de mudanas (PMI, 2004). Os mecanismos de controle das mudanas de escopo da rea de gesto do escopo e as prticas que asseguram a adequada gesto da informao na rea de comunicao so as mais relevantes a esta pesquisa. Ao tratar da gesto do escopo, as prticas descritas no PMBoK (PMI, 2004), por exemplo, tratam da identificao e acompanhamento dos requisitos, contribuindo para a atualizao do escopo do projeto. J a gesto da comunicao importante por determinar um padro de qualidade para a troca de informao entre os envolvidos e facilitar as relaes entre os mesmos. Algumas atividades relacionadas a requisitos esto pulverizadas nas diferentes reas da GP. Por fim, destaca-se que h vantagens em adotar os conceitos da GP para gerenciar os processos de projeto da construo civil, pois estes ltimos deixam de ser tratados como as atividades de rotina. Apesar de os procedimentos e etapas serem repetitivos de um empreendimento para outro, existe a caracterstica essencial da no repetio do mesmo projeto. A presena de elementos repetitivos no muda a singularidade fundamental do trabalho do projeto (PMI, 2004). Para Patah e Carvalho (2001), a conduta de tratar projetos como atividades de rotina compromete a organizao, pois implica em prejuzos, como o desperdcio de tempo e recursos. 2.2 Gesto de requisitos (GR) A GR uma abordagem que contribui no desenvolvimento de projetos por buscar estabelecer e manter a concordncia entre o consumidor, a equipe de desenvolvimento e todos os demais envolvidos (SOMMERVILLE, 2007). A concordncia deve existir tanto frente aos requisitos iniciais, quanto perante as mudanas que ocorrem no decorrer do tempo (KOTONYA; SOMMERVILLE, 2000).
Tais mudanas so inevitveis (SUN et al., 2005) e quanto mais eficaz for a gesto dos requisitos, maior tambm a probabilidade de sucesso do projeto (BRAY, 2002). Miron (2008) destaca que a boa GR contribui para o delineamento mais claro dos resultados que se espera de um projeto, e facilita a identificao das habilidades e carncias que tornam os envolvidos hbeis ou no a desenvolv-lo. Na construo civil usa-se tambm o termo briefing para denominar o processo de GR de um projeto (BARRET; STANLEY, 1999; SHEN et al., 2004; entre outros). Na viso tradicional, at meados da dcada de 90, o briefing era uma atividade da concepo inicial do empreendimento, cujo objetivo era a elaborao de uma lista de necessidades a serem consideradas. No entanto, no final da dcada de 90, firma-se a proposta de que o briefing a maior fonte de comunicao entre os clientes e que deve acompanhar todo o projeto (BARRET; STANLEY, 1999; SHEN et al., 2004), quando os requisitos so progressivamente considerados e colocados em prtica (HUOVILA, 2005). Esta nova abordagem deu origem ao briefing moderno que, basicamente, tem os mesmos conceitos e objetivos da GR, embora mais elementares. Diante disto, para melhor embasar esta pesquisa, foram buscados conhecimentos na rea da engenharia de software, pois onde se encontra uma extensa e mais profunda produo ligada ao assunto. Apesar de softwares serem produtos distintos edificao, e possurem considerveis diferenas no processo de desenvolvimento, no acesso tecnologia da informao, na possibilidade de realizao de testes e na prpria capacitao dos profissionais em relao GR, entende-se que possvel e vlida a proposta de adaptao de algumas prticas. Os autores pesquisados (KOTONYA; SOMMERVILLE, 2000; BRAY, 2002; YOUNG, 2003; WIEGERS, 2003; SOMMERVILLE, 2007), destacam que a GR tem um objetivo fundamental, e diferencial, diante de outras abordagens gerenciais: controlar as mudanas no projeto atravs do rastreamento dos requisitos, e gerenci-las. Para identificar requisitos preciso que, primeiramente, os clientes do projeto sejam ouvidos para o levantamento de suas demandas (KAMARA; ANUMBA; EVBUOMWAN, 2002; SHEN et al., 2004; BRAY, 2002). Nesta pesquisa a definio de cliente sinnima de stakeholder, ou seja, so todos os envolvidos em um
projeto. Whiteley (1992) classifica os clientes em 3 tipos bsicos, apresentados na Figura 2. Esta classificao til, pois a origem atribui caractersticas aos requisitos, como sua prioridade dentro do projeto.
Figura 2 - Tipos de clientes
Fonte: Adaptado de Whiteley (1992)
Outro esclarecimento importante est relacionado diferenciao entre demandas e requisitos. Demandas so as necessidades, desejos e restries emitidas pelos clientes. atravs delas que as empresas podem estabelecer os objetivos de um projeto e identificar as caractersticas que geram maior valor para os clientes MARX (2009). J os requisitos, so transcries das demandas em uma linguagem tcnica (SOMMERVILLE, 2007; BRAY, 2002). So funcionalidades que o produto, ou servio, devem ter para satisfazer uma necessidade ou alcanar objetivos dos clientes, quantificadas por condies mensurveis e limitadas por restries (PARVIAINEN; TIHINEN e VAN SOLINGEN, 2005). A traduo das demandas captadas para o formato de requisitos importante para uma maior garantia de que toda a equipe de desenvolvimento ir interpret-la da mesma forma (SOMMERVILLE, 2007). Segue abaixo um exemplo de transcrio de uma demanda no formato de requisito. importante lembrar que comum a necessidade de mais de um requisito para o atendimento integral de uma demanda (MARX, 2009). Demanda: Adquirir um apartamento seguro. Possveis requisitos: O imvel deve ser bem localizado; O imvel deve ser dotado de sistemas de segurana; (...)
Segundo autores como Kotonya e Sommerville (2000) e Young (2003), requisitos de boa qualidade devem ser necessrios, intelegveis, exeqveis, exatos, completos, testveis, rastreveis, exclusivos e no devem exigir solues prematuras. Estas caractersticas so importantes, pois uma vez atendidas, garantem a qualidade da informao que ir entrar no projeto e gerar valor (YOUNG, 2003). Tendo claros estes conceitos, pode-se partir para a anlise das etapas1 da GR, as quais, embora sejam encontradas com diferentes nomes (KOTONYA e SOMMERVILLE, 2000; BRAY, 2002; SOMMERVILLE, 2007), so apresentadas neste artigo como (i) identificao, (ii) anlise e priorizao, (iii) especificao e (iv) validao. 2.3 Identificao Etapa de coleta e organizao de informaes dos clientes para a empresa entender o que esperado do projeto (BRAY, 2002; SHEN et al., 2004; SOMMERVILLE, 2007) e identificar os requisitos a serem considerados. necessrio que todos os clientes sejam ouvidos para o completo entendimento sobre o que deve ser desenvolvido (SHEN et al., 2004). Alguns mecanismos para realizar o levantamento de informaes que possam gerar requisitos so entrevistas, questionrios, brainstorming, anlise documental, workshops e anlise conjunta (BRAY, 2002). Bray (2002) ainda observa que importante que, primeiramente, haja um esforo na investigao do porqu da existncia do projeto, atravs da identificao dos requisitos da prpria empresa. Para ser competitiva necessrio atender simultaneamente aos requisitos dos clientes e aos requisitos internos da empresa, ligados ao seu planejamento estratgico (MLLER, 2003), pois eles servem de orientao.
Neste artigo a palavra etapa ser relacionada s etapas da GR, enquanto a palavra fase ser relacionada s fases do projeto. A conveno serve para facilitar a compreenso do texto. Revista Produo Online. Florianpolis, SC, v.11, n. 4, p. 965-994, out./dez. 2011. 973
2.4 Anlise e priorizao A etapa de anlise e priorizao envolve a avaliao, organizao e negociao dos requisitos (SOMMERVILLE, 2007). comum que durante esta etapa sejam encontradas divergncias devido a conflitos de interesse entre clientes (BARRET e STANLEY, 1999; KAMARA; ANUMBA; EVBUOMWAN, 2002; BRAY, 2002; SHEN et al., 2004; SOMMERVILLE, 2007). Cada um deles tem seus prprios requisitos e necessrio, atravs de trade-offs, encontrar um conjunto que possa resultar em um produto final com maior valor agregado (MIRON, 2002). Para que estes problemas sejam controlados, alguns autores prope ferramentas para priorizao (SHEN et al. 2004) e estimulam a adoo de prticas da gesto de stakeholders (WARD; CHAPMAN, 2008). 2.5 Especificao A especificao uma maneira de converter os requisitos em um comportamento (BRAY, 2002), de encontrar a soluo funcional para eles serem atendidos. Esta etapa muito importante por englobar uma srie de decises sobre o projeto (SOMMERVILLE, 2007). As solues de projeto so elementos-chave na gerao de valor e tambm exigem anlise de trade-offs, uma vez que um requisito pode ser atendido de diferentes formas. Podem, inclusive, estimular mudanas no projeto (BRAY, 2002). 2.6 Validao Bray (2002) afirma que a etapa de validao existe porque necessrio haver testes sobre os requisitos durante o desenvolvimento de projeto. A finalidade evitar que problemas cheguem a fases mais avanadas. Est relacionada com a descoberta de problemas em tempo de corrigi-los evitando prejuzos e retrabalhos (SOMMERVILLE, 2007; SUN et al. 2005). A validao serve para certificar que o requisito est sendo atendido corretamente, conforme o especificado. Algumas das formas de realizar a validao so a prototipagem, testes e revises com checklists
(SOMMERVILLE, 2007). Requisitos consistentes devem ser testveis (KOTONYA; SOMMERVILLE, 2000; YOUNG, 2003) e esta uma das proeminentes dificuldades dos projetos de edificaes, pois alm de serem nicos, a elaborao de prottipos prximos escala real e a execuo de testes so possibilidades geralmente inviveis. Possveis de serem realizadas somente em alguns casos, ou com alguns componentes, como os pr-fabricados. 2.7 Relao entre as etapas da GR Cada uma das quatro etapas apresentadas so, segundo Sommerville (2007), ciclicamente repetidas ao longo do projeto (Figura 3). As fases do projeto correspondem aos ciclos, nos quais os requisitos so identificados, analisados, priorizados, especificados e validados, pois o conjunto de requisitos se altera com o tempo. O acompanhamento permanente dos requisitos facilita o registro e controle das mudanas. Segundo Sommerville (2007), rastreabilidade a propriedade de um requisito que reflete na facilidade de encontrar a sua origem e as relaes para com os demais, ou seja, possvel saber quem o props, como este requisito evoluiu durante o desenvolvimento do projeto e o quanto outros requisitos podero ser afetados por sua mudana. O rastreamento feito na maioria das vezes pela atribuio de cdigos, mas tambm podem ser utilizadas matrizes e figuras, dependendo da quantidade de requisitos, complexidade do projeto e ferramentas disponveis (SOMMERVILLE, 2007).
Figura 3 - Modelo em espiral das etapas da gesto de requisitos
Fonte: Adaptado de Sommerville (2007)
Com estes esclarecimentos, pode-se perceber com mais clareza as contribuies que a GR pode trazer aos projetos de ambientes construdos. A seguir ser discutido como tais contribuies ocorrem, ou poderiam ocorrer, na prtica. 3 MTODO DE PESQUISA As etapas da pesquisa esto representadas na Figura 4. Aps a reviso terica sobre os assuntos pertinentes, foi realizado um estudo de caso em uma empresa construtora, o qual permitiu que os pesquisadores analisassem, em um ambiente real, como a GP e a GR poderiam ser integradas. A empresa do estudo de caso, Sigma, foi escolhida por possuir algumas caractersticas que permitiram uma abordagem objetiva acerca dos temas da pesquisa. Entre elas esto a estrutura gerencial bem organizada e um projeto formalizado. O estudo foi baseado em duas rodadas de entrevistas semiRevista Produo Online. Florianpolis, SC, v.11, n. 4, p. 965-994, out./dez. 2011. 976
estruturadas, as quais foram gravadas e transcritas para posterior anlise. Os entrevistados foram escolhidos em funo do seu envolvimento no gerenciamento dos projetos da construtora, quais sejam: a gerente de produto, a gerente de projetos complementares e a gerente de planejamento de obras.
Figura 4 Delineamento da Pesquisa
Os objetivos da primeira rodada de entrevistas foram: (i) identificar caractersticas gerenciais e funcionais da empresa para haver um entendimento sobre o ambiente onde seria desenvolvida a pesquisa, (ii) fazer um diagnstico do projeto adotado pela empresa, pois a identificao e caracterizao das principais fases, e respectivas atividades, envolvidos, entradas, sadas, so passos importantes para a investigao de abordagens de gerenciamento, (iii) identificar as fases e prticas da GP em tal processo, pretendendo investigar que benefcios trazem para a empresa. Na primeira rodada foram feitas 2 entrevistas, uma delas com a gerente de produto, responsvel pela concepo do empreendimento e desenvolvimento dos projetos arquitetnico e legal, e a outra com a gerente de projetos complementares, responsvel pelo acompanhamento dos projetos complementares, como o hidrossanitrio, eltrico, de ar-condicionado e de paisagismo. As entrevistas duraram aproximadamente 90 minutos e possuam 20 questes, as quais estavam divididas em dois grupos. As do primeiro grupo examinaram as caractersticas da empresa (por exemplo: qual o ano de fundao, rea de atuao, tipos de produtos, nmero de funcionrios e descrio dos setores). J as do segundo, buscaram informaes
que permitissem o delineamento do projeto (durao, fases, envolvidos, gates, entre outros). O diagnstico do projeto da empresa foi realizado a partir da estruturao grfica das fases citadas pelos entrevistados em paralelo s da GP. A estruturao ocorreu primeiramente de acordo com as semelhanas de propsito entre as fases, seguida pela ordenao das subfases e posicionamento dos gates, identificao dos principais envolvidos em cada uma das fases e, por fim, identificao das principais atividades, entradas e sadas de cada uma das fases. Os gates, representam os marcos gerenciais e tcnicos dos projetos, que normalmente envolvem aprovaes parciais e decises importantes. Na segunda rodada, foram investigadas iniciativas que poderiam estar relacionadas s prticas da GR, como o uso de ferramentas ou existncia de conhecimentos tcitos que pudessem ser analisados e aprimorados. Essa rodada envolveu 3 entrevistas semi-estruturadas, uma com cada uma das gerentes da primeira rodada, com o acrscimo da gerente de planejamento de obras. Estas entrevistas foram precedidas por uma breve explicao sobre a GR. Apresentavam aproximadamente 20 questes, tendo algumas variaes devido diferena de atividades exercidas pelos entrevistados. A gerente de produto, por exemplo, foi questionada sobre como eram levantados e priorizados os requisitos estratgicos do projeto, presentes nas fases iniciais e que envolviam a diretoria, acionistas e pesquisas de mercado, e que ferramentas eram utilizadas ao longo das fases sob sua responsabilidade. A gerente de projetos complementares discorreu sobre os requisitos dos projetistas complementares e sobre as frequentes incompatibilidades que surgem no projeto executivo. J a gerente de planejamento de obras respondeu a questes mais especficas sobre os requisitos de obra, os quais devem ser considerados desde as fases anteriores de obras. Como a GR ainda um assunto pouco conhecido nas empresas deste setor, a abordagem dos entrevistados na segunda rodada evoluiu gradualmente, na medida em que os mesmos compreendiam os conceitos da GR. Neste sentido, a utilizao de entrevistas semi-estruturadas foi vantajosa, pois se pode, aos poucos, revelar conhecimentos tcitos acerca do tema.
As informaes coletadas nos relatos, antes de serem analisadas, ainda foram classificadas segundo trs critrios: (i) fase do projeto que estavam relacionadas, (ii) ligao com prticas de GP e (iii) ligao com prticas de GR. Esta classificao facilitou a anlise dos dados por j direcionar a informao ao tpico pertinente. 4 RESULTADOS Este trabalho foi realizado em uma incorporadora e construtora de grande porte da cidade de Porto Alegre, presente no mercado h mais de 30 anos. A empresa Sigma em seu portflio a construo e incorporao de mais de um milho de metros quadrados, com mais de sete mil imveis para habitao. Os empreendimentos so voltados para as classes A e B, tendo, porm, tipologias e aspectos formais variados de acordo com o pblico alvo especfico de cada empreendimento. 4.1 Delineamento e descrio das fases do projeto Como resultado das informaes da primeira rodada de entrevistas, foi delineado o formato de um projeto genrico da empresa, o que permitiu a compreenso das suas fases, atividades e principais envolvidos. A Figura 5 foi obtida a partir do procedimento descrito no mtodo de pesquisa e aprovada pela gerente de produto. Representa a sntese do projeto, tendo suas fases colocadas em paralelo s fases da GP para a realizao da anlise. 4.1.1 Macrofase 01 Incorporao Envolve definies importantes realizadas pela diretoria, principais acionistas e altas gerncias. Este grupo analisa o portflio de projetos frente s demandas, possibilidades de terrenos e objetivos estratgicos da empresa. Possui como principal gate a escolha do terreno e a definio do carter do empreendimento, o
que envolve a deciso das principais caractersticas, do pblico alvo e do estilo arquitetnico do edifcio, por exemplo. As fases 1.1 e 1.2 podem ocorrer em ordem inversa, pois tanto uma demanda pode deliberar a compra de um terreno, como um terreno com bom potencial pode ser comprado para a posterior concepo de um projeto especfico para ele. Na macrofase de incorporao so adotadas medidas de preveno de riscos como a realizao de ensaios para a verificao da condio geolgica, anlise da vegetao e das leis aplicveis aos terrenos. Alm disso, tambm nesta fase so esboados cronogramas de longo prazo e pr-estabelecidas as equipes que trabalharo no projeto. 4.1.2 Macrofase 02 Desenvolvimento do Projeto Aps ser feita a escolha do terreno e carter do empreendimento, no segundo gate gerencial, iniciada a fase de desenvolvimento do projeto, coordenada pela gerente de produto. Durante o estudo preliminar, ainda existe uma srie de definies, como a rea privativa dos apartamentos, quantidade de vagas para veculos, tipos de usos para reas condominiais e tecnologias construtivas a serem adotadas. Muitas vezes, nesta fase o terreno ainda no foi comprado, pois pode haver incerteza acerca de informaes geradas na macrofase anterior. nesta fase tambm que so elaborados cronogramas e estabelecidas as atividades e responsabilidades dos envolvidos.
Figura 5 - Fases dos projetos da empresa Sigma e relaes com as fases da GP
Aps a definio da tipologia do empreendimento, que envolve a definio de questes como nmero de pavimentos, quantidade de apartamentos por andar e rea construda aproximada, por exemplo, autorizado, pela diretoria, o incio da fase de anteprojeto, que inclui o desenvolvimento de plantas, cortes e fachadas. Neste momento, as gerentes dos projetos arquitetnicos, que gerenciam mais de um projeto, coordenam uma equipe que os desenvolve em profundidade fazendo definies mais precisas de dimenses dos compartimentos, esquadrias, configurao da fachada, usos dos espaos condominiais, atendimento efetivo da
legislao e tambm iniciam a integrao do projeto arquitetnico com os projetos complementares, terceirizados, a fim de j pr-dimensionar os espaos necessrios para as instalaes e estrutura. Foi enfatizado pelos entrevistados, que, pelo fato do grupo de projetistas envolvidos nos projetos j trabalharem juntos h anos, existem prticas j consolidadas. Elas so manifestadas, por exemplo, nas formas de comunicao, troca de informaes e nos tipos de solues de projeto adotadas. Isto facilita as solues de problemas e incompatibilidades, e traz melhorias para projetos futuros diante das lies aprendidas em conjunto. O segundo gate gerencial da macrofase de desenvolvimento do projeto o principal marco do mesmo. Aps terem sido feitas todas as principais definies de questes funcionais, estticas e financeiras, realizada uma reunio com representantes de todas as reas da empresa a fim de decidir se o projeto vai ser lanado no mercado, ou se ainda precisa de melhorias. Uma vez aprovado, alm de passar para a fase de projeto executivo e detalhamentos, quando consolidada a integrao com os projetos complementares, preparado o projeto legal, a ser aprovado pela prefeitura. Simultaneamente ao incio do projeto legal, ocorre o processo de lanamento do empreendimento, envolvendo com intensidade a rea de marketing. 4.1.3 Macrofase 03 Obra Uma vez que sejam encerrados os detalhamentos e o projeto esteja aprovado na prefeitura, a obra pode ser iniciada. Contudo, comum que a preparao do canteiro de obras e a execuo de fundaes iniciem antes da finalizao dos detalhamentos. Na fase de produo, o produto da construo civil possui algumas caractersticas intrnsecas: no passvel produo em larga escala, tem longo ciclo de produo, forte fragmentao e heterogeneidade de fornecedores e clientes internos e h dificuldades em fazer prototipagens (FABRICIO, 2002). Para auxiliar no gerenciamento desta macrofase, existe um gerente e um setor especfico para o planejamento de obra, responsveis pela logstica do canteiro, sequncia de atividades e cronogramas. Este setor conta com o apoio de engenheiros e tcnicos
que trabalham na obra, os quais coletam informaes, alm de controlarem e fiscalizarem as atividades previstas. 4.1.4 Macrofase 04 Entrega A macrofase de encerramento do projeto ocorre ao longo das entregas dos apartamentos. Nessa fase, alm de serem feitos os ltimos ajustes nos acabamentos e encerramentos de contratos, realizado o acompanhamento do uso, quando a empresa coleta informaes sobre todo o andamento do projeto e registra as lies aprendidas para retroalimentar os prximos projetos. Com o mesmo intuito, aps alguns meses feita a avaliao ps-ocupao (APO) visando identificar o nvel de satisfao, e quais requisitos, que atendidos ou no, causaram maior impacto na opinio dos clientes finais. 4.2 Identificao de fases e prticas da GP de ambientes construdos Com base na descrio das fases do projeto, percebeu-se que os objetivos e sadas de cada fase so bem definidos, assim como a posio dos gates e as atribuies dos envolvidos. Por ser uma construtora de grande porte, com 9 setores e 12 projetos em andamento, percebeu-se a preocupao, mesmo que demonstradas de formas pontuais nas entrevistas, com todas as nove reas de conhecimento citadas na bibliografia de GP. A exemplo cita-se (i) a definio criteriosa do escopo do projeto com base nas pesquisas de mercado e interesses dos principais envolvidos (gesto do escopo), (ii) as anlises de risco (gesto de reiscos), (iii) o monitoramento dos prazos das atividades, por meio dos cronogramas e realizao medies (gesto do tempo), (iv) o uso de extranet para troca de informaes entre os envolvidos e controle sobre verses do projeto (gesto da comunicao), (v) registro dos erros atravs de relatrios e documentao das mudanas (gesto do escopo), (v) avaliao dos profissionais envolvidos (gesto de recursos humanos). Estas iniciativas representam importantes contribuies, pois esclarecem informaes importantes, possibilitam o controle sobre o andamento do projeto e
favorecem o desenvolvimento do grupo de profissionais. O registro dos erros, lies e avaliaes dos envolvidos ao longo do projeto so exemplos de fontes de aprendizado, as quais trazem benefcios a todos. Ao longo das fases do projeto foram percebidas as caractersticas da GP citadas por Keeling (2002) e Meredith e Mantel Jr. (2002) como desmembramento dos processos em atividades, foco nos objetivos, interdependncias com atividades de rotina e medio dos processos (especialmente na obra). Destaca-se tambm a constatao da existncia de duas fases de planejamento, e controle e execuo, as quais, inclusive, so coordenadas por gerentes diferentes. Em relao a este aspecto, as entrevistadas defenderam que comum que as fases de design do edifcio sejam planejadas e executadas separadamente das fases de produo sob a justificativa de que envolvem capacitao, atividades e equipes diferentes. Alm disso, o incio das fases de design separado do incio da obra por aproximadamente oito meses. Contudo, h uma dificuldade associada a esta prtica, pois a fragmentao do planejamento tende a criar lacunas na concepo do projeto, pois limitaes de canteiro e dificuldades na obra podem interferir no design. Outra caracterstica que merece ser destacada estrutura organizacioal da empresa, a qual se assemelha estrutura do tipo funcional proposta por Ulrich e Eppinger (2000). Existe um gerente geral de todos os projetos, a qual coordena os gerentes funcionais, que, por sua vez, so responsveis por determinadas etapas e/ou funes dentro do projeto (Figura 6).
Figura 6 - Estrutura da empresa
Fonte: Adaptado de Ulrich e Eppinger (2000) Revista Produo Online. Florianpolis, SC, v.11, n. 4, p. 965-994, out./dez. 2011. 984
Esta estrutura no considerada a mais favorvel para a GP, pois, o projeto no possuiu uma pessoa responsvel por todo o seu desenvolvimento e comum que neste formato existam dificuldades como falhas de comunicao e de registro de informaes e pouca disseminao das lies aprendidas (ULRICH; EPPINGER, 2000). No entanto, a forte estrutura do projeto, a ligao coesa entre os gerentes funcionais, o uso de tipologias e tecnologias construtivas j consolidadas, e a boa comunicao, por vezes informal, entre os envolvidos fazem com que, na prtica, a estrutura funcional no seja to rgida, superando algumas barreiras deste modelo. Este ponto, acrescido dos aproximados cinco anos de experincia conjunta do grupo de projetistas, emerge uma discusso acerca dos prs e contras das informalidades. Pelo que se viu na prtica, a comunicao informal e algumas maneiras tcitas de conduzir a gesto do projeto podem funcionar adequadamente, se dentro desta informalidade existirem regras e entrosamento entre os envolvidos. Assim, importante que as propostas de novas prticas, que pretendem superar problemas, sejam suficientemente flexveis para que as informalidades benficas de cada empresa sejam consideradas e, se conveniente, formalizadas. 4.3 Identificao das fases e prticas de GR nos projetos O primeiro passo para a identificao das prticas de GR foi compreender quais eram os envolvidos no projeto para, em seguida, investigar como suas demandas e requisitos tendem a ser considerados no desenvolvimento dos projetos. A Figura 7 explicita alguns clientes identificados no estudo de caso, classificados de acordo com Whiteley (1992).
Figura 7 - Exemplos de clientes envolvidos nos projetos da empresa e exemplos de requisitos
Na Figura 7 percebe-se que os clientes podem emitir requisitos de diferentes nveis hierrquicos, visto que, enquanto alguns se referem a questes estratgicas do projeto, outros se referem a questes operacionais. Um requisito estratgico da diretoria, como o o edifcio deve ter padro de acabamento classe A, por exemplo, amplo e acompanha o projeto desde a incorporao, devendo ser desdobrado ao longo das fases em requisitos mais especficos, que englobam itens como materiais, tecnologias construtivas, mo-de-obra, entre outros. Sua modificao provavelmente causa mais impacto em outros requisitos, e no projeto como um todo, do que se houver mudana em um requisito mais especfico ou tardio, relacionado escolha de um tipo de tinta, por exemplo. Mesmo havendo algumas boas prticas como a retroalimentao pelo feedback de outros projetos, o registro de erros e a boa comunicao entre os projetistas, percebeu-se que a etapa de identificao limitada. Um exemplo claro desta limitao a existncia de duas fases de planejamento (Figura 5). Esta dissociao dificulta a considerao de requisitos de obra (ligados logstica e segurana do trabalho, por exemplo) durante o desenvolvimento do projeto. Alm disso, nas etapas de identificao deveria ser feita uma coleta de informaes mais aprofundada junto aos envolvidos, e no somente com os clientes finais. Embora a maior prioridade dos requisitos dos clientes finais possa ser uma estratgia da empresa, os requisitos de clientes intermedirios e internos devem ser
melhor considerados. Estes clientes emitem requisitos fundamentais (como os tcnicos, estticos, funcionais e financeiros) que, por vezes, podem no ser percebidos pelo cliente final, mas so fundamentais para a satisfao do mesmo. Outro possvel efeito da pouca considerao dos requisitos dos clientes internos e intermedirios no incio do processo a ocorrncia de retrabalhos e na insatisfao entre parceiros. Em relao aos requisitos dos clientes internos, dos setores da empresa, foi diagnosticada a prioridade dos departamentos de marketing e financeiro, alm da rea de alta gerncia, devido nfase nas entrevistas. O motivo o de que eles tm requisitos mais ligados ao planejamento estratgico e questes voltadas lucratividade dos empreendimentos. Durante as entrevistas, tambm foi percebida pouca preocupao em tornar os requisitos claros e bem definidos, como sugerido por Bray (2002), Kotonya e Sommerville (2000), Young (2003), e tampouco uma forma de estabelecimento de ligaes claras com as estratgias da empresa. De fato, os primeiros requisitos de um projeto devem ser provenientes da prpria empresa e no de agentes externos. Eles devem estar claramente definidos por serem determinantes tanto GP, quanto GR, pois norteiam a alta ou baixa prioridade dos demais requisitos e das atividades a seu atendimento. Assim, as iniciativas de GR identificadas no estudo de caso so de pouca significncia, se comparadas s possveis melhorias. Os requisitos so identificados, analisados, priorizados e especificados tacitamente ao longo do projeto, no havendo mtodo, ferramentas para o rastreamento, o controle da mudana ou a anlise detalhada das relaes entre eles e desdobramentos. 4.4 Relao entre a as prticas de GR e as de GP Um ponto importante a ser apresentado, verificado ainda na reviso terica, de que as prticas de GP aplicam-se a distintas reas de conhecimento (escopo custos, riscos, qualidade, etc.). Portanto, ela trata do assunto da mudana de requisitos de forma genrica, considerando algumas prticas como os documentos de controle de mudanas de escopo. A GR, por sua vez, trata das mudanas de
forma especfica atravs de mtodos formais e estruturados. A razo disso pode residir no fato de que no desenvolvimento de softwares, rea onde a GR mais se desenvolveu, frequentemente existe customizao e o cliente tem forte poder decisrio e de influncia, entre outros aspectos similares aos projetos da construo. Na prtica, com base nas anlises realizadas durante o estudo de caso, foi possvel identificar pontos positivos e negativos nos procedimentos adotados pela empresa estudada tanto sob a tica da GR, quanto da GP. Alguns desses pontos so comuns a ambos os casos. O registro de mudanas e controle de verses, por exemplo, so prticas importantes para as duas abordagens, visto que so atividades bsicas da GR, que contribuem para a gesto do escopo, qualidade e do tempo. J do ponto de vista negativo, a falta de um mtodo para identificao de requisitos de todos os clientes nas diversas fases do projeto um problema que pode trazer dificuldades s duas abordagens: se por um lado compromete todo o processo de GR, devido incompleta coleta de requisitos, por outro interfere em pontos crticos da GP, entre eles uma determinao acertada do escopo. As atividades da GR, em geral, podem trazer vantagens GP devido atualizao contnua dos requisitos do projeto. Uma vez que controla e rastreia os requisitos, a GR age como um apoio ao permitir que todos os envolvidas tenham uma viso clara acerca das relaes e das decises. Neste sentido, atua como uma aliada na gesto da integrao. Contudo, como algumas atividades da GR so semelhantes a outras j tradicionais da GP, como a identificao de requisitos a partir de demandas, o registro e detalhamento dos requisitos, a anlise das mudanas de projeto para no perder o foco no escopo, se no houver uma ao integrada entre as abordagens, possvel que ocorra uma repetio de atividades nos dois processos. Esta repetio potencializa o desperdcio de tempo, conflitos entre informaes e, consequentemente, erros e retrabalhos. Portanto, a integrao efetiva da GR GP essencial para evitar estes riscos. Pode ser feita atravs da unificao de documentos, bases de dados, e da capacitao dos profissionais envolvidos. Com a realizao das entrevistas pode-se tambm entender como as fases da GR se conectam com as fases do projeto. Neste aspecto, verificou-se que a GR deve ser realizada ciclicamente ao longo do projeto, conforme proposto por
Sommerville (2007) na Figura 3. Os requisitos passam pelas quatro etapas da GR ao longo dos projetos. Para ilustrar esta anlise, foi elaborada a Figura 8. Ao final de cada ciclo desejvel que os requisitos do projeto estejam atualizados, priorizados, especificados e validados de forma clara e compatvel aos interesses dos clientes. Para isso necessria a utilizao de ferramentas como planilhas, matrizes e estruturas grficas. Estas ferramentas devem permitir o rastreamento dos requisitos a fim de possibilitar a visualizao de sua origem e de seus desdobramentos.
Figura 8 - Relao das etapas da GR com as fases dos projetos
Para realizar uma boa GR recomendvel que, quando identificados, os requisitos sejam classificados de acordo com a origem e fase onde deve ser considerado (analisado, priorizado, especificado e validado). A classificao de requisitos, que ocorre na etapa de anlise e priorizao, uma dificuldade eminente, para a qual ainda precisam ser desenvolvidos mtodos e ferramentas de apoio. A adequada anlise contribui para a escolha de requisitos mais importantes e para a tomada de deciso frente a situaes de conflitos.
Ao observar a Figura 8 fica evidenciada a importncia de haver um projeto estruturado para a realizao das atividades da GR. Tal estruturao consiste na organizao clara e documentada das fases do projeto, e na identificao das principais atividades, envolvidos, entradas e sadas de cada uma delas. A estruturao uma condicionante para o sucesso na aplicao das prticas da GR. Diante destes resultados, entende-se que as prticas de GR ora apresentadas podem atuar como reforos na gesto da mudana, uma das carncias identificadas na GP de ambientes construdos. Os benefcios oferecidos pela GR no atendem plenamente s nove reas de conhecimento existentes (gesto do escopo, tempo, custos, comunicao, riscos, recursos humanos, aquisies, qualidade e integrao), mas podem trazer importantes contribuies. Por exemplo: (i) alinhamento os requisitos dos clientes aos da empresa (gesto do escopo); (ii) controle as mudanas e preveno de retrabalhos (gesto do tempo, custos, riscos, qualidade); (iii) melhorias para a comunicao entre os envolvidos (gesto da comunicao, tempo, riscos). Deve-se ainda salientar que a realizao das quatro etapas do ciclo da GR importante para que a mesma seja efetiva. Esta observao especialmente importante nos primeiros ciclos, durante a iniciao do projeto, quando devem ser definidos os requisitos estratgicos, que atuam como norteadores dos demais. 5 CONCLUSES As primeiras concluses sobre as similaridades e diferenas das prticas de GR e GP foram aparentes desde a reviso terica, quando se compreendeu que algumas boas prticas de GR estavam presentes na GP de forma pulverizada. No entanto, para preencher a lacuna apontada no problema de pesquisa conclui-se que era importante estreitar as relaes entre estas duas abordagens e encontrar prticas para melhor gerenciar os requisitos dos projetos e suas mudanas. Na comparao do objetivo desta pesquisa frente ao que se viu na prtica, percebeu-se que a colocao da GR como um processo de apoio GP pode trazer benefcios, pois complementar em alguns aspectos. A GR acontece em um projeto, mesmo que de forma desorganizada e tcita, pois os requisitos precisam
existir para que o projeto seja concebido. Assim, a iniciativa de gerenci-los com a utilizao de prticas consolidadas e de controlar suas mudanas pode trazer bons resultados para as empresas que desenvolvem projetos de ambientes construdos. Concluiu-se tambm que uma adequada estruturao do projeto uma premissa para a GR, pois esta abordagem necessita de um ambiente bem preparado para que seja efetiva. Ainda, percebeu-se a relevncia da etapa de identificao, uma vez que define as informaes de entrada do projeto, ou seja, determina quais requisitos entraro no espiral e sero transformados em um produto final. Por fim, observou-se que, de fato, a GR uma disciplina ainda pouco explorada tanto na teoria quanto na prtica. A falta de conhecimento sobre o tema, identificada no estudo de caso, pode ser reflexo da falta de propostas de diretrizes e prticas dinmicas, que possibilitem o acompanhamento dos requisitos ao longo dos projetos. Como sugesto de trabalhos futuros, recomenda-se que as atividades das etapas da GR sejam aprofundadas, e aplicadas em outros cenrios. O objetivo o de detalhar e validar a proposta de integrao apresentada na Figura 8, e obter concluses baseadas em outros casos sobre as vantagens e desvantagens da integrao a GR com a GP. REFERNCIAS ATKINSON, R.; CRAWFORD, L. e WARD, S. Fundamental uncertainties in project and scope of project management. International Journal of Project Management. v.24, p. 687698, 2006. BARRET, P.S; STANLEY, C.A. Better construction briefing. Blackwell Science , 1999. BRAY, I.K. An Introduction to Requirements Engineering. Pearson Education Limited. UK, 2002. FABRCIO, M. M. Projeto simultneo na construo de edifcios. Tese (Doutorado em Engenharia Civil e Urbana). Escola Politcnica,USP, So Paulo, 2002. GUSMO, I. F.; CNDIDO, A. P.; HERMENEGILDO, J. L. S. A gesto de projetos nas organizaes: o gerente de projetos como pessoa-chave. Disponvel em
http://npdeweb.cefetsc.edu.br/conteudos/upload/artigo/15101818082006.pdf. Acesso em: 05 dez. 2009. HUOVILA, P. Organisation&management. Technical Research Centre of Finland, VTT, 2005. KAMARA, J. M.; ANUMBA, C. J.; EVBUOMWAN, N. F. Capturing client requirements in construction projects. American Society of Civil Engineers;Thomas Telford Ltd. 2002 KEELING, R. Gesto de projetos: uma abordagem global. So Paulo: Saraiva, 2002. KERZNER, H. Gesto de projetos: as melhores prticas. Porto Alegre: Bookman, 2002. KOTONYA, G.; SOMMERVILLE, I. Requirements engineering: process and techniques. Chichester: John Wiley & Sons, 2000. MARX, A.M. Proposta de mtodo de gr para o desenvolvimento de produtos sustentveis. Dissertao (Mestrado em Engenharia de Produo). PPGEP, UFRGS, 2009. MELHADO, S.B. Coordenao de projetos de edificaes. So Paulo: O nome da Rosa, 2005. MEREDITH, J. R.; MANTEL JR., S.J. Project management: a managerial approach. 5.ed. New York: Jonh Wiley & Sons, 2002. MIRON, L. I. G. Proposta de diretrizes para o gerenciamento dos requisitos do cliente em empreendimentos da construo. Dissertao (Mestrado em Engenharia Civil). NORIE, UFRGS, 2002. MIRON, L. I. G. Gerenciamento de requisitos dos clientes de empreendimentos habitacionais de interesse social: proposta para o programa integrado entrada da cidade em Porto Alegre RS. Tese (Doutorado em Engenharia Civil). NORIE, UFRGS, 2008. MLLER, C. J. Modelo de gesto integrando planejamento estratgico, sistemas de avaliao de desempenho e gerenciamento de processos (meio modelo de estratgia, indicadores e operaes). Tese (Doutorado em Engenharia de Produo) PPGEP, UFRGS, 2003. PARVIAINEN, P.; TIHINEN, M.; VAN SOLINGEN, R. Requirements engineering: dealing with the complexity of Sociotechnical Systems Development. In: MAT, J. L.; SILVA, A. Requirements engineering for sociotechnical systems. Hershey: Information Science Publishing, 2005. cap. 2.
PATAH, L. A.; CARVALHO, M. M. Estruturas de gerenciamento de projetos e competncias em equipes de projetos. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO, Curitiba, 22, 2002. Anais... Porto Alegre: ABEPRO, p. 1-8, 2002. PEKTAS, S.T.; PULTAR M. Modelling detailed information flows in building design with the parameter-based design structure matrix. Design Studies. Londres, v.27, 122, 2006. PROJECT MANAGEMENT INSTITUTE (PMI) - Um Guia do conjunto de conhecimentos em gerenciamento de projetos (Guia PMBOK). 3 Ed. Project Management Institute, 14 Campus Boulevard, Newtown Square, PA EUA. 2004. ROMANO, F.V. Modelo de referncia para o gerenciamento do processo de projeto na construo civil. Tese (Doutorado em Engenharia de Produo). PPGEP, UFSC, 2003. SHEN, Q.; LI H.; CHUNG, J.; HUI, P. A framework for identification and representation of client requirements in briefing process. Construction management and economics, v. 22, 2004. SOMMERVILLE, I. Engenharia de software. So Paulo: Pearson Addion-Wesley, 2007. SUN, M. et al. Managing changes in construction project. UWE: Bristol, 2005. Disponvel em <http://www.builtenvironment.uwe.ac.uk/research/cprc/publications/mcd.pdf>. Acesso em: 14 nov. 2009. TURNER, J.R. Evolution of project management research as evidenced by papers published in the International Journal of Project Management. International Journal of Project Management, v.28, p. 16. 2010. TZORTZOPOULOS, P. Contribuies para o desenvolvimento de um modelo do processo de projeto de edificaes em empresas construtoras incorporadoras de pequeno porte. Dissertao (Mestrado em Engenharia Civil). NORIE, UFRGS, 1999. TZORTZOPOULOS, P. The design and implementation of product development process models in construction companies. Tese (Engenharia Civil). University of Salford, Salford, UK, 2004 ULRICH, K.T; EPPINGER S.D. Product and design development. 2 ed. Irwin McGraw-Hill, 2000. WARD, S; CHAPMAN, C. Stakeholders and uncertainty management in projects. Construction Management and Economics, v. 26, n. 6, 2008.
WHITELEY, R.C. A empresa totalmente voltada para o cliente Rio de Janeiro: Campus, Publifolha, 1999. WIEGERS, K.E. Software requirements. 2 Ed. Microsoft Press, 2003. YOUNG, R. The requirements engineering handbook. Norwood: Artech House, 2003. Disponvel em: <http://site.ebrary.com/lib/ufrgs/docDetail.action?docID=10081936>. Acesso em: 10 jun. 2009.
Artigo recebido em 12/04/2010 e aceito para publicao em 20/11/2011.

Gestão de Requisitos PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gestão de Requisitos PDF

Uploaded by

Copyright:

Available Formats

O PAPEL DA GESTO DE REQUISITOS EM PROJETOS DE AMBIENTES CONSTRUDOS: UM ESTUDO DE CASO THE ROLE OF REQUIREMENTS MANAGEMENT IN THE DESIGN OF BUILT

Figura 1 - Interao de grupos de processos em um projeto

Fonte: PMI (2004)

Fonte: Adaptado de Whiteley (1992)

Figura 3 - Modelo em espiral das etapas da gesto de requisitos

Fonte: Adaptado de Sommerville (2007)

Figura 5 - Fases dos projetos da empresa Sigma e relaes com as fases da GP

Figura 7 - Exemplos de clientes envolvidos nos projetos da empresa e exemplos de requisitos

Artigo recebido em 12/04/2010 e aceito para publicao em 20/11/2011.

You might also like