engenharia de software - cin.ufpe.breng_soft/eti901/notasdeaulas/a3_2-requisitos.pdf · engenharia...

1

CInCIn--UFPEUFPE 11©2001, ©2001, Jaelson Jaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos

Engenharia de SoftwareEngenharia de Software

Requisitos de Software


Requisitos de softwareRequisitos de software

n Descrição e especificação de um sistema

2


Tópicos CobertosTópicos Cobertos

n Introdução aos conceitos de requisitos do usuário e do sisteman Descrição de requisitos funcional e não-funcionaln Explicação de técnicas para descrição dos requisitos do

sisteman Explicação de como os requisitos de software podem ser

organizados num documento de requisitosn Descrição do processo de elicitação e análise requisitosn Introdução a técnicas de elicitação e análise de requisitos


Requisitos funcionaisRequisitos funcionais

n Descreve a funcionalidade ou serviços do sisteman Depende do tipo de software, usuários esperados e do

tipo de sistema onde o software é usadon Requisitos funcionais do usuário podem ser sentenças

de alto nível sobre o que o sistema deve fazer, mas requisitos funcionais do sistema devem descrever os serviços do sistema em detalhes

3


Exemplos de requisitos funcionaisExemplos de requisitos funcionais

n O usuário deve ser capaz de pesquisar tanto todo o conjunto inicial do banco de dados ou selecionar um subconjunto dele.

n O sistema deve fornecer visualizadores (viewers) apropriados para ler documentos.

n Para cada pedido deve ser alocado um identificador único (ORDER_ID).


Imprecisão dos requisitosImprecisão dos requisitos

n Problemas surgem quando os requisitos não são declarados precisamente

n Requisitos ambíguos podem ser interpretados de forma diferente por desenvolvedores e usuários

n Considere o termo ‘visualizadores apropriados’u Intenção do usuário - visualizadores de propósito especial para

cada tipo de documento diferenteu Interpretação do desenvolvedor - um visualizador textual que

mostra o conteúdo do documento

4


Requisitos nãoRequisitos não--funcionaisfuncionais

n Requisitos de produtou Requisitos que especificam que o produto entregue tem que se

comportar de um modo particular. Por exemplo, velocidade de execução, confiabilidade, etc.

n Requisitos organizacionaisu Requisitos que são uma conseqüência de políticas e

procedimentos organizacionais. Por exemplo, padrões de processos usados, requisitos de implementação, etc.

n Requisitos externosu Requisitos que surgem de fatores que são externos ao sistema e

ao seu processo de desenvolvimento. Por exemplo, exigências de interoperabilidade, requisitos legislativos, etc.


Tipos de requisitos não funcionaisTipos de requisitos não funcionais

Performancerequ irement s

Spacerequ irement s

Usabil ityrequ irement s

Ef fic iencyrequir ements

Reliabilit yrequir ements

Portabilit yrequirements

Interoperabil ityrequirement s

Ethicalrequirements

Legis lativerequirements

Impl ementat ionrequirements

S tand ardsrequirements

Deliveryrequirements

Safetyrequirements

Priv acyrequirements

Pro ductrequir ements

Org anizatio nalrequirements

Externalrequirements

Non-functio nalrequirements

5


Interação entre requisitosInteração entre requisitos

n Conflitos entre requisitos não funcionais diferentes são comuns em sistemas complexos

n Exemplo: em um sistema de uma nave espacialu Para minimizar o peso, a quantidade de chips no sistema deve ser

minimizadau Para minimizar o consumo de energia, chips de baixo consumo

devem ser utilizadosu Contudo, o uso de chips de baixo consumo significa que mais

chips vão ter que ser usados. Qual é o requisito mais crítico


Problemas com especificação em LNProblemas com especificação em LN

n Falta de clarezau Precisão é difícil sem tornar o documento difícil para leitura

n Confusão de requisitosu Requisitos funcionais e não funcionais tendem a ser misturados

n Fusão de requisitosu Vários requisitos diferentes podem ser expressos juntos

6


Problemas com especificação em LNProblemas com especificação em LN

