UNIVERSIDADE DO VALE DO ITAJA

PR-REITORIA DE PS-GRADUAO, PESQUISA, EXTENSO E CULTURA PROGRAMA DE MESTRADO ACADMICO EM COMPUTAO APLICADA

INTRODUO ENGENHARIA DE REQUISITOS

Relatrio Tcnico RT-ES-0001/11

por

Rodrigo Cezario da Silva rodrigocezario@msn.com

Fabiane Barreto Vavassori Benitti, Dra. fabiane.benitti@univali.br

So Jos (SC), agosto de 2011

SUMRIO RESUMO .................................................................................................iii ABSTRACT ............................................................................................. iv

1 2 3 3.1 4 5 6 INTRODUO ................................................................................................ 5 ENGENHARIA DE REQUISITOS ................................................................. 5 PROCESSO DE ENGENHARIA DE REQUISITOS ..................................... 8 ELICITAO DE REQUISITOS ................................................................. 12 RASTREABILIDADE DE REQUISITOS .................................................... 20 DOCUMENTO DE ESPECIFICAO DE REQUISITOS ........................ 24 CONCLUSO ................................................................................................ 30

REFERNCIAS BIBLIOGRFICAS .................................................. 31

ii

RESUMO
SILVA, Rodrigo Cezario. Introduo Engenharia de Software. So Jos, 2011. 43 f. Relatrio de Tcnico (Mestrado em Computao Aplicada)Programa de Mestrado Acadmico em Computao Aplicada, Universidade do Vale do Itaja, So Jos, 2011. A Engenharia de Requisitos, uma subrea da Engenharia de Software, a etapa onde so criados e refinados os requisitos de software. Atravs da aplicao de tcnicas e abordagens de elicitao de requisitos, os requisitos so capturados, analisados e validados com seus interessados. Por sua vez, a definio correta dos requisitos um fator crucial para reduzir custos e riscos no projeto de software. No entanto, entende-se que a falta de um bom trabalho nesta etapa pode levar ao insucesso ou abandono do projeto. Neste sentido, este relatrio tcnico tem o papel de apresentar os conceitos bsicos, o processo e atividades envolvidas na Engenharia de Requisitos. Palavras-chave: Engenharia de Requisitos. Elicitao de requisitos. Tcnicas de elicitao.

iii

ABSTRACT
The Requirements engineering, a sub-area of Software Engineering, is the stage where they are created and refined the software requirements. Through the application of techniques and approaches to requirements elicitation, requirements are captured, analyzed and validated with its stakeholders. In turn, the correct definition of the requirements is a crucial factor in reducing costs and risks in software design. However, it is understood that the lack of a good job at this stage can lead to failure or abandonment of the project. Thus, this technical report is the role of presenting the basic concepts, process and activities involved in requirements engineering. Keywords: Requirements Engineering. Requirements elicitation. Requirements elicitation techniques.

iv

INTRODUO
Nos ltimos anos, as organizaes voltadas ao desenvolvimento de software tm procurado por

melhores prticas em engenharia de requisitos (YOUNG, 2004; WIEGERS, 2006; ROBERTSON; ROBERTSON, 2006; DAVEY; COPE, 2008; TAMAI; KAMATA, 2009; LIU et al., 2010). Essa busca por novas prticas ocorreram porque as organizaes perceberam que o xito no projeto est cada vez mais relacionado a um melhor entendimento dos requisitos (WIEGERS, 2006; ROBERTSON; ROBERTSON, 2006). Neste sentido, a definio correta dos requisitos um fator crucial para reduzir custos e riscos no projeto de software (GOTTESDIENER, 2008), pois a falta de um bom trabalho na atividade de elicitao de requisitos leva ao insucesso ou abandono de projetos (DAVEY; COPE, 2008). Problemas na elicitao de requisitos esto relacionados a escopo, compreenso e volatilidade (CHISTEL; KANG, 1992), esses problemas so decorrentes da dificuldade em se extrair ou identificar as necessidades de seus usurios (HOOD et al., 2008). O objetivo principal deste estudo definir uma introduo bsica de Engenharia de Requisitos oferecendo as competncias bsicas necessrias para o entendimento de suas etapas e de suas atividades.

ENGENHARIA DE REQUISITOS
Devido necessidade de qualidade na produo de um produto de software, o processo de

desenvolvimento de software vem sendo aperfeioado ao longo dos anos (GENVIGIR, 2009). Essa busca por aperfeioamento est ocorrendo porque organizaes perceberam que o xito na execuo dos projetos est cada vez mais relacionado a um melhor entendimento dos requisitos (WIEGERS, 2006; ROBERTSON; ROBERTSON, 2006). Diversos autores destacam a importncia da engenharia de requisitos e seus impactos, principalmente em relao aos custos do projeto e qualidade, ressaltando que os defeitos de software na fase de projetos so muito mais caros e difceis de serem resolvidos do que na fase de definio de requisitos (PRESSMAN, 2002; BOEHM e BASILI, 2001; ROBERTSON; ROBERTSON, 2006; YOUNG, 2004). Segundo Wiegers (2006), a engenharia de requisitos trata os aspectos mais desafiadores no desenvolvimento de software, pois esta estabelece as bases para todo o projeto posterior. Conforme Kotonya e Sommerville (1998), os problemas de escrever requisitos

so universais e nunca haver uma soluo completa para resolver estes problemas. Porm, o resultado do impacto no sistema desses problemas pode ser reduzido utilizando-se de boas prticas de engenharia de requisitos. Neste sentido, a engenharia de requisitos trabalha de forma a sistematizar o tratamento dos requisitos (SWEBOK, 2004). Uma definio para engenharia de requisitos feita por Cheng e Atlee (2007), como um processo pelo qual requisitos so determinados. o processo pelo qual se descobre os propsitos do sistema, faz-se a identificao dos stakeholders e de suas necessidades, documenta-se essas necessidades de forma que seja passvel de anlise, comunicao e que, posteriormente, possa-se implement-las (NUSEIBEH; EASTERBROOK, 2000). No entanto, antes de aprofundar no processo de engenharia de requisitos, faz-se importante compreender o que so requisitos. Requisito, por sua vez, tem o papel de descrever como o sistema dever se comportar, alm de prestar informao sobre o domnio da aplicao ou restries na operao do sistema (KOTONYA; SOMMERVILLE, 1998), a fim de resolver um problema no mundo real (SWEBOK, 2004). Os requisitos servem de base para elaborao de cada projeto (HULL et al., 2005; YOUNG; 2004, p.2) e o sucesso do projeto depende do entendimento desses requisitos (CHENG; ATLEE, 2007). Uma separao por tipos de requisitos pode ser feita de modo a evitar problemas no processo de engenharia de requisitos (KOTONYA; SOMMERVILLE, 1998). Os requisitos podem ser divididos em trs tipos: requisitos de negcio, que dirigido por metas ou objetivos e tambm descrevem vises estratgicas de negcio, requisitos do usurio, que descrevem o que o usurio espera do sistema, e requisitos do sistema, que descrevem o que o sistema deve fazer (GOTTESDIENER, 2008). Essa separao entre diferentes nveis de descrio deve ser feita para facilitar a comunicao entre os diferentes tipos de leitores (KOTONYA; SOMMERVILLE, 1998). Os requisitos de sistema so classificados frequentemente em trs tipos: requisitos funcionais, requisitos no funcionais e requisitos de domnio (KOTONYA; SOMMERVILLE, 1998), definidos da seguinte forma: Requisitos funcionais: so descries de funes que o sistema ir fazer; deve ser til ao usurio para ajudar na execuo de seu trabalho. Qualquer ao ou verbo ativo so considerados requisitos funcionais, como por exemplo, calcular, inspecionar, publicar, processar, imprimir, listar e etc. (ROBERTSON; ROBERTSON, 2006)

 Requisitos no funcionais: expressam condies de comportamento e/ou restries que o software deve satisfazer (CYSNEIROS; LEITE, 1998), ou seja, so descries ou atribuies de qualidade que o sistema deve possuir (ROBERTSON; ROBERTSON, 2006). So exemplos requisitos ligados segurana, desempenho, usabilidade, acurcia, portabilidade e etc. Requisitos do domnio: derivam do domnio da aplicao e refletem caractersticas desse domnio. Podem ser enquadrados como requisitos funcionais ou como requisitos no funcionais (SOMMERVILLE, 2007). A diferena entre esse tipo de requisito e os requisitos funcionais e os no funcionais, que requisitos de domnio normalmente tm uma existncia fora dos limites de qualquer sistema de software (WIEGERS, 2006). Isso quer dizer que, uma regra de negcio no propriamente um requisito de domnio, ela existe independentemente de um sistema computacional, e muitas vezes ela ser aplicada para garantir que o sistema imponha esta regra. Cabe ressaltar aqui que nem todos os autores citam este tipo de requisito. Outra distino referente a requisitos sugerida por Leffingwell e Widrig (2003), propondo a classificao dos requisitos em nveis que podem ser observados sob o ngulo de uma pirmide conforme ilustrada na Figura 1. No topo da pirmide, localizam-se as necessidades (needs) dos stakeholders, ao centro esto s caractersticas (features) e na base os requisitos de sistema. Para Leffingwell e Widrig (2003), as necessidades (needs) e caractersticas (features) esto intimamente relacionadas e devem estar bem definidos para que ambos no entrem em conflito. Esse conflito ocorre porque os stakeholders normalmente especificam uma caracterstica do sistema e no uma necessidade ou requisitos de sistema. Cabe ento ao analista fazer essa identificao, para obter a real necessidade dos stakeholders.

