Requisitos de usuário do modelo
O Visual Studio ajuda você a entender, discutir e comunicar as necessidades dos usuários desenhando diagramas sobre as atividades deles e o papel que seu sistema desempenha para ajudá-los a alcançar as próprias metas. Um modelo de requisitos é um conjunto desses diagramas, cada um dos quais se concentra em um aspecto diferente das necessidades dos usuários.
Para ver quais versões do Visual Studio dão suporte a cada tipo de modelo, confira Suporte de versão para ferramentas de arquitetura e modelagem.
Um modelo de requisitos ajuda você a:
Concentrar-se no comportamento externo do sistema, separadamente de seu design interno.
Descrever as necessidades dos usuários e stakeholders com muito menos ambiguidade do que seria possível em linguagem natural.
Definir um glossário consistente de termos que pode ser usado por usuários, desenvolvedores e testadores.
Reduzir lacunas e inconsistências nos requisitos.
Reduzir o trabalho necessário para responder às alterações de requisitos.
Planejar a ordem na qual os recursos serão desenvolvidos.
Usar os modelos como base para testes do sistema, fazendo uma relação clara entre os testes e os requisitos. Quando os requisitos mudam, essa relação ajuda você a atualizar os testes corretamente. Isso garante que o sistema atenda aos novos requisitos.
Um modelo de requisitos oferece maior benefício se você usá-lo para concentrar discussões com os usuários ou os representantes deles e revisitá-lo no início de cada iteração. Você não precisa preenche-lo em detalhes antes de escrever código. Um aplicativo parcialmente funcional, mesmo que muito simplificado, geralmente forma a base mais estimulante para discussão dos requisitos com os usuários. O modelo é uma maneira eficaz de resumir os resultados dessas discussões. Para obter mais informações, confira Usar modelos em seu processo de desenvolvimento.
Observação
Ao longo desses tópicos, "system" significa o sistema ou o aplicativo que você está desenvolvendo. Pode ser uma grande coleção de muitos componentes de software e hardware; ou apenas um aplicativo; ou um componente de software dentro de um sistema maior. Em todos os casos, o modelo de requisitos descreve o comportamento visível de fora do sistema, seja por meio de uma interface do usuário ou da API.
Tarefas comuns
Você pode criar várias exibições diferentes dos requisitos dos usuários. Cada exibição fornece um tipo específico de informação. Quando você cria essas exibições, é melhor mudar com frequência de uma para outra. Você pode começar de qualquer exibição.
| Diagrama ou documento | O que ele descreve em um modelo de requisitos | Seção |
|---|---|---|
| Diagrama de classe conceitual | Glossário de tipos usados para descrever os requisitos; os tipos visíveis na interface do sistema. | |
| Itens de trabalho ou documentos adicionais | Critérios de desempenho, segurança, usabilidade e confiabilidade. | Descrever os requisitos de qualidade de serviço |
| Itens de trabalho ou documentos adicionais | Restrições e regras não específicas para um caso de uso específico | Mostrar regras de negócios |
Observe que a maioria dos tipos de diagrama pode ser usada para outras finalidades. Para obter uma visão geral dos tipos de diagrama, confira Criar modelos para o seu aplicativo.
Mostrar regras de negócios
Uma regra de negócios é um requisito que não está associado a um caso de uso específico e deve ser observado em todo o sistema.
Muitas regras de negócios são restrições nas relações entre as classes conceituais. Você pode escrever essas regras de negócios estáticas como comentários associados às classes relevantes em um diagrama de classe conceitual. Por exemplo:
As regras de negócios dinâmicas restringem as sequências de eventos permitidas. Por exemplo, você usa um diagrama de sequência ou atividade para mostrar que um usuário precisa fazer logon antes de executar outras operações em seu sistema.
No entanto, muitas regras dinâmicas podem ser declaradas de maneira mais eficaz e genérica substituindo-as por regras estáticas. Por exemplo, você pode adicionar um atributo booliano 'Logged In' a uma classe no modelo de classe conceitual. Você adicionaria Logged In como a pós-condição do caso de uso do log e o adicionaria como uma pré-condição da maioria dos outros casos de uso. Essa abordagem permite que você evite definir todas as combinações possíveis de sequências de eventos. Ela também é mais flexível quando você precisa adicionar novos casos de uso ao modelo.
Observe que a escolha aqui é sobre como você define os requisitos e que isso é independente de como você implementa os requisitos no código do programa.
Os tópicos a seguir fornecem mais informações:
| Para saber mais | Ler |
|---|---|
| Como desenvolver código que adere às regras de negócios | Modelar a arquitetura do aplicativo |
Descrever os requisitos de qualidade de serviço
Há várias categorias de requisito de qualidade de serviço. Eles incluem o seguinte:
Desempenho
Segurança
Usabilidade
Confiabilidade
Robustez
Você pode incluir alguns desses requisitos nas descrições de casos de uso específicos. Outros requisitos não são específicos para casos de uso e são escritos com mais eficiência em um documento separado. Quando possível, é útil aderir ao vocabulário definido pelo modelo de requisitos. No seguinte exemplo, observe que as palavras principais usadas no requisito são os títulos de atores, casos de uso e classes nas ilustrações anteriores:
Se um restaurante excluir um Item de Menu enquanto um cliente estiver fazendo o pedido de uma refeição, qualquer Item de Pedido que se refira a esse Item de Menu será exibido em vermelho.
Confira Modelar a arquitetura do aplicativo para saber como desenvolver código que adere aos requisitos de qualidade de serviço.