Gerência de Requisitos

07/11/2006

Objetivo

Conscientizar os participantes da importância dos requisitos no processo de desenvolvimento de sistemas, em conformidade com as normas de qualidade de software

Parte I:

Introdução a Requisitos

Sumário

Introdução a Engenharia de SistemasProblemas do Processo de DesenvolvimentoA Importância dos Requisitos no Processo de Desenvolvimento Motivação Conceitos– Regras de Negócio– Requisitos Funcionais e Não Funcionais– ISO/IEC 9126

Introdução a Engenharia de Sistemas

O Conceito de Sistemas

Um sistema pode ser definido como:

"Um conjunto, identificável e coerente, de elementos que interagem

coesivamente, onde cada elemento pode ser um sistema."

– equivale a traçar uma fronteira conceitual separando esse conjunto de elementos do resto do universo

Desenvolvimento de Sistemas

O processo de desenvolvimento é composto de (independente de metodologia):– Especificação do Problema – Elicitação e Especificação dos Requisitos (Análise)– Planejamento da Solução (Projeto)– Implementação em uma Linguagem de

Programação

Metodologia– conjunto de conceitos, ferramentas e técnicas

que permitem a construção de um modelo do domínio do problema e da adição de detalhes de implementação durante o projeto do sistema

Ciclo de vida clássico (em cascata)

Engenhariade Sistemas

AnáliseProjeto

Codificação

Teste

Manutenção

Desenvolvimento de Sistemas

Sistemas apresentam uma complexidade– Porte– Intrínseca

Seu desenvolvimento é um processo de elaboração de modelos– A modelagem é aplicada a cada etapa do processo de

desenvolvimento– A cada etapa podem ser empregadas um conjunto

diferente de ferramentas e técnicas de modelagem

Modelagem de Sistemas

Objetivo– reconhecimento do padrão interno que permite ao

sistema responder aos estímulos do ambiente externo

– padrão Interno = comportamento + informação

Recursividade do Conceito de Sistemas

– Sistema = {subsistemas}, onde cada subsistema é também um sistema

O Conceito de Modelo

“Modelo é a representação abstrata que permite descrever e/ou prever comportamentos específicos de um Sistema através do estudo de suas

características relevantes.”

Características de um Modelo

Aplicação de critérios de:– segmentação (porte)– abstração de características irrelevantes ao modelo

(intrínseca)

Objetivo:– explicitação de entidades (objetos) e relacionamentos

relevantes ao modelo

Utiliza uma linguagem de representação rigorosa (sintaxe, semântica e formalismo)

Características de um Modelo

Possui capacidade preditiva– O modelo é capaz de responder a perguntas específicas

• O comportamento do modelo é compatível com o sistema modelado?• O modelo se adequa aos objetivos a serem atingidos pelo sistema?

Como modelar?

o que será modelado é função da relevância dos aspectos a serem inseridos no modelo em função do seu objetivonão existe receita "pronta", envolve a intuição, criatividade e julgamento crítico do modeladormanutenção de consistência interna dos aspectos representados no modelovalidação experimental (correspondência de comportamento previsto a partir do modelo com o comportamento real do sistema)

Problemas do Processo de Desenvolvimento

Software x Hardware

O software é desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico– O software é um elemento de sistema lógico e não físico– existem semelhanças entre o desenvolvimento de

software e o de hardware (manufatura)• a alta qualidade é obtida a partir de um bom projeto mas

os custos do software estão concentrados no trabalho de engenharia

Software x Hardware

O software não se desgasta (como o hardware) mas se deteriora– Durante sua vida o software enfrentará mudanças, que

podem introduzir novos defeitos

Não existem “peças de reposição” para o software– Quando o hardware se desgasta é substituído por uma

peça de reposição– A complexidade e o custo de manutenção do software é

muito maior

A maioria dos softwares é feita sob medida– Montagem por reuso de componentes – Este é um cenário que está mudando

Quais são os problemas?

A sofisticação do software ultrapassou nossa capacidade de desenvolvimento– A construção de programas não acompanha a demanda por novos

programas– A manutenção de programas é ameaçada por projetos ruins– Geralmente não há metodologia e controle de qualidade para projetos

Causas óbvias

