A05 2 Artigo14647

VII Simpósio Internacional São Paulo, SP – Brasil
de Melhoria de Processos 21-23/11/2005

de Software www.simpros.com.br
Método para Definição de Requisitos de Software de um

Sistema a Partir das Necessidades dos seus Stakeholders
Ana Lúcia 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 método de definição 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
análise e o registro dos requisitos. São 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 manutenção
e controle. O registro permite o rastreamento bidirecional desde os
stakeholders e suas necessidades até os respectivos requisitos. O método
descrito serve de base para um protótipo de aplicação sendo implantado no
DMPS/CenPRA pelo grupo de requisitos.
1. Introdução
Embora a Engenharia de Software venha afirmando sistematicamente a necessidade da
especificação 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, não há registro das necessidades que o geraram e, na
melhor da hipóteses, os requisitos estão documentados. Decorrente deste fato, qualquer
validação do produto será feita sobre os requisitos e não sobre as necessidades que
motivaram o seu desenvolvimento. Os motivos de tal comportamento podem ser o
imediatismo por resultados, a redução de custos e a busca de uma suposta flexibilidade
no desenvolvimento. Tudo isso resulta, ao contrário do esperado, em projetos que
estouram em prazos e recursos; produtos que não satisfazem as necessidades de seus
clientes e que são de difícil manutenção e evolução.
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
resolução. Raros são os problemas que podem ser perfeitamente entendidos antes de
começarem a ser resolvidos. Todos os envolvidos no desenvolvimento precisam estar
conscientes da existência dos dois domínios:
• domínio do problema onde situam-se o negócio e todos os nele interessados, isto

é, os stakeholders que possuem aspirações e expectativas que gostariam de ver
satisfeitas pela exploração do negócio às quais denominaremos necessidades;
• domínio da solução onde um sistema é definido com a finalidade de tornar
operacional e de facilitar a implantação do negócio. O sistema deve fornecer um ou
mais serviços que enderece cada necessidade, as features. Cada feature, por sua
vez, para ser efetivada demanda um conjunto de recursos, qualidades e restrições
aos quais denominaremos requisitos.
Convém ressaltar que a fronteira entre os dois domínios nem sempre é muito nítida e
exige, durante a definição dos requisitos, que os envolvidos na tarefa distingam entre os
dois domínios e saibam em qual se está trabalhando.
Nos próximos itens, apresenta-se um método para a definição de requisitos de software
de um sistema a partir das necessidades dos seus stakeholders. São descritos também,
procedimentos e instrumentos destinados a operacionalizar o método de captura, análise
e registro dos requisitos e as respectivas origens, bem como suas características mais
relevantes, que propiciem recursos necessários para a implantação de uma efetiva
gerência de requisitos.
2. Motivação
Este trabalho busca caracterizar melhor os domínios envolvidos no desenvolvimento de
um sistema de software e possibilitar que qualquer solução encontrada possa ser
validada na sua origem. São fornecidos subsídios para quebrar o paradigma “validação
sobre os requisitos especificados” e baseia-se no princípio de que os sistemas devem
ser construídos a partir de uma definição rigorosa dos seus objetivos e que leve em
consideração as expectativas de todos os interessados na sua construção.
Todos os métodos de definição de requisitos levam em consideração as necessidades
que devem ser atendidas pelo sistema. Então, onde reside a diferença que justifique
mais um no conjunto de métodos?
Nos métodos atuais os requisitos de software evoluem durante o seu desenvolvimento,
mas o conjunto de necessidades que os originaram permanece estática; desconsidera-se
o fato de que necessidades novas podem surgir, algumas podem desaparecer e muitas
provavelmente deverão ser ajustadas, corrigidas ou melhoradas para continuarem
existindo. No antigo paradigma, as necessidades são tratadas informalmente, não
evoluem após estar pronta a especificação dos requisitos. Isso torna o produto cada vez
mais distante das necessidades que o originaram.
Mantendo o registro das necessidades e permitindo a sua atualização temos, como
reflexo, uma melhor qualidade e um prolongamento na vida útil do produto. É claro que
isso tem seu preço: há um aumento na complexidade no desenvolvimento do projeto
pois mais informações precisam ser controladas. Acreditamos que a qualidade
adicionada ao produto final e a satisfação dos stakeholders compense o custo adicional.
Embora o presente método não tenha nenhuma restrição de aplicabilidade, ele foi
concebido tendo em vista sua aplicação em organizações de desenvolvimento de
software de pequeno e médio porte. Tal preferência se justifica pela grande carência que
pode ser observada nessas organizações e pela missão do Centro de Pesquisas Renato
Archer - CenPRA em atendê-las já que as grandes organizações em geral já possuem
políticas e recursos para tanto.
3. Visão Geral do Método

