Princpios de Engenharia de

Requisitos

Viviane Torres da Silva

viviane.silva@ic.uff.br

http://www.ic.uff.br/~viviane.silva/2012.1/es1
Problema chave: Comunicao

Cliente Engenheiro de
Software
Etapas da Engenharia de Requisitos

Concepo

Elicitao

Elaborao

Negociao

Especificao

Validao

Gerenciamento
Concepo

Objetivo
Ter uma viso geral do negcio
Conhecer o cliente e suas expectativas

Resultados esperados
Identificao dos interessados (stakeholders)
Identificao dos diferentes pontos de vista
Viso geral do escopo do sistema
Elicitao
Elicitao

Objetivo
Entender o que o cliente espera do software

Problemas mais comuns
Escopo varivel (mas contrato fixo)
Incertezas do cliente
Volatilidade dos requisitos

Elementos a serem identificados
Objetos manipulados pelo sistema
Servios prestados pelo sistema
Restries que devem ser obedecidas
Critrios de desempenho

Resultados esperados
Narrativa em linguagem natural dos requisitos do sistema
Lista de requisitos do sistema
Tcnicas de Elicitao

Entrevistas

Oficinas (workshops)

Reunies de Brainstorming

Prototipao

Maquetes

Anlise de documentao existente

Anlise de sistemas existentes

Observao de pessoas trabalhando

Anlise de mercado

Etc.
Elicitao: Maximizar a satisfao do cliente!

Requisito normal
O cliente lembra de falar
O cliente ficar satisfeito se esse requisito estiver no sistema

Requisito esperado
Requisito implcito
O cliente no lembra de falar
O cliente ficar insatisfeito se esse requisito no estiver no sistema

Requisito excitante
O cliente no lembra de falar
O cliente no espera encontrar esse requisito no sistema
O cliente ficar satisfeito se esse requisito estiver no sistema
Elicitao: Cliente x Usurio final

Nem sempre o cliente o usurio final

Cliente
Quem contrata e paga pelo servio
Ex.: Administrador de um hospital

Usurio final
Quem usa o software no dia a dia
Ex.: Mdicos e enfermeiros

Importante
Nunca deixe de elicitar requisitos com os usurios finais pois sem a
colaborao deles, o software no ser usado
Elicitao: Escolha dos usurios fonte

Alguns sistemas sero utilizados por milhares ou milhes de

usurios

Escolha usurios fonte dos requisitos que sejam
representativos

Lembre-se que a regra de Pareto (80-20) aparenta ser vlida
20% dos requisitos satisfazem a 80% dos usurios
Escolher um usurio muito especialista pode levar a implementao
de requisitos que nunca sero utilizados

Requisitos funcionais:
Descrevem as funcionalidades do sistema

Requisitos no funcionais:
Descrevem a qualidade do sistema
Elicitao: Requisitos funcionais

Narrativa livre
O sistema deve mostrar uma mensagem de status (finalizada, em
andamento, ...) para uma tarefa em intervalos no menores que 60
segundos

Lista de requisitos
RF-1: Uma mensagem de status deve ser mostrada na rea inferior da
janela (desenho da Fig.1)
RF-2: A mensagem deve ser atualizada a cada 60 segundos, com
tolerncia de 10 segundos para mais ou para menos
RF-3: A mensagem deve estar sempre visvel
RF-4: Se a mensagem for referente a uma tarefa em andamento, o
percentual de andamento deve ser mostrado
RF-5: Se a mensagem for referente a uma tarefa j terminada, isso
deve ser informado com o texto Finalizada
Elicitao: Requisitos no funcionais

Sinnimo: atributos de qualidade

Disponibilidade
DS-1: O sistema deve ficar disponvel por 99,5% do tempo nos dias
teis, das 6h s 22h

Eficincia
EF-1: Em condies de pico de uso, deve ter uma reserva de 25% de
capacidade de processamento e memria
EF-2: O clculo de interferncia deve ser finalizado com sucesso em
menos de 5 minutos
EF-3: O mdulo de parser de XML deve processar 1.000.000 de
documentos por segundo
Elicitao: Requisitos no funcionais

Flexibilidade
FL-1: Um novo tipo de sensor deve poder ser configurado no sistema
em menos de 3 horas

Integridade
IN-1: Transaes histricas dos consumidores s podero ser vistas
por usurios com privilgios de auditor

