WEBVTT 00:00:07.694 --> 00:00:10.360 Antes de entrar no universo dos requisitos, 00:00:10.360 --> 00:00:13.974 vamos entender um pouco o contexto de um projeto de software 00:00:13.974 --> 00:00:16.872 e como os requisitos se encaixam nesse processo. 00:00:16.872 --> 00:00:19.868 Quando iniciamos o processo de construção de um software, 00:00:19.868 --> 00:00:24.307 precisamos levantar todas as características que as partes interessadas, 00:00:24.307 --> 00:00:28.417 também conhecidas como stakeholders, desejam que esse software tenha. 00:00:28.417 --> 00:00:32.626 Todas essas solicitações podem ser de naturezas bem diferentes, 00:00:32.626 --> 00:00:35.618 por exemplo, uma tela com um layout específico, 00:00:35.618 --> 00:00:39.079 um relatório que contém informações de vários departamentos 00:00:39.079 --> 00:00:42.719 ou até mesmo a necessidade de que uma determinada transação ocorra 00:00:42.719 --> 00:00:44.965 em um intervalo mínimo de tempo. 00:00:44.965 --> 00:00:49.716 Fica claro que precisamos anotar todos esses desejos de modo organizado, 00:00:49.716 --> 00:00:53.724 já que eles serão o ponto de partida para o projeto do nosso software. 00:00:53.724 --> 00:00:57.962 Atualmente, a comunidade de software, formada pelos que produzem 00:00:57.962 --> 00:01:03.129 e pelos que consomem software, atua com o paradigma dos projetos ágeis. 00:01:03.129 --> 00:01:07.297 Esses projetos ágeis promovem entregas mais rápidas, 00:01:07.297 --> 00:01:10.977 sejam entregas completas ou entregas parciais. 00:01:10.977 --> 00:01:15.925 Já essas entregas permitem que os usuários aproveitem o valor do software 00:01:15.925 --> 00:01:19.087 mesmo antes do projeto ser totalmente concluído. 00:01:19.087 --> 00:01:23.920 Um processo ágil de desenvolvimento de software tem como ponto central 00:01:23.920 --> 00:01:28.751 a entrega dele funcionando, empregando menos esforço em atividades 00:01:28.751 --> 00:01:31.608 que não sejam a sua construção em si. 00:01:31.608 --> 00:01:37.378 Com isso, o escopo dos stakeholders pode ser ajustado ao longo do projeto, 00:01:37.378 --> 00:01:39.489 conforme a necessidade, é claro. 00:01:39.489 --> 00:01:44.370 Agora que entendemos melhor esse processo ágil do desenvolvimento de software, 00:01:44.370 --> 00:01:49.042 vamos revisitar brevemente o processo clássico, o modelo cascata. 00:01:49.042 --> 00:01:52.578 O modelo cascata é composto por fases fixas, 00:01:52.578 --> 00:01:57.050 onde todas as atividades de uma fase devem ser completamente finalizadas 00:01:57.050 --> 00:01:59.189 para que a próxima comece. 00:01:59.189 --> 00:02:03.823 Na fase de análise, fazemos a coleta e a organização dos requisitos 00:02:03.823 --> 00:02:09.429 e, quando finalizada, o modelo não prevê a repetição dessas atividades durante o projeto. 00:02:09.429 --> 00:02:12.398 Para efeito de comparação, no processo ágil, 00:02:12.398 --> 00:02:15.868 essas atividades de coleta e organização de requisitos 00:02:15.868 --> 00:02:19.839 podem acontecer repetidamente em qualquer momento do projeto. 00:02:19.839 --> 00:02:26.546 Outra característica importante do processo ágil é que ele ocorre em ciclos ou espirais. 00:02:26.546 --> 00:02:32.819 Em cada espiral, os requisitos são revistos e complementados se houver necessidade. 00:02:32.819 --> 00:02:36.902 Além disso, as especificações técnicas são modeladas. 00:02:36.902 --> 00:02:42.428 Assim, o incremento da solução é construído, testado e entregue para uso. 00:02:42.428 --> 00:02:46.899 Um exemplo que ilustra o processo ágil com ciclos de entrega é o Scrum. 00:02:46.899 --> 00:02:51.386 O ponto de partida é uma lista de requisitos que o software precisa atender, 00:02:51.386 --> 00:02:53.639 ou seja, o backlog do produto. 00:02:53.639 --> 00:02:58.445 A partir dele, são criadas atividades de modelagem, construção e entrega 00:02:58.445 --> 00:03:02.315 dentro de um ciclo de trabalho conhecido como Sprint. 00:03:02.315 --> 00:03:06.652 Ao fim desse ciclo, se espera a entrega de uma parte do software para o cliente. 00:03:06.652 --> 00:03:09.422 O projeto é composto por várias sprints, 00:03:09.422 --> 00:03:13.626 onde cada uma implementa uma parte da relação dos requisitos 00:03:13.626 --> 00:03:18.097 e os ajustes do backlog do produto podem ocorrer em qualquer momento. 00:03:18.097 --> 00:03:24.937 Comentamos mais de uma vez que essa lista de requisitos deve ser anotada e classificada. 00:03:24.937 --> 00:03:28.207 Podemos classificar os requisitos de diversas maneiras, 00:03:28.207 --> 00:03:32.445 mas, ao final desse processo, devemos ter necessariamente 00:03:32.445 --> 00:03:36.949 dois tipos de requisitos: os funcionais e os não funcionais. 00:03:36.949 --> 00:03:41.969 Os requisitos funcionais são aqueles que se relacionam com uma funcionalidade, 00:03:41.969 --> 00:03:46.025 ou seja, um serviço que o software deve fornecer. 00:03:46.025 --> 00:03:50.236 Por meio deles, entendemos quais dados o sistema deve guardar, 00:03:50.236 --> 00:03:54.566 recuperar e apresentar, quais transações devem acontecer, 00:03:54.566 --> 00:03:57.581 como devem ser as interações com os usuários, 00:03:57.581 --> 00:04:01.507 atendendo, é claro, as regras de negócio envolvidas. 00:04:01.507 --> 00:04:03.694 Já os requisitos não funcionais 00:04:03.694 --> 00:04:08.814 recebem esse nome por serem de natureza oposta aos funcionais. 00:04:08.814 --> 00:04:13.119 São os que se relacionam à performance, a aspectos de interface 00:04:13.119 --> 00:04:17.022 e usabilidade do software e condições de segurança. 00:04:17.022 --> 00:04:19.658 Eles envolvem a solução como um todo. 00:04:19.658 --> 00:04:25.127 Vale ressaltar que o conjunto dos requisitos funcionais e não funcionais de um sistema 00:04:25.127 --> 00:04:28.567 é conhecido como requisitos de software. 00:04:28.567 --> 00:04:30.125 Conhecendo esses requisitos, 00:04:30.125 --> 00:04:36.308 podemos delimitar o escopo do software a ser construído, planejar o seu desenvolvimento 00:04:36.308 --> 00:04:41.847 e ter bases para estimar qual o custo e o tempo envolvidos em sua construção. 00:04:41.847 --> 00:04:46.385 Pronto, agora você já compreende o contexto de um projeto de software 00:04:46.385 --> 00:04:49.255 e como ele serve de plano de fundo para os requisitos.