n Ambigüidadeu Os leitores e escritores do requisito devem interpretar as mesmas

palavras da mesma maneira. LN é naturalmente ambígua o que torna o seu uso muito difícil.

n Flexibilidadeu A mesma coisa pode ser dita de várias formas diferentes na

especificação

n Falta de modularizaçãou Estruturas de LN são inadequadas para estruturar requisitos do s istema

n Conclusão: Necessidade de uma notação mais apropriada


O documento de requisitosO documento de requisitos

n O documento de requisitos é a documentação oficial do que é requerido dos desenvolvedores do sistema

n Deve incluir tanto a definição como a especificação dos requisitos

n Ele NÃO é um documento de projeto. Na medida do possível, ele deve definir O QUE o sistema deve fazer em vez do COMO ele deve fazer

7


Usuários de um documento de requisitosUsuários de um documento de requisitos

Us e t he req ui rement s todevelop val id ati on tes ts fo rt he s ys tem

Use t he requirement sdocument to plan a bid forthe system and to pl an th esyst em develo pment proces s

Use t he requirement s tounderstand wh at sys tem i s tobe developed

Sy st em tes teng in eers

Managers

Sy st em eng in eers

Speci fy the req uiremen ts andread them to check t hat t heymeet the ir needs . Theyspec ify ch anges t o th erequ irements

S ystem cus tomers

Us e the req ui rements to hel punders tand the sy st em andt he rel ati on ship s be tw een it spart s

Sy st emmain tenance

eng in eers


Elicitação Elicitação de Requisitosde Requisitos

n ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão

n Cabe à elicitação a tarefa de identificar os fatos relacionados aos requisitos do Sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado daquele software

8


Elicitação Elicitação de Requisitos: Dificuldadesde Requisitos: Dificuldades

n Usuários podem não ter uma idéia precisa do sistema por eles requerido;

n Usuários têm dificuldades para descrever seu conhecimento sobre o domínio do problema;

n Usuários e Analistas têm diferentes pontos de vista do problema (por terem diferentes formações);

n Usuários podem antipatizar-se com o novo sistema e se negarem a participar da elicitação (ou mesmo fornecer informações errôneas).


Componentes da Componentes da elicitação elicitação de requisitosde requisitos

Applicationdomain

Stakeholderneeds andconstrain ts

Problem to besolved

Busines scontex t

9


Atividades da Atividades da ElicitaçãoElicitação

n Entendimento do domínio da aplicaçãou O conhecimento do domínio da aplicação é o conhecimento geral onde

o sistema será aplicado.

n Entendimento do problemau Os detalhes problema do cliente onde o sistema será aplicado devem

ser entendidos. n Entendimento do negócio

u Deve-se entender como os sistemas interagem e contribuem de forma geral com os objetivos de negócio.

n Entendimento das necessidades e limitações dos stakeholders do sistemau Deve-se entender, em detalhe, as necessidades específicas das

pessoas que requerem suporte do sistema no seu trabalho.


ElicitaçãoElicitação, análise e negociação, análise e negociação

Requirements elicitation Requirements

analysis

Requirements negotiation

Draft statement of requirements

Requirements document

Requirements problems

10


O processo da O processo da elicitação elicitação de requisitosde requisitos

Businessgoals

Systemconstraints

Problem to besolved

Establish objectives Understand background

Organisationalstructure

Applicationdomain

Existingsystems

Stakeholderidentification

Goalprioritisation

Domainknowledge

filtering

Organise knowledge

Stakeholderrequirements

Collect requirements

Domainrequirements

Organisationalrequirements


Estágios da Estágios da ElicitaçãoElicitação

n Definição dos objetivosu Os objetivos organizacionais devem ser estabelecidos incluindo

objetivos gerais do negócio, um descrição geral do problema a ser resolvido, porque o sistema é necessário, e as limitações do sis tema.

n Aquisição de conhecimento do backgroundu Informação de background do sistema: inclui informação acerca da

organização onde o sistema será instalado, o domínio de aplicação do sistema, e informação acerca de outros sistemas existentes

n Organização do conhecimentou A grande quantidade de conhecimento que foi coletada nos estágios