Interoperabilidade
IT-1: O sistema deve ser capaz de importar dados tanto do MS Office
(verso 2003 ou maior) quanto do OpenOffice (verso 2.4 ou maior)

Confiabilidade
CF-1: Em cada 1000 execues, no mais do que 2 podem apresentar
falhas de software
Elicitao: Requisitos no funcionais

Robustez
RB-1: Se acontecer uma falha antes do usurio salvar, o sistema deve
recuperar uma verso no salva com perda de contedo menor que 1
minuto de trabalho

Usabilidade
US-1: Um usurio treinado deve ser capaz de submeter um pedido de
compra em menos que 5 minutos
US-2: Um usurio no treinado deve ser capaz de submeter um
pedido de compra em menos que 30 minutos
US-3: Todos os comandos de menu devem ter teclas de atalho
associadas

Manutenibilidade
MN-1: Todos os mtodos devem ser documentados utilizando a
notao Javadoc
MN-2: Modificaes corretivas devem ser feitas em menos de 5 horas
Elicitao: Requisitos no funcionais

Portabilidade
PR-1: O sistema deve poder ser executado em sistema operacional
Windows e Linux, nas arquiteturas i386, AIX e SPARC

Reusabilidade
RS-1: O controle de usurios deve reutilizar componentes de
autenticao j utilizados no sistema PORTMAP

Testabilidade
TS-1: A complexidade ciclomtica mxima de um mdulo no pode ser
maior que 20
Elicitao: Requisitos no funcionais

Disponibilidade x Robustez
Eficincia x Robustez
DS EF FL IN IT CF RB US MN PR RS TS
DS  + +
EF  - - - - - - - -
FL -  - + + + +
IN -  - - - -
IT - + -  +
CF + - +  + + + +
RB + - +  +
US - +  -
MN + - + +  +
PR - + + - -  + +
RS - + - + - + +  +
TS + - + + + + 
Exerccio: Agenda Eletrnica

Descreva os requisitos de uma agenda eletrnica no papel

Lista de requisitos funcionais

Requisitos normais
Requisitos esperados
Requisitos excitantes

Lista de requisitos no funcionais

Requisitos normais
Requisitos esperados
Requisitos excitantes

Quais so os requisitos que podem estar em conflito?

Elaborao

Objetivo
Explicitar o conhecimento obtido na concepo e elicitao

Transformar narrativas de linguagem natural para UML (uso

de diagramas)

Sinnimo: Anlise de requisitos

Resultados esperados
Casos de uso
Classes conceituais
Negociao I/II

Objetivo
Priorizar e identificar os riscos dos requisitos
Eliminar, combinar ou modificar os requisitos
Chegar a um consenso sobre a lista final de requisitos

Conflitos comuns
Entre representantes do cliente
Requisitos contraditrios
Prioridades
Entre o cliente e a equipe de desenvolvimento
Prazo
Custo
Negociao II/II

Dimenses principais em negociaes

Escopo
Prazo
Custo

As dimenses so interligadas
Mudana de posio em uma das dimenses pode gerar
conseqncias nas outras dimenses
Negociao: Dicas

Identifique o objetivo do interlocutor

Ceda nos aspectos relevantes para o interlocutor que no so
relevantes para voc
No uma competio. Ambos tm que ganhar!

Defina uma estratgia
Saiba de antemo o que pode ser cedido e o que fundamental de ser
mantido

Escute com cuidado os argumentos do interlocutor
Reavalie a sua posio caso necessrio

Caso chegue a uma situao confortvel, faa um acordo de
imediato
No busque melhorar a sua posio se a posio atual j adequada
para ambos!
Especificao

Objetivo
Produzir a especificao de requisitos
Descrio detalhada dos requisitos

Especificao de requisito engloba

Requisitos funcionais
Requisitos no funcionais
Validao

Objetivo
Assegurar que a especificao de requisitos est consistente

Problemas comuns
Ambigidade
Inconsistncia
Omisso
Erro
Validao: Questes

Os requisitos esto claros?

A fonte dos requisitos est identificada?

Os requisitos foram mostrados para essa fonte?

Os requisitos esto descritos de forma quantitativa?

Os requisitos esto relacionados via referncia cruzada?

Os requisitos violam alguma restrio do domnio?

O requisito testvel? Os testes foram especificados?

Os requisitos so rastreveis para os modelos e o cdigo
subseqente?

Existem requisitos implcitos?
Validao: Exemplos de ambigidade

A janela deve abrir rapidamente

