engenharia de software aula 06 - 06 - engenharia de...requisitos funcionais 10/05/2017 7 •os...

ENGENHARIA DE SOFTWARE Aula 06

Engenharia de Requisitos

OBJETIVOS DA AULA

10/05/2017 IFPR QUEDAS DO IGUAÇU - ENGENHARIA DE SOFTWARE - DANILO GIACOBO 2

Compreender os conceitos de requisitos de usuário e de sistema;

Compreender as diferenças entre requisitos de software funcionais e nãofuncionais;

Compreender como os requisitos podem ser organizados em um documentode requisitos de software;

Compreender as principais atividades de levantamento, análise e validaçãoda engenharia de requisitos e as relações entre essas atividades; e

Compreender por que o gerenciamento de requisitos é necessário e comoele dá suporte às outras atividades de engenharia de requisitos.

INTRODUÇÃO

10/05/2017 3

Os requisitos de um sistema são as descrições do que o sistemadeve fazer, os serviços que oferece e as restrições a seufuncionamento.

Requisitos de usuário são declarações, em uma linguagem naturalcom diagramas, de quais serviços o sistema deverá fornecer a seususuários e as restrições com as quais este deve operar.

Requisitos de sistema são descrições mais detalhadas das funções,serviços e restrições operacionais do sistema de software.

IFPR QUEDAS DO IGUAÇU - ENGENHARIA DE SOFTWARE - DANILO GIACOBO

ESTUDO DE CASO

10/05/2017 4

Software de Controle de Atendimento de Alunos (SCAA)

A assistente de alunos precisa de um software para lhe auxiliar no controlede atendimento dos professores aos alunos nas tardes do campus. Ela deve sercapaz de registrar qual aluno participou de qual atendimento e em qual dia ehorário. Ela também deve ser capaz de visualizar relatórios e gráficos cominformações sobre os atendimentos. Para facilitar o seu uso os dados dosprofessores e alunos já estarão disponíveis mas com a possibilidade de inclusão,alteração, exclusão e listagem de dados. Ela também deve ser capaz de podercadastrar os tipos de atendimentos aos quais os alunos participam, como, porexemplo, projetos, disciplinas, esportes, entre outros. Ela também deve ser capazde poder registrar problemas ocorridos ao longo do período de atendimento.


REQUISITOS DE USUÁRIO E DE SISTEMA

10/05/2017 5IFPR QUEDAS DO IGUAÇU - ENGENHARIA DE SOFTWARE - DANILO GIACOBO

Definição de requisitos de usuário

- O software deve gerar relatórios

mensais que mostrem a frequência de

cada aluno no atendimento.

Especificação de requisitos de sistema

- No último dia de cada mês deve ser gerado de forma automática

um resumo da frequência de cada aluno no atendimento.

- O horário de geração do relatório deve ser após as 18 horas do

último dia do mês.

- O relatório deve ser agrupado por disciplina que o aluno

frequenta.

- O acesso ao relatório deve ser restrito à assistente de alunos.

- A assistente de alunos poderá gerar de forma impressa o relatório

para que os professores possam acompanhar a frequência de seus

alunos no atendimento.

REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS

10/05/2017 6

Os requisitos de software são frequentemente classificados como requisitosfuncionais e requisitos não funcionais:

Requisitos funcionais: são declarações de serviços que o sistema deve fornecer, decomo o sistema deve reagir a entradas específicas e de como o sistema deve secomportar em determinadas situações. Em alguns casos, os requisitos funcionaistambém podem explicitar o que o sistema não deve fazer.

Requisitos não funcionais: são restrições aos serviços ou funções oferecidos pelosistema. Incluem restrições de timing, restrições no processo de desenvolvimento erestrições impostas pelas normas. Ao contrário das características individuais ouserviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se aosistema como um todo.


REQUISITOS FUNCIONAIS

10/05/2017 7

• Os requisitos funcionais de um sistema descrevem o que ele deve fazer.

