Requsito - IX

Requisitos Funcionais e Não Funcionais

Os requisitos, de modo geral, podem ser classificados em dois grandes grupos:

Requisitos funcionais

• Que especifica como o sistema interage com o contexto a sua volta.

Descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquele que descreve as funcionalidades, as quais se espera que o sistema forneça. Eles dependem do tipo de software que está sendo desenvolvido, do conhecimento passado pelos usuários sobre o negócio em si e do que deve fazer o software que se espera desenvolver.

A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz.

É importante diferenciar a atividade de especificar requisitos da atividade de especificação que ocorre durante o design do software. No design do software deve-se tomar a decisão de quais funções o sistema efetivamente terá para satisfazer aquilo que os usuários querem, ou melhor, que o processo de negócio exige.

Requisitos não funcionais

• Que expressão atributos de qualidade da solução.

Os requisitos não funcionais não estão ligados diretamente com as funções fornecidas pelo sistema. Em geral se preocupa com padrões de qualidade como:

• Confiabilidade
• Desempenho
• Robustez
• Segurança
• Usabilidade
• Portabilidade
• Legibilidade
• Qualidade
• Manutenibilidade

São muito importantes, pois definem se o sistema será eficiente para a tarefa que se propõe a fazer. Um sistema ineficiente certamente não será usado.

• A base de dados deve ser protegida para acesso apenas de usuários autorizados.
• O tempo de resposta do sistema não deve ultrapassar 30 segundos.
• O software deve ser operacionalizado no sistema Linux.
• O tempo de desenvolvimento não deve ultrapassar seis meses.

Grande Abraço,
Gilberto Ribeiro.

Perfil Profissional - VIII

Aprovação de Requisitos

Envolve o Cliente, Gerente de Projeto, o Analista de Sistema e o Analista de Requisitos, com o objetivo de aprovar os seguintes documentos:

• Documento de Visão
• Lista de Requisitos Funcionais e Não Funcionais

Devemos seguir os critérios de aceitação no Plano de Gerenciamento de Requisitos. A aprovação dos requisitos é fundamental para o bom andamento do projeto.

Produto de Entrada

Modelo V - Documento de Visão.

O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo VIII - Lista de Requisitos.

O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo VIII - Lista de Requisitos.

O arquivo contém o modelo do documento e instruções de preenchimento.

Especificações de cenários operacionais.

Protótipos.

Tem como propósito mostrar a ideia do projeto, a navegação entre as interfaces, os relatórios previstos, o comportamento do sistema e as regras de negócio que se aplicam no sistema e não são visíveis na tela.

Apresentação para validação.

Produto de Saída

Atas da reunião.

Termo de homologação.

Atividades

Preparar a apresentação.

Apresentação didática do projeto cobrindo todas as especificações funcionais solicitadas pelo cliente.

Obter aprovação dos requisitos.

Grande Abraço, 
Gilberto Ribeiro.

SCRUM - Implantação VIII

Entendendo o Manifesto Ágil

O Manifesto Ágil documentou também os doze princípios orientadores para o desenvolvimento ágil e definiu uma filosofia em torno de um conjunto de metodologias existentes.

O texto original do manifesto diz o seguinte:

“Estamos descobrindo maneiras melhores de desenvolver softwares fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas. Software em funcionamento mais que documentação abrangente. Colaboração com o cliente mais que negociação de contratos. Responder a mudanças mais que seguir um plano. Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.” (http://manifestoagil.com.br)

Indivíduos e interações, mais que processos e ferramentas

Não precisa ser uma equipe formada por gênios, mas por desenvolvedores comuns que façam uso constante da comunicação, este perfil é fundamental na formação de uma equipe ágil. A habilidade dos recursos e a interação entre eles garantirão o sucesso do projeto. Os recursos devem ser capacitados, ter experiência e naturalmente conhecerem os processos da empresa. Porém, também sabemos que os processos não salvam um projeto do fracasso, pessoas capazes sim, por isso, o framework preza mais pelos indivíduos e as interações entre eles. O que não descarta na implementação do Scrum a definição ou correção dos processos existentes na empresa, pois para sermos ágeis precisamos antes sermos organizados e é a organização quem garantirá a agilidade.

O mesmo se dá com frequência na adoção das ferramentas, já que só obtemos os recursos produtivos esperados, se a equipe envolvida tem domínio sobre elas, pois a curva de aprendizagem pode se tornar um risco para o projeto pela falta de capacitação da equipe na ferramenta. Cabe aqui o conceito de simplicidade. 

Grande Abraço,

Gilberto Ribeiro.

Engenharia de Software - VIII

Usabilidade segundo a Norma ISO 9126

 “Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas”. (NBR ISO/IEC 9126)

O envolvimento do Dono do Produto possibilita que o domínio do negócio seja refletido no sistema em desenvolvimento, garantindo pela coautoria do especialista a usabilidade do sistema.

  

Inteligibilidade

“Capacidade do produto de software de possibilitar ao usuário compreender se o software é apropriado e como ele pode ser usado para tarefas e condições de uso específicas”. (NBR ISO/IEC 9126)

Item da norma também garantida com o envolvimento do especialista do negócio.

Apreensibilidade

“Capacidade do produto de software de possibilitar ao usuário aprender sua aplicação”. (NBR ISO/IEC 9126)

A facilidade de uso e apreensibilidade do sistema também é garantida pela participação do Dono do Produto no ciclo de vida de desenvolvimento do sistema, refletindo na sistematização o modus operandos do usuário final, tornando o sistema familiar e fácil de operar.

Operacionalidade

“Capacidade do produto de software de possibilitar ao usuário operá-lo e controlá-lo”. (NBR ISO/IEC 9126)

O envolvimento dos stakeholders torna mais fácil a adequação do sistema a este item da Norma, garantindo a facilidade de operação e controle do sistema.

Atratividade

“Capacidade do produto de software de ser atraente ao usuário”. (NBR ISO/IEC 9126)

O envolvimento dos stakeholders garante este item da Norma ISO.

Conformidade relacionada à usabilidade

“Capacidade do produto de software de estar de acordo com normas, convenções, guias de estilo ou regulamentações relacionadas à usabilidade”. (NBR ISO/IEC 9126)

Grande Abraço,

Gilberto Ribeiro.

Métrica de Software - VIII

Como classificar um TD - Tipo de Dado

• É um campo único
• Reconhecido pelo usuário
• Não repetido
• Mantido ou recuperado por um ALI ou AIE (por um processo elementar)

Regras de Contagem de Tipo de Dados

• Contar como 1 TD nos casos em que vários campos implementam apenas um tipo de dados: 

• Realização de uma imagem, o conteúdo salvo nos campos em histórico conta um único tipo de dado.

 

Imagem = 11 TD, contamos os 10 campos de Contatos e 1 do Histórico, que é a imagem de Contatos.

• Campos calculados e armazenados em ALI também deve ser contados como Tipos de Dados.
• Campos do tipo timestamps, se reconhecidos pelo usuário, devem ser contados como tipos de dados.

Arquivos com várias ocorrências do mesmo campo: Janeiro, Fevereiro,..., Dezembro. Doze campos repetidos mapeados como dois tipos de dados únicos.

                   Cliente            Saldos [12 campos]

                                         | J | F | M | A | M | J | J | A | S | O | N | D |

                   1 ALI              2 TD = Saldo e Mês

• Quando duas aplicações mantêm ou referenciam o mesmo ALI/AIE, conte apenas os campos utilizados pela aplicação em análise, por exemplo:

a.  Se uma aplicação faz uso de 3 campos e a outra faz uso de 2 campos teremos respectivamente 3 TD para primeira e 2 TD para segunda aplicação.

b.  Se uma aplicação faz uso de 6 campos e na outra aplicação só faz sentido usar o conjunto, pois as informações desassociadas são irrelevantes

• Conte um Tipo de Dado para cada campo solicitado pelo usuário para estabelecer um relacionamento com outro arquivo (ALI ou AIE).

Funcionário (independente) # empresa #funcionário ...

Cliente (independente) # cliente # empresa # funcionário ...

2 Arquivos Lógicos

2 Tipo de Dados

• Caso a chave estrangeira seja composta por vários campos, todos devem ser contados como tipos de dados.
• Quando um único arquivo lógico é composto por mais de uma tabela no banco de dados, a chave estrangeira usada para estabelecer o relacionamento entre essas tabelas não deve ser contada mais de uma vez como tipo de dados.

Atenção: Nem sempre a relação entra Tipo de Dados e Campo de Arquivo é 100% correto.

Grande Abraço,

Gilberto Ribeiro.