anteriores deve ser organizada e colocada em ordem.

n Coleta dos requisitos dos stakeholdersu Os stakeholders do sistema são consultados para descoberta de seus

requisitos.

11


Análise e negociação de requisitosAnálise e negociação de requisitos

Necessitychecking

Consis tency andcompleteness

checking

Feasibilitychecking

Unnecessaryrequirements

Confli cting andincomplete

requirementsInfeasible

requirements

Requirementsdiscussion

Requirementsprioritisation

Requirementsagreement

Requ irements analysis

Requ irements negotiation


Análise dos requisitosAnálise dos requisitos

n Verificação da necessidade u A necessidade os requisitos é analisada. Em alguns casos, alguns

requisitos propostos podem não contribuir para os objetivos de negócio da organização ou para o problema específico tratado pelo sistem a.

n Verificação de consistência e completudeu Os requisitos são verificados entre si para determinar consistência e

completude. Consistência significa que nenhum requisito deve ser contraditório; completude significa que nenhum serviço (ou limitação) que seja necessário foi esquecido.

n Verificação de viabilidade u Os requisitos são verificados para garantir que são viáveis dentro do

orçamento e tempo disponível para o desenvolvimento do sistema.

12


Negociação dos requisitosNegociação dos requisitos

n Discução dos requisitosu Os requisitos que foram identificados como problemáticos são

discutidos e os stakeholders envolvidos apresentam seus pontos de vista acerca dos requisitos.

n Priorização dos requisitosu Os requisitos disputados são priorizados para identificar requisitos

críticos e ajudar o processo de tomada de decisão.

n Concordância dos requisitosu Soluções para os problemas dos requisitos são identificadas e um

conjunto de requisitos são acordados. Geralmente isto envolve mudanças em alguns dos requisitos.


Técnicas de Técnicas de ElicitaçãoElicitação

n Técnicas especiais que podem ser usadas para coletar conhecimento sobre os requisitos dos usuários

n Este conhecimento deve ser estruturadou Particionamento - agregando conhecimentos relacionadosu Abstração - reconhecendo generalidadesu Projeção - organizando de acordo com uma perspectiva

n Problemas da elicitação u Não existir muito tempo para a elicitaçãou Preparação inadequada dos engenheirosu Stakeholders não estarem convencidos da necessidade de um

novo sistema

13


Algumas técnicas deAlgumas técnicas de elicitaçãoelicitação

n Entrevistasn Leitura de documentosn Questionáriosn Cenários n Observações e análise sociais (etnografia) n Reuso de requisitosn Prototipagem


n O profissional de ER deve selecionar as técnicas a serem utilizadas e estabelecer de que maneira elas serão integradas

n É importante utilizar uma técnica de modelagem de apoio para que os fatos elicitados fiquem corretamente representados para futuro tratamento

n A escolha das técnicas e seu esquema de integração dependerá do problema e da equipe participante

n O ponto importante é ter conhecimento sobre estas técnicas e identificar onde uma técnica é superior a outra

ElicitaçãoElicitação de Requisitosde Requisitos

14


Técnicas de Técnicas de ElicitaçãoElicitação

n Sempre perguntar: o que? Por que(m)? Como? n Pergunte o óbvion Organize as respostas: durante versus depoisn Observen Estudar o que? Por que? Onde começarn Seja humilde, procure aprender!


CenáriosCenários

n Cenários são estórias que explicam como um sistema poderá ser usado. Eles devem incluir:u uma descrição do estado do sistema antes de começar o cenáriou o fluxo normal de eventos do cenáriou exceções ao fluxo normal de eventosu informações sobre atividades concorrentesu uma descrição do estado do sistema ao final do cenário

n Cenários são exemplos de sessões de interação que descrevem como o usuário interage com o sistema

n A descoberta de cenários expõe interações possíveis do sistema erevela as facilidades que o sistema pode precisar

15


Cenários e Projeto OOCenários e Projeto OO

n Cenários são partes inerentes de alguns métodos de desenvolvimento orientados a objeto