Figura 1 - Viso de requisitos em nveis. Fonte: adaptado de Leffingwell e Widrig (2003).

PROCESSO DE ENGENHARIA DE REQUISITOS

Conforme Nuseibeh e Easterbrook (2000), o sucesso de um sistema de software decorrente

do cumprimento das finalidades para o qual o sistema foi desenvolvido. De um modo amplo, podese dizer que o processo de engenharia de requisitos objetiva a criao e manuteno do documento de especificao de requisitos (SOMMERVILLE, 2007, p.143). Esse processo ou domnio da engenharia de requisitos pode ser divido em desenvolvimento de requisitos, que centra as atividades de identificar e acordar um conjunto de requisitos; e gerenciamento de requisitos, parte responsvel por gerir as alteraes do conjunto de requisitos gerado pelas atividades de desenvolvimento de requisitos (WIEGERS, 2006). Segundo Sommerville (2007, p.143), a engenharia de requisitos pode ser divido em desenvolvimento de requisitos e gerenciamento de requisitos. O desenvolvimento de requisitos dividido em quatro atividades: elicitao1, anlise, especificao e validao. E o gerenciamento de requisitos composto de trs atividades: identificao de requisitos (a identificao de requisitos aqui no se refere atividade de elicitao de requisitos, mas sim a atividade de organizar, como por exemplo: fazer atribuio de identificador nico, adequaes de

Optou-se por utilizar o termo elicitao para a traduo da palavra elicitation da lngua inglesa. Pode-se afirmar que elicitar e elicitao so simples adaptaes de palavras inglesas: o verbo (to) elicit pode ser traduzido como: eliciar, fazer sair, trazer tona, deduzir, concluir, induzir, evocar; e o substantivo elicitation tm como significado: ao de extrair ou fazer surgir; (MICHAELIS, 1998). O termo elicitation de uso corrente na literatura inglesa sobre o tema de engenharia de requisitos. O vocbulo elicitao est sendo usado com freqncia nas publicaes de lngua portuguesa na rea de engenharia de requisitos (CYSNEIROS, 2001; FREITAS et al., 2007).

atributos como status, prioridade e urgncia), gerenciamento de mudanas de requisitos e rastreabilidade de requisitos. Para um melhor entendimento, a Figura 2 ilustra a diviso das atividades do processo de engenharia de requisitos.

Figura 2 - Processo de engenharia de requisitos. Fonte: adaptado de Wiegers (2006) adicionando a viso de Vliet (2007). No contexto deste trabalho, adotado o termo atividade para referir-se s subreas do desenvolvimento de requisitos. As atividades do processo de engenharia de requisitos so descritas como: Elicitao - a elicitao de requisitos compreende as atividades que envolvem o entendimento ou descoberta das necessidades dos stakeholders (WIEGERS, 2006), com isso pretende-se entender as metas, objetivos e motivos que levam ao desenvolvimento de um sistema computacional. Diversos autores relatam problemas nessa atividade do processo de desenvolvimento de requisitos (FREITA et al., 2007; HOOD et al., 2008; PRESMANN, 2002; YOUNG, 2004). Em trabalhos como o de Gottesdiener (2008) e Freitas et al. (2007), ainda observado que a definio correta dos requisitos no incio do desenvolvimento uma fator crucial para reduo de risco de falhas e custos com defeitos. Anlise depois de extrado os requisitos a anlise de requisitos utiliza-se destes para derivao e para que se possa chegar a um nvel de maior detalhamento, alm de resolver conflitos de interesses dos stakeholders, verificar pontos vagos e fazer 9

priorizao dos requisitos (GOTTESDIENER, 2008; WIEGERS, 2006). A anlise d subsdios para que o analista possa aprimorar o entendimento durante uma atividade de elicitao (WIEGERS, 2006). Especificao a atividade de especificao de requisito procede de forma a documentar os requisitos em um nvel apropriado de detalhes (WIEGERS, 2006). Normalmente, essa documentao realizada em linguagem natural. Outros aspectos sobre especificao incluem a diferenciao dos requisitos entre requisitos funcionais e no funcionais, visando documentar requisitos de forma inequvoca e completa (GOTTESDIENER, 2008). Para Vliet (2007, p.202), a especificao de requisitos reflete no entendimento mtuo do problema entre os stakeholders e o documento gerado serve de base para um contrato e tambm para testes de conformidade com a especificao de requisitos. Validao a validao de requisitos tem a preocupao de demonstrar que os requisitos definidos realmente refletem as necessidades do cliente

(SOMMERVILLE, 2007, p. 158). Conforme Nuseibeh e Easterbrook (2000), a validao de requisitos uma tarefa nada fcil de realizar, isso devido a razes de natureza filosfica, no que diz respeito a questes do que verdade e do que conhecido, e razes sociais, nas quais diz respeito dificuldade de entrar em consenso nos pontos conflitantes. Segundo Vliet (2007, p.242), uma forma de contornar essas dificuldades envolve a participao do cliente na validao dos requisitos, segundo o autor, o cliente quem realmente conhece o problema e ele quem deve decidir se a especificao do requisito foi escrita de forma adequada e que esta realmente descreva o seu problema. Em paralelo a atividade de desenvolvimento de requisitos, encontra-se o gerenciamento de requisitos, este voltado a entender e controlar as mudanas dos requisitos de sistema (SOMMERVILLE, 2007, p. 161). Segundo Wiegers (2006), esta atitude tem seu incio aps os stakeholders terem acordado que os requisitos esto bons o suficiente para servir de base para a construo de uma parte do produto (software). Conforme Hood et al. (2008, p.35), o gerenciamento de requisitos uma interface da engenharia de requisitos com todos os outros processos. Sendo assim, todas as alteraes no projeto

10

devem estar em conformidade com a documentao de requisitos, alm de ser possvel de filtrar ou selecionar um conjunto de requisitos s diversas verses de produto. Para isso, o gerenciamento de requisitos envolve trs atividades (VLIET, 2007, p.236): Identificao de requisitos nessa atividade os requisitos so identificados atravs de um identificador nico para que possa ser referenciado por outros requisitos em uma matriz de rastreabilidade (SOMMERVILLE, 2007, p.162). Como sugerido por Vliet (2007, p.237), conveniente incluir tambm informaes sobre os requisitos como, por exemplo: status, prioridade, stakeholders envolvidos e verso. A verso necessria, j que os requisitos podem por diversas vezes serem alterados e atualizados. Gerenciamento de mudanas de requisitos Essa atividade conduzida de forma a visualizar cada requisito como um item de configurao em um procedimento de gerncia de configurao2 (VLIET, 2007, p.237), o seu objetivo de avaliar o impacto e custos das mudanas (SOMMERVILLE, 2007, p.163). Rastreabilidade de requisitos essa atividade objetiva relacionar requisitos com artefatos ou elementos da soluo. A rastreabilidade permite rastrear artefatos onde os requisitos so realizados (rastreabilidade para frente), e tambm permite rastrear artefatos que j foram escolhidos na soluo (rastreabilidade para trs). A rastreabilidade est ligada intimamente a melhorar a qualidade dos sistemas de software (SPANOUDAKIS e ZISMAN, 2005; DICK, 2002). Segundo Wiegers (2006), o processo de engenharia de requisitos deve ser realizado de forma iterativa, deve ser planejado em vrios ciclos, com o intuito de refinar os requisitos para se obter um nvel de detalhamento mais adequado. A realizao das atividades de levantamento, anlise, especificao e validao podem ser feitas em paralelo (HOOD et al., 2008, p.44; WIEGERS, 2006).

