Aula3 engenharia requisitos

Engenharia de Software

Aula 3 – Engenharia de RequisitosProfa. Dra. Judith Pavón

Universidade Salvador – UNIFACS2012

Objetivo da aula

2

O objetivo desta aula é apresentar os conceitos básicos de Engenharia de Requisitos.

3

Conteúdo

1. Introdução

2. Importância dos requisitos

3. Processo de Engenharia de Requisitos

4. Classificação dos requisitos

Introdução

Um processo de engenharia de requisitos eficiente evita uma compreensão incorreta dos requisitos.

4

Introdução Requisitos são importantes para projetos

de desenvolvimento de software, pois são a base para : Análise de contratos; Elaboração / análise de propostas; Planejamento; Estimativas; Análise de riscos; Gestão e controle; Modelagem do sistema; Desenvolvimento; Testes.

5

Introdução

Problemas com requisitos levam a: Clientes insatisfeitos; Altos custos; Perda de reputação; Compreensão do “problema incorreto”; Efeito cascata nas demais fases de

desenvolvimento de software.

6

CMMI-SE/SW (Capability Maturity Model Integration)

Modelo de melhoria de processo de desenvolvimento de software.

Modelo seguindo 5 níveis de maturidade.

Capacidade de um processo de software: faixa de resultados esperados dentro de uma margem

de probabilidade.

Maturidade do processo: reflete em que medida ele pode ser definido,

gerenciado, medido, controlado e executado de maneira eficaz. 7

Importância dos requisitos

CMMI-SE/SW (Capability Maturity Model Integration)

5.

OTIMIZADO

4. GERENCIADO

QUANTITATIVAMENTE

3.

DEFINIDO

2. Processo orientado a projetos e geralmente reativo

3. Processo orientado à organização e proativo

2.

GERENCIADO

4. Processo medido e controlado

5. Processo focado na melhoria contínua

1.

INICIAL

1. Processo imprevisível, pouco controlado e reativo

8


Níveis de Maturidade - CMMI-SE/SW

9


Processo de Engenharia de Requisitos (PER) no modelo CMMI

nível 1. inicialPER adhoc

nível 2. repetívelPER obedecendo

a normas

nível 3. definidoPER baseado

em melhores práticas;melhoria contínua

10


Ciclo de Vida de Software (SWEBOK, 2004)

SWEBOK – Guide to the Software Engineering Body of Knowledge (IEEE)

Levantamento e Definição de Requisitos

Projeto deSoftware

Implementaçãode Software

Teste deSoftware

Manutenção deSoftware

Elicitação de Requisitos

Análise de Requisitos

Especificaçãode Requisitos

Validaçãode Requisitos

Gerenciamentode Requisitos

Modelo Genérico

11


56% dos erros em um sistema associam-se a problemas na fase de identificação dos requisitos (Fonte: “Extra time saves money” Warren Kuffel).

Erros mais comuns: uso de fatos incorretos, omissão, inconsistência e ambigüidade.

56%

27%

10%7%

Distribuição de Defeitos

Requisitos

Projeto

Outros

Codificação


Clássicas falhas de sistemas por problemas de requisitos

Aeroporto de Denver: mais de US$ 50 milhões perdidos em função de erros no sistema de controle de bagagens (Flower).

Sistema de Ambulâncias de Londres: o sistema foi desativado um dia após o início de suas operações com causa de seus erros e falhas de segurança, confiabilidade e usabilidade (Flower).

Foguete do Satélite Ariane 5: a trajetória do foguete era controlada por um sistema de computador, que falhou junto com seu sistema backup. Comandos de diagnóstico foram enviados para os motores, fazendo com que o foguete mudasse para uma trajetória instável (Nuseibeh).

13


Conceitos Básicos

Requisito

Uma especificação do que deve ser implementado. Descrição de como o sistema deve se comportar, ou uma propriedade ou atributo do sistema. Pode ser uma restrição no processo de desenvolvimento do sistema. (Sommerville & Sawyer)

Uma condição ou capacidade que o sistema deve contemplar (Pressman)

