Análise e Levantamento de Requisitos

Primeiro que eu detesto essa palavra: "Requisitos".
Requisitos me faz lembrar de toda aquela baboseira sobre Engenharia de Software que eu tive que engolir na graduação.
É por isso que eu só desenvolvo programas para mim mesmo, pois eu sei os meus tais requisitos.

Funções e Restrições.

Requisitos de Usuário =>  São requisitos de alto nível, abstratos. Em linguagem natural e também em diagramas sobre as funções que o sistema deve fornecer e as restrições que ele deve operar.
Podem ser requisitos funcionais ou não-funcionais.
Podem ser escritos em linguagem natural, formulários ou diagramas muito simples.

Requisitos de Sistema => Descrição detalhada do que o sistema deve fazer. Pode servir de contrato entre o comprador do sistema e o desenvolvedor.
Grave isso bem: "Requisitos do sistema informam de maneira detalhada o que um sistema deve fazer, e não como ele deve ser implementado"

Um único requisito de usuário de ser desbulhado em vários requisitos do sistema.

Especificação do Projeto => É uma descrição abstrata do projeto de software.

Tipo de Requisito	Escrito para quem poder entender?
Requisitos de Usuário	Gerentes de clientes Usuário final do sistema Engenheiro do Cliente Gerente do Fornecedor Arquiteto do Sistema
Requisitos do Sistema	Usuário final do sistema Engenheiro do Cliente Arquiteto do Sistema Desenvolvedor do Software ( Note que ele considera o desenvolvedor ignorante demais para entender os requisitos direta da boca do usuário) Note que aqui também os gerentes pulam fora.
Especificação do Projeto de Software	Engenheiro do Cliente Arquiteto do Sistema Desenvolvedor do Software

Então até aqui concordamos que os requisitos de usuário, sistema e a especificação formam uma espécie de pirâmide.

 No topo tempos a especificação - um monte de diagrama UML.
No meio temos os requisitos do sistema, em mais alto nível porém mais detalhado que os requisitos do usuário, expressos por vossa majestade Engenheiro de Software. É preciso esse nível porque segundo eles os desenvolvedores são estúpidos e não conseguem entender diretamente os requisitos do usuário.
Aqui o usuário vai dizer o que quer do software, com as palavras dele.






== Agora os Requisitos Classificam-se em ==

Requisitos Funcionais => São as funções.

Requisitos Não-funcionais => São as restrições.

Requisitos de Domínio => Podem ser funcionais ( as funções ) ou não-funcionais ( as restrições ). Emergem do próprio domínio de aplicação do software. Bom, eu procurei alguns exemplos mas Enrolagem de Software é algo tão subjetivo que ninguém se arrisca a dar um exemplo diferente do que tem no livro de Somevile.

"A desaceleração do trem deve ser computada através da fórmula Dtrem=Dcontrole+Dgradiente onde ..."

O próprio Someleca fala que na prática é muito difícil se classificar um requisito como funcional ou não funcional porque um requisito não-funcional pode envolver a implementação de um requisito funcional.

Ná prática a Engenharia de Software não é Engenharia, se fosse, engenheiro de software tinha o CREA.

Requisitos Não-Funcionais

Eles estão relacionados com as propriedades emergentes dos sistemas.
Eles são as restrições sobre as funcionalidades do sistema, como desempenho, portabilidade de código, robustez, resiliência e etc.

Eles se dividem em:

Os requisitos de produto especificam as restrições impostas ao produto, como  a portabilidade, o desempenho, requisitos de espaço e a confiabilidade.

Os requisitos organizacionais derivam das restrições políticas da organização do cliente e também da organização do desenvolvedor, como por exemplo, linguagem de programação X ou utilizar SGBD Y.

Requisitos Organizacionais de Linguagem de Programação

Os requisitos externos são restrições externas ao sistema e ao seu processo de desenvolvimento, a citar, requisitos de interoperabilidade com outros sistemas legados, utilizando por exemplo JCA ( Java Conector Architecture) ou ainda (Java para Coisas Antigas). Também os requisitos legais, como por exemplo, é proibido utilizar criptografia na China.

Destino de quem usa SSL, TSL, IPSec, SSH ...  na China

Não confundir interoperabilidade com portabilidade.

