Requisitos do usuário de modelagem.

Microsoft Visual Studio Ultimateajuda você a compreender, discutir e comunicarem a seus usuários precisam desenhando diagramas sobre suas atividades e a parte de que seu sistema desempenha no ajudando-los atingir suas metas. Um modelo de requisitos é um conjunto desses diagramas, cada um deles se concentra em um aspecto diferente dos usuários precisa.

Um modelo de requisitos ajuda você a:

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

• Descrever os usuários e dos participantes. precisa com muito menos ambigüidade que em linguagem natural.

• Defina um consistente Glossário de termos que pode ser usado 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 se muito mais simplificado, geralmente baseia mais interessantes para discussão sobre os requisitos de usuários. O modelo é uma maneira eficaz de 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 em um único aplicativo; ou um componente de software dentro de um sistema maior. Em cada caso, o modelo de requisitos descreve o comportamento é visto de fora do seu sistema, através de uma interface de usuário ou uma API.

Tarefas comuns

Você pode criar vários modos de exibição diferentes, os usuários requisitos. Cada modo de exibição fornece um tipo específico de informação. Quando você cria esses modos de exibição, é melhor mover-se freqüentemente de um para outro. 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 O desenvolvimento de modelos de Design de Software. Para obter informações básicas sobre como desenhar diagramas, consulte Como: Editar um modelo UML e diagramas.

Descrever como o seu sistema é usado

Crie diagramas de caso de uso para descrever quem usa o sistema e o que eles usam 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 de menores. Por exemplo, a ordenação refeição é parte de comprar uma refeição, que também inclui a entrega e pagamento:

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, os 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 nas versões sucessivas. Por exemplo, você pode discutir se, na primeira versão do sistema, o pagamento para refeição é 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 outros diagramas. Para saber como fazer isso, consulte Como: Vincular a um caso de uso para documentos e diagramas.

Um diagrama de caso de uso de desenho ajuda 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 de negócios usados para as seguintes finalidades:

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

• Descrever os usuários precisa, 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ê poderia desenhar essas classes conceituais para o sistema de 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 um ordeme, em seguida, cria Itens em ordem na ordem selecionando Itens de Menu do Menu.

Observe como os termos usados na descrição do que 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 usuários requisitos freqüentemente podem ser rastreados para os 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 fica 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 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, desempenho, distribuição, flexibilidade e outros fatores. Várias implementações diferentes de uma classe conceitual freqüentemente são encontradas 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 diferentes maneiras, como, por exemplo, referências dentro do código de C#, as relações no banco de dados, ou referência cruzada para IDs em XML. Mas Apesar dessas variações, o modelo conceitual fornece informações importantes que é verdadeiras para cada parte do software. No exemplo de diagrama de classe nos informa que em cada implementação, haverá apenas um que menu associado a cada pedido.

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

• Definir e padronizar os termos básicos usados em discussões sobre os usuários precisa.

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

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

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ático as 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 de atividade para mostrar que um usuário deve efetuar logon antes de executar outras operações no seu sistema.

No entanto, muitas regras dinâmicas podem ser mais eficiente e genericamente declaradas substituindo-os por regras estáticas. Por exemplo, você pode adicionar um atributo booleano 'Registrados no' para uma classe no modelo conceitual de classe. 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 evitar 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 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 dos requisitos de serviço

Há várias categorias de qualidade da requisição 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í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 dos 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 os casos de uso diferentes. É freqüentemente útil iniciar 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 os 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 de 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 as 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 é o que é fácil ver quais mensagens chegam ao sistema que você está construindo. Para projetar o sistema, pode substituir a única linha de vida do sistema com uma linha de vida separada para cada um de 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 em que os usuários requisitos. Freqüentemente, os diferentes interessados tem entendimentos diferentes do mundo dos negócios em que o sistema funciona. Portanto, sua primeira tarefa é resolver as 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 primeiro e solicite os acionistas da empresa se a resposta é clara:

• Para cada classe no modelo de requisitos, pergunte "O caso de uso cria instâncias dessa classe"? Por exemplo, em um serviço on-line de pedidos de refeição, você poderia perguntar: "O caso de uso cria instâncias da classe Menu 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 os 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 de palavras fornecida pelo 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 casos de uso diz "um item de menu é adicionado para o pedido do cliente" esboçar instâncias das classes de 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 o sistema precisará armazenar e transmitir.

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

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

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, em uma etapa inicial do projeto, para permitir que usuários experimentá-los.

Consulte também

Conceitos

Como: Editar um modelo UML e diagramas

O desenvolvimento de testes de um modelo

Usando modelos dentro do processo de desenvolvimento

A arquitetura de um sistema de Software de modelagem.