n O termo “caso de uso” ou use-case (um caso específico do uso do sistema) é usado às vezes para se referir a um cenário


Cenário de um sistema de livraria virtual Cenário de um sistema de livraria virtual

n Entre no sisteman Escolha o comando “pedido de documentos”n Entre um número de referência do documento pedidon Selecione um ponto de entregan Saia do sistema

16


Observação e Análise SocialObservação e Análise Social

n As pessoas geralmente acham difícil descrever o que elas fazem. Às vezes, a melhor forma de entender será observá-las no trabalho.

n Etnografia é uma técnica das ciências sociais que se mostrou útil no entendimento dos processos reais realizados nos trabalhos

n Os processos reais de trabalho geralmente diferem daqueles processos formais descritos

n Um etnógrafo passa algum tempo observando as pessoas no trabalho e constrói uma imagem de como o trabalho é realizado


Diretrizes para EtnografiaDiretrizes para Etnografia

n Procure formas não padronizadas de trabalhon Gaste algum tempo conhecendo as pessoas e estabeleça

um relacionamento de confiançan Tome nota de forma detalhada de todas as práticas de

trabalho. Analise-as e chegue a uma conclusão a partir delas

n Combine observação com entrevistas abertasn Organize regularmente seções de relato, onde o

etnógrafo fala para pessoas externas ao processon Combine etnografia com outras técnicas de elicitação

17


Reuso de requisitosReuso de requisitos

n Reuso envolve considerar requisitos que foram desenvolvidos para um sistema e usá-los em sistemas diferentes

n O reuso de requisitos economiza tempo e esforço, pois requisitos reutilizados já foram analisados e validados em outros sistemas

n Atualmente o reuso de requisitos é um processo informal. Contudo, um reuso mais sistemático economizaria muito esforço


Possibilidades de reusoPossibilidades de reuso

n Na existência de um domínio (encapsulamento do conhecimento da área de aplicação) do qual o requisito está relacionadou Na mesma área de aplicação, apenas 15% dos requisitos de

um novo sistema são exclusivos dele. O restante são os mesmos de outros sistemas similares

n Na apresentação da informação. O reuso levaria a consistência dos estilos entre aplicações.

n Onde o requisito refletir políticas da companhia, tais como segurança.

18


Prototipagem Prototipagem

n Um protótipo é uma versão inicial de um sistema que poderá ser usado para experimentação.

n Protótipos são úteis para elicitação de requisitos porque os usuários poderão experimentar o “sistema” e mostrar os pontes fortes e fracos. Eles terão algo concreto para criticar.

n O desenvolvimento rápido dos protótipos é essencial para que eles fiquem disponíveis logo para o processo de elicitação .


Benefícios da prototipagemBenefícios da prototipagem

n O protótipo permite que os usuários experimentem e descubram o que eles realmente necessitam para suportar o trabalho deles

n Estabelece a viabilidade e utilidade antes que altos custos de desenvolvimento tenham sido realizados

n Essencial para desenvolvimento do aspecto ‘look and feel’ da interface do usuário

n Pode ser usado para teste do sistema e desenvolvimento da documentação

n Força um estudo detalhado dos requisitos, revelando inconsistências e omissões

19


Análise de requisitosAnálise de requisitos

n O objetivo da análise é descobrir problemas, incompletude e inconsistência nos requisitos elicitados. Eles normalmente são retornados aos stakeholders para resolvê-los, através de um processo de negociação

n A análise é intercalada com elicitação, pois problemas são descobertos quando os requisitos são elicitados

n Uma lista de verificação de problemas poderá ser usada para ajudar a análise. Cada requisito poderá ser avaliado contra esta lista


Lista de verificação da análiseLista de verificação da análise

n Projeto prematurou Os requisitos incluem informação prematura de projeto ou

implementação?

n Requisitos combinados u A descrição do requisito descreve um requisito único ou este pode ser

descrito em vários requisitos diferentes?

n Requisitos desnecessáriosu O requisito é realmente necessário, ou será que é uma mera adição

cosmética ao sistema?

n Uso de hardware não padronizadou Os requisitos implicam no uso de uma plataforma de hardware não