Uma necessidade do usuário ou característica, função ou atributo de um sistema que pode ser percebido de uma posição externa ao sistema. (Davis)

14

Engenharia de Requisitos

A Engenharia de Requisitos é um processo que envolve todas as atividades necessárias para criar e manter um Documento de Especificação de Requisitos (Sommerville).

A Engenharia de Requisitos é uma sub-área da Engenharia de Software que estuda o processo de definição de requisitos que o software deverá atender (Sampaio).

A Engenharia de Requisitos tem como objetivo prover ao profissional de métodos, técnicas e ferramentas que auxiliem o processo de compreensão e registro dos requisitos que o sistema deve atender (Sampaio).

Conceitos Básicos

15

Processo de Engenharia de Requisitos

Processo É um conjunto organizado de atividades que transforma entradas

em saídas (Pressman).

Atividades do Processo de Engenharia de Requisitos (Sommerville &

Kontoya) Elicitação de Requisitos

Os requisitos são descobertos por meio das consultas com as partes interessadas.

Análise e Negociação de Requisitos Requisitos são analisados e conflitos são resolvidos por meio da

negociação. Documentação de Requisitos

Um documento de requisitos é produzido. Validação de Requisitos

É checada a consistência, completude e outros atributos de qualidade do documento de requisitos.

Gerenciamento de Requisitos Consiste no controle de mudanças dos requisitos dentro do ciclo de

vida do software. 16


Fonte: Sommerville & Sawyer, 2000

Elicitação Documentação

Validação

Análise

Gerenciamento de Requisitos

17


Desenvolvimento de Requisitos Gerenciamento de Requisitos

Requisitos

Elicitar Requisitos

Analisar Requisitos

Documentar Requisitos

Validar Requisitos

Controlar Mudanças

Gerenciar Configuração

Rastreabilidade

Gerenciar Qualidadede Requisitos

18


Processo de Engenharia de Requisitos(Entradas e Saídas)

processo de engenharia de

requisitosDocumento

deRequisitos

requisitosaprovados

sistemas existentes

necessidades dos

usuáriosnormas

da organização

regulamentos

informaçãodo

domínioFonte: Kotonya & Sommerville, 1998

19

Características Principais da Engenharia de Requisitos

O processo de engenharia de requisitos é estruturado como um conjunto de atividades que leva a produção do documento de requisitos.

As entradas do processo de engenharia de requisitos são as informações existentes dos sistemas, necessidade das pessoas interessadas (stakeholders), padrões organizacionais, regulamentações e informações do domínio.

Os processos de engenharia de requisitos variam radicalmente entre empresas. A maioria dos processos incluem a elicitação de requisitos, análise e negociação, a documentação e a validação dos requisitos.

A atividade de gerenciamento de requisitos é uma atividade complementar que auxilia no controle das mudanças dos requisitos.

20


Stakeholders

Atores no Processo de Engenharia de Requisitos: Stakeholders

Quem são os “interessados no sistema”?

São as pessoas que serão afetadas pelo sistema e que têm uma influência direta ou indireta na elaboração dos requisitos:

usuários finais, gestores e outros envolvidos nos processos organizacionais que o sistema influencia, responsáveis pelo desenvolvimento e manutenção do sistema, clientes da organização que possam vir a usar o sistema, organismos de regulação e certificação, etc.

21

Alguns exemplos de partes interessadas (stakeholders):

Gestor do sistema; Usuários finais; Gestores de sistemas impactados; Funcionários; Clientes do banco; Especialistas no negócio; Órgãos reguladores; Parceiros.

22

Stakeholders

Conceito de Rastreabilidade Técnica usada para prover relacionamento entre requisitos,

projeto e implementação final do sistema (Edwards). É uma técnica que permite que os requisitos sejam

claramente ligados às suas fontes e aos artefatos criados durante o ciclo de vida de desenvolvimento do sistema (Ramesh).

Habilidade de permitir que mudanças em qualquer artefato – requisitos, especificação e implementação– sejam rastreadas através do sistema (Greenspan).

Necessidades

Macro-Requisitos

Requisitos

Projeto e Documentações

Rastreabilidade

Domínio doProblema

Domínio daSolução

23