A gerncia de configurao conforme o modelo CMMI-DEV (SEI, 2010a, p.114), tem o objetivo de estabelecer e manter a integridade dos produtos de trabalho usando a identificao da configurao, controle de configurao, representando status de configurao e configurao de auditorias. Modelos importantes de maturidade como CMMIDEV (SEI, 2010a), MPS.BR (SOFTEX, 2009) e norma ISO/IEC 15504 (ISO/IEC Std. 15504, 2005, p.55) tambm conhecida como SPICE, exigem o gerenciamento de configurao em um processo de gesto de requisitos.

11

Como mencionado na literatura, o processo de engenharia de requisito visa a criao e manuteno do documento de especificao de requisitos (SOMMERVILLE, 2007, p.143). Ento, no fim de um ciclo de uma iterao, gerado um documento de especificao de requisitos, esse documento reflete o entendimento mtuo do problema entre os stakeholders e serve de base para um contrato e tambm para testes de conformidade com a especificao de requisitos (VLIET, 2007 p.202).

3.1 Elicitao de Requisitos

A elicitao de requisitos compreende atividades nas quais objetivam o descobrimento preciso do problema a ser resolvido e, portanto, identificao das necessidades dos stakeholders e suas restries ou limites (NUSEIBEH; EASTERBROOK, 2000; WIEGERS, 2006; AOUAD; ARAYICI, 2010). Deve envolver atividades que permitam a comunicao, a definio de prioridade, a negociao e a colaborao com os stakeholders relevantes (ZOWGHI; COULIN, 2005, p.21). Na literatura, no existe consenso sobre as atividades realizadas durante a elicitao de requisitos. Contudo, consenso que a elicitao de requisitos uma atividade realizada no incio do processo de Engenharia de Requisitos e deve ser conduzida de forma iterativa e integrada (SOMMERVILLE, 2007, p. 148; ZOWGHI; COULIN, 2005, p.21). Uma diviso da atividade de elicitao feita por Zowghi e Coulin (2005, p.21-23), definindo a elicitao de requisitos como um processo que se divide em cinco tipos fundamentais: (i) entendimento do domnio da aplicao; (ii) identificar as fontes de requisitos; (iii) anlise dos stakeholders; (iv) seleo de tcnicas, abordagens e instrumentos que sero usados; e (v) elicitar os requisitos das partes interessadas e de outras fontes. A definio de um processo para a elicitao de requisitos visa melhorar a colaborao entre os envolvidos (BARBOSA et al., 2009). Porm, o processo pode variar muito, este delineado dependendo das pessoas que o envolvem (ZHANG, 2007). A elicitao de requisitos uma tarefa difcil de ser realizada (AOUAD; ARAYICI, 2010; HOOD et al., 2008) e tambm dita como crucial para o sucesso de um projeto de software (GOTTESDIENER, 2008; FREITA et al., 2007; ZHANG, 2007). Pesquisas relatam que problemas na atividade de elicitao de requisitos podem levar ao insucesso ou abandono de projetos (DAVEY; COPE, 2008) e que erros cometidos nesse ponto podem ser muito mais custosos de serem resolvidos (BOEHM; BASILI, 2001; PRESSMAN, 2002) e, em complemento, Robertson e

12

Robertson (2006) afirmam que 60% dos erros em produtos de software so decorrentes de requisitos incorretos ou incompletos. Conforme relatado na literatura, os problemas ocorridos na elicitao de requisitos so decorrentes de problemas de comunicao humana; mudanas das necessidades das organizaes e limitao da viso de oportunidades (DAVEY; COPE, 2008; CHRISTEL; KANG, 1992). Na literatura, pode-se encontrar outros autores que reforam problemas na atividade de elicitao de requisitos e atribui que o maior peso de dificuldade incide na compreenso dos requisitos (HOOD et al., 2008; PRESMANN, 2002; YOUNG, 2004; SOMMERVILLE, 2007, p.146). Neste sentido, Zhang (2007) afirma que os requisitos devem ser analisados e identificados proativamente, e devese selecionar um mtodo adequado para diminuir os problemas na elicitao. As tcnicas para elicitao de requisitos so mtodos que os analistas utilizam para determinar as necessidades dos clientes e usurios, de modo que os sistemas construdos possam ter uma alta probabilidade de resolver de forma satisfatria essas necessidades (HICKEY; DAVIS, 2003). Segundo Leffingwell e Widrig (2003), a escolha de uma tcnica (mtodo) para elicitao ir variar dependendo de alguns pontos: tipo de aplicao, habilidade da equipe de desenvolvimento, habilidades e sofisticao do cliente, dimenso do problema, criticidade3 da aplicao, tecnologia utilizada e singularidade da aplicao. E o conhecimento dos engenheiros de software sobre os mtodos de desenvolvimento de requisitos deve ser pleno, o que contribuir para prever as necessidades do desenvolvimento e selecionar o mtodo mais apropriado para cada projeto (ZHANG, 2007). Diversas tcnicas so mencionadas na literatura, cada uma dessas tcnicas possui um objeto diferente de observao ou investigao, e cada uma delas tem um foco especfico em um determinado tipo de requisitos. Segundo Zhang (2007), por se tratar de um processo iterativo, e de acordo com os meios em que se procede a comunicao entre analistas e stakeholders, as tcnicas

Optou-se por utilizar o termo criticidade para a traduo do da palavra criticality da lngua inglesa, que possui como significado: criticidade (Google tradutor, 2010). O termo criticality de uso corrente na literatura inglesa sobre assuntos que abordam problemticas. No contexto deste trabalho o termo criticidade ser utilizado para determinar quo crtica uma determinada situao.

13

de elicitao de requisitos podem ser distinguidas em quatro tipos: estudo observacional, de conversao, analticos e sintticos. A classificao dos mtodos por tipos serve como um guia para os engenheiros na escolha do mtodo mais apropriado ou adequado para o levantamento, alm de fornece base para evoluo dos mtodos de levantamento de requisitos (ZHANG, 2007). Os tipos de mtodos de elicitao de requisitos so descritos a seguir, conforme Zhang (2007): 1. Mtodos observacionais: mtodo utilizado para compreenso do domnio da aplicao. Esse mtodo constitui na observao das atividades humanas para obteno de requisitos no tcitos e de difcil verbalizao. Incluem nesse grupo as seguintes tcnicas de elicitao: a. Estudo etnogrfico Tcnica utilizada para estudar as pessoas em seus ambientes naturais. Com uso de mtodos etnogrficos, mais fcil o descobrimento de conhecimento tcito, o que no ocorre na maioria das outras tcnicas de elicitao (VLIET, 2007, p. 218). Segundo Zowghi e Coulin (2005, p. 29), um estudo etnogrfico eficaz quando a necessidade de um novo sistema decorrente de problemas existentes com o processo e procedimentos e padres complexos de relacionamento entre os stakeholders. b. Anlise social Consiste em colocar um observador em uma sociedade ou cultura por um determinado tempo com a preocupao de observar detalhadamente todas as prticas realizadas pelo grupo (ZHANG, 2007). c. Observao Nesta tcnica, o observador inserid o em um grupo para observao de um determinado processo ou atividade. Durante a observao, o observador deve compreender as atividades que esto sendo realizadas pelo grupo sem exercer interferncia direta sobre estas (ZOWGHI; COULIN, 2005, p.29). Ainda segundo Zowghi e Coulin (2005, p. 29), tcnicas de observao so custosas e exigem habilidade e esforo significativo para compreenso das aes que esto sendo realizadas. Outra questo quanto eficcia, nesta o indivduo que est sendo observado tem a tendncia de mudar o seu comportamento na execuo da tarefa quando consciente que est sendo vigiado.

14

d. Anlise de protocolo

Em uma anlise de protocolo, os usurios so

