Requisitos do usuário de modelagem.

Microsoft Visual Studio Ultimateajuda a compreender, discutir e comunicar suas necessidades de usuários desenhando diagramas sobre suas atividades e a parte um sistema desempenha no ajudando-os alcançar seus objetivos.Um modelo de requisitos é um conjunto desses diagramas, cada um deles se concentra em um aspecto diferente das necessidades dos usuários.

Para uma demonstração em vídeo, consulte: a modelagem de domínio da empresa.

Um modelo de requisitos ajuda você a:

• Focalizar o comportamento de externos do sistema, separadamente do seu design interno.

• Descreva dos usuários e dos interessados precisam com muito menos ambigüidade que em linguagem natural.

• Defina um consistente Glossário de termos que podem ser usadas por usuários, desenvolvedores e testadores.

• Reduza as lacunas e inconsistências nos requisitos.

• Reduza o trabalho necessário para responder às mudanças de requisitos.

• Planeje a ordem na qual os recursos serão desenvolvidos.

• Use os modelos como base para testes de sistema, fazendo uma relação clara entre os testes e os requisitos.Quando as necessidades mudam, esta relação ajuda você a atualizar os testes corretamente.Isso garante que o sistema atende aos novos requisitos.

Um modelo de requisitos fornece o maior benefício se você usá-lo para que concentre as discussões com os usuários ou seus representantes e revisitá-lo no início de cada iteração.Não é necessário para concluí-la detalhadamente antes de escrever código.Um aplicativo de trabalho parcialmente, mesmo que muito mais simplificado, geralmente baseia mais interessantes para discussão sobre os requisitos de usuários.O modelo é uma maneira eficaz resumem os resultados dessas discussões.Para obter mais informações, consulte Usando modelos dentro do processo de desenvolvimento.

Observação

Durante esses tópicos, "sistema" significa que o sistema ou o aplicativo que você está desenvolvendo.Pode ser uma grande coleção de muitos componentes de software e hardware; ou um único aplicativo; ou um componente de software dentro de um sistema maior.Em todos os casos, o modelo de requisitos descreve o comportamento que é visto de fora do sistema, seja por meio de uma interface de usuário ou uma API.

Tarefas comuns

Você pode criar várias visualizações dos requisitos dos usuários.Cada modo de exibição fornece um tipo específico de informação.Quando você cria esses modos de exibição, é melhor movem freqüentemente entre si.Você pode iniciar a partir de qualquer modo de exibição.

Observe que a maioria dos tipos de diagrama pode ser usada para outros fins.Para uma visão geral dos tipos de diagramas, consulte Desenvolvendo modelos para design de software.Para obter informações básicas sobre como desenhar diagramas, consulte Como: Editar modelos e diagramas UML.

Descrever como o seu sistema é usado

Crie diagramas de caso de uso para descrever quem usa o sistema e o que eles usá-lo para.Um caso de uso representa uma meta de um usuário do sistema e o procedimento que eles executam para atingir o objetivo.

Por exemplo, uma refeição on-line, vendendo o sistema deve permitir que os clientes escolham os itens de um menu e deve permitir os fornecimento restaurantes atualizar o menu.Você pode resumir isso em um diagrama de caso de uso:

Você também pode mostrar como um caso de uso é composto de casos menores.Por exemplo, a ordenação refeição é parte de uma refeição, que também inclui o pagamento e o fornecimento de compra:

Você também pode mostrar quais casos de uso estão incluídos no escopo do sistema que você está desenvolvendo.Por exemplo, o sistema na ilustração não fazer parte no caso de uso de entregar refeição.Isso ajuda a definir o contexto para o trabalho de desenvolvimento.(Em um diagrama de caso de uso, recipientes de subsistema podem ser usados para representar o sistema ou seus componentes.)