Além disso, os requisitos não-funcionais podem ser de difícil verificação. Sempre que possível utilizar uma métrica quantitativa.

Abaixo, uma questão que eu errei no último concurso que teve para Engenheiro de Software. E assim, com mais duas questões que eu errei de algoritmos, coisa que eu estava bastante confiante pois já tinha participado de duas maratonas de programação, assim eu deixei escapar a chance de comprar meu honda civic. (Fiquei a 3 questões das vagas)


(Petrobras, 2011) Na Engenharia de Software, os requisitos que descrevem
o comportamento externo do sistema, estabelecendo uma
descrição detalhada das funções, dos serviços e das restrições
operacionais do referido sistema, são os requisitos
(A) funcionais
(B) externos
(C) de sistema
(D) do usuário
(E) não funcionais


O que me lascou foi esse "comportamento externo".  Porém ele fala em funções e restrições operacionais do sistema.  E note também que ele fala em comportamento externo, não em restrições externas, que seriam os requisitos externos. Comportamento externo é o sentido pelo usuário, então trata-se dos requisitos de sistema, letra C, que abarcam os requisitos funcionais (funções) e requisitos não-funcionais (restrições) de forma mais detalhadas que os requisitos de usuário.

Levantamento de Requisitos

Eita, vou até pegar um café que o texto é longo.


Algumas partes que escrevi abaixo foi retirado no trabalho de FABIANA MICHELE FERNANDES PIVOTO FARIA, podendo ser encontrada aqui [1]


Outras foram escritas com base em minhas anotações e mindmaps que perdi as referências.

Amostragem

• Determinar os dados a serem coletados
• Determinar a população a ser amostrada
• Escolher o tipo da amostra
• Decidir o tamanho da amostra

Observação

• Levantar informações que passam despercebidas em outras técnicas
• Ver não apenas o que é documentado e especificado
• O relacionamento do tomador de decisão e os demais membros da organização
• Confirmar ou negar informações obtidas em entrevistas e questionários

A técnica em que o levantador de requisitos se insere no ambiente de trabalho para coletar requisitos é chamado de etnografia, é como um antropólogo ir morar em uma aldeia indígena para aprender o costume dos índios.

Etnografia para o sommerville:
Utilizada para compreender os requisitos sociais e organizacionais. Um analista se insere no ambiente de trabalho onde o sistema será usado. Observa o trabalho do dia a dia e anota as tarefas reais nas quais os participantes estão envolvidos. O valor da etnografia está na ajuda que presta aos analistas para descobrir requisitos implícitos de sistemas que refletem os processos reais, e não os formais.
Ela é eficaz para descobrir dois tipos de requisitos:
1. derivados da maneira como as pessoas realmente trabalham
2. derivados da cooperação e do conhecimento das atividades de outras pessoas.

Entrevista

Quanto ao tipo de pergunta

• Perguntas Abertas ( Subjetivas )
• Perguntas Capciosas
• Tendem a fazer o entrevistado responder de uma forma específica
• São tendenciosas
• Duas questões em uma Ex: O que você faz nessa situação, e como?
• Perguntas Fechadas (Objetivas) 
• Que nem questões de concurso. 

Agora que formulamos as perguntas, vamos fazer a entrevista.

Lembre-se, as questões objetivas são mais arrochadas que as subjetivas. As objetivas são as estreitas, as subjetivas são largas. Isso é útil para decorar sobre a geometria de como são estruturadas as entrevistas.

• Quanto a estrutura da entrevista.
• Estrutura Pirâmide 
• Começa com questões detalhadas (Objetivas / finas)
• Termina com questões mais gerais (Subjetivas / largas )
• Estrutura Funil
• Começa com questões mais gerais (Subjetivas / largas )
• Termina com questões mais detalhadas (Objetivas / finas)
• Estrutura de Diamante 
• Funil + Pirâmide
• Específicas -> Gerais -> Específicas
• Geralmente a melhor forma
• Tende a ser mais longa
• Não-Estruturada
• Não há uma sequência de como as questões serão abordadas
• Porém as questões são definidas a-priori (Isso é questão de concurso, já errei uma no QC assim. Não tem como vc ir para um entrevista sem saber o que perguntar!)

Prototipação