submetidos execuo de uma tarefa na qual sero observados por um analista, de forma simultnea a sua execuo, os participantes falam em voz alta o que esto fazendo e tambm sobre o seu pensamento sob o processo (GOGUEN; LINDE, 1993). Segundo Zowghi e Coulin (2005, p. 29), um vis pode ser introduzido pelo uso dessa tcnica. Na maioria dos casos, pequenos passos realizados no processo do usurio acabam ficando fora do processo, por serem tomados como abreviados ou esquecidos pelos usurios, os quais no podem ser explicados, que consequentemente ficam fora do registro do processo, assim, registrados de forma incompleta ou incorreta. 2. Mtodos de conversao: so mtodos de obteno de requisitos no qual se utiliza comunicao verbal entre duas ou mais pessoas. A conversa um meio natural de expressar necessidade e ideias. considerada muito eficaz para desenvolver e compreender problemas. Algumas tcnicas de levantamento que se utiliza deste mtodo so: a. Entrevista A tcnica mais comum na elicitao de requisitos (ZHANG, 2007). Alguns pontos chaves referente entrevista so definidos por Leffingwell e Widrig (2003). Eles contribuem em afirmar que entrevista uma tcnica simples e que pode ser usada na maioria das circunstncias. E a sua conduo em um contexto de perguntas livres pode ajudar a obter entrevistas sem vis. Tambm pode ser apropriada para descoberta de requisitos e explorao de solues possveis. Conforme Alexander e Stevens (2002, p.22), a entrevista pode ser conduzida de forma estruturada ou de discusso livre. Nas entrevistas estruturadas, um roteiro de perguntas formulado de forma a fazer perguntas em pontos especficos. J as entrevistas de discusso livre ajudam a levantar novos requisitos ainda em aberto ou desconhecido. Alguns cuidados na escolha do tipo de entrevista podem ser tomados, as entrevistas estruturadas tendem a limitar o que os stakeholders poderiam dizer sobre o problema, ocultando coisas que podem ser de interesse no sistema. Sugesto para conduo de uma entrevista feita em Alexander e Stevens (2002, p.23).

15

b. Workshop

uma forma poderosa e muito utilizada para fazer os

stakeholders pensarem alm da forma atual de como realizam suas tarefas. (ROBERTSON; ROBERTSON, 2006; LEFFINGWELL; WIDRIG, 2003). A tcnica consiste em uma reunio realizada de forma estruturada, dinamizada e intensiva, na qual esto presentes os stakeholders chaves do projeto e concentra-se na criao ou reviso das caractersticas de alto nvel do projeto. Sua conduo elaborada de forma a se obter mais rapidamente o consenso e acordo dos stakeholders sob os requisitos (LEFFINGWELL; WIDRIG, 2003). Normalmente, realizada em conjunto com as tcnicas de entrevistas (ALEXANDER; STEVENS, 2002, p. 27), e de brainstorming

(LEFFINGWELL; WIDRIG, 2003). c. Brainstorming A tcnica de brainstorming envolve a gerao e reduo de idias (ZHANG, 2007; LEFFINGWELL; WIDRIG, 2003). Uma sesso de brainstorming amplamente utilizada no incio do projeto, ela objetiva coletar idias ou caracterstica inovadoras de um produto em um curto espao de tempo (AOUAD; ARAYICI, 2010, p.55). 3. Mtodos Analticos: As tcnicas classificadas no mtodo analtico so aquelas que exploram documentao existente, ou que utiliza deduo para adquirir conhecimentos e requisitos. As tcnicas que se enquadram no mtodo analtico so: a. Reuso de requisitos Consiste em tcnicas nas quais se procura

especificaes de requisitos em projetos anteriores que tenha potencial reutilizvel. Muitas das especificaes de requisitos utilizadas em projetos anteriores podem ser reutilizadas sem nenhum tipo de alterao, e muitas podem ser reutilizadas para um novo projeto com pequenas adequaes (ROBERTSON; ROBERTSON, 2006). Segundo Cybulski e Reed (2000), a reutilizao de requisitos fornece importantes ganhos tanto na produtividade quanto na qualidade no processo de desenvolvimento. As prximas sees abordaro mais detalhadamente sobre tcnicas de reuso por se tratar de um dos focos deste trabalho. b. Estudo e anlise de documentos Nessa tcnica, os requisitos so extrados de documentos informais. Os requisitos escondidos que possam estar 16

contidos nos documentos so extrados e registrados. No entanto, para os requisitos obtidos por esta tcnica devem estar relacionados com algum stakeholder que justifique a existncia desses requisitos (HULL et al., 2005, p. 100). c. Laddering (escada) Se trata de uma tcnica de questionamento estruturado que possibilita uma hierarquia de conceitos a ser estabelecidos

(CORBRIDGE et al., 1994). Laddering utiliza da tcnica de entrevista para obter uma compreenso de como os stakeholders percebem os atributos de produtos em associaes significativas com relao a si mesmo. A entrevista realizada de forma dirigida, as perguntas so do tipo "Por que isso importante para voc?". As questes realizadas na entrevista objetivam expressar um conjunto de ligaes entre os principais elementos de percepo em toda gama de atributos, consequncias e valores. Esse conjunto de ligaes, ou escada, referido como orientaes de percepo. As orientaes de percepo por sua vez, representam combinaes de elementos que servem de base para distino entre produtos e classes de um determinado produto (REYNOLDS; GUTMAN, 1988). Essa tcnica usada principalmente para esclarecer requisitos e categorizar entidades de domnio (ZOWGHI; COULIN, 2005, p.28). d. Carto de triagem (card sorting) uma tcnica usada para descobrir como os stakeholders classificam determinada informao em sua mente de acordo com seu prprio entendimento (ZOWGHI; COULIN, 2005, p.27). A tcnica consiste na utilizao de cartes, os quais so escritos termos os quais se pretende analisar como os stakeholders os entendem. Os participantes agrupam esses cartes da forma que for mais lgica para ele e depois rotula cada grupo de cartes. A tcnica aplicada individualmente, e no final os agrupamentos comuns geram o conceito que se buscava com a tcnica (LEITE, 2007). Segundo Wang et. al. (2006), carto de triagem um meio eficaz para suscitar ideias sobre a estrutura do conhecimento e muito til para ajudar os entrevistados a recordar conceitos do domnio. A tcnica de card sorting tambm muito utilizada por design para identificar a navegao em um sistema interativo (ZILSE, 2007; VAN AMSTEL, 2005).

17

e. Grade de repertrio uma tcnica derivada da Psicologia dos Construtos4 Pessoais (KELLY, 1955 apud FERNANDES, 2002). Nela o analista faz observaes de uma forma no intrusiva da percepo do mundo pelos stakeholders. As observaes so anotadas em uma matriz na qual existe uma relao estabelecida entre os construtos e elementos. Um sistema de pontuao responsvel por estabelecer a relao entre construtos, entre os elementos e entre construtos e elementos (FERNANDES, 2002). Conforme Steed e Macdonnell (2003), uma grade repertrio deve de expressar algo sobre a maneira como uma pessoa olha para as coisas. O apelo para Psicologia uma forma de se obter algo que difcil de expressar por outros meios. 4. Mtodos Sintticos: so mtodos nos quais se combina diferentes meios de comunicaes para demonstrar funcionalidade e interaes do sistema. Destacam-se como exemplo de tcnicas do mtodo sinttico as seguintes tcnicas: a. Cenrios uma tcnica muito utilizada para compreenso e validao de requisitos e desenvolvimento de casos de teste (ZOWGHI; COULIN, 2005, p. 31). uma narrativa que descreve uma viso geral de uma interao por parte dos stakeholders com o sistema. A narrativa representa normalmente um passo-a-passo do objetivo que se pretende alcanar (POTTS, 1995; ALEXANDER; STEVENS, 2002, p. 45). Segundo Sommerville (2007, p.153), os cenrios ajudam particularmente a adicionar um maior grau de detalhamento na descrio de requisitos. b. Storyboards Segundo Zowghi e Coulin (2005), storyboard uma tcnica utilizada para obter uma reao inicial dos stakeholders sobre um determinado conceito proposto para a aplicao. empregada no incio do ciclo de desenvolvimento, mesmo antes do desenvolvimento dos requisitos. Destaca-se como fatores positivos sobre os storyboarding, o fato de se tratar

Construtos definido uma unidade bsica de construo de significado, consistindo essencialmente em uma discriminao entre elementos, sendo que a construo de uma experincia ou acontecimento tem subjacente uma afirmao e uma negao simultneas (FERNANDES, 2002, p.82).

