18/08/2008

Requisitos de Software
Parte 2 Requisitos de Software
A parte mais rdua na construo de um sistema de software decidir o que construir. Nenhuma outra parte do trabalho compromete mais o sistema se for feito de forma imprpria. Nenhuma outra parte mais difcil de corrigir a posteriori.
F. P. Brooks Jr, No Silver Bullet: Essence and Accidents in Software Engineering, IEEE Computer, abril 1987.

Requisitos so propriedades desejveis para um sistema de software. Um requisito pode ser mensurvel (ex., tempo mdio de atendimento de requisies), ou avaliado subjetivamente (ex., qualidade da documentao). Requisitos so descritos em diferentes nveis de abstrao: Requisitos de usurio: especificam em linguagem natural as funes que o sistema deve prover ao usurio final; Requisitos de sistema: especificam em linguagem natural (mais estruturada) as funes e restries (especificao funcional) para que o sistema de software seja capaz de atender os requisitos de usurio.

EA976 Prof. Eleri Cardozo FEEC/Unicamp EA976 Prof. Eleri Cardozo FEEC/Unicamp

Requisitos Funcionais e No Funcionais

Requisitos funcionais descrevem as funcionalidades ou servios que se espera do sistema (funes precpuas do sistema). Exemplo: o sistema deve notificar o requisitante por e-mail quando sua requisio estiver disponvel para retirada. Requisitos no funcionais so requisitos no diretamente relacionados s funes precpuas do sistema. Exemplos: reuisitos de confiabilidade, robustez, eficincia e segurana.

Requisitos No Funcionais
De acordo com sua procedncia, os requisitos no funcionais podem ser classificados em: Requisitos de produto: relacionados ao comportamento do produto tais como facilidade de uso, eficincia (desempenho, recursos exigidos), confiabilidade, portabilidade. Requisitos organizacionais: relacionados s organizaes do cliente e do fornecedor tais como prticas, padres e restries contratuais e de projeto. Requisitos externos: relacionados a restries impostas por fatores externos ao sistema tais como restries de interoperabilidade, ticas e legais.

EA976 Prof. Eleri Cardozo FEEC/Unicamp

EA976 Prof. Eleri Cardozo FEEC/Unicamp

18/08/2008

Requisitos de Usurio
Requisitos de usurio especificam o comportamento externo do sistema sob a perspectiva do usurio (humano ou no). Problemas na identificao dos requisitos de usurio: Falta de clareza ou ambiqidades, por serem descritos em linguagem natural (ex.: o usurio deve ser alertado sobre operaes perigosas); Confuso entre requisitos funcionais, no funcionais e objetivos do sistema (ex.: o sistema deve facilitar a solicitao de declaraes); Fuso de requisitos onde um nico requisito na verdade uma condensao de vrios requisitos (Ex.: O sistema deve permitir ao usurio escolher a imagem a ser processada (dentre os diversos formatos permitidos) por meio de um file chooser).
EA976 Prof. Eleri Cardozo FEEC/Unicamp

Requisitos de Sistema
Requisitos de sistema (funcionais, no funcionais e de domnio) descrevem mais detalhadamente os requisitos de usurio. So base para um contrato de implementao do sistema. Problemas na identificao dos requisitos de sistema: Requisitos de sistema ainda so descritos em linguagem natural acompanhada de diagramas ilustrativos (a ambiqidade persiste); Idealmente, os requisitos de sistema no devem conter decises de projeto, mas requisitos impostos pela arquitetura e sistemas legados acabam sendo incorporados nos requisitos de sistema.

EA976 Prof. Eleri Cardozo FEEC/Unicamp

Requisitos de Interfaces Externas

Interfaces externas estabecem requisitos para que o sistema possa interoperar com outros sistemas e com os usurios humanos (so, portanto, requisitos de sistema). O IEEE classifica as interfaces externas em: Interfaces de usurio; Interfaces de hardware; Interfaces de software; Interface de comunicao. As interfaces de software definem: procedimentos (servios providos/requeridos); estruturas de dados (trocados entre sistemas); representao de dados trocados (XML, Base64, ...).

Descrio de Requisitos
Recomendaes: Padronize o formato e a linguagem de descrio. Exemplo: as RFCs do IETF empregam os termos deve, requer, dever, deveria e poder para especificar o grau de obrigatoriedade dos requisitos. Enfatize no texto as partes importantes dos requisitos. Evite o uso de jarges (ex., o sistema deve ser tunado para maximizar a agregao de valor ao produto e assim favorecer sua relao custo/benefcio).