O sistema deve ser flexvel

O clculo deve ser eficiente

A interface com o usurio deve ser melhor que a atual

No devem ser mostradas muitas mensagens de erro

A exibio do mapa de navegao deve ser amigvel

Exerccio: Agenda Eletrnica

Dos requisitos especificados pelo outro grupo, quais os

problemas que estes requisitos possuem?

Ambigidade
Inconsistncia
Omisso
Erro

Junte os requisitos que o seu grupo fez com os que o grupo ao

lado fez. Negociem para que o nmero de mximo de
requisitos no ultrapasse o nmero de requisitos do grupos
que descreveu mais requisitos
Gerenciamento

Objetivo
Controlar as mudanas nos requisitos
Permitir a anlise de impacto das mudanas

Tipos de rastreabilidade
Caractersticas do sistema
Fonte do requisito
Dependncias entre requisitos
Subsistemas
Interfaces
Gerenciamento: Matriz de rastreabilidade
10 princpios de engenharia de requisitos I/III

Primeiro passo para se resolver um problema entender o

problema
No basta comunicar, necessrio entender!

Princpio 1: Escute
Tente prestar a ateno no que o interlocutor fala
Evite interromper a linha de raciocnio do interlocutor
Pea detalhes de algo que no ficou claro
No desestimule seu interlocutor com gestos ou palavras

Princpio 2: Se prepare antes da reunio
Tente entender o problema antes da reunio
Tente compreender qual o jargo utilizado no domnio
Elabore uma agenda para a reunio
10 princpios de engenharia de requisitos II/III

Princpio 3: importante ter um mediador

O mediador responsvel por manter a reunio com foco apropriado
O mediador responsvel por resolver conflitos

Princpio 4: Comunicao face a face o ideal
Na comunicao face a face possvel perceber gestos
A dedicao na comunicao face a face maior

Princpio 5: Tome nota das decises
Em pouco tempo, no ser possvel saber por que uma deciso foi
tomada
fundamental documentar as razes de cada deciso

Princpio 6: Estimule colaboraes
Duas ou mais mentes pensam melhor que uma
Colaboraes geram cumplicidade na equipe
10 princpios de engenharia de requisitos III/III

Princpio 7: Mantenha o foco

Evite que o reunio se desvie muito do seu objetivo
Lembre s pessoas o que ainda precisa ser visto

Princpio 8: Se algo estiver obscuro, desenhe!
Representaes visuais ajudam a uniformizar idias
Faa uso de papel e quadro branco em abundncia

Princpio 9: Siga em frente!
Se concordarem, sigam em frente
Se discordarem, sigam em frente
Se estiverem em dvida e no for possvel tirar a dvida no momento,
sigam em frente

Princpio 10: Negociao no um jogo
Busque por solues boas para ambas as partes
Ceda em aspectos que no so fundamentais
Brigue somente pelas batalhas que valem a pena
Um possvel processo...

1. Identifique os interessados no software

2. Se reunia com os interessados e faa perguntas genricas sobre
como funciona o sistema
3. Faa um diagnstico de uma pgina sobre o escopo do projeto
4. Revise o diagnstico com os interessados, visando validar a
comunicao anterior
5. Faa reunies tcnicas com os interessados para descobrir os
cenrios de uso do sistema (entradas, sadas, caractersticas,
funcionalidades e comportamentos)
6. Faa um breve relatrio desses cenrios
7. Refina com os interessados esse relatrio
8. Priorize esses cenrios com os interessados
9. Revise com os interessados o relatrio de cenrios
10. Inicie o planejamento das etapas de projeto, codificao e testes
De engenharia de requisitos para implantao

A priorizao dos requisitos determina o contedo de cada

iterao de implantao do software
Dependncias entre requisitos pode influenciar nessa ordem

Entregar mais que o prometido pode ser uma faca de dois
gumes
Alegra o cliente naquela iterao
Chateia o cliente em iteraes futuras se isso no se repetir

Requisitos no funcionais podem implicar em custos ps-
implantao
Ex: SLA determinando 4 horas para correo de defeitos
Bibliografia

Roger Pressman. 2004. Software Engineering: A Practitioner's

Approach. 6th ed. McGraw-Hill.

Wiegers, Karl E. 2003. Software Requirements, Second Edition.

2nd ed. Microsoft Press.

Vrias transparncias foram produzidas por Leonardo Murta

http://www.ic.uff.br/~leomurta