Os requisitos de um sistema especificam o conjunto de funcionalidades que ele deve
prover para satisfazer as necessidades de todos os seus stakeholders, as características
de qualidade e as restrições a que devem estar sujeitas as funcionalidades. Os
proponentes de um sistema sempre anseiam por benefícios sejam eles financeiros,
técnicos, sociais ou políticos e é justamente para atender esses anseios que são
projetados os sistemas. Um sistema representa uma solução aos problemas decorrentes
da exploração de um negócio.
Numa primeira classificação, os requisitos de um sistema pertencem a uma das
seguintes categorias: requisitos funcionais e requisitos não funcionais. Os requisitos
funcionais especificam as funções que devem ser desempenhadas pelo sistema e os
requisitos não funcionais especificam qualidades que o sistema deve possuir assim
como suas condições ou restrições de operação.
A definição de requisitos consiste, na verdade, na compreensão de um dado problema, e
a definição das características e restrições para a solução desse problema. A
compreensão do problema, ou seja, o negócio, os stakeholders e suas necessidades
pertencem ao domínio do problema e as características e restrições do sistema
pertencem ao domínio da solução. Uma dificuldade que se apresenta nesse processo é
que, para os stakeholders, a separação entre esses dois domínios não é nítida. As
pessoas têm a tendência de elaborar características e definir restrições antes de
compreender detalhadamente necessidades relativas a elas e isto é natural, pois a
compreensão de um problema às vezes demanda o esboço de elementos para a sua
solução.
O método aqui apresentado é concebido de forma tal que os elementos do domínio do
problema são capturados e os do domínio da solução são vislumbrados e definidos
permitindo que a fronteira entre os domínios seja cruzada nos dois sentidos várias vezes
durante a elicitação. Desta forma as necessidades, características e restrições são
definidas num processo incremental e iterativo a partir de entrevistas com stakeholders
e análise e síntese de especialistas de requisitos. Além disso, o método registra o
histórico de cada requisito, da necessidade que o gerou aos artefatos utilizados na
análise. A definição de requisitos é realizada em duas etapas sendo que ambas são
conduzidas pelos especialistas de requisitos que devem ser direcionados por aspectos
institucionais, ambientais e pelas fronteiras ou bordas do problema.
Na etapa 1 determinam-se quais são os grupos funcionais de stakeholders (gerentes,

desenvolvedores, patrocinadores, agentes reguladores, usuários,...), definem-se a
população 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 necessários ao
seu atendimento.
3. Definição dos Stakeholders
A sistemática para a definição de stakeholders é baseada no modelo proposto por Ian
Alexander [1] e é detalhada nas seções seguintes.
3.1. Modelagem dos stakeholders e Sistemática de Aplicação

Na modelagem escolhida, como ponto de partida é necessário estabelecer a estrutura do
conjunto dos prováveis 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)
Beneficiário
Financeiro Sistema envolvente
(também sócio- tecnico )
Outros
Nosso Sistema Sistemas
(sócio- tecnico )
KIT
(Sw +Hw)
Beneficiário Beneficiário Operador (técnico) Legislador
Político Funcional Normal
Operador
Suporte Manutenção
Operacional
Consultor
Comprador Stakeholder
Negativo
Desenvolvedor
Figura 1 – Organização dos Stakeholders (Diagrama da Cebola)

