VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Mtodo para Definio de Requisitos de Software de um Sistema a Partir das Necessidades dos seus Stakeholders
Ana Lcia de Sousa Sampaio1, Francisco Formoso Primo1, Wagner Roberto De Martino1
1

Centro de Pesquisas Renato Archer CenPRA Rodovia D. Pedro I - SP 65 - Km 143,6 13069-901 Campinas SP Brasil

{ana-lucia.sampaio@cenpra.gov.br francisco.formoso@cenpra.gov.br wagner.de-martino@cenpra.gov.br }

Resumo. Este artigo descreve um mtodo de definio de requisitos de software de um sistema a partir das necessidades dos seus stakeholders. Abrange as atividades iniciais de Engenharia de Requisitos: a captura, a anlise e o registro dos requisitos. So descritos procedimentos que possibilitam desde a captura das necessidades dos stakeholders at o registro dos requisitos de uma forma segura e eficiente que permite a sua manuteno e controle. O registro permite o rastreamento bidirecional desde os stakeholders e suas necessidades at os respectivos requisitos. O mtodo descrito serve de base para um prottipo de aplicao sendo implantado no DMPS/CenPRA pelo grupo de requisitos.

1. Introduo
Embora a Engenharia de Software venha afirmando sistematicamente a necessidade da especificao de requisitos, comum, nos atuais ambientes de desenvolvimento de software, que ela ainda seja realizada de maneira informal e artesanal. Quando finalmente o produto fica pronto, no h registro das necessidades que o geraram e, na melhor da hipteses, os requisitos esto documentados. Decorrente deste fato, qualquer validao do produto ser feita sobre os requisitos e no sobre as necessidades que motivaram o seu desenvolvimento. Os motivos de tal comportamento podem ser o imediatismo por resultados, a reduo de custos e a busca de uma suposta flexibilidade no desenvolvimento. Tudo isso resulta, ao contrrio do esperado, em projetos que estouram em prazos e recursos; produtos que no satisfazem as necessidades de seus clientes e que so de difcil manuteno e evoluo. Uma dificuldade que se apresenta sempre aos desenvolvedores de sistemas de software que o entendimento claro de um problema normalmente surge apenas durante a sua resoluo. Raros so os problemas que podem ser perfeitamente entendidos antes de comearem a ser resolvidos. Todos os envolvidos no desenvolvimento precisam estar conscientes da existncia dos dois domnios:

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

domnio do problema onde situam-se o negcio e todos os nele interessados, isto , os stakeholders que possuem aspiraes e expectativas que gostariam de ver satisfeitas pela explorao do negcio s quais denominaremos necessidades; domnio da soluo onde um sistema definido com a finalidade de tornar operacional e de facilitar a implantao do negcio. O sistema deve fornecer um ou mais servios que enderece cada necessidade, as features. Cada feature, por sua vez, para ser efetivada demanda um conjunto de recursos, qualidades e restries aos quais denominaremos requisitos. Convm ressaltar que a fronteira entre os dois domnios nem sempre muito ntida e exige, durante a definio dos requisitos, que os envolvidos na tarefa distingam entre os dois domnios e saibam em qual se est trabalhando. Nos prximos itens, apresenta-se um mtodo para a definio de requisitos de software de um sistema a partir das necessidades dos seus stakeholders. So descritos tambm, procedimentos e instrumentos destinados a operacionalizar o mtodo de captura, anlise e registro dos requisitos e as respectivas origens, bem como suas caractersticas mais relevantes, que propiciem recursos necessrios para a implantao de uma efetiva gerncia de requisitos.