Ele também ajuda a sua equipe discutir o que será incluído em versões sucessivas.Por exemplo, você pode discutir se, na primeira versão do sistema, o pagamento para refeição está organizada diretamente entre o restaurante e o cliente, em vez de passar pelo sistema.Nesse caso, você pode mover o pagamento para refeição fora do retângulo de jantar agora sistema para a versão inicial.

Um diagrama de caso de uso só fornece um resumo dos casos de uso.Para fornecer descrições mais detalhadas, você pode vincular os casos de uso no diagrama para separar documentos e para outros diagramas.Para saber como fazer isso, consulte Como: vincular um caso de uso para documentos e diagramas.

Um diagrama de caso de uso de desenho ajuda a sua equipe:

• Focalizar o que os usuários esperam fazer com o sistema, sem sendo distraia com detalhes da implementação.

• Discuta o escopo do seu sistema ou versões específicas do sistema.

Os tópicos a seguir fornecem mais informações:

A definição de termos usados para descrever os requisitos

Você pode usar diagramas de classe UML para ajudá-lo a desenvolver um vocabulário consistente dos conceitos comerciais usados para as seguintes finalidades:

• Pelos usuários para discutir os negócios em que o sistema funciona.

• Descrever as necessidades dos usuários, por exemplo, nas descrições de casos de uso, regras de negócios e histórias de usuários.

• Os tipos de informações trocadas na API do sistema ou por meio da interface do usuário.

• Descrições dos testes de aceitação ou de sistema.

Quando eles são usados para essa finalidade, o conteúdo de um diagrama de classe UML é chamado de um diagrama conceitual de classe.(Ele também é conhecido como um modelo de domínio ou modelo de classe de análise.)

Em um diagrama conceitual de classe, você pode mostrar apenas essas classes necessárias nas descrições dos requisitos, sem mostrar nenhum dos detalhes do design de interno do sistema.O diagrama não mostra os detalhes de design de interno do sistema.Você não normalmente mostraria operações ou interfaces em classes conceituais.

Por exemplo, você pode desenhar essas classes conceituais para o sistema jantar agora:

Um diagrama conceitual de classe fornece o vocabulário de termos que podem ser usados em todo o modelo de requisitos.Por exemplo, na descrição detalhada do uso caso solicitar uma refeição, você pode escrever:

O cliente escolhe um Menu da qual construir uma ordeme, em seguida, cria Itens da ordem no ordem selecionando Itens de Menu da Menu.

Observe como os termos usados nessa descrição são os nomes das classes no modelo.O diagrama remove ambigüidades as relações entre essas classes.Por exemplo, mostra claramente que cada pedido está associado a apenas um Menu.

Mal-entendidos sobre os requisitos dos usuários com freqüência podem ser rastreados para mal-entendidos sobre os significados detalhados de palavras.Por exemplo, a maioria dos restaurantes terá uma compreensão geral dos termos de Menu e a ordem, mas a diferença entre um item em um pedido e um item em um Menu é menos evidente.Quando os requisitos estão sendo discutidos com os acionistas da empresa, é importante para expor essas diferenças.O diagrama de classe é uma ferramenta útil para ajudá-lo a esclarecer os termos e suas relações.

O modelo conceitual de classe pode formar o vocabulário básico pelo qual a lógica de negócios do seu sistema pode ser descrita.Mas as classes no software normalmente será muito mais complexas do que o modelo conceitual, porque sua implementação deve considerar questões como, por exemplo, distribuição, desempenho, flexibilidade e outros fatores.Várias implementações diferentes de uma classe conceitual são encontradas com freqüência em um único sistema.

Por exemplo, pedidos poderiam ser representados em XML, SQL, HTML e C# em diferentes partes do sistema e em interfaces diferentes entre as partes.A associação entre um pedido e um Menu poderia ser representada de várias formas diferentes, como, por exemplo, referências no código de C#, as relações no banco de dados, ou referência cruzada para o IDs em XML.Mas Apesar dessas variações, o modelo conceitual fornece informações importantes que é verdadeiras para cada parte do software.O diagrama de classe no exemplo nos diz que em cada implementação, haverá apenas um que menu associado a cada pedido.