O diagrama é constituído por quatro círculos concêntricos nos quais situam-se diversas
classes de stakeholders, ou slots, simbolizados pela figura e o respectivo nome da
classe representada. As classes são dispostas nos círculos de forma que nos mais
externos estarão aquelas mais envolvidas com aspectos do negócio. Caminhando-se no
sentido do centro serão encontradas classes cada vez mais envolvidas com o sistema
que implementa a solução. É nos slots que serão alocadas pessoas que irão desempenhar
os papéis relevantes na definição dos requisitos.
A organização dos stakeholders, utilizando o diagrama da cebola, é genérica e precisa
ser adaptada dependendo do problema sendo abordado, de aspectos organizacionais e
culturais do seu ambiente. Estabelecida esta organização, é necessário escolher quais os
slots relevantes, populá-los e definir representantes para cada um deles. Além disso, é
também necessário definir a relevância da opinião de cada slot quando da tomada de
decisões, através da atribuição de pesos a cada um deles. Esses assuntos deverão ser
tratados durante os primeiros contatos envolvendo os proponentes do produto e os
especialistas responsáveis pela definição dos requisitos.
Beneficiário
Financeiro
Outros
Sistemas
Proponente
Beneficiário
Político
SW + HW
Beneficiário Operador Legislador
Instrumentos Funcional Normal
Operador
Especialistas Suporte
Manutenção
Operacional
de Consultor
Comprador
Requisitos Stakeholder
Negativo
Desenvolvedor
Figura 2 – Definição da organização de stakeholders

A Figura 2 exemplifica a definição da organização dos stakeholders: levando em
consideração o domínio do negócio, aspectos organizacionais, ambientais e o contexto
vislumbrado para o sistema. Os especialistas de requisitos em conjunto com os
representantes do slot que contém o papel do proponente do sistema deverão escolher,
popular, definir e registrar representantes para os demais slots.
O processo acima esboçado poderá resultar em um ou mais slots vazios, o que significa
que, para o desenvolvimento do projeto em questão, os papéis que seriam contidos
naqueles slots foram considerados irrelevantes. Na figura 2 temos:
simboliza um slot considerado relevante na definição dos requisitos e

simboliza slot considerado irrelevante e que portanto não será populado.
É, também, nesta reunião inicial que, dependendo do tipo de organização, número e
diversidade de stakeholders envolvidos, são definidos os instrumentos a serem
utilizados no processo, tanto para a captura de necessidades como para a definição de
features e requisitos.
3.2 Estabelecimento de necessidades, features e requisitos

As necessidades, features e requisitos são definidos incremental e iterativamente à
medida que novos elementos vão sendo agregados e os elementos existentes
aprimorados. Esta etapa, para melhor entendimento, é dividida em quatro fases que são
descritas nas seções 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 DEFINIÇÂO DE REQUISITOS
Análise em conjunto Análise em conjunto
com Stakeholders com Stakeholders
“donos da Necessidade” e Especialistas
Problema
Escopo Requisitos
NEGOCIAÇÂO LEVANTAMENTO
Decisão em Plenária DAS NECESSIDADES
Entrevistas
+
Análise no Slot
Necessidades
Figura 3: Processo de definição de Necessidades, features e requisitos