EA976 Prof. Eleri Cardozo FEEC/Unicamp

EA976 Prof. Eleri Cardozo FEEC/Unicamp

18/08/2008

Descrio de Requisitos
Uso de formulrios padro. Exemplo: Funo: Processar pginas dinmicas. Descrio: Executa o cdigo associado uma pgina dinmica, coleta o resultado do processamento deste cdigo e retorna o resultado para o navegador do cliente. Entradas: URL da pgina dinmica. Saidas: Resultado do processamento da pgina armazenado em um buffer. Destino: Conexo de transporte estabelecida com o cliente. Requer: Autenticao, caso o recurso associado URL seja protegido. Pr-condio: Pgina dinmica j compilada. Ps-condio: Resultado do processamento retornado ao cliente. Efeitos colaterais: nenhum.
EA976 Prof. Eleri Cardozo FEEC/Unicamp

Documento de Requisitos
uma declarao oficial do que exigido dos desenvolvedores do sistema: Utilizados por diferentes profissionais com diferentes propsitos; Clientes ( isso que eu quero?); Gerentes de projeto (atividades?, pessoas?, riscos?); Engenheiros de sistema (o que vamos desenvolver?); Engenheiros de teste (como validadar estes requisitos?); Engenheiros de manuteno (como manter o sistema sem alterar os requisitos?). Importantssimo para contratar o desenvolvimento de um sistema de software; O contratante pode exigir que este documento siga determinada norma, exemplo IEEE 830-1998.

Documento de Requisitos
O padro IEEE 830-1998 (1998) sugere a seguinte estruturao para o documento de requisitos: 1. Introduo 1.1. Propsito do documento de requisitos 1.2. Escopo do produto 1.3. Definies, acrnimos e abreviaes 1.4. Referncias 1.5. Viso geral do restante do documento 2. Descrio Geral 2.1. Perspectiva do produto 2.2. Funes do produto 2.3. Caractersticas do usurio 2.4. Restries gerais 2.5. Suposies e dependncias 3. Requisitos Especficos Apndices ndice
EA976 Prof. Eleri Cardozo FEEC/Unicamp

O padro IEEE 830-1998 sugere 7 formas de organizar o captulo 3 do documento de requisitos. Cada forma organiza os requisitos por um critrio especfico: 1. 2. 3. 4. 5. 6. 7. modo (de operao, utilizao, etc.); classe de usurio; objeto; facilidade (feature); estmulo; hierarquia funcional; mltiplos critrios (Ex.: facilidade + classe de usurio).

EA976 Prof. Eleri Cardozo FEEC/Unicamp

Documento de Requisitos

EA976 Prof. Eleri Cardozo FEEC/Unicamp

18/08/2008

Documentos de Requisitos
3. Requisitos Especficos 3.1. Requisitos de interfaces externas 3.1.1. Interfaces com o usurio 3.1.2. Interfaces de hardware 3.1.3. Interfaces de software 3.1.4. Interface de comunicao 3.2. Requisitos Funcionais 3.2.1. Critrio #1 3.2.1.1. Requisito funcional #1 .... 3.2.1.k. Requisito funcional #k .... 3.2.2. Critrio #n .... 3.3. Requisitos de desempenho 3.4. Restries de projeto 3.5. Atributos do sistema de software 3.6. Outros Requisitos
EA976 Prof. Eleri Cardozo FEEC/Unicamp

Atributos de um Bom Documento de Requisitos (IEEE 830-1998)

Correto: os requisitos listados so aqueles que o sistema deve efetivamente atender; Sem ambiqidades: cada requisito listado possui uma nica interpretao; Completo: todos os requisitos significantes esto identificados, bem como todas as respostas do sistema para todas as situaes de utilizao; Consistente: todos os requisitos esto de acordo com especificaes superiores; Verificvel: uma pessoa ou sistema pode atestar o cumprimento de cada requisito listado; Modificvel: qualquer requisito listado pode ser alterado sem impactar nos demais requisitos (requisitos ortogonais); Travel: todos os requisitos listados so globalmente identificados e relacionados com componentes funcionais do sistema.
EA976 Prof. Eleri Cardozo FEEC/Unicamp

Exerccio

Engenharia de Requisitos
Conjunto de atividades que culminam no documento de requisitos.

Estabelea alguns requisitos funcionais e no funcionais para o sistema de oferta de disciplinas proposto. Identifique os requisitos de usurio, de sistema e de interfaces externas. Classifique os requisitos segundo a classe de usurio (professor, funcionrio da coordenao).