padronizada? Para tomar esta decisão, você precisa conhecer os requisitos de plataforma do computador.

20


Lista de verificação da análiseLista de verificação da análise

n Está de acordo com os objetivos de negóciou O requisito é consistente com os objetivos de negócio definidos na

introdução do documento de requisitos?

n Ambigüidade de requisitosu O requisito é ambíguo, isto poderá ser lido de forma diferente por pessoas

diferentes? Quais são as possibilidades de interpretação dos requisitos?

n Realismo dos requisitosu O requisito é realístico em relação a tecnologia usada para a

implementação do sistema?

n Teste dos requisitosu Podemos testar os requisitos, ou seja, eles foram escritos de tal forma que

um engenheiro de teste poderá derivar o teste que mostrará se o sistema satisfaz os requisitos?


Interação entre requisitos Interação entre requisitos

n Um objetivo importante da análise de requisitos é descobrir as interações entre requisitos e informar os conflitos e sobreposições de requisitos

n Uma matriz de interação de requisitos mostrará como um requisito interage com outros. Os requisitos são mostrados nas linhas e colunas da matrizu Para cada requisito que conflita, preencha 1

u Para cada requisito que sobrepõe-se, preencha 1000u Para cada requisito que é independente, preencha um 0

21


Matrizes de InteraçãoMatrizes de Interação

Requirement R1 R2 R 3 R4 R5 R6R1 0 0 1000 0 1 1R2 0 0 0 0 0 0R3 1000 0 0 1000 0 1000R4 0 0 1000 0 1 1R5 1 0 0 1 0 0R6 1 0 1000 1 0 0


Negociação de requisitosNegociação de requisitos

n Problemas nos requisitos são inevitáveis quando um sistema possui muitos stakeholders. Conflitos não são falhas, mas refletem necessidades e prioridades diferentes entre as partes interessadas

n A negociação de requisitos é o processo de discussão dos conflitos de requisitos e a busca de um compromisso no qual todas as partes interessadas concordem

n No planejamento do processo de engenharia de requisitos, é importante deixar bastante tempo para negociação. Alcançar um compromisso aceitável pode tomar um tempo considerável

22


Encontros de negociaçãoEncontros de negociação

n Um estágio de informação onde a natureza dos problemas associados com os requisitos são explicados.

n Um estágio de discussão onde as partes interessadas discutem como o problema poderá ser resolvido.u Todas as partes interessadas no requisito devem ter a

oportunidade de comentar. Neste estágio são atribuídas prioridades aos requisitos.

n Estágio de resolução onde as ações que dizem respeito ao requisito são concordadas.u Estas ações podem ser: deletar o requisito, sugerir modificações

ao requisito ou elicitar mais informações sobre o requisito.


Pontos principaisPontos principais

n Requisitos definem o que sistema deve fazer e as restrições sobre suas operações e implementação

n Requisitos funcionais definem os serviços que os sistema deve fornecer

n Requisitos não funcionais restringem o sistema que está sendo desenvolvido ou o processo de desenvolvimento

n O documento de requisitos é a especificação para os clientes, engenheiros e gerentes

23



n A elicitação de requisitos envolve a compreensão do domínio da aplicação, o problema específico a ser resolvido, as necessidades e limitações organizacionais e as facilidades especificas necessárias para as partes interessadas.

n Os processos de elicitação de requisitos, análise e negociação são interativos e intercalados, precisando ser repetidos várias vezes.

n Existem várias técnicas de elicitação de requisitos que podem ser usadas, incluindo entrevistas, cenários, prototipagem e observação dos participantes.



n Listas de verificação são formas particularmente úteis para organizar o processo de validação dos requisitos. Elas lembram ao analista o que deve ser verificado quando da leitura dos requisitos propostos.

n Negociação dos requisitos é sempre necessária para resolver conflitos e remover a sobreposição de requisitos. Negociação envolve a troca de informação, discussão e resolução de conflitos.

engenharia de software - cin.ufpe.breng_soft/eti901/notasdeaulas/a3_2-requisitos.pdf · engenharia...

Documents