A volta mais interna da espiral representa a primeira compreensão do conjunto das
necessidades até a definição dos requisitos que as endereçam. As demais voltas
representam aperfeiçoamentos 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 necessário e suficiente
para iniciar o desenvolvimento propriamente dito. Conforme sugere a figura o processo
é iterativo e é constituído por quatro fases, cada uma representada por um quadrante.
No quadrante 1, LEVANTAMENTO DAS NECESSIDADES, parte-se do conjunto anterior de
necessidades e através de procedimentos e instrumentos específicos envolvendo
especialistas de requisitos e representantes dos slots vão sendo colhidas e incorporadas
as necessidades. Quando todos os slots forem considerados os especialistas estarão de
posse de um conjunto de necessidades dos slots e tal conjunto terá redundâncias e
incongruências minimizadas.
O quadrante 2, NEGOCIAÇÃO, representa uma negociação em que as necessidades
apuradas anteriormente são submetidas à apreciação de uma plenária cujos participantes
têm poder de decisão. Tal plenária tem como objetivo a definição do escopo do projeto,
ou seja, definir quais as necessidades que deverão ser atendidas por ele. Esse conjunto
de necessidades servirá como base para a definição dos requisitos. As necessidades
recusadas serão mantidas no sistema a título de histórico não sendo mais objeto de
análise do projeto.
No quadrante 3, ESCOLHA DE FEATURES, cada necessidade constante do escopo do
projeto é objeto de análise 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 auxílio dos stakeholders que deram origem às
necessidades, buscam uma solução adequada à ela. O resultado é um conjunto de
features em que cada uma é descrita na forma de caso de uso com um nível alto de
abstração.
No último quadrante, DEFINIÇÃO DE REQUISITOS, as features são 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 técnicos e
especialistas. O resultado é um conjunto dos requisitos do projeto descritos na forma de
casos de uso com um nível 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 modificação, incorporação ou remoção de elementos.
3.2.1 Captura das necessidades, negociação e definição de escopo

O processo de captura de necessidades é realizado mediante a aplicação de instrumentos
de captura, análise, definição 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 deverão se utilizar dos registros obtidos
anteriormente. A figura 4 ilustra o processo.
N1 1
2
N2 Sugestões de
Features e
Requisitos
Coletados
Ni i 2
SW + HW
I+1
Ni+1
n 1
Necessidades
Nn
Escopo
- Entrevista ANALISTA-i-ésimoREPRESENTANTE
Tratamento de Redundâncias/Confitos 1 Decisão Final para definição de ESCOPO + Registro
i
- Reuinão Geral do Slot 2 Registro deFeatures e Requisitos Sugeridos
Figura 4: Captura e Registro de Necessidades

As necessidades são coletadas pelo especialista de requisitos que utiliza como fonte de
informação os representantes de cada classe de stakeholders. Caso seja capturado um
requisito ao invés 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, são registradas juntamente com os seus
respectivos proprietários. No caso das necessidades obtidas indiretamente são
registrados, à parte, as features e os requisitos a elas relacionados. Desta forma a tabela
de features e requisitos pode e deve servir de referência na definição dos requisitos.
As necessidades são coletadas slot a slot. Quando o especialista de requisitos aborda um
novo slot para a coleta ele leva de bagagem as necessidades até então coletadas. Uma
vez realizada a captura em um slot, se houver controvérsias entre os membros do slot,
promove-se uma negociação das necessidades obtidas fazendo-se os ajustes que forem
necessários e dando início a um novo ciclo de captura. Isso caracteriza a face
incremental do processo e deve-se ressaltar aqui que cabe ao especialista o cuidado de

minimizar redundâncias e conflitos que possam aparecer.
No final dessa etapa o especialista terá disponível o conjunto total das necessidades
coletadas, minimizados as redundâncias e conflitos. Tal conjunto constitui a base para
negociação do escopo do projeto.
O conjunto de necessidades apurado é submetido à apreciação daqueles stakeholders
aos quais anteriormente foi delegada a responsabilidade de decisão. A partir de
pareceres emitidos por essas pessoas e de um processo de negociação é definido o
escopo do projeto que constitui o conjunto daquelas necessidades que deverão ser
endereçadas 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 proprietários das
necessidades, isto é, os stakeholders nos quais as necessidades têm a sua origem. O
processo é ilustrado na Figura 5.
Necessidades Necessidades
Features 6
Features
R1 Requisitos
3
F1 R2
R3
N1 F2
R4
F3
1 R5
Escopo
N2 F4 R6
N3 F5 R7
N2
R8
F6
R9
N2 F7 5
R10
N2
R11
Fi
Ri
Fn
Ri+1
2 Rn
Sugestões de Features
e Requisitos Coletados
4
1 Alocação de Features às Necessidades 3 Registro das Features 5 Definição dos Requisito

2 Utilização de Features do Repositório 4 Utilização de Requisitos do Repositório 6 Registro dos Requisitos
Figura 5: Definição e registro de features e requisitos

Cada uma das necessidades do escopo é considerada com o objetivo de se estabelecer