Estudo de Viabilidade

Obteno e Anlise de Requisitos

Especificao de Requisitos

Validao de Requisitos

Relatrio de Viabilidade

Modelos de Sistema

Requisitos de Usurio e de Sistema

Documento de Requisitos

EA976 Prof. Eleri Cardozo FEEC/Unicamp

EA976 Prof. Eleri Cardozo FEEC/Unicamp

18/08/2008

Estudo de Viabilidade
Perguntas a serem respondidas: O sistema contribui para os objetivos gerais da organizao? O sistema pode ser implementado respeitando-se restries de custo e prazo? O sistema pode ser integrado com outros j em operao? Exemplo de atividades de anlise de viabilidade: Estabelecer cenrios com e sem o novo sistema; Elencar os problemas atuais que seriam eliminados com o novo sistema; Estabelecer custos e prazos de desenvolvimento realistas; Estabelecer custos operacionais realistas (treinamentos, contrataes, aquisies); Avaliar se os sistemas existentes esto preparados para interoperar com o novo sistema.
EA976 Prof. Eleri Cardozo FEEC/Unicamp

Levantamento e Anlise de Requisitos

Atividades: Compreenso do domnio. Coleta de requisitos. Classificao (estruturao) dos requisitos. Resoluo de conflitos. Identificao dos requisitos prioritrios. Verificao dos requisitos (consistentes, completos, etc.).

EA976 Prof. Eleri Cardozo FEEC/Unicamp

Stakeholder
(pessoa que possui interesse em algo)

Levantamento Orientado a Pontos de Vista

Conceitos chave: Ponto de vista: uma perspectiva para se examinar o sistema (do ponto de vista do cliente, o sistema ATM permite retirada de dinheiro; do ponto de vista do gerente, o sistema ATM permite limitar o montante de dinheiro retirado). pontos de vista de interao (cliente); pontos de vista indiretos (gerente); pontos de vista de domnio (comunicao inter-bancos). Servio: funcionalidade propiciada pelo sistema (retirada de dinheiro e limitao do montante retirado).
EA976 Prof. Eleri Cardozo FEEC/Unicamp

Stakeholder uma pessoa que ter alguma influncia direta ou indireta sobre os requisitos do sistema. Dificuldades que o analista encontra ao interagir com os stakeholders: stakeholders em geral no tem uma idia clara do sistema a ser desenvolvido; stakeholders empregam termos prprios para expressar os requisitos; diferentes stakeholders tm em mente diferentes requisitos; stakeholders podem impor requisitos movidos por interesses prprios; stakeholders no consultados podem impor requisitos em fases avanadas do desenvolvimento.

EA976 Prof. Eleri Cardozo FEEC/Unicamp

18/08/2008

Identificao dos Pontos de Vista e Servios

Brainstorming: desenvolvedores e stakeholders procuram as palavras-chave associadas ao sistema. Destas, pontos de vista e servios so identificados.

Hirarquias de Pontos de Vista

Servios: Consultar saldo Retirar dinheiro Todos os Pontos de Vista

Cliente (interao)

Funcionrios do Banco (indireto)

Correntista Ponto de vista

Consulta Saldo Servio

Segurana Requisito no funcional

Cliente do Banco Cliente de Banco Conveniado Gerente De Contas Engenheiro de Software

Servios: Emitir talo de cheques Emitir extrato detalhado Transferir fundos

EA976 Prof. Eleri Cardozo FEEC/Unicamp EA976 Prof. Eleri Cardozo FEEC/Unicamp

Templates para Ponto de Vista

Referncia Cliente Numero da conta Senha pessoal Limite de retirada Selecionar servio Cancelar transao Encerrar transao Consultar saldo Retirar dinheiro Cliente do banco Cliente de banco conveniado

Templates para Servios

Referncia Razo Retirar dinheiro Aumentar a gama de servios oferecidos aos clientes do banco e de bancos conveniados Clientes escolhem esse servio selecionando a opo "retirada de dinheiro". A seguir informam a quantia a ser retirada. A operao confirmada e, se o saldo permitir, o dinheiro entregue. Cliente Ajustar timeouts velocidade com que o cliente supre os dados

Atributos

Eventos

Especificaes

Servios Subpontos de Vista

Pontos de Vista Requisitos no funcionais Provedor

EA976 Prof. Eleri Cardozo FEEC/Unicamp

EA976 Prof. Eleri Cardozo FEEC/Unicamp

18/08/2008

