Levantamento de Requisitos
Fevereiro de 2017
LR
Resumo A Engenharia de Software é o ramo da informática que aborda a construção de sistemas de software, cuja complexidade obriga a que sejam construídos por equipas de engenheiros. Pequenos programas de Software (escritos por um individuo), não são considerados suficientemente complexos para requererem o uso de abordagens de engenharia. Um engenheiro de Software dedica menos de 10% do seu tempo a programar. Engenharia de software é a aplicação duma abordagem sistemática, disciplinada e quantificável no contexto do planeamento, do desenvolvimento e da exploração do sistema de software. O SWEBOK é o referencial para a caracterização da disciplina de Engenharia de Software. Onde se encontra estruturado por 15 áreas. 1.
Requisitos de Software;
2.
Conceção de Software
3.
Construção de Software;
4.
Teste de Software;
5.
Manutenção de Software;
6.
Gestão de Configuração de Software;
7.
Gestão de Engenharia de Software;
8.
Processo de engenharia de Software;
9.
Modelos e métodos de Engenharia de Software;
10. Qualidade de Software; 11. Prática profissional em engenharia de Software; 12. Economia da engenharia de software; 13. Fundamentos da informática; 14. Fundamentos da matemática; 15. Fundamentos da Engenharia. Neste manual teremos toda a informação necessária, de base, para realizar o tópico número um, relativamente aos requisitos de software.
Palavras-Chave: SWEBOK, Requisitos de Software, Engenharia de Software
i
Índice 1. Requisitos de Software
1
1.1. Tipos de Requisitos
1
1.2. Independência dos Requisitos Não Funcionais
2
1.3. Independência dos Requisitos Funcionais
3
2. Engenharia de Requisitos
5
2.1. Objetivos da engenharia de requisitos
5
3. Levantamento de Requisitos
6
3.1. Técnicas de Levantamento de Requisitos
6
3.1.1 Entrevistas
7
3.1.2 Inquérito
8
3.1.3 Introspeção
9
3.1.4 Etnografia
10
3.1.5 Dinâmica de grupo
10
3.1.6 Brainstorming
10
3.1.7 Análise de Domínio
11
4. Escrita de Requisitos
12
5. Conclusão
14
Anexos I.
Exemplo de Entrevista
17
II.
Exemplo de Inquérito
18
ii
Índice de Figuras Figura 1:Exemplo de diferentes requisitos para a mesma arquitetura
2
Figura 2:Imagem que suporta os Requisitos Não Funcionais de um carro 3 Figura 3: Fluxo de trabalho em torno de uma entrevista
7
Figura 4: Fluxo de trabalho na elaboração de um Inquérito
9
Figura 5: Figura ilustrativa de uma análise de domínio.
11
iii
Índice de Tabelas Tabela 1 - Ilustração de inserção de uma tabela e sua legenda. Marcador não definido.
iv
Erro!
Curso: Levantamento de Requisitos
1. Requisitos de Software Trata o levantamento, a análise, a documentação, a validação, e a manutenção de requisitos de software. Requisitos são as propriedades que os sistemas (ainda em projeto) devem manifestar. Os requisitos de Software exprimem as necessidades e as restrições que são colocadas a um sistema de software. Um requisito é qualquer coisa que alguém pretende. Os requisitos exprimem as necessidades dos utilizadores e as restrições que são colocadas a um sistema. Segundo a norma IEEE 610.12-1990, um requisito é: 1. Uma condição ou uma capacidade de que alguém necessita para resolver um problema ou atinguir um objetivo; 2. Uma condição ou uma capacidade que deve ser verificada ou possuída por um sistema para satisfazer um contrato, uma norma ou uma especificação; 3. Uma representação documentada duma condição ou duma capacidade, no âmbito de (1) ou (2).
1.1. Tipos de Requisitos Um requisito é uma capacidade que um sistema deve possuir, de modo a satisfazer as necessidades dos utilizadores. Podem dividir-se os requisitos entre: 1. Funcionais; 2. Não funcionais. Classificar um requisito como funcional ou não funcional depende da perspetiva do observador. Um requisito que paga alguém é fundamental, pode para uma outra pessoa ser não funcional para um arquiteto urbano.
Um requisito funcional descreve uma funcionalidade a disponibilizar os utilizadores dum sistema.
1
Curso: Levantamento de Requisitos
Devem eliminar-se deste tipo de requisitos quaisquer questões tecnológicas. Idealmente, os requisitos têm de ser independentes de questões de conceção e de implementação. Assim aumenta-se as alternativas tecnológicas que podem ser exploradas durante o projeto. Os requisitos não funcionais correspondem a um conjunto de restrições impostas ao sistema a desenvolver. Estabelece quão atrativo, usável, rápido ou fiável é o sistema. Inclui restrições temporais, restrições no processo de desenvolvimento, a adoção de normas. Exemplo de uma restrição tecnológica: O produto deve ser desenvolvido em c++.
Figura 1:Exemplo de diferentes requisitos para a mesma arquitetura 1
1.2. Independência dos Requisitos Não Funcionais Um requisito não funcional não altera a essência das funcionalidades do sistema considerado. Em desporto a cor de uma bola não afeta a sua funcionalidade. Independentemente dos requisitos não funcionais dum sistema, os requisitos funcionais mantêm-se inalterados. Se o sistema atual é lento, isso pode levar à necessidade de se criar um sistema mais rápido e que faça exatamente o mesmo. Os requisitos não funcionais são, frequentemente, propriedades emergentes do sistema. 2
1
Fonte: https://pixabay.com/pt/bola-futebol-desporto-azul-couro-430974
2
Curso: Levantamento de Requisitos
Figura 2:Imagem que suporta os Requisitos Não Funcionais de um carro Segundo a imagem anterior, teríamos os seguintes requisitos não funcionais:
O carro deverá possuir o modelo X;
O carro deverá consumir 2litros em 100km.
1.3. Independência dos Requisitos Funcionais Se um sistema for concebido apenas com base em requisitos funcionais, a solução poderá ser uma entidade monolítica. Os requisitos não funcionais são cruciais para decidir a arquitetura do sistema. A satisfação dum requisito não funcional não pode fazer-se de forma isolada. Um sistema optimizador para o desempenho pode ver reduzidas as características da manutibilidade.
2
Emergente – uma propriedade emergente dum sistema é aquela que não pode ser determinada apenas pelas
propriedades associadas aos seus componentes, mas que adicionalmente é determinada pela estrutura do sistema.
3
Curso: Levantamento de Requisitos
Figura 3 :Imagem que suporta os Requisitos Funcionais de um carro3
Na figura anterior, temos um exemplo de um carro. O levantamento de requisitos para este modelo, implicaria a recolha das informações seguintes:
3
O Carro deverá possuir 4 rodas;
O carro deverá possuir todos os vidros fumados.
Fonte: https://pixabay.com/pt/carro-roadster-carro-esporte-161770/
4
Curso: Levantamento de Requisitos
2. Engenharia de Requisitos O termo engenharia de requisitos é relativamente recente. Designa todas as atividades relacionadas com a descoberta, a negociação, a documentação e a manutenção de requisitos em projeto de engenharia. A engenharia de requisitos é inerentemente ampla, interdisciplinar e está constantemente em aberto. Está relacionada com a transformação de descrições informais do mundo real para especificações em linguagem rigorosa e de base matemática.
2.1. Objetivos da engenharia de requisitos A engenharia de requisitos tem por finalidade ajudar a entender melhor o problema que vai ser abordado. O objetivo da engenharia de requisitos é aumentar as probabilidades do sistema em desenvolvimento vir a satisfazer os utilizadores futuros. A engenharia de requisitos procura garantir 3 objetivos: 1. Todos os requisitos relevantes são conhecidos e compreendidos com o necessário nível de detalhe; 2. Foi alcançado, entre as partes interessadas, um acordo alargado em relação aos requisitos; 3. Todos os requisitos estão documentados, em conformidade com os formatos estabelecidos.
.
5
Curso: Levantamento de Requisitos
3. Levantamento de Requisitos Esta atividade trata a forma como devem ser capturados os requisitos. As técnicas de levantamento de requisitos devem: 1. Identificar as diversas fontes de requisitos; 2. Ajudar as várias partes interessadas a descrever corretamente os requisitos. Esta atividade é inerentemente comunicacional, dado que exige uma intenção com as partes interessadas. O Engenheiro de Requisitos deve possuir algumas competências no que diz respeito a utilização das técnicas de levantamento de requisitos, que serão abordadas seguidamente neste manual: 1. Questionar: colocar perguntas sobre os requisitos às pessoas certas; 2. Observar: presenciar o comportamento dos utilizadores dum sistema, para inferir as necessidades espectáveis; 3. Discutir: debater com os utilizadores as suas necessidades, para formular um entendimento dos requisitos; 4. Negociar: facilitar a negociação entre os utilizadores, para chegar a soluções de consenso sobre os requisitos a incluir; 5. Supor: antecipar funcionalidades que os utilizadores possam necessitar, em especial para produtos para o mercado de massas.
3.1. Técnicas de Levantamento de Requisitos Existem algumas técnicas de levantamento de requisitos: Entrevistas, inquéritos, introspeção, análise de domínio, orientação a objetos, prototipagem, cenários e personas.
6
Curso: Levantamento de Requisitos
3.1.1 Entrevistas As entrevistas não têm regras nem formulas exatas. O entrevistador tem grande liberdade na condução da entrevista. Em muitos casos, é baixa a relevância dos resultados obtidos; É relevante definir como realizar entrevistas estruturadas, já que conversas completamente abertas não funcionam bem. Existe, no entanto, um fluxo que o entrevistador deve executar:
Figura 3: Fluxo de trabalho em torno de uma entrevista
Identificar entrevistados: No mínimo devem ser entrevistados o cliente e alguns utilizadores. Caso seja impossível entrevistar todos os utilizadores, devemos selecionar uma amostra representativa. A identificação dos entrevistados não precisa de ficar fechada antes de se iniciarem as entrevistas. É aceitável que se descubram outras pessoas que se justifique serem entrevistados, durante a entrevista. Para obtermos estas informações, podemos fazer uso de frases como: “Quem devo entrevistar mais?” “Quem mais deverá usar o sistema?”
Preparar entrevista: As entrevistas devem ser preparadas, o que envolve agendá-las e preparar questões relevantes. O entrevistador deve munir-se de questões-ancora para dinamizar as entrevistas. As respostas do entrevistado podem abrir novas perguntas que o entrevistador deve colocar durante a entrevista: Comparação: melhor, pior, mais rápido, menos útil Juízo de valor: Quem diz que é melhor, Porque (não) tem de o fazer? Generalização: “O que o leva a (impede de) fazer?”, “Porque (não) tem de o fazer? Quantificadores universais: “É mesmo nunca?”, “É mesmo para todos? Não existe nenhum tipo de excepção?”
7
Curso: Levantamento de Requisitos
Conduzir entrevista:
A condução duma entrevista deve seguir algumas recomendações:
Contexto;
Objetivos;
Duração;
Tratamento a dar à informação recolhida;
Tópicos a abordar.
Quando disponíveis os diagramas de casos de uso podem ser usados como elementos de referência para a entrevista. Deve recorrer-se a terminologia do problema que é familiar ao entrevistado, e evitar-se o uso de jargão no domínio da solução. Isso mantém o dialogo no contexto do domínio. O entrevistador deve usar menos tempo para colocar as questões que o entrevistado para responder. 20% e 80% são adequados! Pode ser relevante a presença duma terceira pessoa para tomar notas durante a entrevista. Pode recorrer-se a gravações áudio ou vídeo, se o entrevistado der consentimento explicito para efetuar esse registo.
Finalizar a entrevista: A entrevista pode ser finalizada quando todas as questões tiverem sido respondidas ou quando o tempo estiver esgotado. Antes de finalizar a entrevista deve:
Informar sobre aquilo que aprendeu;
Indicar quão valioso isso é para a equipa de desenvolvimento;
Agradecer ao entrevistado o tempo e esforço despendido.
Em anexo poderão visualizar uma proposta de uma entrevista, para um projeto de desenvolvimento de Software. Onde se procura recolher informações sobre a recolha de lixo urbano, de forma a mecanizar informaticamente todo o processo, tornando-o inteligente e interativo.
3.1.2 Inquérito É comum usar-se inquéritos para recolha de requisitos, especialmente nas etapas do processo. Um inquérito recorre ao uso de questionários para recolher e tratar a informação de múltiplos respondentes.
8
Curso: Levantamento de Requisitos
Figura 4: Fluxo de trabalho na elaboração de um Inquérito
Identificar audiência e objetivos: O questionário (conjunto de questões) serve para coligir informação. Ao usar-se o mesmo questionário para todas as pessoas, é possível tratar estaticamente as respostas recolhidas. O sucesso dos inquéritos depende bastante da forma como o questionário é concebido. Conceber questionários: Se as perguntas não forem focadas, estiverem mal formuladas, ou aparecerem na ordem errada, as respostas obtidas podem ser irrelevantes e enganadoras. Os questionários devem ser bem redigidos, sem erros gramaticais e com pontuação correta. É desejável que os questionários sejam focados, de forma a evitar a recolha de informação em quantidade irrelevante. Deve ser realizada uma única pergunta de cada vez, evitando várias perguntas em simultâneo. Os questionários não permitem, que se justifiquem as respostas, nem que se explorem novas ideias. Exemplo: Gosta de bolas azuis? E gosta de pinheiros brancos, ou do Natal?
Deve evitar-se o uso de perguntas na negativa, pois fica-se sempre com dúvidas na resposta. Exemplo: Não gostas de chocolate?
O problema para as perguntas não respondidas pode ser atacado através do uso de ferramentas informáticas. Esta solução pode não ser a mais desejável, dado que obriga o respondente a ter acesso a um computador. O inquérito deve ser usado como uma técnica preliminar que ajuda na preparação das entrevistas. Em anexo, podem visualizar um exemplo de um inquérito realizado no mesmo âmbito de um projeto de desenvolvimento de Software.
3.1.3 Introspeção A introspeção é a mais básica, óbvia e rudimentar de todas as técnicas de levantamento de requisitos. O analista define os requisitos dum sistema com base naquilo que julga serem as necessidades das partes interessadas.
9
Curso: Levantamento de Requisitos
O engenheiro coloca-se no papel do cliente e dos utilizadores. Raciocina com base em premissas do tipo: “Se eu fosse o cliente, eu gostaria que o produto… “
3.1.4 Etnografia A etnografia ajuda o comportamento das pessoas no seu ambiente “natural”. O engenheiro de requisitos participa nas atividades que normalmente os utilizadores realizam. Na observação, o analista observa e acompanha a execução de processos naturais. Trata-se de uma técnica bastante passiva que obriga o analista a um grande esforço e a elevada capacidade de abstração.
3.1.5 Dinâmica de grupo O uso de técnicas baseadas em dinâmicas de grupo é bastante comum e recomendável. As sessões são difíceis de organizar, especialmente em projetos que envolvam muitas pessoas. A eficácia fica comprometida se não for garantida a presença de representantes de todas as partes interessadas. Como moderador, o analista tem de:
Evitar que certos participantes dominem as discussões;
Garantir que toda a gente se sente confortável para emitir as suas ideias e opiniões.
3.1.6 Brainstorming O Brainstorming facilita a geração de ideias. Uma sessão reúne um grupo de 5 a 12 pessoas. O grupo sugere e explora o maior número possível de ideias para o sistema a desenvolver, sem que essas ideias sejam criticadas ou julgadas.
Na primeira etapa, os intervenientes são encorajados, a gerar ideias, sem que se discutam os méritos de cada uma delas. Não se rejeitam ideias disparatadas, pois muitas alternativas aumentam a probabilidade de aparecer uma ideia certa. Na etapa de consolidação, as ideias são discutidas, revistas e avaliadas. O objetivo é organizar as ideias para aumentar a sua probabilidade de utilização. As ideias semelhantes devem ser combinadas e reescritas para captar a sua essência comum. No final da sessão, documenta-se as ideias relevantes e identificam-se a sua ordem de prioridades. 10
Curso: Levantamento de Requisitos
3.1.7 Análise de Domínio •
Para obter requisitos para um determinado sistema pode-se analisar documentação e estudar outros sistemas já existentes;
•
O objetivo da análise de domínio não é examinar um dado sistema, mas antes o domínio em que ele se enquadra. A fim de serem identificados todos os elementos comuns de todos os sistemas nesse domínio.
•
A análise de documentos baseia-se na procura de requisitos em documentos, relatórios e arquivos.
Figura 5: Figura ilustrativa de uma análise de domínio. 4 Como podemos verificar pela imagem anterior, um analista de sistema, para poder implementar novas funcionalidades, deverá analisar como o sistema esta integrado e implementado, de forma a manter as funcionalidades já existentes, aplicando as novas nos mesmos moldes.
4
Fonte: https://pixabay.com/pt/an%C3%A1lise-analytics-neg%C3%B3cios-gr%C3%A1fico-1841158/
11
Curso: Levantamento de Requisitos
4. Escrita de Requisitos A escrita de requisitos em linguagem natural é quase inevitável. Nem todas as partes interessadas conseguem interpretar especificações formais de requisitos. Um engenheiro, em geral tem de saber comunicar quer de forma oral quer de forma escrita com outras pessoas. Escrever de forma eficaz é uma tarefa propensa a erros. É importante escrever requisitos, de acordo com um conjunto de princípios e recomendações. Escrever requisitos requer aperfeiçoamento continuo, através do treino e prática. Não há formulas mágicas para se escrever bem, pois a escrita é uma arte! A opção pela escrita de requisitos em linguagem natural sem qualquer tipo de restrição, apresenta diversas vantagens:
Não há limites à expressividade;
É percetível por todas as pessoas alfabetizadas;
Não requer nenhuma formação especifica.
A escrita livre apresenta muitas ambiguidades. A qualidade final acaba por variar bastante de caso para caso. É crucial encontrar alguns princípios que ajudem a escrever bem os requisitos. Não existe um requisito “Perfeito”, logo a escrita dum requisito está sempre em aberto. A escrita de requisitos para produtos de engenharia deve obedecer às regras básicas de escrita técnica. A linguagem deve ser simples, clara e precisa. Não devem ser usados recursos literários, metáforas ou analogias. As palavras devem ser usadas no seu sentido denotativo, sem espaço para eventuais interpretações alternativas. A escrita técnica deve ser redigida num estilo que seja impessoal, objetivo, claro, modesto e cortês. Por exemplo, o requisito seguinte, encontra-se errado! O utilizador Xavier e a secretária Ana deveriam ter escolhido sequencialmente o João e o Xico para que fosse cada um com cada qual. Assim o Xavier só tem de fazer login na área de acesso e o Xico terá de realizar proformas no sistema. Mas ambos devem Realizar rapidamente a abertura das respetivas janelas no sistema.
12
Curso: Levantamento de Requisitos
Corretamente escrito, este requisito deveria ficar da seguinte forma:
R1: O utilizador deve ser capaz de realizar login na รกrea de acesso em 2 segundos. R2: O utilizador deve ser capaz de registar proformas no sistema em 5 segundos.
13
Curso: Levantamento de Requisitos
5. Conclusão A engenharia de requisitos cria canais de comunicação entre os detentores do problema e os que vão construir a solução. A engenharia de requisitos permite levantar, negociar e documentar as funcionalidades e restrições dum sistema. O levantamento de requisitos envolve várias atividades que permitem identificar quais são os requisitos dum dado sistema. As técnicas de engenharia de requisitos cobrem essencialmente a fase de análise. Os engenheiros de requisitos dedicam-se a contactar pessoas que conhecem bem o problema, para:
Identificar todas as restrições que possam limitar a solução;
Decidir a forma como organizar o documento de requisitos;
A identificação das partes interessadas é uma tarefa importante. Uma parte interessada num sistema é uma pessoa que tenha algum tipo de interesse legitimo nesse sistema. O analista deve dominar um conjunto alargado de técnicas e aplicar aquelas que melhor se adaptam a cada projeto. Um projeto dificilmente será um projeto de êxito, se todas as partes interessadas não derem a sua opinião em relação aos Requisitos. Escrever é uma tarefa propensa a erros, já que nem sempre aquilo que se escreve é interpretado da forma pretendida. Por essa razão é necessário aplicar uma escrita técnica ao invés da linguagem livre.
14
Curso: Levantamento de Requisitos
ReferĂŞncias Usability- and Accessibility-Focused Requirements Engineering, Achim Ebert,Shah Rukh
15
Curso: Levantamento de Requisitos
Anexos
16
Curso: Levantamento de Requisitos
I.
Exemplo de Entrevista
17
Curso: Levantamento de Requisitos
II. Exemplo de InquĂŠrito
18