2. Motivao
Este trabalho busca caracterizar melhor os domnios envolvidos no desenvolvimento de um sistema de software e possibilitar que qualquer soluo encontrada possa ser validada na sua origem. So fornecidos subsdios para quebrar o paradigma validao sobre os requisitos especificados e baseia-se no princpio de que os sistemas devem ser construdos a partir de uma definio rigorosa dos seus objetivos e que leve em considerao as expectativas de todos os interessados na sua construo. Todos os mtodos de definio de requisitos levam em considerao as necessidades que devem ser atendidas pelo sistema. Ento, onde reside a diferena que justifique mais um no conjunto de mtodos? Nos mtodos atuais os requisitos de software evoluem durante o seu desenvolvimento, mas o conjunto de necessidades que os originaram permanece esttica; desconsidera-se o fato de que necessidades novas podem surgir, algumas podem desaparecer e muitas provavelmente devero ser ajustadas, corrigidas ou melhoradas para continuarem existindo. No antigo paradigma, as necessidades so tratadas informalmente, no evoluem aps estar pronta a especificao dos requisitos. Isso torna o produto cada vez mais distante das necessidades que o originaram. Mantendo o registro das necessidades e permitindo a sua atualizao temos, como reflexo, uma melhor qualidade e um prolongamento na vida til do produto. claro que isso tem seu preo: h um aumento na complexidade no desenvolvimento do projeto pois mais informaes precisam ser controladas. Acreditamos que a qualidade adicionada ao produto final e a satisfao dos stakeholders compense o custo adicional.

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Embora o presente mtodo no tenha nenhuma restrio de aplicabilidade, ele foi concebido tendo em vista sua aplicao em organizaes de desenvolvimento de software de pequeno e mdio porte. Tal preferncia se justifica pela grande carncia que pode ser observada nessas organizaes e pela misso do Centro de Pesquisas Renato Archer - CenPRA em atend-las j que as grandes organizaes em geral j possuem polticas e recursos para tanto.

3. Viso Geral do Mtodo

Os requisitos de um sistema especificam o conjunto de funcionalidades que ele deve prover para satisfazer as necessidades de todos os seus stakeholders, as caractersticas de qualidade e as restries a que devem estar sujeitas as funcionalidades. Os proponentes de um sistema sempre anseiam por benefcios sejam eles financeiros, tcnicos, sociais ou polticos e justamente para atender esses anseios que so projetados os sistemas. Um sistema representa uma soluo aos problemas decorrentes da explorao de um negcio. Numa primeira classificao, os requisitos de um sistema pertencem a uma das seguintes categorias: requisitos funcionais e requisitos no funcionais. Os requisitos funcionais especificam as funes que devem ser desempenhadas pelo sistema e os requisitos no funcionais especificam qualidades que o sistema deve possuir assim como suas condies ou restries de operao. A definio de requisitos consiste, na verdade, na compreenso de um dado problema, e a definio das caractersticas e restries para a soluo desse problema. A compreenso do problema, ou seja, o negcio, os stakeholders e suas necessidades pertencem ao domnio do problema e as caractersticas e restries do sistema pertencem ao domnio da soluo. Uma dificuldade que se apresenta nesse processo que, para os stakeholders, a separao entre esses dois domnios no ntida. As pessoas tm a tendncia de elaborar caractersticas e definir restries antes de compreender detalhadamente necessidades relativas a elas e isto natural, pois a compreenso de um problema s vezes demanda o esboo de elementos para a sua soluo. O mtodo aqui apresentado concebido de forma tal que os elementos do domnio do problema so capturados e os do domnio da soluo so vislumbrados e definidos permitindo que a fronteira entre os domnios seja cruzada nos dois sentidos vrias vezes durante a elicitao. Desta forma as necessidades, caractersticas e restries so definidas num processo incremental e iterativo a partir de entrevistas com stakeholders e anlise e sntese de especialistas de requisitos. Alm disso, o mtodo registra o histrico de cada requisito, da necessidade que o gerou aos artefatos utilizados na anlise. A definio de requisitos realizada em duas etapas sendo que ambas so conduzidas pelos especialistas de requisitos que devem ser direcionados por aspectos institucionais, ambientais e pelas fronteiras ou bordas do problema.

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Na etapa 1 determinam-se quais so os grupos funcionais de stakeholders (gerentes, desenvolvedores, patrocinadores, agentes reguladores, usurios,...), definem-se a populao de cada grupo e respectivos representantes. Na etapa 2 feita a captura das necessidades dos stakeholders e, para cada necessidade, determinado um conjunto de features e para cada feature os requisitos necessrios ao seu atendimento. 3. Definio dos Stakeholders A sistemtica para a definio de stakeholders baseada no modelo proposto por Ian Alexander [1] e detalhada nas sees seguintes. 3.1. Modelagem dos stakeholders e Sistemtica de Aplicao Na modelagem escolhida, como ponto de partida necessrio estabelecer a estrutura do conjunto dos provveis stakeholders e, em seguida, definir como esse conjunto ser preenchido. A estrutura de stakeholders adotada conhecida como diagrama da cebola e esquematizada na Figura 1.
Todo o Ambiente (principalmente social)
Beneficirio Financeiro