um conjunto de features para atendê-la ①. 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 ②. Tais features podem ser
reutilizadas parcial ou integralmente se isso for julgado conveniente. No caso de
necessidades que não tenham features sugeridas será necessário que se criem novas ou
se reutilize alguma que já tenha sido definida. Assim que forem definidas, todas as
features deverão ser registradas ③ na forma de casos de uso com nível pequeno de
detalhes bem como informações sobre o seu estado e seus relacionamentos com as
necessidades de origem e com os requisitos a ela alocados.
A definição dos requisitos é feita com um processo semelhante à da features: para cada
uma das features é determinado o conjunto de requisitos funcionais e não funcionais
necessários à sua realização⑤. 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 serão
registrados como casos de uso detalhados juntamente com as respectivas informações
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 modificação futura.
As features e requisitos sugeridos durante a captura de necessidades deverão ser
mantidos pelo sistema a título de histórico, mesmo os que não foram reaproveitados
pois existe sempre a possibilidade que venha a sê-lo numa próxima iteração.
4. Instrumentos de Captura e Análise

Durante o processo de definição de requisitos de um sistema diversos são 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 conveniências dos proponentes do produto. Como principais
exemplos de instrumentos podemos citar:
Entrevistas realizadas por especialistas de requisitos com os stakeholders do negócio
sendo abordado, sejam individuais ou em grupo;
Questionários formulados por especialistas de requisitos que deverão ser respondidos
pelos stakeholders do negócio: proponentes, beneficiários, futuros usuários,
especialistas, etc;
Sessões de brainstorming envolvendo especialistas do domínio do problema e do
domínio da solução;
Prototipação de partes do sistema sendo proposto;
Instrumentos de Auxílio à Análise tais como tabelas, checklists, etc.
E outros tipos de instrumentos que estejam disponíveis ou sejam convenientes.
É importante frisar também que a opção por um ou mais instrumentos pode ser
determinada por ferramentas utilizadas para a definição dos requisitos.
5. Infra-estrutura de Registro e Recuperação de Dados

Na implantação de qualquer método deve-se sempre garantir que o ele seja factível e o
mais eficiente possível. Visando tais objetivos no método proposto é vital a realização
de registros de dados em meio não volátil, seguro e de fácil recuperação.
Outro fator a ser levado em conta é o rastreamento dos dados. As necessidades, por
exemplo, precisarão ser rastreadas nas suas origens, os stakeholders proprietários, e
também nas features e requisitos decorrentes. Isso é devido à volubilidade da
necessidade, ela é passível de ser modificada no tempo e tais modificações podem ter
efeitos colaterais no conjunto.
As necessidades serão registradas na forma textual descritiva, as features e requisitos
serão registrados na forma de caso de uso, conforme templates predefinidos. Para cada
um desses elementos, no seu registro, deverão constar informações adicionais que
possibilitem o seu rastreamento e seus atributos tais como estabilidade, estado de
implementação, etc. O formato e meios de tais registros deverá ser definido caso a
caso.
6. Estado Atual e Perspectivas Futuras

O método descrito encontra-se em fase de formalização pelo grupo de requisitos da
DMPS/CenPRA. Para facilitar a sua implantação será desenvolvido um protótipo de
ferramenta para captura, definição e gerência de requisitos. Logo que esteja pronta a sua
primeira versão pretende-se aplicar o método em parceria com alguma empresa de
desenvolvimento de software de pequeno ou médio porte. Isso feito, estaremos em
condições de fazer uma avaliação e aperfeiçoamento do método.
6. Conclusão
Neste trabalho foi apresentado um método de definição de requisitos utilizando as
necessidades para a dedução dos requisitos e enfatizando a importância de sua captura e
registro. Tal abordagem possibilita que o produto final possa ser validado não 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 estratégia ou falta de recursos, tais necessidades poderão
numa versão futura ser agregadas ao produto. Além disso, o conjunto das necessidades
do escopo pode evoluir através de inclusões, exclusões ou modificações nas
necessidades.
8. Referências
Alexander, I. F. “A Taxonomy of Stakeholders”,
htpp://easynet.co.uk/~iany/consultancy/stakholder_taxonmy
Leffingwell, D. “Features, Use Cases, Requirements, Oh My!”, Rational the e-