Não dedicamos tempo para coletar dados sobre o desenvolvimento do software - resulta em estimativas “a olho”Comunicação entre o cliente e o desenvolvedor é fracaFalta de testes sistemáticos e completos

Causas menos óbvias

Gerentes sem background em desenvolvimento de softwareProfissionais recebem pouco treinamento formalFalta investimento (em ES)Faltam métodos e automaçãoFalta acompanhamento do processo de desenvolvimento

Mitos do Software - Administrativos

Um manual oferece tudo que se precisa saberComputadores de última geração solucionam problemas de desenvolvimentoSe estamos atrasados, basta adicionarmos programadores e tirar o atraso (chamado “conceito de hordas de mongóis”)

Mitos do Software - do Cliente

Uma declaração geral é suficiente para começar a escrever programasMudanças podem ser facilmente acomodadas em um projeto

Mitos do Software - do Profissional

Um programa está terminado ao funcionarQuanto mais cedo escrever o código, mais rápido terminarei o programaSó posso avaliar a qualidade de um programa em funcionamentoA única coisa a ser entregue em um projeto é o programa funcionando

Recursos Humanos - Importância

Qual a importância dos Recursos Humanos no processo de desenvolvimento de software?

Motivo: a comunicação é absolutamente essencial para o desenvolvimento do software. Todo novo caminho de comunicação exige esforço adicional e portanto, tempo adicional.

Recursos Humanos – Grau de participação em projetos

Análise derequisitos

participação

baixo

alto

Grau de

no projeto

Planejamento Projetopreliminar

Pessoaltécnico senior

Pessoaltécnico junior

Administrador

Projetodetalhado

CodificaçãoTeste deunidade

As 10 Áreas da Engenharia de Software

Gerência de Configuração de SoftwareGerência de Engenharia de SoftwareProcesso de Engenharia de SoftwareFerramentas e MétodosQualidade de SoftwareRequisitos de softwareDesign de softwareConstrução de SoftwareTeste de SoftwareManutenção de Software

(SWEBOK, 2004)

Motivação

A crise do software

Força Aérea Americana, software de comando e controle (anos 80):– custo inicial estimado: U$400.000,00– custo final: U$3.200.000,00

(Jalote, 1997)

Software de recebimento de imposto de renda (EUA):– qualidade: o sistema se mostrou inadequado para a carga esperada– custo: a Receita Federal dos EUA gastou mais U$90.000.000,00 para

corrigir o software que custou U$103.000.000,00– devido ao atraso, a RF ainda teve de pagar mais U$63.000.000,00 de

multas por atraso e juros(B.Brügge 1997, Notas de curso TUM)

A crise do software

Ônibus Espacial:– Custo: U$10.000.000.000,00 (vários milhões a mais do que o

estimado)– Prazo: 3 anos de atraso– Qualidade: primeiro lançamento do Columbia foi cancelado devido a

problemas de sincronização de seus 5 computadores de bordo• Causa: modificação feita 2 anos antes, em que o tempo de espera de um

tratador de interrupção passou de 50ms para 80ms• O erro era um evento raro, tanto que não foi detectado durante as mais de

mil horas de teste– Muitos erros ainda subsistem. Os astronautas recebem um livro

contendo os problemas de software que já são conhecidos

(B.Brügge 1997, Notas de curso TUM)

Motivação

70% dos projetos de software falham ou são gravemente prejudicados:– negligenciam os cuidados com a elicitação dos requisitos – gerenciam mal seus requisitos

Um software que não satisfaz as necessidades software inútil

(Chaos, 1994)

Pesquisa realizada com 365 gerentes executivos de TI dos EUA

Três principais critérios de sucesso1. Envolvimento do Usuário2. Apoio da Gerência Executiva3. Indicação Clara dos Requisitos

Projetos falham ou são prejudicados1. Requisitos Incompletos2. Falta de Envolvimento do Usuário3. Falta de Recursos

Motivação

(Chaos, 1994)

Motivação

O que acontece se:– o usuário mudar de idéia em relação a uma funcionalidade?– o engenheiro de requisitos (ou analista) não entendeu corretamente a

necessidade do usuário?– o ambiente mudar?– o usuário perceber novas possibilidades na automação?

Mudanças

Motivação

Mudanças são inevitáveisRazões para mudanças:– modificações no ambiente: regras de negócios, leis,