Um diagrama de classes de requisitos de desenho ajuda a sua equipe:

• Defina e padronizar os termos básicos usados discussões das necessidades dos usuários.

• Esclareça as relações entre esses termos.

Os tópicos a seguir fornecem mais informações:

Em um diagrama conceitual de classe, normalmente não é útil colocar as setas nas associações para representar a navegabilidade.Isso ocorre porque o diagrama não representa uma implementação.As associações de representam as relações entre objetos do mundo real.O seguinte Visual Studio extensão tornar não-direcional setas padrão: exemplo: recursos de modelagem de domínio de UML.

Mostrando as regras de negócios

Uma regra de negócio é um requisito que não está associado 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 esses estáticoas regras de negócios como comentários associados as classes relevantes em um diagrama conceitual de classe.Por exemplo:

Regras de negócios dinâmicos restringir as seqüências permitidas de eventos.Por exemplo, você deve usar um diagrama de seqüência ou atividade para mostrar que um usuário deve efetuar login antes de executar outras operações no seu sistema.

No entanto, muitas regras dinâmicas podem ser mais eficaz e genericamente declaradas substituindo-os por regras estáticas.Por exemplo, você poderia adicionar um atributo booleano 'Registrados no' a uma classe no modelo conceitual de classe.Deseja adicionar conectado como a pós-condição do log em caso de uso e adicioná-lo como uma pré-condição para a maioria dos outros casos de uso.Essa abordagem permite que você evite a definição de todas as combinações possíveis de seqüências de eventos.Também é mais flexível quando você precisar adicionar novos casos de uso para o modelo.

Observe que a opção aqui é sobre como você pode definir os requisitos e que isso é independente de como implementar os requisitos do código de programa.

Os tópicos a seguir fornecem mais informações:

Descrevendo a qualidade de requisitos de serviço

Há várias categorias de qualidade da requisição de serviço.Eles incluem o seguinte:

• Desempenho

• Segurança

• Facilidade de uso

• Confiabilidade

• Robustez

Você pode incluir alguns desses requisitos nas descrições de casos de uso específico.Outros requisitos não são específicos para casos de uso e com mais eficiência são gravados em um documento separado.Quando possível, é útil cumprir o vocabulário definidas pelo modelo de requisitos.No exemplo a seguir, observe que as palavras principais usadas na requisição de são os títulos dos atores, casos de uso e classes nas ilustrações anteriores:

Se um restaurante exclui um Item de Menu, enquanto um cliente estiver encomendando refeição, qualquer Item do pedido que se refere a esse Item de Menu será exibida em vermelho.

Os tópicos a seguir fornecem mais informações:

Mostrando o fluxo de trabalho entre usuários e o seu sistema.

Você pode usar um diagrama de atividade para mostrar o fluxo de trabalho entre casos de uso diferentes.É freqüentemente útil começar a um modelo de requisitos desenhando um diagrama de atividade, mostrando as principais tarefas que os usuários realizam - com o sistema e fora dele.

Por exemplo:

Você pode desenhar diagramas de caso de uso e diagramas de atividade para mostrar modos de exibição diferentes das mesmas informações.O diagrama de caso de uso é mais eficaz para mostrar o aninhamento das ações menores dentro da atividade maior, mas não mostra o fluxo de trabalho.Por exemplo:

Observe que você também pode usar diagramas de atividade para retratar algoritmos dentro de seu software, mas quando você usa os diagramas para o processo de negócios, você se concentre nas ações que são visíveis fora do sistema.

Os tópicos a seguir fornecem mais informações:

Mostrando interações entre usuários e seu sistema.