development 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 Simpósio Internacional de

Melhoria de Processo de Software - SIMPROS
Método para Definição de Requisitos

de Software de um Sistema a Partir das
Necessidades dos seus Stakeholders
Ana Lúcia Sampaio

Francisco Formoso Primo
Wagner Roberto De Martino
DMPS/CenPRA
São Paulo - Novembro 2005
CenPRA - DMPS: Divisão de

Melhoria de Processos de Software
• Foco: Avaliação e Melhoria de Processos
• Formas de atuação: pesquisa tecnológica, articulações,
disseminação e serviços
• Modelos CMMI, MPS.BR e ISO/IEC 15504
• Melhoria: genérica para um conjunto de processos
relevantes, ou específicos para:
– Aquisição de Software e serviços correlatos;
– Gerência de Configuração de Software;
– Testes de Software; e outros ...
Motivação
• Relevância do assunto Especificação de Requisitos
dentro do processo de desenvolvimento de Sw
• Trabalho desenvolvido junto a uma empresa
desenvolvedora de Sw que tem como características:
• Um produto que é o seu carro chefe e que não possui
especificação de seus requisitos;
• Equipe pequena de desenvolvimento;
• Produto precisa evoluir continuamente pois tem vários
clientes potenciais com necessidades diversas.
Necessidade de um método que levasse em consideração
a natureza dinâmica 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)
NEGÓCIO: Empreendimento que visa explorar total ou parcialmente

alguma atividade. Visa sempre algum tipo de benefício para quem o
explora seja ele financeiro, político ou social. A concretização de um
negócio implica naturalmente a resolução de alguns problemas
STAKEHOLDERS: Conjunto de todos os interessados em um negócio
desde a sua criação, a identificação dos problemas a serem
solucionados por um sistema, a definição e implantação da sua
solução até a sua posterior utilização
NECESSIDADES: Os stakeholders de um negócio possuem
aspirações ou anseios que pretendem sejam atendidos pelo sistema.
Necessidades são deduzidas a partir de tais aspirações ou anseios
SISTEMA: Concepção para contribuir de alguma maneira na solução
de problemas decorrentes da exploração de um negócio
SIMPROS 2005 4
Conceitos Fundamentais (II)
COMPOSIÇÃO DE UM SISTEMA: Sw + Hw + Processos

REQUISITOS DE SISTEMA: Conjunto que define o que o sistema deve
fazer e em quais circunstâncias ele deve operar. Define os serviços a
serem providos pelo sistema e determina as restrições sobre a sua
operação
REQUISITOS DE SOFTWARE: Recurso, ou condição fornecidos pelo
Sw no sentido de atender alguma necessidade a ser provida por um
sistema
SIMPROS 2005 5
Problema x Solução
Domínio do Problema Domínio da Solução
Aspirações e
Desejos Hardware
Pessoas
Necessidades
Stakeholders Software
Mundo Real SISTEMA
SIMPROS 2005 6
Processo de Especificação de Requisitos de Sw - Visão Geral
Elicitação
Análise
R1
Especificação
Captura R2
e Análise
Rx
Especificação de
Stakeholders Requisitos
Ry
Requisitos
Necessidades
SIMPROS 2005 7
Documento de Especificação de Requisitos de Software
Testes
Aceitação
e
Negociação Validação
Docume
de Espec ntos
ificação
Requisit de
os
Projeto
Elicitação
de
Requisitos
Contrato
SIMPROS 2005 8
Engenharia de Requisitos - Abrangência (II)
Release 1 Release 2 Release 3
Referência
Elicitação
Análise
Referência
Verificação Elicitação
Gerência Análise
Requisitos Verificação
Gerência Elicitação
Especificação
Requisitos
Análise
Especificação Verificação
Gerência
Requisitos
Especificação
SIMPROS 2005 9

Visão geral do método
Identificar Grupos de Stakeholders
Definir
Alocar Stakeholders nos grupos
Stakeholders
Definir Representantes dos grupos
Capturar e Registrar as necessidades dos Representantes