18

de uma tcnica extremamente barata, amigvel, informal e interativa (LEFFINGWELL; WIDRIG, 2003). c. Prototipao A prototipao uma tcnica indicada quando houver a criao de um sistema sem precedentes. Geralmente utilizada para dar uma ideia aos stakeholders do que pode ser possvel no projeto, proporcionando um maior entendimento de suas necessidades (HULL et al., 2005, p. 103). Ainda segundo Hull et al., (2005, p.103), existem alguns problema em se usar prottipos: (i) esforo considervel para construo de prottipos, (ii) prottipos tendem a fazer os stakeholders a mudarem facilmente de ideia, e (iii) prottipos tendem a impulsionar os stakeholders a utiliz-lo de forma operacional. d. Joint Application Development - JAD uma tcnica de reunio que visa acelerar o processo de desenvolvimento de software. utilizada como meio de se obter um senso comum entre os stakeholders. O JAD conduzido em quatro sesses: i. primeira reunio: as atividades dessa sesso so: (i) abertura pelo patrocinador; (ii) definio do escopo do projeto; (iii) definio dos objetivos especficos; (iv) descrio dos problemas com a abordagem atual, referente ao que o novo sistema ir resolver; (v) identificao dos stakeholders que sero entrevistados na atividade de elicitao de requisitos; (vi) definio da data da sesso de design5. ii. levantamento de dados e anlise. iii. planejamento para a sesso de design.

Sesso de Design uma reunio em que o Analista de Sistemas apresenta ao Condutor a proposta do sistema, para que o Condutor possa apresentar suas crticas e sugestes para uma melhor apresentao da proposta a ser debatida na reunio de design (PALUDO et al., 2009).

19

iv. reunio de design6: considera a sesso principal da tcnica do JAD, nesta etapa que feita a definio de objetivos, levantamento de problemas e limites do sistema, anlise dos processos, dados e interfaces do sistema, anlise do novo fluxo e necessidades administravas, apresentao do cronograma, aprovao do novo fluxo e avaliao da reunio. No final desta sesso elaborado o documento final, no qual consiste de todas as anotaes de todas as sesses realizadas e representa a concluso do grupo (JUDY, 1993 apud PALUDO et al., 2009). e. Inqurito contextual uma adaptao de tcnicas de etnografia, no qual se combina tcnicas de entrevistas, de observao do local de trabalho e prototipagem. essencialmente usado para design de sistemas interativos, nos quais o design interface do usurio crtica (HOLTZBLATT; BEYER, 1993; ZHANG, 2007).

RASTREABILIDADE DE REQUISITOS
A rastreabilidade uma das atividades da gerncia de requisitos (VLIET, 2007, p.236), mas

tambm uma atividade que apoia vrias atividades no processo de desenvolvimento de software. Seu emprego visa a melhoria de qualidade na obteno de sistemas de software (SPANOUDAKIS; ZISMAN, 2005; GENVIGIR, 2009). Utilizando-se do entendimento de Gotel e Finkelstein (1994), rastreabilidade de requisitos refere-se capacidade de descrever e acompanhar a vida de um requisito no ciclo de desenvolvimento, tanto para frente quanto para traz deste ciclo, e atravs de todas as variaes entre o modelo de desenvolvimento em um estgio do ciclo de vida de desenvolvimento de sistemas. Conforme Kulak e Guiney (2003), os requisitos devem ser identificados durante todo o ciclo de desenvolvimento do sistema. A rastreabilidade fornece suporte para auditoria de cada atividade no

A reunio de design uma reunio onde os atores envolvidos no projeto iro debater sobre a proposta. Neste sentido, esta reunio dividida da seguinte forma: i) apresentao, definio de objetivos, levantamento de problemas e limites do sistema; ii) anlise dos processos, dados e interfaces do sistema; iii) anlise do novo fluxo e necessidades administrativas surgidas; iv) cronograma, aprovao do novo fluxo e avaliao da reunio; e v) elaborao do documento final (PALUDO et al., 2009).

20

desenvolvimento e manuteno. O emprego correto de rastreabilidade no projeto descreve o porqu da atividade estar sendo realizada. A rastreabilidade pode ser enquadrada em duas classificaes gerais: i) rastreabilidade horizontal e vertical, e ii) pr-rastreabilidade e ps-rastreabilidade (GENVIGIR, 2009, p.39). Segundo Lindvall e Sandahl (1996), a rastreabilidade horizontal a classificao referente s diferentes verses ou variaes de requisitos ou artefatos. E rastreabilidade vertical refere-se a que realizada entre requisitos e artefatos produzidos ao longo do processo de software. A segunda classificao de rastreabilidade trata da pr-rastreabilidade e ps-rastreabilidade. Ambas se referem aos aspectos do ciclo de vida dos requisitos, porm a pr-rastreabilidade se concentra antes de serem includos na especificao dos requisitos e a ps-rastreabilidade se concentra aps a sua incluso na especificao de requisitos (GOTEL; FINKELSTEIN, 1994). Isso quer dizer que pr-rastreabilidade se preocupa com a produo dos requisitos e a ps-rastreabilidade no desenvolvimento dos requisitos. A Figura 3 ilustra o conceito de pr e a ps-rastreabilidade sugerido por Gotel e Finkelstein (1994).

Figura 3 - Pr e ps-rastreabilidade. Fonte: Adaptado de Gotel e Finkelstein (1994). Para Gotel e Finkelstein (1994), problemas na prtica de rastreabilidade foram encontrados pela falta da sua distino, e crucial o entendimento da diferena entre as duas classificaes. destacada como principal diferena a forma de lidar com as informaes e os problemas que a rastreabilidade pode ajudar. A pr-rastreabilidade depende da capacidade de rastreabilidade de requisitos para frente ou para trs, de volta a sua origem ou fontes (clientes, usurios, normas e etc.), atravs dos artefatos gerados ao longo do processo de engenharia de requisitos. Mudanas no

21

processo precisam ser refeitas na especificao de requisitos e devem ser propagadas a partir de sua fonte. A ps-rastreabilidade depende da capacidade de rastrear os requisitos para frente ou para trs de uma base de referncia. Neste caso, o documento de especificao de requisitos a base de referncia (baseline) e seu rastreabilidade realizada atravs dos artefatos que esto relacionados com os requisitos. Mudanas realizadas na baseline devem ser propagadas a todos os artefatos relacionados (GOTEL; FINKELSTEIN, 1994). Em relao rastreabilidade, existem tambm diversos tipos de relacionamentos, esses relacionamentos esto dispostos na literatura em oito grupos: i. Dependncia: neste tipo de relao, um elemento e1 depende de um elemento e2, se a existncia do elemento de e1 depende da existncia do elemento e2, ou se os impactos ocorridos em e2 tm que ser refletidos em e1; O seu papel de ajudar a gerencia dependncias entre objetos (este normalmente no mesmo estgio de desenvolvimento), que por muitas vezes impostas por uma restrio (recurso, competncia, compatibilidade). Esse relacionamento utilizado para registrar a composio e hierarquia dos objetos e para gerir as repercusses das mudanas em um objeto sobre outro que dele dependa (RAMESH; JARKE, 2001). ii. Generalizao/Refinamento: este relacionamento objetiva identificar como os elementos de um sistema complexo podem ser divididos em componentes, como os elementos podem ser combinados para originar outros elementos, e como um elemento pode ser refinado por outro elemento; iii. Evoluo: este relacionamento especifica a evoluo dos elementos, consiste em um elemento e1 evolves_to um elemento e2, se e1 for substitudo por e2 durante o processo de desenvolvimento. Seu propsito de permitir a identificao das origens dos objetos para melhor compreenso dos requisitos e outros objetos e para registrar informaes quanto s modificaes e histricos de refinamentos dos vrios objetos (SAYO; LEITE, 2005); iv. Satisfao: a relao em que um elemento e1 satisfaz um elemento e2, se em e1 corresponde s expectativas, necessidades e desejos para e2, ou se e1 corresponde as condies representadas por e2. Este relacionamento visa garantir que os requisitos 22