• Eles dependem do tipo de software a ser desenvolvido, de quem são seuspossíveis usuários e da abordagem geral adotada pela organização aoescrever os requisitos.

• Exemplos:

1. A assistente de alunos deve ser capaz de registrar a presença de um determinadoaluno em um dia atendimento.

2. A assistente deverá ser capaz de cadastrar os dados de novos alunos no aplicativo.

3. O software deverá gerar relatórios mensais de frequência de atendimento.

4. A assistente de alunos deverá ser capaz de registrar qualquer ocorrência ao longodos atendimentos.


REQUISITOS NÃO FUNCIONAIS

10/05/2017 8

• Os requisitos não funcionais são requisitos que não estão diretamenterelacionados com os serviços específicos oferecidos pelo sistema aseus usuários.

• Exemplos:

1. O software deve ser capaz de realizar as operações de inclusão, exclusão ealteração de dados em menos de 2 segundos.

2. O software deverá gerar o relatório mensal de frequência de atendimento nomáximo em 1 minuto.

3. O software deverá gerar automaticamente e diariamente o backup dos dados.

4. A taxa de erros do software deve ser em torno de 1%.


O DOCUMENTO DE REQUISITOS DE SOFTWARE

10/05/2017 9

• O documento de requisitos de software é uma declaração oficial deo que os desenvolvedores do sistema devem implementar.

• Deve incluir tanto os requisitos de usuário para um sistema quantouma especificação detalhada dos requisitos de sistema.

• Documentos de requisitos são essenciais quando um contratanteexterno está desenvolvendo o sistema de software.

• O nível de detalhes que você deve incluir em um documento derequisitos depende do tipo de sistema em desenvolvimento e oprocesso usado.


ESPECIFICAÇÃO DE REQUISITOS

10/05/2017 10

• A especificação de requisitos é o processo de escrever os requisitosde usuário e de sistema em um documento de requisitos.

• Os requisitos devem ser claros, inequívocos, de fácil compreensão,completos e consistentes.

• Os requisitos de sistema devem descrever apenas o comportamentoexterno do sistema e suas restrições operacionais.

• Os requisitos de usuário são quase sempre escritos em linguagemnatural de suplementados no documento de requisitos por diagramasapropriados e tabelas.


ESPECIFICAÇÃO DE REQUISITOS

10/05/2017 11

Especificação em linguagem natural

Forma mais usada para escrever os requisitos do software.

É expressiva, intuitiva e universal mas é também vaga e ambígua e seusignificado depende do conhecimento do leitor.

Especificações estruturadas

Forma de escrever os requisitos do sistema de forma limitada e escritos em umaforma padrão.

Essa abordagem garante mantém grande parte da expressividade ecompreensão da linguagem natural, mas garante certa uniformidade impostasobre a especificação.


ESPECIFICAÇÃO EM LINGUAGEM NATURAL

10/05/2017 12

São recomendadas algumas diretrizes simples para minimizar os mal-entendidos:

1. Crie um formato-padrão e garanta que todas as definições de requisitos sejamescritos com este formato.

2. Use uma linguagem consistente para distinguir entre os requisitos obrigatórios eos desejáveis.

3. Use uma forma de destacar as partes fundamentais do requisito.

4. Não assuma que os leitores compreendam a linguagem técnica da Engenhariade Software.

5. Sempre que possível, tente associar uma lógica a cada um dos requisitos dousuário.


ESPECIFICAÇÃO EM LINGUAGEM NATURAL

10/05/2017 13

Exemplos - Software de Controle de Atendimento de Alunos (SCAA)

1. O sistema deve permitir o cadastro de alunos.

2. O sistema deve permitir o cadastro de professores.

3. O sistema deve permitir o lançamento de presenças de alunos em atendimentos.

4. O sistema deve emitir um relatório de alunos que vieram no atendimento em umdeterminado dia.

5. O sistema deve gerar um relatório de frequência individual de cada aluno noatendimento em um determinado período.