Definir as
Necessidades
Analisar e Refinar as Necessidades
Estabelecer Features que endereçam cada necessidade

Definir as
Features
Analisar e Refinar as Features
Estabelecer Requisitos que enderecem cada feature

Definir os
Analisar e refinar Requisitos
Requisitos
Registrar Requisitos
SIMPROS 2005 10

Visão esquemática do método
Captura Análise Análise

e Análise
Stakeholders Necessidades Features Requisitos
SIMPROS 2005 11

Definição do conjunto de stakeholders
Comunicações
Dinheiro
Associações Especialistas
Requisitos
Negócio
Serviços
Conhecimento
Tecnologias
Pessoas
Stakeholders
SIMPROS 2005 12

Como descobrir o conjunto de stakeholders ?
• Contato inicial normalmente irá indicar pessoas, seus papéis e

interesses
• Cada stakeholder pode indicar ou sugerir outros stakeholders
Stakeholders incluem usuários diretos do sistema e interessados
indiretos tais como reguladores e organizações normativas
SIMPROS 2005 13

Organização de stakeholders - Diagrama da Cebola
Papéis ou Classes
Níveis ou Camadas
de stakeholdes
(slots)
Beneficiário
Financeiro
Outros
Sistemas
Beneficiário
Funcional
Beneficiário
Político
Operador
Normal
Preenchimento Sw + Hw
Legislador
Operador
Suporte Manutenção
Operacional
Consultor
Comprador Stakeholder
Negativo
Desenvolvedor Ian F. Alexander
SIMPROS 2005 14

Preenchimento do Diagrama da Cebola
• Níveis e slots fazem parte
do modelo
Beneficiário
• No contato inicial o(s)
proponente(s) sugere(m)
Financeiro
Outros
slots a serem populados e

Sistemas
Beneficiário
indica(m) representantes
Proponente Político
• Cada slot quando

Sw + Hw
Entrevistas Beneficiário Operador
Funcional Normal
Legislador
Suporte
Operador
consultado pode indicar
outros slots e seus
Manutenção
Operacional
Analistas Consultor
de Comprador Stakeholder
Negativo
Requisitos
Desenvolvedor
representantes
• O processo termina
quando não houver mais
sugestões de população
dos slots
SIMPROS 2005 15

Esquema da captura das necessidades dos stakeholders
N1 1
2
N2 Sugestões de
Features e
Requisitos
Sw + Hw
Ni i 2 Coletados
I+1
Ni+1
n 1
Necessidades
Nn
Escopo
- Entrevista ANALISTAi-ésimoREPRESENTANTE
1 Decisão Final para definição de ESCOPO + Registro
Tratamento de Redundâncias/Conflitos
i
2 Registro de Features e Requisitos Sugeridos
- Reunião c/ Slot
SIMPROS 2005 16

Rastreabilidade
Captura Requisitos
e Features
Necessidades
Análise
Stakeholders
SIMPROS 2005 17

Esquema geral
Necessidades Necessidades
Features 6 Features
R1 Requisitos
3
F1 R2
R3
N1 F2
R4
F3 R5
Escopo 1
N2 F4 R6
N3 F5 R7
N2
F6 R8
R9
N2 F7 5 R10
N2 R11
Fi
Ri
Fn
Ri+1
2 Rn
Repositório de Features
e Requisitos Coletados 4
1 Alocação de Features às Necessidades 3 Registro Features 5 Definição Requisitos

2 Utilização de Features do Repositório 4 Utilização de Requisitos do Repositório 6 Registro Requisitos
SIMPROS 2005 18
Rastreabilidade
Rastreamento Vertical e Horizontal
Horizontal
Necessidade x
Necessidade y
Vertical
Serviços Serviços
RequisitosRequisitos
Sw Sw RequisitosRequisitos
Hw Hw
Planos de Planos
Teste de Teste
Projeto Projeto ............... ...............
Procedimentos Código .......................

.......................
Procedimentos Código
.......................
.......................
SIMPROS 2005 19

