requisitos)

requisito de usuário

  • uma primeira escrita de qual vai ser a solução;
  • feito pelo engenheiro de software, de forma que seja fácil de qualquer pessoa entender.

requisitos de sistema

  • escritos pelos e para os desenvolvedores.

login e senha pode ser um requisito não funcional, uma vez que você descreve-lo como “estar protegido por login e senha”.

Para fazer um sistema ser fácil de usar, siga o padrão de outros apps mais usados.

História de usuário

  • praticamente um requisito de usuário, mas com um formato padrão;
  • você sempre possui um ator(quem), o que ele quer(o que) e porque ele quer (para que);
  • usado no SCRUM;
  • Por possuir o quem, ele ajuda a encontrar os stakeholders.

exemplo: “Como funcionário da biblioteca, eu quero que o sistema envie e-mails de cobrança para os alunos, para que nenhum livro seja perdido”.

Casos de uso

  • diagrama (semelhante com um grafo), que define quem são os atores e suas ações no sistema.

fonte:\n<a href=\DEVMEDIA" loading="lazy" src="/posts/ciencias-da-computacao-dia-98-h3a7j7e7e9j8/image_187.png">

Levantamento de requisitos(elicitação de requisitos)

  • identificar os problemas e propor elementos para solucionar e a partir disso, negociar as abordagens;
  • usar casos de uso e/ou histórias de usuário;
  • deve ser feito em conjunto com os stakeholders.

Reuniões

  • Você precisa ter um facilitador (alguém que vai comandar a reunião), assim como pessoas de outros departamentos, para debaterem seus interesses;
  • São necessárias várias reuniões, ao longo do tempo, para descobrir todos os requisitos.

Obs: Vision box também é um método de levantamento de requisitos.

Ao levantar os requisitos do usuário, faça uma lista de:

  • objetos → tudo aqui que o sistema vai gerenciar/manipular (dinheiro, livros, carros, etc.);
  • serviços → tudo aqui que o sistema vai oferecer (as suas funções);
  • restrições → custos, prazos, dimensões que o sistema vai seguir (também podem ser regras de negócio).

Miniespecificação

  • Descrição de um item de uma das listas a cima, que pode não estar claro;
  • Pode ser ainda uma mini história do sistema ou então caso de uso.

Embates podem acontecer nas primeiras reuniões, no entanto, isso no momento não é bom. Foque em apenas anotar todos os possíveis requisitos, e depois pense no que vai e não vai para o projeto final.

Classificação de requisitos

normais

  • o que o sistema deve ter (requisitos pedidos).

esperados

  • aquilo que não foi especificado, mas, por ser padrão, o cliente não especificou e acreditava que estava óbvio dado o problema.

fascinantes

  • requisitos que vão além do que foi pedido (AI por exemplo).

obs: faça sempre os requisitos normais e esperados primeiro, após tudo estar pronto, ai você vai atrás de fazer os fascinantes. Lembre-se que grande parte do software não é usado por que não resolve o problema do usuário. (regra 80:20, 20% das funções representam 80% do valor do software).

Cenários de uso

  • a partir do levantamento de requisitos, você vai aprofundando e começa a entender melhor as coisas.

Joint Application Design

  • criado pela IBM;
  • reuniões com segmentos bem definidos;
  • feito para que com poucas reuniões seja possível definir todos os requisitos;
  • Método bom para ser utilizado quando horários de funcionários não batem.

Protótipo

  • também é uma ferramenta para entender melhor os requisitos e o que o usuário de fato quer;
  • fazer um esboço do projeto.