Sistema envolvente (tambm scio- tecnico ) Nosso Sistema (scio- tecnico )

Outros Sistemas

KIT (Sw +Hw)

Beneficirio Poltico Beneficirio Funcional Operador Normal

(tcnico)

Legislador

Consultor Comprador

Suporte Operacional

Operador Manuteno Stakeholder Negativo

Desenvolvedor

Figura 1 Organizao dos Stakeholders (Diagrama da Cebola) O diagrama constitudo por quatro crculos concntricos nos quais situam-se diversas classes de stakeholders, ou slots, simbolizados pela figura e o respectivo nome da classe representada. As classes so dispostas nos crculos de forma que nos mais externos estaro aquelas mais envolvidas com aspectos do negcio. Caminhando-se no sentido do centro sero encontradas classes cada vez mais envolvidas com o sistema que implementa a soluo. nos slots que sero alocadas pessoas que iro desempenhar os papis relevantes na definio dos requisitos. A organizao dos stakeholders, utilizando o diagrama da cebola, genrica e precisa ser adaptada dependendo do problema sendo abordado, de aspectos organizacionais e culturais do seu ambiente. Estabelecida esta organizao, necessrio escolher quais os

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

slots relevantes, popul-los e definir representantes para cada um deles. Alm disso, tambm necessrio definir a relevncia da opinio de cada slot quando da tomada de decises, atravs da atribuio de pesos a cada um deles. Esses assuntos devero ser tratados durante os primeiros contatos envolvendo os proponentes do produto e os especialistas responsveis pela definio dos requisitos.

Beneficirio Financeiro

Outros Sistemas

Proponente
Beneficirio Poltico Beneficirio Funcional Operador Normal

SW + HW

Legislador

Instrumentos
Especialistas de Requisitos

Consultor

Suporte Operacional Comprador

Operador Manuteno

Stakeholder Negativo

Desenvolvedor

Figura 2 Definio da organizao de stakeholders A Figura 2 exemplifica a definio da organizao dos stakeholders: levando em considerao o domnio do negcio, aspectos organizacionais, ambientais e o contexto vislumbrado para o sistema. Os especialistas de requisitos em conjunto com os representantes do slot que contm o papel do proponente do sistema devero escolher, popular, definir e registrar representantes para os demais slots. O processo acima esboado poder resultar em um ou mais slots vazios, o que significa que, para o desenvolvimento do projeto em questo, os papis que seriam contidos naqueles slots foram considerados irrelevantes. Na figura 2 temos: simboliza um slot considerado relevante na definio dos requisitos e simboliza slot considerado irrelevante e que portanto no ser populado. , tambm, nesta reunio inicial que, dependendo do tipo de organizao, nmero e diversidade de stakeholders envolvidos, so definidos os instrumentos a serem utilizados no processo, tanto para a captura de necessidades como para a definio de features e requisitos. 3.2 Estabelecimento de necessidades, features e requisitos As necessidades, features e requisitos so definidos incremental e iterativamente medida que novos elementos vo sendo agregados e os elementos existentes

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

aprimorados. Esta etapa, para melhor entendimento, dividida em quatro fases que so descritas nas sees seguintes. A Figura 3 ilustra o processo de captura das necessidades dos stakeholders e a partir delas o estabelecimento do conjunto de features e requisitos..
Features
ESCOLHA DE FEATURES Anlise em conjunto com Stakeholders donos da Necessidade DEFINIO DE REQUISITOS Anlise em conjunto com Stakeholders e Especialistas

Problema

Escopo

Requisitos

NEGOCIAO Deciso em Plenria

LEVANTAMENTO DAS NECESSIDADES Entrevistas + Anlise no Slot

Necessidades

