Assim que um cliente manifesta interesse em automatizar seus processos de negócio e depois de assinar o TAP, o Time de Desenvolvimento planeja e executa as primeiras reuniões para identificar as necessidades e problemas para propor soluções de software. O objetivo é ter tantas reuniões quantas forem necessárias para se definir o escopo do sistema. Prepare a entrevista antes, ver o Guia - Técnica de Entrevista, para realizar o levantamento de requisitos utilizando a Técnica de Entrevista. Utilize a Ata de Reunião para registrar as questões e posteriormente complemente-a com as respostas. Lembrando que é uma boa prática gravar as entrevistas para depois, logo após a reunião, consolidar o entendimento utilizando a Guia - Workshop de Requisitos. E toda Ata de Reunião deve ser aprovada pelos interessados ou fornecedores de requisitos, assinando ou dando o "de acordo" por e-mail. Uma vez identificado os problemas e necessidades registre-as no documento Visão.
[ ] Definir o sistema (escopo)
Requisitos de Sistema
Os requisitos de sistema de software são classificados frequentemente como funcionais e não funcionais (SOMMERVILLE, 2019):
Requisitos funcionais - são declarações dos serviços que o sistema deve fornecer, do modo como o sistema deve reagir a determinadas entradas e como deve se comportar em determinadas situações. Em alguns casos os requisitos funcionais também podem declarar explicitamente o que o sistema não deve fazer.
Requisitos não funcionais - São restriçoes sobre os serviços ou funções oferecidas pelo sistema. Eles incluem restrições de tempo, restrições sobre o processo de desenvolvimento e restrições impostas por padrões. Os requisitos não funcionais se aplicam, frequentemente, ao sistema como um tudo, em vez de às características individuais ou aos serviços.
Com base nas necessidades definidas no Visão (na forma de Histórias de Usuário) deve-se elaborar o Modelo de Caso de Uso. Normalmente as Histórias são mapeadas ao Modelo de Caso de Uso um-para-um, os quais definem as principais funcionalidades que compõem o escopo do sistema.
Uma boa prática é fazer uma descrição resumida para cada caso de uso do Modelo de Caso de Uso. Sugere-se a ferramenta Astah para modelagem e descrição dos casos de uso.
[ ] Levantar necessidades do cliente
Assim que um cliente manifesta interesse em automatizar seus processos de negócio e depois de assinar o TAP, o Time de Desenvolvimento planeja e executa as primeiras reuniões para identificar as necessidades e problemas para propor soluções de software. O objetivo é ter tantas reuniões quantas forem necessárias para se definir o escopo do sistema. Prepare a entrevista antes, ver o Guia - Técnica de Entrevista, para realizar o levantamento de requisitos utilizando a Técnica de Entrevista. Utilize a Ata de Reunião para registrar as questões e posteriormente complemente-a com as respostas. Lembrando que é uma boa prática gravar as entrevistas para depois, logo após a reunião, consolidar o entendimento utilizando a Guia - Workshop de Requisitos. E toda Ata de Reunião deve ser aprovada pelos interessados ou fornecedores de requisitos, assinando ou dando o "de acordo" por e-mail. Uma vez identificado os problemas e necessidades registre-as no documento Visão.
[ ] Definir o sistema (escopo)
Requisitos de Sistema Os requisitos de sistema de software são classificados frequentemente como funcionais e não funcionais (SOMMERVILLE, 2019): Requisitos funcionais - são declarações dos serviços que o sistema deve fornecer, do modo como o sistema deve reagir a determinadas entradas e como deve se comportar em determinadas situações. Em alguns casos os requisitos funcionais também podem declarar explicitamente o que o sistema não deve fazer. Requisitos não funcionais - São restriçoes sobre os serviços ou funções oferecidas pelo sistema. Eles incluem restrições de tempo, restrições sobre o processo de desenvolvimento e restrições impostas por padrões. Os requisitos não funcionais se aplicam, frequentemente, ao sistema como um tudo, em vez de às características individuais ou aos serviços. Com base nas necessidades definidas no Visão (na forma de Histórias de Usuário) deve-se elaborar o Modelo de Caso de Uso. Normalmente as Histórias são mapeadas ao Modelo de Caso de Uso um-para-um, os quais definem as principais funcionalidades que compõem o escopo do sistema.
Uma boa prática é fazer uma descrição resumida para cada caso de uso do Modelo de Caso de Uso. Sugere-se a ferramenta Astah para modelagem e descrição dos casos de uso.