Uma especificação de requisitos é rastreável se permite a fácil determinação dos antecedentes e conseqüências de todos os requisitos.

Rastreabilidade para Trás: Deve ser possível localizar a origem de cada requisito. Deve-se saber por que existe cada requisito, e quem ou o que o originou.

Rastreabilidade para Frente: Deve ser possível localizar quais os resultados do desenvolvimento que serão

afetados por cada requisito. Isso é importante para garantir que os itens de análise, modelagem, código e

teste abranjam todos os requisitos, e para localizar os itens que serão afetados por uma mudança nos requisitos.

Isso é importante para que se possa avaliar o impacto da mudança daquele requisito, e dirimir dúvidas de interpretação.

24

Conceito de Rastreabilidade


Os usuários comunicaram uma série de mudanças nas regras de negócio do Sistema de Contabilidade. Quanto você acha que vamos levar para alterar o sistema?

Cara, vai dar um trabalhão. A lógica do cálculo dos impostos está espalhado por todo o sistema. Vamos gastar um tempão só para localizar todos os lugares que teremos de mexer.

25


A gestão de requisitos deve prover meios para que seja possível fazer um rastreamento entre os requisitos.

Devem ser criados e mantidos entre requisitos, desde os requisitos de negócio até os requisitos de implementação, de testes e de documentação.

Deve ser possível seguir estes vínculos nas duas direções.

26

Motivos para fazer Rastreabilidade

Certificação – demonstração de que todos os requisitos foram implementados.

Análise de impacto – cálculo do custo, tempo e risco de uma mudança.

Manutenção – Indicação dos lugares onde deverão ser feitas as alterações solicitadas.

Acompanhamento do projeto – aferição do progresso de um projeto de desenvolvimento ou manutenção.

27

Motivos para fazer Rastreabilidade

Reengenharia – vínculo entre as funções do velho sistema e o local em que as mesmas estão implementadas no novo sistema.

Reutilização – identificação de pacotes reutilizáveis de requisitos, design, código e testes.

Redução de riscos – redução do impacto causado pela perda de um membro da equipe que mantém conhecimento essencial sobre o projeto.

Testes – apoio na identificação dos locais onde pode estar o defeito detectado.

28

Classificação de Requisitos

29

Classificação de Requisitos

Níveis de Requisitos Nível de negócio Nível de sistema

Tipos de Requisitos

Nível de negócio Requisitos de usuário (negócio) Regras de negócio

Nível de sistema Requisitos Funcionais Requisitos Não Funcionais; Requisitos Inversos;

30

Níveis de Requisitos Existem basicamente dois níveis de

requisitos:

Nível de negócio:

Considera-se um nível macro, onde o foco principal é o negócio, independente do sistema.

Nível de sistema:

Considera-se um nível mais micro, onde a preocupação é identificar todos os requisitos necessários para o negócio, que devem ser contemplados no sistema.

31

Nível de Negócio Existem dois tipos de requisitos neste nível:

Requisitos de negócio:

São as necessidades do negócio que são expressas pelos usuários ou clientes do sistema.

São declarações, em linguagem natural ou em diagramas sobre o que o negócio exige que seja desenvolvido. Os requisitos de negócio devem se concentrar no que o sistema deve atender e não no como.

Regras de negócio:

São restrições sobre dados ou processos de negócio.

32

Regras de Negócios

Uma regra de negócio descrevem, restringem ou controlam os dados ou atividades de um processo de negócio.

Um processo de negócio é um conjunto de um ou mais procedimentos, os quais coletivamente realizam um objetivo de negócio, normalmente dentro do contexto de uma estrutura organizacional.

33

Uma organização ou empresa opera de acordo com um conjunto de regras de negócio, tais como, regras jurídicas, regras de venda, regras de interação com o cliente, entre outras.

As regras expressam aspectos estáticos e dinâmicos do negócio.

A automatização dos processos de negócio exige a automatização das regras que regem estes processos.

As regras são representadas em uma linguagem processável, com a finalidade de automatizá-las em um sistema.

34

Regras de Negócios

ExemploRegra: O gerente designado para atender a um cliente deve estar lotado em uma agência onde o cliente possui conta corrente.