6. A assistente de alunos pode solicitar uma cópia impressa dos relatórios gerados pelosistema.


ESPECIFICAÇÕES ESTRUTURADAS

10/05/2017 14

A linguagem natural estruturada é uma forma de escrever os requisitos do sistemana qual a liberdade do escritor dos requisitos é limitada e todos os requisitos sãoescritos em uma forma-padrão.

Essa abordagem mantém grande parte da expressividade e compreensão dalinguagem natural, mas garante certa uniformidade imposta sobre aespecificação.

Usar as especificações estruturadas elimina alguns dos problemas deespecificação em linguagem natural. Reduz-se a variabilidade na especificação, eos requisitos são organizados de forma mais eficaz.

No entanto, algumas vezes ainda é difícil escrever os requisitos de forma clara einequívoca, especialmente quando processamentos complexos devem serespecificados.


10/05/2017 15

Exemplo - Requisito: O sistema deve permitir o cadastro de alunos

Função Cadastrar um aluno no sistema

Descrição Salvar os dados de um determinado aluno no sistema

Entradas Nome, Turma, Sexo, Foto do aluno

Saídas Código do aluno e mensagem de sucesso ou falha no cadastro do aluno.

Ação Realizar a validação dos dados do aluno e realizar o registro dos dadosdo mesmo no banco de dados do sistema

Requisitos Estar logado no sistema

Pré-condição O aluno não estar cadastrado

Pós-condição Dados do aluno salvos no banco de dados


ESPECIFICAÇÕES ESTRUTURADAS

PROCESSOS DE ENGENHARIADE REQUISITOS


ELICITAÇÃO E ANÁLISE DE REQUISITOS

10/05/2017 17

• Após o estudo de viabilidade, o próximo passo estágio do processo deengenharia de requisitos é a elicitação e análise de requisitos.

• Nessa atividade, os engenheiros de software trabalham com clientes e usuáriosfinais do sistema (stakeholders) para obter informações sobre o domínio daaplicação, os serviços que o sistema deve oferecer, o desempenho do sistema,restrições de hardware e assim por diante.

• As atividades do processo são

• Descoberta de requisitos

• Classificação e organização de requisitos

• Priorização e negociação de requisitos

• Especificação de requisitos

• Razões porque levantar e compreender requisitos é um processo difícil?


DESCOBERTA DE REQUISITOS

10/05/2017 18

• A descoberta de requisitos (às vezes, chamada elicitação de requisitos) é oprocesso de reunir informações sobre o sistema requerido e os sistemasexistentes e separar dessas informações os requisitos de usuário e de sistema.

• Fontes de informação durante a fase de descoberta de requisitos incluemdocumentação, stakeholders do sistema e especificações de sistemas similares.

• Você interage com os stakeholders por meio da observação e de entrevistas epode usar cenários e protótipos para ajudar os stakeholders a compreenderem oque o sistema vai ser.

• Os stakeholders variam desde os usuários finais, passando pelos gerentes dosistema até stakeholders externos, como reguladores, que certificam aaceitabilidade do sistema.

• Exemplos?


ENTREVISTAS

10/05/2017 19

• Entrevistas formais ou informais com os stakeholders do sistema são parte damaioria dos processos de engenharia de requisitos.

• Nessas entrevistas, a equipe de engenharia de requisitos questiona osstakeholders sobre o sistema que usam no momento e sobre o sistema que serádesenvolvido. Requisitos surgem a partir das respostas a essas perguntas.

• As entrevistas podem ser de dois tipos:

1. Entrevistas fechadas, em que o stakeholder responde a um conjunto predefinidode perguntas.

2. Entrevistas abertas, em que não existe uma agenda predefinida. A equipe deengenharia de requisitos explora uma série de questões com os stakeholders dosistema, e assim, desenvolve uma melhor compreensão de suas necessidades.


CENÁRIOS

10/05/2017 20