políticas internas– mudanças tecnológicas– a complexidade dos sistemas impõe mudanças à medida

que se adquire maior conhecimento sobre os mesmos– correção ou ajustes em requisitos incorretos ou mal

definidos– desenvolvedores querem adicionar funcionalidades mais

avançadas de modo a oferecer vantagem– clientes mudam de idéia

Motivação

é preciso gerenciar as mudanças!mudanças em requisitos ao longo do desenvolvimento de software fazem parte do processoalterações em requisitos podem implicar em mudanças em artefatos de design, de código, casos de testes, etcRequisitos que tendem a mudar devem ser tratados isoladamenteIsolar regras de negócio para reuso

Motivação

re-trabalho e custo associado à correção de erros

quanto mais tarde o erro é descoberto, mais custosa será a correção

(Boehm, 1981)

A Importância dos Requisitosno Processo de Desenvolvimento

Requisitos de Software

Uma compreensão completa dos Requisitos do Software é fundamental para obter um software e um processo de desenvolvimento com alta qualidade

O software deve evoluir para atender às necessidades mutáveis dos clientes

.....“a construção por múltiplas pessoas de um software de múltiplas versões” (Parnas, 1987)

Requisito – Uma condição ou capacidade que deve ser satisfeita

ou possuída por um sistema ou componente do sistema para satisfazer um contrato, um padrão ou uma especificação(IEEE, 1990)

Especificação:– Uma descrição rigorosa e minuciosa das

características que um material, uma obra, ou um serviço deverão apresentar

(Aurélio, 1999)

Requisitos

Requisitos

Requisitos do usuário– Declarações, em linguagem natural e diagramas, sobre os

serviços que o sistema oferece e as restrições para a sua operação. Escrito para os clientes

Requisitos do sistema– Estabelecem detalhadamente as funções e restrições do

sistema. O documento de requisitos, chamado de especificação funcional, pode servir como um contrato entre cliente e desenvolvedor

Especificação de software– Especificação abstrata e precisa do software, indicando o que

ele deve fazer (sem dizer como) que serve de base para o projeto e para a implementação

– Acrescenta mais detalhes à especificação funcional e é escrito para a equipe de desenvolvimento

Requisitos PETROBRAS

Requisito de Negócio– Descrevem as atividades que os usuários deverão ser

capazes de executar com a utilização do sistema, delimitando o domínio do problema

– Estão descritos no Documento de Visão– Funcionais, não funcionais e inversos

Requisito de Produto– Descrevem características associadas a implementação

da solução– Funcionais (Doc. de Caso de Uso) e não funcionais (Doc.

de Especificação Suplementar)

Requisitos servem como especificação do que deve ser implementadoRequisitos são descrições de como o sistema deve se comportar, de uma propriedade ou atributo do sistemaUm requisito pode descrever:– uma facilidade encontrada no nível do usuário– uma propriedade geral do sistema– uma restrição do sistema– uma restrição ao desenvolvimento do sistema

(Sommerville, 2003)

Requisitos

“O sistema deve rodar em microcomputadores da linha PC que possuam microprocessador Pentium ou superior”“A interface do sistema deve ser gráfica, de acordo com um padrão de interface dirigida a menu”“Alternativamente, o sistema deve possibilitar o seu uso através de linhas de comando, para usuários avançados”“O gerente da padaria deve consultar quanto vendeu em um dia”

Requisitos - Exemplos

Requisitos: diretrizes para elaboração 1/2

Definir um formato padrão e usá-lo para todos os requisitosUtilizar o idioma de forma consistente. Usar “deve” para requisitos obrigatórios, “deveria” (ou é recomendável) para requisitos desejáveisEvitar o uso de jargões de computaçãoEmpregar termos característicos do problema

Requisitos: diretrizes para elaboração 2/2

Use sentenças diretas e objetivasUse vocabulário limitadoDefina requisitos verificáveisEvite ambigüidadesEvite sentenças muito longasEvite uso de conjunções como ou, e, com, tambémEvite termos vagos ou indefinidos

Como especificar Requisitos

Linguagem natural estruturada– A abordagem estruturada emprega templates para registrar, validar e

gerenciar requisitos– Nesta abordagem é preciso definir um ou mais formulários ou

templates para expressar os requisitos.– Vantagens