Figura 3: Processo de definio de Necessidades, features e requisitos A volta mais interna da espiral representa a primeira compreenso do conjunto das necessidades at a definio dos requisitos que as endeream. As demais voltas representam aperfeioamentos sobre os resultados anteriores. Devido a um melhor entendimento do problema, novos elementos podem surgir, alguns podem desaparecer ou serem modificados at que se chegue a um resultado julgado necessrio e suficiente para iniciar o desenvolvimento propriamente dito. Conforme sugere a figura o processo iterativo e constitudo por quatro fases, cada uma representada por um quadrante. No quadrante 1, LEVANTAMENTO DAS NECESSIDADES, parte-se do conjunto anterior de necessidades e atravs de procedimentos e instrumentos especficos envolvendo especialistas de requisitos e representantes dos slots vo sendo colhidas e incorporadas as necessidades. Quando todos os slots forem considerados os especialistas estaro de posse de um conjunto de necessidades dos slots e tal conjunto ter redundncias e incongruncias minimizadas. O quadrante 2, NEGOCIAO, representa uma negociao em que as necessidades apuradas anteriormente so submetidas apreciao de uma plenria cujos participantes tm poder de deciso. Tal plenria tem como objetivo a definio do escopo do projeto, ou seja, definir quais as necessidades que devero ser atendidas por ele. Esse conjunto de necessidades servir como base para a definio dos requisitos. As necessidades

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

recusadas sero mantidas no sistema a ttulo de histrico no sendo mais objeto de anlise do projeto. No quadrante 3, ESCOLHA DE FEATURES, cada necessidade constante do escopo do projeto objeto de anlise com o objetivo de definir pelo menos uma feature do futuro sistema que a atenda. Podem existir diversas features alocadas a uma necessidade mas nenhuma necessidade pode ficar sem uma feature alocada. Essa parte do processo executada por especialistas que, com o auxlio dos stakeholders que deram origem s necessidades, buscam uma soluo adequada ela. O resultado um conjunto de features em que cada uma descrita na forma de caso de uso com um nvel alto de abstrao. No ltimo quadrante, DEFINIO DE REQUISITOS, as features so trabalhadas no sentido de se chegar a um conjunto de recursos ou requisitos que as suporte. Tal tarefa deve ser comandada pelos especialistas de requisitos auxiliados por stakeholders tcnicos e especialistas. O resultado um conjunto dos requisitos do projeto descritos na forma de casos de uso com um nvel de detalhes que permita o seu entendimento por qualquer interessado. Note-se que o processo inicia-se com a proposta do problema pelos interessados no desenvolvimento do sistema. Na primeira volta da espiral, a mais interna, obtida a maioria das necessidades, features e requisitos. As voltas adicionais da espiral sugerem que os conjuntos de necessidades, features e requisitos podem sempre ser alterados seja para modificao, incorporao ou remoo de elementos.

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

3.2.1 Captura das necessidades, negociao e definio de escopo O processo de captura de necessidades realizado mediante a aplicao de instrumentos de captura, anlise, definio e registro de elementos capturados envolvendo representantes de todos os slots. Inicia-se pelo slot do proponente e propaga-se pelos demais no sentido do exterior para o interior no diagrama da cebola. Na abordagem de cada novo slot os especialistas envolvidos devero se utilizar dos registros obtidos anteriormente. A figura 4 ilustra o processo.

N1 N2 Ni Ni+1

Sugestes de Features e Requisitos Coletados

SW + HW

I+1

Nn
- Entrevista ANALISTA-i- simoREPRESENTANTE Tratamento de Redundncias/ Confitos - Reuino Geral do Slot

Necessidades

Escopo
1 2 Deciso Final para definio de ESCOPO + Registro Registro deFeatures e Requisitos Sugeridos

Figura 4: Captura e Registro de Necessidades As necessidades so coletadas pelo especialista de requisitos que utiliza como fonte de informao os representantes de cada classe de stakeholders. Caso seja capturado um requisito ao invs de uma necessidade, cabe ao especialista trabalhar junto ao fornecedor do requisito no sentido de extrair as necessidades subjacentes a ele. Todas as necessidades obtidas, direta ou indiretamente, so registradas juntamente com os seus respectivos proprietrios. No caso das necessidades obtidas indiretamente so registrados, parte, as features e os requisitos a elas relacionados. Desta forma a tabela de features e requisitos pode e deve servir de referncia na definio dos requisitos. As necessidades so coletadas slot a slot. Quando o especialista de requisitos aborda um novo slot para a coleta ele leva de bagagem as necessidades at ento coletadas. Uma vez realizada a captura em um slot, se houver controvrsias entre os membros do slot, promove-se uma negociao das necessidades obtidas fazendo-se os ajustes que forem necessrios e dando incio a um novo ciclo de captura. Isso caracteriza a face

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