Cenrios
Cenrios descrevem situaes de uso do sistema (sesses de interao). Modelam os eventos que ocorrem na fronteira do sistema. A descrio de um cenrio pode incluir: o estado do sistema no incio da interao; o fluxo normal de eventos; fluxos alternativos de eventos; atividades concorrentes; o estado do sistema no final da interao.
Agente (Ator)

Casos de Uso (Use Cases)

Interao (Use Case)

Um caso de uso pode representar um ou mais cenrios. O conjunto de casos de uso representa todas as possveis interaes suportadas pelo sistema. Via de regra, um requisito funcional modelado por um caso de uso. Tipicamente, um ponto de vista um agente e um servio uma interao.

EA976 Prof. Eleri Cardozo FEEC/Unicamp

EA976 Prof. Eleri Cardozo FEEC/Unicamp

Caso de Uso
Um caso de uso pode usar ou especializar (estender) outro caso de uso. Exemplo
Aprova Cheque Especial <<uses>> Gerente Aprova Crdito <<estends>>

Templates para Casos de Uso

ID do caso de uso Nome Criado por Data de criao Analisa Risco Atualizado por Data da ultima atualizao Atores Descrio Prioridade Gerente Este caso de uso apoia o gerente do banco na aprovao de crdito aos clientes A ser definido Cliente j cadastrado na base de clientes Crdito inserido na carteira de crdito do banco
EA976 Prof. Eleri Cardozo FEEC/Unicamp

2.1 Aprova crdito Eleri Cardozo 20/08/2007

Aprova Crdito Imobilirio

Aprova Crdito Pessoal

Pr-condio Ps-condio

EA976 Prof. Eleri Cardozo FEEC/Unicamp

18/08/2008

Templates para Casos de Uso

Fluxo bsico de eventos
Aes do Ator 1. Gerente escolhe opo "Aprovar Crdito" 3. Gerente supre username e senha 6. Gerente supre dados do cliente Aes do Sistema 2. Sistema solicita autenticao do usurio 4. Sistema valida senha 5. Sistema solicita dados do cliente 7. Sistema valida dados do cliente 8. Sistema efetua avaliao de risco 9. Sistema indica aprovao do crdito 11. Sistema insere crdito na carteira de crdito do banco

Templates para Casos de Uso

Fluxo alternativo de eventos
Aes do Ator Aes do Sistema 4a. Sistema detecta username ou senha incorreto - solicita novamente

10. Gerente confirma aprovao de crdito

EA976 Prof. Eleri Cardozo FEEC/Unicamp

EA976 Prof. Eleri Cardozo FEEC/Unicamp

Etnografia
Tcnica na qual o analista se insere no ambiente em que o sistema ser utilizado a fim de extrair requisitos sociais e organizacionais. Exemplo: para desenvolver um sistema de controle de trfego areo importante que o analista conhea a rotina de trabalho dos controladores de trfego areo. A tcnica interessante para adquirir conhecimento do domnio.

Validao de Requisitos
Objetivo: tornar o documento de requisitos um "bom documento de requisitos" (IEEE 830-1998). Tcnicas de validao: Revises por uma equipe de reviso (desenvolvedores + stakeholders). Prototipao (ex.: interfaces). Gerao de casos de teste (se um requisito difcil de testar, provavelmente ser difcil de implementar). Anlise automatizada da consistncia (raramente possvel).

EA976 Prof. Eleri Cardozo FEEC/Unicamp

EA976 Prof. Eleri Cardozo FEEC/Unicamp

18/08/2008

Gerenciamento de Requisitos
o processo de compreender e controlar as mudanas nos requisitos do sistema. Requisitos podem ser permanentes ou volteis. Requisitos volteis devem ter alto grau de independncia dos demais requisitos. Exemplo:
Aprova Cheque Especial <<uses>> Gerente Aprova Crdito <<estends>> Aprova Crdito Imobilirio Aprova Crdito Pessoal
OK se for voltil

Engenharia de Requisitos
Estudo de Viabilidade Obteno e Anlise de Requisitos

Especificao de Requisitos

Validao de Requisitos

Analisa Risco

Ruim se for voltil (Ex.: alterao de poltica de concesso de crditos pode exigir novas informaes no caso de uso "Aprova Crdito").

Relatrio de Viabilidade

Modelos de Sistema

Requisitos de Casos Usurio e de de Uso Sistema Documento de Requisitos

Modelo de contexto Modelos de comportamento Modelo de dados Modelos de objeto

EA976 Prof. Eleri Cardozo FEEC/Unicamp

Cap. 7(8)

EA976 Prof. Eleri Cardozo FEEC/Unicamp