foram satisfeitos pelo sistema, registrando os desenhos criados para satisfazer requisitos e os componentes para os quais requisitos so alocados (SAYO; LEITE, 2005). Alguns exemplos de propsitos para sua utilizao seriam: assegurar a coerncia entre as sadas das diferentes fases do ciclo de vida, acompanhamento dos projetos criados para satisfazer os requisitos, e identificar o sistema/subsistema/ componentes que satisfaam requisitos e que cada componente satisfaa algum requisito; v. Sobreposio: esta relao corresponde a um elemento e1 que coincide com um elemento e2, e ambos se referem a uma caracterstica comum de um sistema ou ao seu domnio. O trabalho de Spanoudakis (2002) apresenta uma proposta para utilizao deste tipo de relacionamento, o estudo descreve regras que expressam heursticas para gerao dos relacionamentos de sobreposio baseando-se em padres sintticos especficos; vi. Conflitantes: neste tipo de relao existem conflitos entre os dois elementos e1 e e2. Este tipo de relaciona auxilia na indicao de conflitos relacionados entre requisitos, componentes, e elementos de projeto, para que se possa definir questes relacionadas a esses elementos, e para fornecer informaes que possam ajudar na soluo dos conflitos e problemas (SPANOUDAKIS; ZISMAN, 2005); vii. Racionalizao: esta relao usada para representa e manter a lgica por trs da criao e evoluo dos elementos, e as decises sobre o sistema em diferentes nveis de detalhe. Nesta relao o objetivo identificar as razes por trs da criao de vrios objetos, para isso so identificadas as seguintes razes: justificativa para criao/modificao dos objetos, decises importantes e as suposies feitas, identificao do contexto no qual o objeto foi criado, assegurar a transparncia no processo de deciso, incluindo alternativas descartadas (RAMESH; JARKE, 2001); e viii. Contribuio: este tipo de relacionamento visa representar as associaes entre os artefatos de requisitos e os stakeholders que tem contribudo para a gerao dos requisitos (SPANOUDAKIS; ZISMAN, 2005, p.5-8). Segundo Dick (2002), a atividade de rastreabilidade tornou-se uma prtica fundamental na engenharia de sistemas e a relao de ligao dos requisitos em um documento com os outros

23

artefatos do processo de software pode ser usada para vrios tipos de anlise, tais como: anlise de impacto, anlise de derivao, anlise de cobertura de impacto e anlise de cobertura de derivao. A capacidade para realizao dessas anlises proporciona um salto qualitativo no processo de engenharia de requisitos. Conforme Spanoudakis e Zisman (2005), alm de servir de base nas anlises relatadas por Dick (2002), a rastreabilidade tambm pode ser usada para anlise em processo de reutilizao dos componentes de sistema de software e na identificao e comparao das necessidades de sistemas novos com sistemas j existentes. Outro aspecto relatado pelos autores, a possibilidade de utilizar a rastreabilidade para permitir que os usurios tenham uma melhor compreenso das funcionalidades do sistema. Segundo Spanoudakis e Zisman (2005), a gerao de rastreabilidade pode ser feita de forma manual, automtica ou semi-automtica. A maioria dos instrumentos para o emprego de rastreabilidade limita o seu suporte para a criao das relaes de rastreabilidade manualmente. Porm, esse tipo de abordagem para gerao das relaes de rastreabilidade difcil de ser realizada, envolve maior complexidade, necessita de mais tempo para ser realizada e mais propensa a erros. Para aliviar estes problemas citados, faz-se necessrio a aplicao de alguma abordagem que d suporte a gerao automtica ou semi-automtica das relaes de rastreabilidade (SPANOUDAKIS; ZISMAN, 2005).

DOCUMENTO DE ESPECIFICAO DE REQUISITOS

O documento de especificao de requisitos o documento que dispe das declaraes

oficiais as quais os desenvolvedores devem implementar (SOMMERVILLE, 2007, p. 136). A especificao dos requisitos do sistema a atividade auge da anlise. neste ponto em que todas as descries das funes do sistema, restries do projeto, validaes apropriadas e outros dados pertinentes aos requisitos so documentados (PRESSMAN, 2002, p. 267). Sua utilizao tambm essencial para a elaborao de um contrato de desenvolvimento do software (SOMMERVILLE, 2007, p. 138). A concluso da sua reviso um marco final do processo de engenharia de requisitos, nas quais todas as atividades do processo de engenharia de requisitos foram concludas (VLIET, 2007 p.12). Segundo Smith (2006), a elicitao de requisitos, anlise e documentao so atividades importantes no processo de software, mas muitas vezes so realizadas de forma negligente e trazem 24

problemas nesta etapa do processo de desenvolvimento. Sem uma descrio precisa dos requisitos do produto muito improvvel que um desenvolvedor consiga entregar um produto que atenda as necessidades do seu cliente. Entretanto, se o desenvolver j tem uma boa compreenso do problema pode ser que se aproxime do produto esperado sem utilizar-se de uma documentao dos requisitos, mas dificilmente isso ocorrer porque normalmente as potenciais divergncias fazem produzir um documento de especificaes de requisitos (PARNAS, 2000). Conforme Smith (2006), a documentao dos requisitos importante porque os problemas que envolvem a computao so complexos, com muitas fontes potenciais para ambiguidade no entendimento de terminologias e notaes. Parnas (2000) ressalta a importncia do documento de especificao de requisitos afirmando que a sua concluso dada de forma incompleta ou inconsistente pode levar ao fracasso ou abandono do projeto ou implementaes de necessidades equivocadas pelos desenvolvedores. Porm, ressalta-se que a documentao precisa propicia muitos benefcios no processo de desenvolvimento. Segundo Van Schouwen et al. (1993), esses benefcios so: 1) os profissionais que trabalham no projeto do software tm uma melhor viso do que esto construindo, antes de prosseguir o seu trabalho; 2) a reviso das especificaes com os stakeholders pode ser feita de forma a verificar se suas necessidades esto sendo satisfeitas; 3) os profissionais responsveis pela garantia da qualidade podem verificar uma implementao contra uma declarao de comportamento exigido e pode formular testes de validao sem olhar o cdigo fonte; 4) a equipe de manuteno pode se familiarizar mais facilmente com o sistema, podendo manter o design original quando houver intenes de fazer alteraes. Smith (2006) refora alguns desses benefcios e contribui em destacar mais alguns como: 1) nica maneira de julgar a exatido e confiabilidade do software por comparao com as especificaes dos requisitos; 2) possibilidade de documentar claramente as especificaes das premissas e restries de dados.

25

Segundo Pressman (2002, p.259), o modo de realizar a especificao se reflete na qualidade da soluo. Neste sentido, como caractersticas de uma boa especificao de requisitos, a norma Std 830-1998 (1998, p.4) contribui em destacar que a especificao de requisitos deve ser: a) Correta: considerada correta quando todos os requisitos registrados nele sero correspondidos pelo software. b) No ambgua: quando o requisito expresso tem uma nica interpretao. c) Completa: refere-se a que todos os requisitos significantes estejam reconhecidos e tratados, e que todas as respostas do software estejam definidas, que todas as figuras, tabelas e diagramas estejam com suas respectivas legendas e referncias completas, bem como a definio de todos os termos e unidades de medidas utilizadas no documento. d) Consistente: nenhum subconjunto individual de requisitos descrito entra em conflito com outro requisito. e) Classificado por importncia e/ou estabilidade: refere-se associao de um requisito expresso no documento a um identificador de importncia e/ou estabilidade. f) Verificvel: a verificao de um requisito pode ser feita por um processo finito, no qual uma mquina ou uma pessoa possa fazer a sua verificao quanto a sua implementao no produto de software. g) Modificvel: esta caracterstica implica quanto estrutura e estilo aos quais mudanas a requisitos possam ser efetuados de forma fcil, completa e consistente, e ainda preservando a estrutura e estilo. h) Rastrevel: refere-se quanto facilidade a qual um requisito consiga identificar a sua origem e suas verses futuras no processo de desenvolvimento. Alm dessas caractersticas, Young (2006) complementa como caractersticas desejveis: a) Necessrio : quanto o requisito atende as necessidades reais do sistema.

26

b) Possvel: refere-se a quanto um requisito factvel e pode ser realizado dentro do oramento e cronograma. c) Conciso: o requisito deve ter uma declarao breve, resumida e exata. d) Usar construtor padro: o requisito deve ser declarado no imperativo, utilizando-se da palavra dever. e) Implementvel: possvel de traduzir para o projeto. f) Clusulas evasivas: recomenda-se a no utilizao de palavras que implicam excees ou termos especulativos. Como por exemplo: se, quando, mas, exceto, a menos que, embora, geralmente, frequentemente e tipicamente. Conforme Sommerville (2007, p. 137), o documento de especificao de requisitos visa atender diferentes stakeholders. Alguns destes possveis stakeholders so apresentados na Figura 4. Para esses stakeholders, o documento de especificao de requisitos tem que ser um compromisso de comunicao, definindo em detalhes as informaes sobre as necessidades dos clientes, como tambm informaes de possvel evoluo do sistema.