incremental do processo e deve-se ressaltar aqui que cabe ao especialista o cuidado de minimizar redundncias e conflitos que possam aparecer. No final dessa etapa o especialista ter disponvel o conjunto total das necessidades coletadas, minimizados as redundncias e conflitos. Tal conjunto constitui a base para negociao do escopo do projeto. O conjunto de necessidades apurado submetido apreciao daqueles stakeholders aos quais anteriormente foi delegada a responsabilidade de deciso. A partir de pareceres emitidos por essas pessoas e de um processo de negociao definido o escopo do projeto que constitui o conjunto daquelas necessidades que devero ser endereadas por ele. 3.2.2 Estabelecimento de Features e Requisitos O escopo do projeto e o conjunto de requisitos sugeridos nas fases anteriores constituem as entradas para esta fase. Dela participam os especialistas de requisitos, os stakeholders especialistas no assunto sendo focalizado e os proprietrios das necessidades, isto , os stakeholders nos quais as necessidades tm a sua origem. O processo ilustrado na Figura 5.

Necessidades Features
3

R1 F1 F2
1 N2 N2 N3

Necessidades Features Requisitos

R2 R3 R4 R5 R6 R7 R8 R9
5

N1

F3 F4 F5 F6

Escopo

N2 N2

F7 Fi Fn

R10 R11 Ri Ri+1 Rn

Sugestes de Features e Requisitos Coletados

1 2

2 4

Alocao de Features s Necessidades Utilizao de Features do Repositrio

3 4

Registro das Features Utilizao de Requisitos do Repositrio

5 6

Definio dos Requisito Registro dos Requisitos

Figura 5: Definio e registro de features e requisitos

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Cada uma das necessidades do escopo considerada com o objetivo de se estabelecer um conjunto de features para atend-la x. Pelo menos uma feature precisa ser estabelecida para cada necessidade. Para auxiliar nessa tarefa devem-se considerar as features coletadas durante a captura das necessidades y. Tais features podem ser reutilizadas parcial ou integralmente se isso for julgado conveniente. No caso de necessidades que no tenham features sugeridas ser necessrio que se criem novas ou se reutilize alguma que j tenha sido definida. Assim que forem definidas, todas as features devero ser registradas z na forma de casos de uso com nvel pequeno de detalhes bem como informaes sobre o seu estado e seus relacionamentos com as necessidades de origem e com os requisitos a ela alocados. A definio dos requisitos feita com um processo semelhante da features: para cada uma das features determinado o conjunto de requisitos funcionais e no funcionais necessrios sua realizao|. O conjunto de requisitos coletados na captura das necessidades de grande valia nessa tarefa pois o reuso total ou parcial de requisitos sugeridos pode agilizar essa etapa{. Os requisitos que forem definidos sero registrados como casos de uso detalhados juntamente com as respectivas informaes de estado e relacionamentos}. O registro dos relacionamentos dos requisitos permitem o seu rastreamento, isto , determinar as suas origens e o que pode ser afetado em caso de uma modificao futura. As features e requisitos sugeridos durante a captura de necessidades devero ser mantidos pelo sistema a ttulo de histrico, mesmo os que no foram reaproveitados pois existe sempre a possibilidade que venha a s-lo numa prxima iterao. 4. Instrumentos de Captura e Anlise Durante o processo de definio de requisitos de um sistema diversos so os instrumentos que podem ser empregados. A escolha desses instrumentos dever ser realizada caso a caso, dependendo da estrutura organizacional, de aspectos culturais, das disponibilidades e das convenincias dos proponentes do produto. Como principais exemplos de instrumentos podemos citar: Entrevistas realizadas por especialistas de requisitos com os stakeholders do negcio sendo abordado, sejam individuais ou em grupo; Questionrios formulados por especialistas de requisitos que devero ser respondidos pelos stakeholders do negcio: proponentes, beneficirios, futuros usurios, especialistas, etc; Sesses de brainstorming envolvendo especialistas do domnio do problema e do domnio da soluo; Prototipao de partes do sistema sendo proposto; Instrumentos de Auxlio Anlise tais como tabelas, checklists, etc. E outros tipos de instrumentos que estejam disponveis ou sejam convenientes.

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