• As pessoas geralmente acham mais fácil se relacionar com exemplos da vidareal do que com descrições abstratas.

• Elas podem compreender e criticar um cenário de como elas podem interagircom um sistema de software.

• Engenheiros de requisitos podem usar a informação obtida a partir destedebate para formular os requisitos do sistema atual.

• Os cenários podem ser particularmente úteis para adicionar detalhes a umadescrição geral de requisitos.

• A elicitação baseada em cenários envolve o trabalho com os stakeholderspara identificar cenários e capturar detalhes que serão incluídos nessescenários.


CENÁRIOS - EXEMPLO

10/05/2017 21

Cenário para o requisito Logar no Sistema

Suposição Inicial:

A assistente de alunos acessa o software e a tela de login do mesmo é apresentada.

Normal:

A assistente de alunos informa seu login e senha e clica no botão de Entrar.

O que pode dar errado:

O login e/ou senha podem ser inválidos ou podem não ter sido informados.

Outras atividades:

Não se aplica.

Estado do sistema na conclusão:

A tela principal do software é exibida.


CASOS DE USO

10/05/2017 22

• Os casos de uso são uma técnica de descoberta de requisitos introduzidainicialmente no método Objectory.

• O diagrama de casos de uso faz parte da especificação da UML.

• Um caso de uso identifica os atores envolvidos em uma interação e dá o nomedo tipo de interação.

• Atores, que podem ser pessoas ou outros sistemas, são representados comofiguras ‘palito’.

• Cada classe de interação é representada por uma elipse. Linhas fazem aligação entre os atores e a interação. Opcionalmente, pontas de flechas podemser adicionadas às linhas para mostrar como a interação se inicia.


CASOS DE USO - EXEMPLO


Diagrama de Casos de Uso

(apenas com alguns requisitos)

Criado com a ferramenta ArgoUML

http://argouml.tigris.org/

http://argouml.tigris.org/

ETNOGRAFIA

10/05/2017 24

• Etnografia é uma técnica de observação que pode ser usada paracompreender os processos operacionais e ajudar a extrair os requisitos deapoio para esses processos.

• Um analista faz uma imersão no ambiente de trabalho em que o sistema seráusado.

• O trabalho do dia a dia é observado e são feitas anotações sobre astarefas reais em que os participantes estão envolvidos.

• O valor da etnografia é que ela ajuda a descobrir requisitos implícitos dosistema que refletem as formas reais com que as pessoas trabalham, em vezde refletir processos formais definidos pela organização.


VALIDAÇÃO DE REQUISITOS

10/05/2017 25

• A validação de requisitos é o processo pelo qual se verifica se os requisitosdefinem o sistema que o cliente realmente quer.

• Ela é importante porque erros em um documento de requisitos podem gerar altoscustos de retrabalho quando descobertos durante o desenvolvimento ou após osistema já estar em uso.

• O custo para consertar um problema de requisitos por meio de uma mudança nosistema é geralmente muito maior do que o custo de consertar erros de projeto oude codificação.

• Durante o processo de validação de requisitos, diferentes tipos de verificaçãodevem ser efetuados com os requisitos do documento de requisitos.

• Existem uma série de técnicas de validação de requisitos que podem ser usadasindividualmente ou em conjunto.


GERENCIAMENTO DE REQUISITOS

10/05/2017 26

• Os requisitos para sistemas de grande porte estão sempre mudando.

• Uma vez que o um sistema tenha sido instalado e seja usado regularmente,inevitavelmente surgirão novos requisitos.

• As mudanças em um software são inevitáveis pelas razões citadas a seguir:

1. Após a instalação, o ambiente técnico e de negócios do sistema sempre muda.

2. As pessoas que pagam por um sistema e os usuários deste raramente são osmesmos.

3. Geralmente, sistemas de grande porte têm uma comunidade de diversosusuários, com diferentes requisitos e prioridades, que podem ser conflitantesou contraditórios.