Clientes

Especificam os requisitos e os lem para verificar se eles atendem a suas necessidades. Especificam as mudanas nos requisitos.

Gerentes

Utilizam o documento de especificao de requisitos para planejar um pedido de proposta para o software e para planejar o processo de desenvolvim ento.

Engenheiros de software

Utilizam os requisitos para compreender o sistema que deve ser desenvolvido.

Engenheiros de testes

Utilizam os requisitos para desenvolver testes de software.

Engenheiros de manuteno

Utilizam os requisitos para ajudar a compreender o software e as relaes entre as suas partes.

Figura 4 - Usurios de um documento de especificao de requisitos de software. Fonte: Sommerville (2007, p. 137).

27

Pressman (2002, p. 271) colabora em afirmar que uma reviso do documento de especificaes de requisitos fundamental para garantir que os stakeholders tenham a mesma percepo do sistema. Essa reviso deve ser conduzida de forma a descobrir problemas que possam estar ocultos no contedo do documento. De um modo geral, um documento de especificao de requisitos deve sempre descrever as seguintes questes (IEEE Std 830-1998, 1998, p.3): Funcionalidades: Refere-se ao que o software deve fazer. Interfaces externas: descreve questes relacionadas com a interao do software com as pessoas. Performance ou Desempenho : Referente a questes de velocidade, disponibilidade, tempo de resposta, tempo de recuperao, entre outras. Atributos: Refere-se s questes de portabilidade, correo, manuteno, segurana, etc. Restries: Preocupa-se com as questes quanto as restries impostas a implementao do projeto. Outra orientao feita pela norma IEEE Std 830-1998 (1998), diz respeito estrutura do documento de especificao de requisitos. A Figura 5 ilustra um esboo da estrutura de um documento de especificao de requisitos obtido na norma IEEE Std 830-1998 (1998, p.11). Em nada implica a mudana dos nomes dos dados, porm todas essas informaes devem ser includas para obter-se um bom documento de especificao de requisitos.

28

1. Introduo 1.1. Propsito 1.2. mbito 1.3. Definies, acrnimos e abreviaturas 1.4. Referncias 1.5. Organizao 2. Descrio geral 2.1. Perspectiva do produto 2.2. Funcionalidades do produto 2.3. Caracterstica do utilizador 2.4. Restries 2.5. Assunes e dependncias 3. Requisitos Apndices ndice

Figura 5 - Esboo de um documento de especificao de requisitos. Fonte: IEEE Std 830-1998 (1998, p.11). Segundo as orientaes da Std 830-1998 (1998, p.11-15), a Seo 1 disposta na Figura 5, refere-se introduo do documento de especificao de requisitos, devendo fornecer informaes de uma viso geral de todo documento. A Seo 2 para um documento de especificao de requisitos deve descrever os fatores gerais que afetam o produto e seus requisitos, contribuindo para um melhor entendimento dos requisitos que so apresentados detalhadamente na Seo 3. A Seo 3 deve conter todos os requisitos de software, esses requisitos devem ser detalhados a um nvel que permita que os projetistas e equipe de testes possam projetar e testar um sistema visando satisfazer esses requisitos. Ressalta-se em Std 830-1998 (1998, p.15), que os requisitos declarados na Seo 3, devem incluir, no mnimo, um estmulo como descrio de cada entrada no sistema, cada resposta de sada do sistema, bem como todas as funes desempenhadas pelo sistema ao responder uma entrada ou apoiar uma sada. Conforme Hull et al. (2005, p.75), a organizao dos requisitos em uma estrutura correta pode beneficiar nos seguintes pontos: minimizar o nmero de requisitos; compreender grandes quantidades de informao; encontrar conjuntos de requisitos relativos a temas especficos; deteco de omisses e duplicaes de requisitos; eliminar os conflitos entre os requisitos;

29

 gerir iterao (por exemplo, requisitos em atraso); rejeitar requisitos pobres; avaliar os requisitos; reuso de requisitos de outros projetos. Segundo Wiegers (2006), requisitos nunca so acabados ou completos. Alguns cuidados devem ser tomados para no chegar a uma paralisia da anlise, pois o sucesso do negcio no est na escrita perfeita de um documento de especificao de requisitos. Esta etapa deve ser concluda quando se obteve requisitos de sistemas bons o suficiente para que a equipe possa prosseguir com o projeto.

CONCLUSO
Este relatrio tcnico oferece discusso sobre os conceitos bsicos sob os aspectos gerais de

Engenharia de Requisitos, bem como seu processo e atividades. Foram abordados tambm os principais aspectos sobre a prtica da atividade de rastreabilidade e a descrio dos aspectos que envolvem o documento de especificao de requisitos. A Engenharia de Requisitos oferece atividades, no qual se pode coletar, especificar, analisar/verificar e gerenciar os requisitos. A preocupao da engenharia de requisito est em entender as necessidades reais do sistema, e document-la.

30

REFERNCIAS BIBLIOGRFICAS
ALEXANDER, I. F., STEVENS, R. Writing Better Requirements, Pearson Education: Great Britain, 2002 AOUAD G., ARAYICI, Y. Requirements Engineering for Computer Integrated Environments in Construction, Wiley-Blackwell: United Kingdom, 2010 BARBOSA, B., WERNECK, M., ASSIS, H., FERNANDES, U., SILVA, I. Um processo de elicitao de requisitos com foco na seleo da tcnica de elicitao, SBQS 2009 - VIII Simpsio Brasileiro de Qualidade de Software, 2009 BOEHM, B., BASILI, V. R.. Software Defect Reduction Top 10 List, IEEE Computer. 34(1); Los Alamitos, CA: IEEE Computer Society; 2001, doi:10.1109/2.962984 CHENG, B. H. C., ATLEE, J. M. Research Directions in Requirements Engineering, International Conference on Software Engineering 2007 Future of Software Engineering, IEEE Computer Society Washington, DC, USA, 2007, ISBN:0-7695-2829-5 CHRISTEL, M. G., KANG, K. C. Issues in Requirements Elicitation, Technical Report Software Engineering Institute CMU/SEI-92-TR-12.7, September 1992. Disponvel em:http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf. Acessado outubro de 2009. CORBRIDGE, C., RUGG, G., MAJOR, N. P., SHADBOLT, N. R., BURTON, A.M. Laddering: technique and tool use in knowledge acquisition, Knowledge acquisition, 6, pp. 315-341, 1994. CYBULSKI, J. L., REED, K. Requirements Classification and Reuse: Crossing Domain Boundaries. In Conference on Software Reuse, ICSR'2000, (Vienna, Austria, 2000), 190-210, 2000 CYSNEIROS, L. M. Requisitos No Funcionais: Da Elicitao ao Modelo Conceitual, PUCRio, Tese de Doutorado e Cincias da Computao, 2001 CYSNEIROS, L. M., LEITE, J. C. S. P. Utilizando Requisitos No Funcionais para Anlise de Modelos Orientados a Dados, Anais do WER98 - Workshop em Engenharia de Requisitos, Maring-PR, Brasil, Outubro 12, 1998, pp 149-158. Disponvel em: <http://wer.inf.pucrio.br/WERpapers/artigos/artigos_WER98/cysneiros.pdf>. Acessado junho de 2010 DAVEY, B; COPE, C. Requirements Elicitation Whats Missing?, Issues in Informing Science and Information Technology, vol.5, 2008 DICK, J. Rich Traceability, Proceedings of the 1st International Workshop on Traceability in Emerging Forms of Software Engineering, Edinburgh, Scotland, 2002 FERNANDES, E. M. Grelha de Repertrio, Universidade do Minho. Centro de Estudos em Educao e Psicologia, 2002. Disponvel em http://repositorium.sdum.uminho.pt/bitstream/1822/4210/1/Grelha%20de%20Repert%C3%B3rio.p df. Acessado em junho de 2010

31