importante frisar tambm que a opo por um ou mais instrumentos pode ser determinada por ferramentas utilizadas para a definio dos requisitos. 5. Infra-estrutura de Registro e Recuperao de Dados Na implantao de qualquer mtodo deve-se sempre garantir que o ele seja factvel e o mais eficiente possvel. Visando tais objetivos no mtodo proposto vital a realizao de registros de dados em meio no voltil, seguro e de fcil recuperao. Outro fator a ser levado em conta o rastreamento dos dados. As necessidades, por exemplo, precisaro ser rastreadas nas suas origens, os stakeholders proprietrios, e tambm nas features e requisitos decorrentes. Isso devido volubilidade da necessidade, ela passvel de ser modificada no tempo e tais modificaes podem ter efeitos colaterais no conjunto. As necessidades sero registradas na forma textual descritiva, as features e requisitos sero registrados na forma de caso de uso, conforme templates predefinidos. Para cada um desses elementos, no seu registro, devero constar informaes adicionais que possibilitem o seu rastreamento e seus atributos tais como estabilidade, estado de implementao, etc. O formato e meios de tais registros dever ser definido caso a caso.

6. Estado Atual e Perspectivas Futuras

O mtodo descrito encontra-se em fase de formalizao pelo grupo de requisitos da DMPS/CenPRA. Para facilitar a sua implantao ser desenvolvido um prottipo de ferramenta para captura, definio e gerncia de requisitos. Logo que esteja pronta a sua primeira verso pretende-se aplicar o mtodo em parceria com alguma empresa de desenvolvimento de software de pequeno ou mdio porte. Isso feito, estaremos em condies de fazer uma avaliao e aperfeioamento do mtodo.

6. Concluso
Neste trabalho foi apresentado um mtodo de definio de requisitos utilizando as necessidades para a deduo dos requisitos e enfatizando a importncia de sua captura e registro. Tal abordagem possibilita que o produto final possa ser validado no apenas nos requisitos utilizados no seu projeto mas, principalmente nas necessidades dos stakeholders. Registrando todas as necessidades, mesmo as que forem consideradas fora do escopo do projeto, por estratgia ou falta de recursos, tais necessidades podero numa verso futura ser agregadas ao produto. Alm disso, o conjunto das necessidades do escopo pode evoluir atravs de incluses, excluses ou modificaes nas necessidades.

8. Referncias
Alexander, I. F. A Taxonomy of Stakeholders, htpp://easynet.co.uk/~iany/consultancy/stakholder_taxonmy

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Leffingwell, D. Features, Use Cases, Requirements, Oh My!, Rational the edevelopment company Kotonya, G. e Sommerville, I. Requirements Engineering, John Wiley & Sons ltd., 1998 Davis, A. Software Requirements: Objects, Functions, and States, Prentice Hall, 1993 Reed Jr, P.R. Developing Application with JAVA and UML, Addison-Wesley, 2002 Cockburn, A. Escrevendo Casos de Uso Eficazes, Bookman, 2005

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

VII Simpsio Internacional de Melhoria de Processo de Software - SIMPROS

Mtodo para Definio de Requisitos de Software de um Sistema a Partir das Necessidades dos seus Stakeholders
Ana Lcia Sampaio Francisco Formoso Primo Wagner Roberto De Martino DMPS/CenPRA So Paulo - Novembro 2005

CenPRA - DMPS: Diviso de Melhoria de Processos de Software

Foco: Avaliao e Melhoria de Processos Formas de atuao: pesquisa tecnolgica, articulaes, disseminao e servios Modelos CMMI, MPS.BR e ISO/IEC 15504 Melhoria: genrica para um conjunto de processos relevantes, ou especficos para: Aquisio de Software e servios correlatos; Gerncia de Configurao de Software; Testes de Software; e outros ...

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Motivao
Relevncia do assunto Especificao de Requisitos dentro do processo de desenvolvimento de Sw Trabalho desenvolvido junto a uma empresa desenvolvedora de Sw que tem como caractersticas: Um produto que o seu carro chefe e que no possui especificao de seus requisitos; Equipe pequena de desenvolvimento; Produto precisa evoluir continuamente pois tem vrios clientes potenciais com necessidades diversas. Necessidade de um mtodo que levasse em considerao a natureza dinmica dos requisitos, principalmente no que diz respeito s necessidades e que pudesse ser utilizado por empresas desenvolvedoras de Sw em geral
SIMPROS 2005 3