Gerente AgênciaEstá lotado

ClienteConta

CorrentePossui

Atende Pertence

35

Nível de Sistema

Requisitos de sistema:

Estabelecem detalhadamente as funções e as restrições de sistema. O documento de requisitos de sistema, algumas vezes chamado de especificação funcional é gerado neste nível. Ele pode servir como um contrato entre o comprador do sistema e o desenvolvedor de software.

36

Tipos de Requisitos de Sistema Requisitos Funcionais

Descrevem os serviços que se espera que o sistema deve oferecer.

Especificam as funcionalidades do sistema.

Requisitos Não Funcionais Descrevem aspectos de qualidade que o software deverá

apresentar, ou as restrições a serem atendidas. Os requisitos não funcionais referem-se às condições

nas quais deve funcionar o sistema. Podem estar relacionados a propriedades do sistema, tais

como, confiabilidade, desempenho, etc.

Requisitos Inversos Referem-se ao que o sistema não fará. Descrevem as

funções e restrições que não serão consideradas na abrangência do sistema.

São declarações do que o sistema não deve fazer ou de condições que nunca devem ocorrer durante o uso do sistema.

37

Tipos de Requisitos de Sistema Exemplos de Requisitos Funcionais:

O sistema deve permitir o cálculo dos gastos diários, semanais, mensais e anuais com o pessoal.

O sistema deve permitir consultar informações gerenciais operacionais da empresa.

Exemplos de Requisitos Não Funcionais: O tempo de resposta do sistema não deve

ultrapassar 30 segundos. O software deve ser operacionalizado no sistema

Linux.. O sistema deve ter uma disponibilidade 24x7.

Exemplos de Requisitos Inversos: A integração com o banco central, contabilidade e

recursos humanos não fazem parte deste sistema.38

Requisitos Funcionais

Como especificar requisitos funcionais? Linguagem Natural

Os requisitos funcionais podem ser descritos em linguagem natural em nível macro.

Casos de uso Um modelo de casos de uso é utilizado para

representar as funcionalidades do sistema de forma detalhada.

Um modelo de casos de uso identifica quem ou o que interage com o sistema e o que sistema deve fazer.

Casos de uso são técnicas baseadas em cenários onde são identificados atores e sua interação com o sistema.

39

Requisitos Não Funcionais

TIPOS DE REQUISITOS NÃO FUNCIONAIS (Sommerville) Requisitos de produtos

São os requisitos que especificam o comportamento do produto. Exemplo: requisitos de desempenho, que especificam com que rapidez

o sistema deve operar. Requisitos organizacionais

São procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor.

Entre os exemplos estão os padrões de processos que devem ser utilizados, os requisitos de implementação, como a linguagem de programação ou a metodologia de processo de desenvolvimento.

Requisitos externos Abrange todos os requisitos procedentes de fatores externos ao

sistema e ao seu processo de desenvolvimento. Exemplo: requisitos de interoperabilidade, requisitos legais, requisitos

éticos.

40

Requisitosnão-funcionais

Produto Organizacionais Externos

Eficiência ConfiabilidadePortabilidade

Desempenho Espaço

Facilidade de uso PadrõesImplementaçãoEntrega

Interoperabilidade

Legislativos

Privacidade Segurança

Éticos

41


Usabilidade (facilidade de uso) Definição: A facilidade de aprendizado e operação do software pelos

potenciais usuários. Métrica: Tempo de treinamento Habilidades do usuário / unidade de tempo Recursos de ajuda on-line Exemplo:

Um balconista treinado deve ser capaz de cadastrar um cliente em no máximo 5 minutos.

Novos usuários do internet banking devem ser capazes de encontrar o serviço de recarga de celulares no máximo em duas tentativas.

Eficiência (performance) Definição: medida de velocidade e eficiência do sistema em execução. Métrica: Throughput (quantidade de transações/unidade de tempo) Tempo de resposta ao usuário/evento

Capacidade (quantidade de usuários usando o sistema simultaneamente)

Exemplo:

O tempo de resposta do serviço “saldo da conta” deve ser no máximo 4 segundos.