Modelo do Processo de Requisitos
Features
ESCOLHA DE FEATURES DEFINIÇÂO DE REQUISITOS
Análise em conjunto Análise em conjunto
com Stakeholders com Stakeholders
“donos da Necessidade” e Especialistas
Problema
Escopo Requisitos
NEGOCIAÇÂO LEVANTAMENTO
Decisão em Plenária DAS
NECESSIDADES
Entrevistas
+
Análise no Slot
Necessidades
SIMPROS 2005 20
Referências
- 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
Divisão de Melhoria de Processos de Software - DMPS
Centro de Pesquisas Renato Archer - CenPRA
www.cenpra.gov.br
Ana Lúcia 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

A05 2 Artigo14647

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

A05 2 Artigo14647

Enviado por

Direitos autorais:

Formatos disponíveis

VII Simpósio Internacional São Paulo, SP – Brasil

de Melhoria de Processos 21-23/11/2005

Método para Definição de Requisitos de Software de um

Resumo. Este artigo descreve um método de definição de requisitos de

• domínio do problema onde situam-se o negócio e todos os nele interessados, isto

3. Visão Geral do Método

Na etapa 1 determinam-se quais são os grupos funcionais de stakeholders (gerentes,

3.1. Modelagem dos stakeholders e Sistemática de Aplicação

Figura 1 – Organização dos Stakeholders (Diagrama da Cebola)

Instrumentos Funcional Normal

Figura 2 – Definição da organização de stakeholders

simboliza um slot considerado relevante na definição dos requisitos e

3.2 Estabelecimento de necessidades, features e requisitos

Figura 3: Processo de definição de Necessidades, features e requisitos

3.2.1 Captura das necessidades, negociação e definição de escopo

Figura 4: Captura e Registro de Necessidades

incremental do processo e deve-se ressaltar aqui que cabe ao especialista o cuidado de

3.2.2 Estabelecimento de Features e Requisitos

1 Alocação de Features às Necessidades 3 Registro das Features 5 Definição dos Requisito

Figura 5: Definição e registro de features e requisitos

Cada uma das necessidades do escopo é considerada com o objetivo de se estabelecer

4. Instrumentos de Captura e Análise

5. Infra-estrutura de Registro e Recuperação de Dados

6. Estado Atual e Perspectivas Futuras

Leffingwell, D. “Features, Use Cases, Requirements, Oh My!”, Rational the e-

VII Simpósio Internacional de

Método para Definição de Requisitos

Ana Lúcia Sampaio

São Paulo - Novembro 2005

CenPRA - DMPS: Divisão de

Conceitos Fundamentais (I)

NEGÓCIO: Empreendimento que visa explorar total ou parcialmente

Conceitos Fundamentais (II)

COMPOSIÇÃO DE UM SISTEMA: Sw + Hw + Processos

Domínio do Problema Domínio da Solução

Processo de Especificação de Requisitos de Sw - Visão Geral

Documento de Especificação de Requisitos de Software

Engenharia de Requisitos - Abrangência (II)

Release 1 Release 2 Release 3

Método para Definição de Requisitos

Capturar e Registrar as necessidades dos Representantes

Estabelecer Features que endereçam cada necessidade

Estabelecer Requisitos que enderecem cada feature

Método para Definição de Requisitos

Captura Análise Análise

Stakeholders Necessidades Features Requisitos

Método para Definição de Requisitos

Método para Definição de Requisitos

• Contato inicial normalmente irá indicar pessoas, seus papéis e

Método para Definição de Requisitos

Desenvolvedor Ian F. Alexander

Método para Definição de Requisitos

slots a serem populados e

• Cada slot quando

Método para Definição de Requisitos

Método para Definição de Requisitos

Método para Definição de Requisitos

1 Alocação de Features às Necessidades 3 Registro Features 5 Definição Requisitos

Procedimentos Código .......................

Método para Definição de Requisitos

- Gerald Kotonya & Ian Sommerville “REQUIREMENTS

- Mary Beth Chrissis, Mike Konrad, Sandy Shrum “CMMI

- “Guide to the Software Engineering Body of Knowledge -