Pode utilizada para descoberta ou validação de requisitos
Pode ser

• Evolucionária
• Exploratória

Prototipação em papel não têm a necessidade de linguagem de programação. Essa é a melhor de todas, a gente faz cada programa revolucionário no papel... Eu mesmo tenho uma suite todinha que fiz enquanto lanchava um dia desses.

Análise de Protocolo
Cenário

Sessões JAD

Criada pela IBM
Workshop estruturado

5 FASES

1. Definição do projeto
2. Pesquisa
3. Preparação para a sessão
4. A Sessão
5. Documento Final

PD
QFD
CRC

IFQ (Implantação da Função de Qualidade)

• Também conhecido como ou QFD (Quality Function Deployment)
• Traduzir Necessidades dos clientes para requisitos técnicos de software
• Três tipos de requisitos
• Requisitos Normais
• Requisitos Funcionais
• Requisitos Esperados
• Requisitos Implícitos
• Importantes, porém não mencionados na coleta
• Requisitos Excitantes
• Vão além da expectativa dos usuário

Atividades do Processo

obtenção; classificação e organização; priorização e negociação; documentação.

Validação de Requisitos

Assim como o software, os requisitos também devem ser avaliados quanto à qualidade. A validação, atividade da engenharia de requisitos, é responsável por garantir que os requisitos tenham sido declarados de forma clara e precisa. Além disso, a validação busca detectar inconsistências, erros e omissões, objetivando alinhar os requisitos às normas estabelecidas para o projeto, produto e processo.

Prova: CESGRANRIO - 2006 - Petrobrás - Analista de Sistemas Pleno - Especialidade - Engenharia de Software

Disciplina: Engenharia de Software | Assuntos: Análise de Requisitos;  Engenharia de Requisitos; 

Analise as afirmativas abaixo a respeito de técnicas de levantamento de requisitos:

I - Uma entrevista não estruturada deve "fluir" entre o entrevistado e o entrevistador e, para isso, as questões a serem feitas não se devem ser definidas previamente.

II - A Implantação da Função de Qualidade (IFQ) é uma técnica que traduz as necessidades do cliente para requisitos técnicos de software, identificando três tipos de requisitos: normais, esperados e excitantes.

III - Amostragem é o processo de seleção sistemática de elementos representativos de uma população, que permite revelar informações úteis acerca da população como um todo.

IV - Uma técnica importante no levantamento de requisitos é observar o comportamento e o ambiente do indivíduo tomador de decisões, já que muitas informações passam desapercebidas com a utilização de outras técnicas.

Estão corretas apenas as afirmativas:

•  a) I e II.

•  b) III e IV.

•  c) I, II e III.

•  d) I, II e IV.

•  e) II, III e IV.

I - Uma entrevista não estruturada deve "fluir" entre o entrevistado e o entrevistador e, para isso, as questões a serem feitas não se devem ser definidas previamente. 

ERRADO.  As questões devem ser definidas anteriormente, porém a forma com a qual essas questões serão estruturadas é que não é definida.

As questões podem ser abertas (subjetivas) ou fechadas (objetivas) e podem ser estruturadas em várias estruturas (Pirâmide, Funil e Diamante), ou em nenhuma estrutura como cita a questão.

II - A Implantação da Função de Qualidade (IFQ) é uma técnica que traduz as necessidades do cliente para requisitos técnicos de software, identificando três tipos de requisitos: normais, esperados e excitantes.

Sim, isso mesmo. (Requisitos Excitantes - Que excedem a expectativa do cliente )

III - Amostragem é o processo de seleção sistemática de elementos representativos de uma população, que permite revelar informações úteis acerca da população como um todo.

Correto também. Quando o universo da população é muito grande pode-se utilizar uma parcela dessa população para se representar o todo.

IV - Uma técnica importante no levantamento de requisitos é observar o comportamento e o ambiente do indivíduo tomador de decisões, já que muitas informações passam desapercebidas com a utilização de outras técnicas.

Observar o comportamento e o ambiente do indivíduo que toma decisões pode ser
uma forma bastante eficaz de levantar informações que, tipicamente, passam
desapercebidas usando outras técnicas.

Note que as pessoas tem um conhecimento tácito, algo inerente a elas que não pode ser facilmente formalizado em um documento.