42


43


Portabilidade Definição: A habilidade do software de se adaptar a diferentes

ambientes pré-definidos. Métrica: Número de sistemas-alvo

Porcentagem de declarações dependentes de sistemas-alvo

Exemplo: O sistema deverá ser capaz de operar em Windows e Linux.

Confiabilidade Definição: A habilidade do software de se comportar

consistentemente de forma aceitável pelo usuário. Métrica: Taxa de ocorrências de falhas Probabilidade de indisponibilidade (downtime) Disponibilidade Exemplo:

O sistema deverá estar disponível 24x7.44


Interoperabilidade Definição: capacidade de interação com outros produtos

especificados. Métrica: Produtos com os quais o sistema deve se comunicar Exemplo:

O sistema deverá permitir exportar os relatórios para Excel.

Segurança Definição: resistência ao acesso não-autorizado e à perda de

informações. Se preocupa pela privacidade dos dados. Métrica: Restrições de acesso

Definição de perfis de usuários Procedimentos de segurança dos dados

Exemplo: Duas cópias de segurança dos dados do sistema serão feitas

diariamente e pelo menos uma delas deve ser armazenada em local externo.

45


Requisitos de entrega Definição: indicam restrições de prazos e forma de entrega dos

produtos a serem elaborados. Métrica: Data de Entrega Formato de entrega de artefatos Exemplo:

O módulo referente a empréstimos deve ser entregue até dia 20 de janeiro de 2008.

Requisitos de implementação Definição: indicam restrições quanto ao uso de ferramentas ou

linguagens de programação. Métrica: Lista de ferramentas

Definição de padrões Exemplo:

O sistema será desenvolvido utilizando a linguagem de programação Java e o SGBD PostgreSQL.

46


Requisitos relativos a padrões Definição: indica a necessidade de obedecer métodos, normas e

padrões institucionais. Métrica: Lista de padrões Definição de métodos Exemplo:

O sistema será desenvolvido seguindo o modelo de processo de desenvolvimento RUP.

Requisitos éticos Definição: abordam a prevenção da divulgação não autorizada de

informações pessoais e o respeito aos indivíduos como cidadãos. Métrica: Regras éticas

Normas de comportamento do usuário Exemplo:

O sistema deverá possuir meios de impedir a cópia e divulgação de listas de clientes para pessoas não autorizadas.

47


Requisitos legais Definição: indica a necessidade de

conformidade com determinações legais e regulatórias.

Métrica: Leis vigentes Normas da empresa Exemplo:

O sistema deverá permitir o fornecimento dos dados pessoais sobre os clientes quando a gerencia solicitar os mesmos.

48


Importância dos Requisitos Não Funcionais Todos os Requisitos Funcionais devem ser

satisfeitos, mas se os Requisitos Não-Funcionais forem negligenciados, o sistema falhará.

Exercícios de RevisãoIdentificação de Tipos de Requisitos Verifique se as sentenças abaixo são requisitos verificáveis. Caso não sejam verificáveis, há uma forma melhor de defini-los? Caso sejam requisitos verificáveis, indicar o tipo de requisito.

a) Todo funcionário deve possuir um cartão de identificação da empresa.b) O downtime do sistema é 2 horas no período da madrugada de domingo.c) O sistema deve permitir aos professores realizar uma reserva de equipamentos por meio de uma aplicação web.d) As janelas do sistema devem ter uma interface que permita aos usuários utilizar o sistema de forma intuitiva.e) O sistema deverá estar preparado para usuários com deficiências físicas.f) O sistema deve permitir a criação de um menu de opções de equipamentos que possam ser reservados.g) O sistema deverá ser desenvolvido na linguagem de programação Java.h) O sistema deve exportar dados de uma forma clara e precisa.i) A reserva de um equipamento deve ser realizada no máximo 24 horas antes do evento marcado.j) O sistema deve ter a capacidade de suportar 2500 usuários simultaneamente.k) O sistema deverá ser finalizado antes do final do ano.

Dúvidas

51

Aula3 engenharia requisitos

Documents

Transcript of Aula3 engenharia requisitos