Este artigo foi traduzido por máquina. Coloque o ponteiro do mouse sobre as frases do artigo para ver o texto original. Mais informações.
Tradução
Original

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 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.

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.

Diagrama ou documento

Ele descreve em um modelo de requisitos

Section

Diagrama de caso de uso

Quem usa o sistema e o que fazer com ele.

Descrever como o seu sistema é usado

Diagrama de classes conceitual

Glossário de tipos que são usados para descrever os requisitos; os tipos visíveis na interface do sistema.

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

Diagrama de atividade

Fluxo de trabalho e de informações entre as atividades realizadas pelo sistema ou usuários e suas partes.

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

Diagrama de seqüência

Seqüência de interações entre usuários e o sistema ou suas partes. Um modo de exibição alternativo para o diagrama de atividade.

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

Outros documentos ou itens de trabalho

Critérios de desempenho, segurança, usabilidade e confiabilidade.

Descrevendo a qualidade de requisitos de serviço

Outros documentos ou itens de trabalho

Restrições e regras não específicas a um determinado caso de uso

Mostrando as regras de negócios

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.

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:

Casos de uso para o cliente e restaurante

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:

O sistema participa do pagamento, mas não entrega.

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:

Para saber mais sobre

READ

Casos de uso de informações mais detalhadas sobre como criar

Diagramas de caso de uso UML: diretrizes

Elementos em um diagrama de caso de uso

Diagramas de caso de uso UML: referência

Como desenvolver o código de casos de uso

A arquitetura de um sistema de Software de modelagem.

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:

Menu de classes, ordem, Item de Menu, Item do pedido.

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:

Para saber mais sobre

READ

Informações mais detalhadas sobre a localização de classes de requisitos

Diagramas de classe UML: diretrizes

Elementos em um diagrama conceitual de classe

Diagramas de classe UML: referência

Como desenvolver o código das classes conceituais

A arquitetura de um sistema de Software de modelagem.

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.

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:

Regra em comentário anexado à classe Order.

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:

Para saber mais sobre

READ

Informações mais detalhadas sobre a localização e a gravação de regras de negócios estático

Diagramas de classe UML: diretrizes

Elementos em um diagrama conceitual de classe

Diagramas de classe UML: referência

Como desenvolver código que está sujeito às regras de negócios

A arquitetura de um sistema de Software de modelagem.

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:

Para saber mais sobre

READ

Informações mais detalhadas sobre a qualidade de requisitos de serviço da gravação

Guidelines for Defining Quality of Service Requirements

Anexando documentos adicionais para casos de uso

Como: vincular um caso de uso para documentos e diagramas

Como desenvolver código que segue a qualidade de requisitos de serviço

A arquitetura de um sistema de Software de modelagem.

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:

Atividade com três ações e um loop.

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:

Casos de uso para ações anteriores

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:

Para saber mais sobre

READ

Obter mais informações sobre como definir fluxos de trabalho de negócios

Diagramas de atividade UML: diretrizes

Elementos em um diagrama de atividade

Diagramas de atividade UML: referência

Como desenvolver código em diagramas de atividade

A arquitetura de um sistema de Software de modelagem.

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:

Diagrama de seqüência com o sistema e atores.

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:

Para saber mais sobre

READ

Obter mais informações sobre como definir as interações

Diagramas de seqüência UML: diretrizes

Elementos em um diagrama de seqüência

Diagramas de seqüência UML: referência

Como desenvolver o código de diagramas de seqüência

A arquitetura de um sistema de Software de modelagem.

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.

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários

Contribuições da comunidade

ADICIONAR
Mostrar:
© 2015 Microsoft