• Uniformidade• Possibilidade de agrupar requisitos• Possibilidade de rastrear os requisitos

Para especificar requisitos:– Descrição da necessidade atendida pelo requisito– Descrição da função ou entidade que está sendo

especificada– Descrição de suas entradas e de onde elas se originam;– Descrição de suas saídas e para onde elas prosseguirão– Indicação de quais outras entidades são utilizadas – Pré-Condição

• Condição que deve ser verdadeira para que seja executado– Pós-Condição

• O estado resultante do sistema

Itens importantes de um template

Pré-condições:– definem o que deve ser verdadeiro na estrutura da

informação armazenada para que a operação ou consulta possa ser executada

– algum mecanismo externo deverá garantir sua validade antes de habilitar a execução da operação ou consulta ao sistema

Pós-condições:– estabelecem o que uma operação de sistema muda na

estrutura da informação armazenada – estabelece a resposta gerada pelo sistema quando a

operação é executada

Abordagem estruturada

Requisitos– um novo cliente deve ser cadastrado em uma Video

Locadora– O cadastro do cliente contém nome, endereço e telefone

Pré-condição:– Não existe nenhum cliente com o nome informado

Pós-condição:– O cliente foi adicionado ao cadastro– Os dados informados sobre o cliente são atualizados nos

atributos do cliente– O cliente é criado com o débito zerado

Abordagem estruturada - Exemplo

Conceitos

• Regra de Negócio

• Requisitos Funcionais e Não Funcionais

• ISO/IEC 9126

Regra de Negócio

O que é uma Regra de Negócio?– Define ou restringe aspectos da organização– Fontes:

• decisões estratégicas • leis e regulamentações• obrigações contratuais

Importância de identificar Regras de Negócio

As melhores práticas de engenharia de software advogam código reusável e modular

Separar regras de negócio de projetos específicos é uma forma de adaptar esta regra para a gerência de requisitos– as regras de negócio podem ser empregadas em vários projetos

Exemplo de Regra de Negócio

“Os remédios comercializados devem ter, no mínimo, 30 dias de validade”“Para ser considerado dependente, a pessoa não pode ter renda ou a renda deve ser abaixo de um salário mínimo”

requisitos funcionais, não funcionais, inversos

requisitos funcionais: – aqueles diretamente relacionados à funcionalidade do software– dependentes do problema e independentes da solução

Requisitos: Classificação

Requisitos: Classificação

Requisitos não funcionais: relacionados a aspectos de qualidade que o software deverá apresentar, ou a restrições a serem atendidasExemplo: Norma de Qualidade da ISO/IEC 9126– Dependente da solução

Requisitos inversos: representam funcionalidades que estão fora do escopo da solução

Exemplos de Requisitos

Requisito funcional“O sistema deve controlar o horário de entrada e saída dos funcionários” Requisito não funcional

“O relatório mensal dos horários, por funcionários, deve ser impresso em papel timbrado” Requisito inverso

“O sistema somente será implementado em idioma nacional”

Exercício: Fazer o levantamento de Requisitos para o problema a seguir:

A exploração e produção de petróleo em águas profundas é difícil e

custosa. Para tanto, são utilizados robôs tanto para perfuração como para instalação dos equipamentos. Estes robôs são controlados a distância e configurados de acordo com a operação que irão realizar. Atualmente, o treinamento para capacitar as pessoas a utilizarem estes robôs são feitos com os próprios robôs, causando um alto custo de manutenção. Deseja-se um sistema, simulador virtual, que possa se comportar exatamente como o robô real, com uma série de benefícios, tais como: painel gráfico de controle exatamente igual ao controlador do robô; cadastro de usuários para que seja gravado um acompanhamento e histórico do aluno e este possa ser avaliado; acesso, pelos instrutores, aos dados de cada aluno. É necessário que o ambiente do robô seja simulado graficamente, bem como os aspectos físicos: sua colisão com objetos, fricção com a água, tempo de resposta. Além disso, o simulador deve permitir uma ampla configuração de variáveis do robô.

Exemplos de Requisitos

Requisito funcional“O sistema deve controlar o horário de entrada e saída dos funcionários” Requisito não funcional

“O relatório mensal dos horários, por funcionários, deve ser impresso em papel timbrado” Requisito inverso

“O sistema somente será implementado em idioma nacional”