Conteúdos - Página: 364 - Colaborar Portfólios

Modelo de uso: permite que você explore como os usuários trabalharão com seu sistema. Pode ser uma coleção de casos de uso essenciais ou uma coleção de histórias de usuário;

A documentação pode vir mais tarde, se você realmente precisar dela. Para seu modelo de requisitos inicial, minha experiência é que você precisa de alguma forma de:

Seu objetivo é ter uma ideia do que é o projeto, não documentar em detalhes a operacionalidade do sistema.

Casos de Uso No início de um projeto, você precisa de vários dias para elicitar e, por que não, prever os requisitos de alto nível e entender o escopo, nesse caso, é o que você acha que o sistema deve fazer.

Por estar no contexto do wireframe (próxima seção), é mais conciso. Você pode simplesmente fazer referência ao nome do campo, em vez de declarar detalhadamente tudo sobre o campo. Você pode manter os detalhes no comprimento do campo, obrigatório etc.

Detalhamento dos Requisitos Esses são os detalhes do recurso. Documente todas as telas e todos os campos, rótulos, validações, mensagens e ações. Esta é essencialmente a especificação funcional dos detalhes da(s) tela(s) envolvida(s).

Segue uma lista de alguns para você usar na construção de sua aplicação. Eles ajudarão a explicar o sistema através de fluxos e vão apoiar no desenvolvimento. Suas versões demo vão permitir que você utilize pelo tempo desse desafio, tranquilamente, portanto, não “durma no ponto”. São todos amigáveis e não precisam de curso para usar. Use e abuse:

Aqui, uma imagem vale mais que mil palavras, pois os detalhes do fluxo através do recurso podem ser bastante complexos, e é difícil explicar os detalhes na próxima seção (aqui, visão é tudo, me desculpem os sinestésicos e auditivos).

Os estados de erro (incluindo as telas de mensagem de erros) e as alterações de visualização com base na função devem ser documentados.

Fluxo de Trabalho Isso deve incluir uma imagem das telas envolvidas (você fará isso na IHC e no protótipo das telas; riqueza de detalhes é fundamental).

Por favor, pense como um profissional, e você vai pensar, “mas sou aluno”, sim todos nós somos alunos, incluindo o autor desse material, mas atitude é tudo e é isso que queremos de você. Atitude positiva e construtiva!

Entendeu o que esperamos de você. Dezenas de cartões de história do usuário completos, claros, concisos, especificando a ação e o que se espera, incluindo para que serve.

Olhe só: Histórias de Usuários Indica todos os cenários dos usuários envolvidos. O padrão mundial disso é: Como ALGUM PAPEL, EU QUERO FAZER ALGUMA COISA, PARA QUE POSSA OBTER ALGUNS BENEFÍCIOS.

Daí fica realmente difícil construir algo se nem entendemos o português que está escrito, não é mesmo?! Cada seção de análise traz muito para a mesa e muitas vezes são julgadas como uma "perda de tempo", porém, quando vamos codificar, fazem toda a diferença.

Sem nenhuma das seções mencionadas, os requisitos começam a perder valor e sentido. Muitas vezes, quando sou chamado para dar consultoria, vejo times ágeis e especificações de sistemas como um “punhado de gente bem-intencionada que não consegue escrever ou muitas vezes ler o livro que ganharam”.

E nesse caso você vai possuir múltiplos “chapéus”; ora será analista de negócios, ora desenvolvedor, ora etc. Bons requisitos precisam de: Histórias de usuários; Testes de Aceitação do Usuário; Fluxo de Trabalho; Detalhes dos Requisitos; Wireframes.

Um bom requisito deve dizer a cada membro do público exatamente qual é a funcionalidade esperada e nunca gerar uma miríade de perguntas de todos os envolvidos. Frequentemente, é difícil solicitar informações a um cliente, mas documentar para desenvolvedores nunca deve ser tão difícil.

Então respire fundo e se prepare para pensar e analisar muito em profundidade, pois analistas de sistemas criados no raso jamais enfrentaram grandes tempestades e ondas avassaladoras, acredite. Aqui serão apresentadas dicas preciosas para você desenvolver seu trabalho com menos incerteza, vindas de um “velho marujo”.

Claro que faltava, também creio eu, a todas essas pessoas, se apropriarem de verdade do conhecimento e dos processos do negócio. Minha sorte foi que, o tempo e a dedicação sempre trazem frutos, para o bem ou para o mal. No meu caso, foi para o bem!

Eu olhava para os “requisitos” e eles não eram nada mais do que um quadro com uma infinidade de notas e postites. Eu era desenvolvedor e tinha muitas dúvidas e, em geral, todas as pessoas envolvidas, clientes, usuários, desenvolvedores, analistas de negócios, arquitetos de solução e inclusive os testadores, não têm um bom entendimento do sistema como um todo e quais são as várias personas que usam o sistema.

Requisitos Ágeis Primeiramente, algumas constatações. Muitas vezes, no início de minha carreira vi projetos com dificuldades porque seus requisitos eram mal elaborados, muitas vezes sem sentido, e eu me sentia um completo inútil.

Com certeza, é bastante estranho pedir por algo dessa natureza a quem está tentando entrar, ou desenvolver, uma carreira. Porém, com esses desafios você tem a oportunidade de mostrar que desenvolveu seu aprendizado e que está pronto para qualquer desafio de seleção de pessoas para concorrer de igual para igual com qualquer outro candidato.

Você também encontrará leituras e material complementares que, sinceramente te alerto, serão essenciais no aprofundamento e desenvolvimento desse desafio. Muitas pessoas e discentes comentam que muitos RH de empresas pedem experiência aos candidatos.

Introdução A ideia do desenvolvimento deste conteúdo didático é fazer com que você possa se recordar do que você já aprendeu de forma a mantê-lo(a) focado no desafio e ter praticamente tudo do precisa para desenvolvê-lo num lugar só.

Para resolver a Situação-Problema 3, utilize ferramentas da qualidade, como o diagrama de Ishikawa, para identificar os principais problemas e sugerir possíveis soluções. Proponha soluções para o problema de quebra de máquina também.

Para resolver a Situação-Problema 2, elabore um fluxograma para o processo da Croqui, analise as etapas do processo e, se houver oportunidades de otimizá-lo e torná-lo mais eficiente, faça as sugestões de implantação de melhorias. Por exemplo, é possível sugerir inclusão de tecnologias para otimizar o processo? É possível reduzir alguma etapa do processo?

Pesquise o setor têxtil no Google e anote o que as empresas desse setor fazem. Após isso, inclua a sua perspectiva em uma matriz de importância-desempenho. Nesse caso, é interessante a Croqui permanecer com as prioridades competitivas ou não?

Problema em Foco Para resolver a Situação-Problema 1, identifique as prioridades competitivas da empresa e aconselhe a organização a permanecer ou alterar a prioridade, conforme sua pesquisa de mercado.

Situação-Problema 3 Suponha que você seja contratado pela Croqui para resolver as principais reclamações dos clientes. Quais medidas você sugere para a empresa?

Situação-Problema 2 Faça a análise do processo dessa empresa e identifique oportunidades de melhoria do processo.

« Anterior 1 … 362 363 364 365 366 … 476 Próximo »