FREITAS, D. P.; BORGES, M. R. S., ARAJO, R. M. Colaborao e Negociao na Elicitao de Requisitos, In IDEAS - Workshop Iberoamericano de Ingenieria de Requisitos y Ambientes de software, Venezuela - Maio 2007, Disponvel em: http://kuainasi.ciens.ucv.ve/ideas07/documentos/articulos_ideas/Articulo74.pdf, Acessado outubro de 2009 GENVIGIR, E. C. Um modelo para rastreabilidade de requisitos de software baseado em generalizao de elos e atributos, So Jose dos Campos - SP, INPE, Tese de dourado em computao aplicada, 2009 GOTEL, O. C. Z., FINKELSTEIN, C. W. An Analysis of the Requirements Traceability Problem, Proceedings of the First International Conference on (22 April 1994), pp. 94-101, 1994 GOTTESDIENER, E. Good Practices for Developing User Requirements, Crosstalk - The Journal of Defense Software Engineering, March, 2008 HICKEY A. M., DAVIS, A. M. Elicitation technique selection: How do experts do it? In Proceedings of the 11th IEEE International requirements engineering conference, Monterey Bay, CA, pp. 169-178, 2003 HOLTZBLATT, K., BAYER, H. Making customer-centered design work for teams. Comm. ACM, Volume 36, Issue 10, 1993 HOOD, C., WIEDEMANN, S., FICHTINGER, S., PAUTZ, U. Requirements Management: The Interface Between Requirements Development and All Other Systems Engineering Processes. Springer-Verlag Berlin Heidelberg, 2008. ISBN 978-3-540-47689-4 HULL, E., JACKSON, K., DICK, J. Requirements Engineering, Second Edition, Springer London Berlin Heidelberg, 2005 IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, Nova Iorque: IEEE, 1998. ISBN 0-7381-0332-2 ISO/IEC Std. 15504. Information Tecnology - Process Assessment - Part 5, International Organization for Standardization, 2005 JUDY, A. H. Joint Application Design. So Paulo: Markron Books, 1993 KELLY, G. The psychology of personal constructs. New York: Norton, 1955 KOTONYA, G., SOMMERVILLE, I. Requirements Engineering: Process and Techniques. Editora John Wiley and Sons. 1998. KULAK, D., GUINEY, E. Use Cases: Requirements in Context, Second Edition, Addison Wesley, 2003 LEFFINGWELL, D., WIDRIG, D. Managing Software Requirements: A Use Case Approach, Second Edition, Addison Wesley, 2003 LEITE, J. C. S. P. Tcnicas de Coleta de Fatos (Elicitao), setembro de 2007, em Livro Vivo: Engenharia de Requisitos, http://livrodeengenhariaderequisitos.blogspot.com/, 2007. Disponvel

32

em: <http://livrodeengenhariaderequisitos.blogspot.com/2007/09/tcnicas-de-coleta-de-fatoselicitao.html>. Acessado em maro de 2010. LINDVALL M., SANDAHL, K., Practical Implications of Traceability, Software Practice and Experience, v. 26, n. 10, pp. 1161-1180, 1996 LIU, L., LI, T., PENG, F. Why Requirements Engineering Fails: A Survey Report from China, Requirements Engineering Conference (RE), 2010 18th IEEE International, 2010 MICHAELIS, Dicionrio Michaelis: Moderno dicionrio da lngua portuguesa , So Paulo, Companhia Melhoramentos, 1998 (Dicionrios Michaelis) NUSEIBEH, B., EASTERBROOK, S. Requirements Engineering: A Roadmap, Proceedings of International Conference on Software Engineering (ICSE-2000), Limerick, Ireland : ACM Press, 2000 PALUDO, M.A.; BURNETT, R.C.; LOCH, J.M.; REIS, D. Desenvolvimento de Software Aplicando a Tcnica Joint Application Design, 2009. Disponvel em: http://www.pg.utfpr.edu.br/ppgep/Ebook/ARTIGOS/56.pdf. Acessado em junho de 2010 PARNAS, D. L. Requirements Documentation: Why a Formal Basis is Essential, Proceedings. 4th International Conference on Requirements Engineering, 2000, pp. 81-82 POTTS, C. Using Schematic Scenarios to Understand User Needs, Proc. DIS95 - ACM Symposium on Designing interactive Systems: Processes, Practices and Techniques, University of Michigan, 1995 PRESSMAN, Roger S. Engenharia de software, 5 edio. MacGraw-Hill, 2002. RAMESH, B., JARKE, M. Towards Reference Models For Requirements Traceability, IEEE Transactions in Software Engineering, 27(1), 58-93, 2001 REYNOLDS, T. J., GUTMAN, J. Laddering Theory, Method, Analysis, and Interpretation, Journal of Advertising Research, Vol. 28, No. 1. pp. 11-31, 1988 ROBERTSON, S. ROBERTSON, J. Mastering the Requirements Process, Second Edition. Addision Wesley Professional, Maro 17, 2006 SAYO, M., LEITE, J. C. S. P. Rastreabilidade de Requisitos, RITA Vol. XII N1, 2005 SEI, Software Engineering Institute. CMMI for Development, Version 1.3 (CMMI-Dev V1.3). Novembro, 2010a. Disponvel em < http://www.sei.cmu.edu/reports/10tr033.pdf > acessado em janeiro de 2011 SMITH, S. Systematic Development of Requirements Documentation for General Purpose Scientific Computing Software, Proceedings of the 14th IEEE International Requirements Engineering Conference, RE 2006, pages 209-218, Minneapolis/St. Paul, Minnesota, 2006 SOFTEX, Sociedade para Promoo da Excelncia do Software Brasileiro. MPS.BR - Melhoria de Processo do Software Brasileiro, V2009, Atualizado em Setembro de 2009, Disponvel em

33

http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf, acessado em junho de 2010 SOMMERVILLE, Ian. Engenharia de software, 8 edio. So Paulo: Pearson Addison Wesley, 2007. SPANOUDAKIS, G., Plausible and Adaptive Requirement Traceability Structures, in Proc. 14th International Conference Software Eng. and Knowledge Eng, 2002. SPANOUDAKIS, G., ZISMAN, A., Software Traceability: A Roadmap. Advances in Software Engineering and Knowdledge Engineering, Vol. 3: Recent Advances,(ed) S.K Chang, World Scientific Publishing, ISBN:981-256-273-7, Agosto de 2005 STEED, A., MACDONNELL, J. Experiences with repertory grid analysis for investigating effectiveness of virtual environments. Proceedings of the 6th International Workshop on Presence, Denmark, 2003 SWEBOK. Guide to the Software Engineering Body of Knowlegment, IEEE Computer Society, 2004. Disponvel em http://www.computer.org/portal/web/swebok/htmlformat. Acesso em outubro de 2009. TAMAI, T., KAMATA, M. L. Impact of Requirements Quality on Project Success or Failure, Design Requirements Engineering: A Ten-Year Perspective, Lecture Notes in Business Information Processing, 14, 258-275, 2009 VAN AMSTEL, F. Card-sorting melhor que buraco , 2005. Disponvel em: http://usabilidoido.com.br/cardsorting_e_melhor_que_buraco.html. Acessado em julho de 2010 VAN SCHOUWEN, A.J., PARNAS, D.L., and MADEY, J. Documentation of Requirements for Computer Systems. Proceedings of the Requirements Engineering Symposium - RE 93, San Diego, CA, 1993, Janeiro 1993, pp. 198-207. VLIET, H. V. Software Engineering: Principles and Practice, Wiley, 2007 WANG, Y., SURE, Y., STEVENS, R., RECTOR, A. Knowledge Elicitation Plug-in for Protg: Card Sorting and Laddering, Asian Semantic Web Conference (ASWC'06), Beijing, China, 2006 WIEGERS, K. E. More About Software Requirements: Thorny Issues and Practical Advice, Microsoft Press, ISBN:0735622671, 2006 YOUNG, R. R. The Requirements Engineering Handbook . Artech House, 2004 ZHANG, Z; Effective Requirements Development - A Comparison of Requirements Elicitation techniques, SQM2007 conference, 2007 ZILSE, R. Card sorting no tudo, 2007. Disponvel em: http://webinsider.uol.com.br/2007/08/29/card-sorting-nao-e-tudo. Acessado em julho de 2010. ZOWGHI, D., COULIN, C. Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. In AURUM, A., WOHLIN, C. Engineering and Managing Software Requirements, Springer: Germany, 2005, p.19-46.

34

35