Ciências da computação dia 98

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.

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.