Você pode usar um diagrama de seqüência para mostrar o intercâmbio de mensagens entre o seu sistema e os atores externos ou partes de seu sistema.Isso fornece um modo de exibição das etapas em um caso de uso mostra claramente a seqüência de interações.Diagramas de seqüência são especialmente úteis, onde há a que interação de várias partes em um caso de uso, e também onde o seu sistema tem uma API.

Por exemplo:

Uma vantagem dos diagramas de seqüência é que ele é fácil ver quais mensagens chegam ao sistema que você constrói.Para projetar o sistema, você pode substituir a única linha de vida do sistema com uma linha de vida separada para cada um dos seus componentes e, em seguida, mostrar as interações entre eles em resposta a cada mensagem recebida.

Os tópicos a seguir fornecem mais informações:

Usando um modelo para reduzir as inconsistências

Criando um modelo geralmente resulta em uma redução significativa no inconsistências e ambigüidades nos requisitos dos usuários.Freqüentemente, os diferentes interessados tem entendimentos diferentes do mundo dos negócios em que o sistema funciona.Portanto, sua primeira tarefa é resolver essas diferenças entre seus clientes.

Você encontrará muitas perguntas sobre o domínio de negócios naturalmente surgem enquanto você estiver criando um modelo.Colocando essas perguntas para os usuários, você reduzirá a necessidade de alterações em um estágio posterior no projeto.Aqui estão algumas perguntas específicas que pergunte-se à primeira e pedir os acionistas da empresa se a resposta é clara:

• Para cada classe no modelo de requisitos, pergunte "caso de uso o que cria instâncias dessa classe"? Por exemplo, em um serviço on-line de ordenação refeição, você poderia perguntar: "caso de uso o que cria instâncias da classe Menu de restaurante?" Isso levaria a uma discussão de como um restaurante novo inscreveu no serviço e contribui com o seu menu.Você pode pedir perguntas semelhantes sobre o que cria ou altera atributos e associações.

• Para cada caso de uso do modelo de requisitos, tente descrever o resultado ou a pós-condição, de cada caso de uso em palavras fornecida pelos diagramas de classe.Ele é freqüentemente útil mostrar o efeito de um caso de uso delineando instâncias das classes antes e depois de uma ocorrência de caso de uso.Por exemplo, se a pós-condição de casos de uso diz "um item de menu é adicionado para o pedido do cliente", faça um rascunho instâncias das classes ordem e o Item de Menu.Mostre os efeitos do caso de uso, como, por exemplo, um novo link ou um novo objeto, em uma cor diferente ou em um novo desenho.Freqüentemente, isso leva a discussões sobre quais informações são necessárias no modelo.Embora as classes de requisitos diretamente não estão preocupadas com a implementação, eles descrevem as informações que seu sistema será necessário para armazenar e transmitir.

• Pergunte sobre as restrições em atributos e associações, especialmente as restrições que envolvem mais de um atributo ou uma associação.

• Pergunte sobre seqüências válidas e inválidas de casos de uso, diagramas de seqüência ou atividade para ilustrá-los de desenho.

Examinando as relações entre os modos de exibição que fornecem a diferentes diagramas, você pode rapidamente entender os conceitos principais com o qual seus usuários trabalham, e ajudá-los a entender o que precisam do sistema.Você também pode alcançar um melhor entendimento dos requisitos de que os interessados certeza menos sobre.Você pode planejar desenvolver esses recursos, pelo menos uma forma simplificada, nas primeiras fases do projeto, para permitir que usuários experimentá-los.

Consulte também

Conceitos

Como: Editar modelos e diagramas UML

O desenvolvimento de testes de um modelo

Usando modelos dentro do processo de desenvolvimento

A arquitetura de um sistema de Software de modelagem.

Outros recursos

Amostra a extensão do VS: Recursos de modelagem de domínio UML

extensão VS de exemplo: elementos UML de cor por estereótipo

extensão VS de exemplo: os elementos Link de UML para diagramas, arquivos e outros elementos

extensão VS de exemplo: Alinhar formas em um diagrama UML

vídeo: modelagem de domínio da empresa