Conceitos Fundamentais (I)

NEGCIO: Empreendimento que visa explorar total ou parcialmente alguma atividade. Visa sempre algum tipo de benefcio para quem o explora seja ele financeiro, poltico ou social. A concretizao de um negcio implica naturalmente a resoluo de alguns problemas STAKEHOLDERS: Conjunto de todos os interessados em um negcio desde a sua criao, a identificao dos problemas a serem solucionados por um sistema, a definio e implantao da sua soluo at a sua posterior utilizao NECESSIDADES: Os stakeholders de um negcio possuem aspiraes ou anseios que pretendem sejam atendidos pelo sistema. Necessidades so deduzidas a partir de tais aspiraes ou anseios SISTEMA: Concepo para contribuir de alguma maneira na soluo de problemas decorrentes da explorao de um negcio

SIMPROS 2005

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Conceitos Fundamentais (II)

COMPOSIO DE UM SISTEMA: Sw + Hw + Processos REQUISITOS DE SISTEMA: Conjunto que define o que o sistema deve fazer e em quais circunstncias ele deve operar. Define os servios a serem providos pelo sistema e determina as restries sobre a sua operao REQUISITOS DE SOFTWARE: Recurso, ou condio fornecidos pelo Sw no sentido de atender alguma necessidade a ser provida por um sistema

SIMPROS 2005

Problema x Soluo Domnio do Problema

Aspiraes e Desejos

Domnio da Soluo

Hardware

Pessoas Necessidades

Stakeholders

Software

Mundo Real

SISTEMA
6

SIMPROS 2005

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Processo de Especificao de Requisitos de Sw - Viso Geral Elicitao Anlise

R1

Especificao

Captura e Anlise
Stakeholders

R2 Rx Ry
Requisitos Especificao de Requisitos

Necessidades

SIMPROS 2005

Documento de Especificao de Requisitos de Software

Testes Aceitao e Validao

Negociao

Docume de Espec ntos ificao de Requisit os

Projeto

Elicitao de Requisitos

Contrato
SIMPROS 2005 8

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Engenharia de Requisitos - Abrangncia (II)

Release 1

Release 2

Release 3

Referncia
Elicitao Anlise Verificao Gerncia Requisitos Especificao Especificao Elicitao Anlise Verificao Gerncia Requisitos Elicitao Anlise Verificao Gerncia Requisitos Especificao

Referncia

SIMPROS 2005

Mtodo para Definio de Requisitos

Viso geral do mtodo
Identificar Grupos de Stakeholders Definir Stakeholders Alocar Stakeholders nos grupos Definir Representantes dos grupos Capturar e Registrar as necessidades dos Representantes Definir as Necessidades Analisar e Refinar as Necessidades Estabelecer Features que endeream cada necessidade Analisar e Refinar as Features Estabelecer Requisitos que enderecem cada feature Definir os Requisitos Analisar e refinar Requisitos Registrar Requisitos
SIMPROS 2005 10

Definir as Features

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Mtodo para Definio de Requisitos

Viso esquemtica do mtodo Captura e Anlise Anlise Anlise

Stakeholders

Necessidades

Features

Requisitos

SIMPROS 2005

11

Mtodo para Definio de Requisitos

Definio do conjunto de stakeholders

Comunicaes

Dinheiro Associaes

Negcio
Conhecimento Servios

Especialistas Requisitos

Tecnologias Pessoas

Stakeholders

SIMPROS 2005

12

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Mtodo para Definio de Requisitos

Como descobrir o conjunto de stakeholders ?

Contato inicial normalmente ir indicar pessoas, seus papis e interesses Cada stakeholder pode indicar ou sugerir outros stakeholders Stakeholders incluem usurios diretos do sistema e interessados indiretos tais como reguladores e organizaes normativas
SIMPROS 2005 13

Mtodo para Definio de Requisitos

Organizao de stakeholders - Diagrama da Cebola
Nveis ou Camadas
Beneficirio Financeiro

Papis ou Classes de stakeholdes (slots)

Outros Sistemas