• O gerenciamento de requisitos é o processo de compreensão e controle dasmudanças nos requisitos do sistema.


PLANEJAMENTO DE GERENCIAMENTO DE REQUISITOS

10/05/2017 27

• O planejamento é o primeiro estágio essencial no processo de gerenciamento derequisitos, e determinada o nível de detalhamento requerido no gerenciamento derequisitos. Durante este estágio, você deve decidir sobre:

1. Identificação de requisitos

2. Processo de gerenciamento de mudanças

3. Políticas de rastreabilidade

4. Ferramenta de apoio

• Você precisa de ferramentas de apoio para

1. Armazenamento de requisitos

2. Gerenciamento de mudanças

3. Gerenciamento de rastreabilidade


GERENCIAMENTO DE MUDANÇA DE REQUISITOS

10/05/2017 28

• Após a aprovação do documento de requisitos, o gerenciamento de mudança derequisitos deve ser aplicado a todas às mudanças propostas aos requisitos de umsistema.

• Existem três estágios principais em um processo de gerenciamento de mudanças:

1. Análise de problema e especificação de mudanças

2. Análise de mudanças e custos

3. Implementação de mudanças

• Se um novo requisito precisa ser implementado com urgência, há sempre atentação de mudar o sistema e, em seguida, retrospectivamente modificar odocumento de requisitos.

• Processos ágeis de desenvolvimento foram concebidos para lidar com requisitosmutáveis durante o processo de desenvolvimento.


RESUMO

10/05/2017 29

Os requisitos para um sistema de software estabelecem o que o sistema devefazer e define as restrições sobre seu funcionamento e implementação.

Os requisitos funcionais são declarações dos serviços que o sistema deve fornecerou descrições de como alguns processamentos devem ser efetuados.

Muitas vezes, os requisitos não funcionais restringem o sistema que está sendodesenvolvido e o processo de desenvolvimento que está sendo usado. Estes podemser os requisitos de produto, requisitos organizacionais, ou requisitos externos. Elescostumam se relacionar com as propriedades emergentes do sistema e, portanto,aplicam-se ao sistema como um todo.

O documento de requisitos de software é uma declaração acordada dosrequisitos do sistema. Deve ser organizado para que ambos – os clientes dosistema e os desenvolvedores de software – possam usá-lo.


RESUMO

10/05/2017 30

O processo de engenharia de requisitos inclui estudo da viabilidade, elicitação eanálise de requisitos, especificação de requisitos, validação e gerenciamento derequisitos.

Elicitação e análise de requisitos é um processo iterativo que pode ser representadocomo uma espiral de atividades – descoberta de requisitos, classificação eorganização de requisitos, negociação de requisitos e documentação de requisitos.

A validação de requisitos é o processo de verificação da validade, consistência,completude, realismo e verificabilidade dos requisitos.

Mudanças organizacionais, mudanças nos negócios e mudanças técnicas,inevitavelmente geram mudanças nos requisitos para um sistema de software. Ogerenciamento de requisitos é o processo de gerenciamento e controle dessasmudanças.


ATIVIDADE

10/05/2017 31

Trabalho Individual

Usando seu conhecimento de como uma caixa eletrônico (ATM)funciona, desenvolva um conjunto de requisitos funcionais (5) e nãofuncionais (2) que poderia servir de base para o entendimento domesmo.

A atividade deve ser entregue na próxima aula.

Qualquer irregularidade na confecção ou do não seguimento dasinstruções na realização da mesma acarretará no desconto doconceito final.


REFERÊNCIAS


SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson PrenticeHall, 2011. 530 p. ISBN: 978-85-7936-108-1.

PILONE, D.; MILES, R. Use a Cabeça - Desenvolvimento de Software. 1. ed.Rio de Janeiro: Alta Books, 2008. 380 p. ISBN: 978-85-7608-212-5.

engenharia de software aula 06 - 06 - engenharia de...requisitos funcionais 10/05/2017 7 •os...

Documents