Beneficirio Funcional Beneficirio Poltico Operador Normal

Preenchimento

Sw + Hw

Legislador

Suporte Operacional Consultor Comprador

Operador Manuteno

Stakeholder Negativo

Desenvolvedor

Ian F. Alexander
SIMPROS 2005 14

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Mtodo para Definio de Requisitos

Preenchimento do Diagrama da Cebola Nveis e slots fazem parte do modelo No contato inicial o(s) proponente(s) sugere(m) slots a serem populados e indica(m) representantes Cada slot quando consultado pode indicar outros slots e seus representantes O processo termina quando no houver mais sugestes de populao dos slots
15

Beneficirio Financeiro

Outros Sistemas

Proponente

Beneficirio Poltico

Entrevistas
Analistas de Requisitos

Beneficirio Operador Funcional Normal

Sw + Hw
Legislador

Consultor

Operador Suporte Manuteno Operacional Comprador Stakeholder Negativo

Desenvolvedor

SIMPROS 2005

Mtodo para Definio de Requisitos

Esquema da captura das necessidades dos stakeholders N1 N2
Sw + Hw

Ni Ni+1

Sugestes de Features e Requisitos Coletados

I+1

Nn
- Entrevista ANALISTAi-simoREPRESENTANTE Tratamento de Redundncias/Conflitos - Reunio c/ Slot 1 2

Necessidades

Escopo
i
Deciso Final para definio de ESCOPO + Registro Registro de Features e Requisitos Sugeridos

SIMPROS 2005

16

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Mtodo para Definio de Requisitos

Rastreabilidade

Captura e Anlise

Requisitos Features Necessidades

Stakeholders
17

SIMPROS 2005

Mtodo para Definio de Requisitos

Esquema geral
Necessidades Features
3 N1 Escopo N2 N2 N2 N2 N3 1 6

F1 F2 F3 F4 F5 F6 F7 Fi Fn
5

R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 Ri Ri+1 Rn

Necessidades Features Requisitos

Repositrio de Features e Requisitos Coletados

1 2

2 4 3 Registro Features 4

Alocao de Features s Necessidades Utilizao de Features do Repositrio

5 6

Definio Requisitos Registro Requisitos 18

Utilizao de Requisitos do Repositrio SIMPROS 2005

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Rastreabilidade
Rastreamento Vertical e Horizontal
Horizontal
Necessidade x Necessidade y

Vertical

Servios Servios

RequisitosRequisitos Sw Sw

RequisitosRequisitos Hw Hw

Planos de Planos de Teste Teste Projeto

Projeto

............... ............... ....................... .......................

Procedimentos Cdigo Procedimentos

Cdigo

....................... .......................
SIMPROS 2005 19

Mtodo para Definio de Requisitos

Modelo do Processo de Requisitos
Features
ESCOLHA DE FEATURES Anlise em conjunto com Stakeholders donos da Necessidade DEFINIO DE REQUISITOS Anlise em conjunto com Stakeholders e Especialistas

Problema

Escopo

Requisitos

NEGOCIAO Deciso em Plenria

Necessidades SIMPROS 2005

LEVANTAMENTO DAS NECESSIDADES Entrevistas + Anlise no Slot

20

VII Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 21-23/11/2005 www.simpros.com.br

Referncias - Gerald Kotonya & Ian Sommerville REQUIREMENTS ENGINEERING - John Wiley & Sons - 1998 - Mary Beth Chrissis, Mike Konrad, Sandy Shrum CMMI Guidelines for Process Integration and Product Improvement - Addison-Wesley - 2003 - Guide to the Software Engineering Body of Knowledge SwEBOK - IEEE - 2004 Version - Alexander, I. F. A Taxonomy of Stakeholders, htpp://easynet.co.uk/~iany/consultancy/stakholder_taxonmy
SIMPROS 2005 21

MUITO OBRIGADO! Contatos

Diviso de Melhoria de Processos de Software - DMPS Centro de Pesquisas Renato Archer - CenPRA www.cenpra.gov.br Ana Lcia de Sousa Sampaio ana-lucia.sampaio@cenpra.gov.br Francisco Formoso Primo francisco.formoso@cenpra.gov.br Wagner Roberto De Martino wagner.de-martino@cenpra.gov.br
SIMPROS 2005 22