Levantamento De Requisitos

Question

Como você ir sobre o levantamento de requisitos fase?Alguém tem um bom conjunto de orientações ou dicas a seguir?Quais são algumas boas perguntas a fazer os stakeholders?

Atualmente, estou trabalhando em um novo projeto, e há um monte de desconhecidos.Eu estou no processo de vir acima com uma lista de perguntas para as partes interessadas.No entanto, eu não posso ajudar, mas sentir o que eu estou faltando alguma coisa ou esquecendo de perguntar uma questão crítica.

Answer 1

Você está quase certamente falta algo.Um monte de coisas, provavelmente.Não se preocupe, é ok.Mesmo se você se lembrou de tudo e cobriu todas as bases de partes interessadas não vai ser capaz de dar-lhe muito boa, clara requisitos, sem qualquer ponto de referência.A melhor maneira de fazer esse tipo de coisa para conseguir o que você pode a partir de agora, em seguida, tomar e dar-lhes algo para reagir.Ele pode ser um protótipo em papel, uma maquete, a versão 0.1 do software, qualquer que seja.Em seguida, eles podem começar a contar-lhe o que eles realmente querem.

Answer 2

Ver obrigatória quadrinhos abaixo...

Em geral, eu tento começar uma sensação para o modelo de negócio do meu cliente está tentando emular com o aplicativo que deseja construído.Estamos construindo uma glorificado formas de processador?Estamos a obter dados a partir de várias fontes em um único aplicativo para poupar tempo?Estamos realizando algum tipo de integração?

Uma vez que o geral businesss modelo é estabelecido, em seguida, mover para o "deve" e "deve pobres" para o aplicativo para ditar quais os dados que eu possa recuperar, quem pode realizar o que funciona, etc.

Normalmente, se você pode receber o cliente a explicar o seu modelo ou fluxo de trabalho, você pode mover de lá e encontrar mais perguntas-chave.

A pergunta que eu sempre certifique-se de perguntar alguma forma ou de outra é "o Que é a mais complicada de/mais irritante coisa que você tem que fazer, quando fazer X.Normalmente a resposta para o que revela o mais louco de negócios/data regra terá de implementar.

Espero que isso ajude!

Answer 3

Steve Yegge fala diversão, mas há dinheiro para ser feito em trabalhar para fora o que as outras pessoas são os requisitos para que eu pegue o seu artigo com uma pitada de sal.

Levantamento de requisitos é incrivelmente difícil devido a forma em que a comunicação funciona.Um processo de quatro etapas que com perdas em cada etapa.

• Eu tenho uma idéia na minha cabeça
• Eu transformar isso em palavras e imagens
• Você interpretar as imagens e palavras
• Você pintar uma imagem em sua mente do que a minha ideia original era como

E os humanos falham miseravelmente em esta com preocupante frequência através de sua adorável imperfeições.

Ágil, faz direito na promoção do desenvolvimento iterativo.A obtenção de versões anteriores para o cliente é importante identificar quais são os recursos mais importantes (o que navios de 0,1 - 0,5 ish), ajuda a mantê-lo tanto no caminho certo em termos de como o aplicativo funciona e identifica rapidamente os recursos ocultos que você vai perder.

Os dois principais cenários de problema são as duas extremidades da escala:

• Não ter uma pálida idéia sobre o que você está fazendo - obter alguns especialistas de domínio
• Ter muitos requisitos - recurso poço.- Pergunta, abate (prioridade ;) ) características e uso iterativo de desenvolvimento

Yegge faz bem em apontar que os especialistas são essenciais para produzir bons requisitos, porque eles sabem o negócio e ter trabalhado nele.Eles podem ajudar a identificar o núcleo desejo do cliente e ajudar a explicar como a sua equipe irá utilizar o sistema e o que é importante para a equipe.Alternativas e adições incluem tentando fazer o trabalho sozinho para entrar no modo de pensar ou ter um cliente do membro da equipe, ocasionalmente, no local, embora este último é improvável que isso aconteça.

O recurso de poço é o outro lado, a maioria cheia de governo falhado de projetos de TI.Muito, muito em breve, não o suficiente pensamento ou aplicação de realismo (mas o que é que você espera que eles têm apenas cerca de quatro anos a fazer-se sentir importante?).O objetivo aqui é descobrir o que o cliente realmente deseja.Enquanto você trabalhar na obtenção de componentes principais correto, eficiente e livre de bugs clientes, geralmente, permanecem tolerante com a falta de recursos que chegam mais tarde embarques, enquanto eles finalmente chegam.Este é o lugar onde iterativo de desenvolvimento realmente ajuda.

Lembre-se de separar as ideias do cliente sobre o que o programa vai ser como e o que eles querem que o programa alcançar.Alguns clientes podem criar confusão ao comunicar as suas necessidades, a forma de aplicação de recursos que pode ser mal pensado ou despedidos por muito mais simples funcionalidade, em seguida, eles acham que eles exigem.Enquanto eu não estou a defender a chamar o cliente de um idiota ou não ouvi-los sinto que vale a pena sempre pedindo por eles querem uma funcionalidade específica para chegar ao seu objetivo subjacente.

Lembre-se de que em qualquer cenário é de imperativo importantance a raiz para fora o mais rápido caminho para o cumprimento de clientes núcleo necessário e colocam você em um cenário onde ambos estão a tirar proveito da relação.

Answer 4

Wow, por onde começar?

Primeiro, há um conjunto de conhecimentos alguém deve ter para fazer a análise em alguns projetos, mas realmente depende do que você está criando para que.Em outras palavras, isso faz uma grande diferença se você estiver modificando uma empresa de aplicação de uma Fortuna de 100 corporation, a construção de um aplicativo de iPhone, ou adicionar funcionalidades a uma página web pessoal.

Segundo, existem tipos diferentes de requisitos.

• Objectivos:O que o usuário quer realizar?
• Funcional:O que o usuário precisa fazer para alcançar seu objetivo?(acho etapas para atingir o objetivo/s)
• Não-funcionais:Quais são as limitações que seu programa precisa para funcionar dentro?(acho que 10 vs 10 usuários simultâneos, de crescimento, de back-up, etc.)
• Regras de negócio:Dinâmica restrições de fazer, você tem que cumprir?(acho cálculos, definições, questões legais, etc.)

Terceiro, a forma de levantamento dos requisitos de forma mais eficaz e, em seguida, obter feedback sobre eles (o que você vai fazer, certo?) é a utilização de modelos.Utilizador casos e histórias de usuário de um modelo de o que o usuário precisa fazer.Modelos de processo são de outra versão do que deve acontecer.Sistema de diagramas de são apenas mais um exemplo de como diferentes partes de um programa(s) de interagir.Boa modelagem de dados irá definir os conceitos de negócios e mostrar as entradas, as saídas e as alterações que ocorrem dentro de seu programa.Modelos (e há mais do que eu listados) são realmente a chave para o interesse da lista.Alguns bons modelos irá capturar as necessidades e a partir de modelos, você pode determinar seus requisitos.

Quarta, obter feedback.Eu sei que eu mencionei isso já, mas você não vai conseguir tudo certo na primeira vez, de modo a obter respostas para o que seu cliente quer.

Tanto quanto eu aprecio requisitos e os modelos que orientam, os usuários normalmente não compreende as consequências de todos os seus pedidos.A comunicação constante com chances para revisão e feedback dará aos usuários uma melhor compreensão do que você está entregando.Além disso, eles irão refinar seu entendimento com base no que eles vêem.A menos que você está trabalhando para o governo, iterações e / ou protótipos são úteis.

Answer 5

Primeiro de tudo reunir os requisitos antes de você iniciar a codificação.Você pode começar o design enquanto você estiver coletando-los, dependendo do seu ciclo de vida do projeto, mas você não deve nunca iniciar a codificação sem eles.

Os requisitos são um conjunto de documentos escritos que protegem o cliente e a si mesmo.Nunca se esqueça que.Se nenhum requisito está presente, então ele não foi pago (e, portanto, requer uma mudança formal de solicitação), se estiver presente, então ele deve ser implementado e deve funcionar corretamente.

Requisitos devem ser testáveis.Se um requisito não pode ser testado, então ele não é um requisito.Que significa algo como, "O sistema "

Requisitos devem ser concreto.O que significa afirmando que "A interface de usuário do sistema deve ser fácil de usar" não é correta a exigência.

A fim de, na verdade, "reunir" os requisitos que você precisa primeiro se certificar de que você entende o businness modelo.O cliente irá dizer-lhe o que eles querem com suas próprias palavras, é seu trabalho para compreendê-lo e interpretá-la no contexto certo.

Fazer reuniões com o cliente enquanto você estiver desenvolvendo os requisitos.Descrevê-los para o cliente com suas próprias palavras e certifique-se de que você e o cliente ter o mesmo conceito nos requisitos.

Requisitos exigem concisa, testável exemplo, mas mantenha o controle de todas as outras coisa que vem nas reuniões, diagramas, dúvidas e tente manter um registro de todas as reuniões.

Se você pode usar um backup incremental do ciclo de vida, que lhe dará a capacidade para melhorar o mau reunidos os requisitos.

Answer 6

Você nunca pode perguntar muitas ou "estúpido" perguntas.Quanto mais perguntas você pedir, o mais respostas que você recebe.

Answer 7

De acordo com Steve Yegge que o errado pergunta.Se você está recolhendo requisito é já demasiado tarde, seu projeto é condenado.

Answer 8

1. Alto nível de discussões sobre a finalidade, o escopo, limitações do ambiente operacional, tamanho, etc.

2. Audição em um único parágrafo de descrição do sistema martelo-lo

3. Mock-up de INTERFACE do usuário

4. Formalização de requisitos conhecidos

5. Agora iterar entre 3 e 4, com mais e mais protótipos funcionais e mais especificações, com mais detalhes.Escrever os testes que você vá.Fazer isso até que você tenha software funcional e completo, objetivo, requisitos testáveis spec.

Esse é o sonho.A realidade é, normalmente, depois de algumas iterações vai todo mundo de cabeça para baixo e os códigos até que há um mês para testar.

Answer 9

A Coleta De Requisitos De Negócio Besteira - Steve Yegge

Answer 10

• leia o manifesto ágil - software funcional é a única medida para o sucesso de um projeto de software
• familiarize-se com métodos ágeis de práticas - estudo de Scrum , programação lean , xp, etc. - isto irá poupar-lhe imenso tempo, não só para o levantamento de requisitos, mas também para o ciclo de desenvolvimento de software
• manter as discussões regulares com os Clientes e, especialmente, os futuros usuários e key-users
• certifique-se de falar para as Pessoas entender o domínio do problema - por exemplo,especialistas no campo
• Tomar pequenas notas durante as palestras
• Depois de cada CONVERSA escrever um oficial da lista de necessidades e apresentar, para aprovação.Mais tarde, ele iria ser difícil argumentar contra todos concordaram documentação
• certifique-se de que seus Clientes saibam, aproximadamente, quais são os aproximados de gastos em tempo e dinheiro para implementar "é bom ter" requisitos
• certifique-se de que você etiqueta os requisitos como "tem que ter" , "deve ter" e que "é bom ter" desde o início, garantir aos Clientes a compreender as diferenças entre esses tipos também
• integrar todos os documentos para a última e final de análise de requisitos (ou actual para a iteração ou o que seja ágil do ciclo de programação que você está usando ...)
• lembre-se de que os requisitos de mudança ao longo do ciclo de vida do software , de modo que a coleta é uma coisa, mas a gestão e a implementação de outro
• BEIJO - manter o mais simples possível
• o estudo também o ambiente onde o futuro sistema irá residir há mais e mais restrições tecnológicas do legado ou sistemas próximos , uma vez que as empresas não preferir jogar ao lixo o dinheiro que investiram por décadas, mesmo se no nosso moderno mentes 20 anos de código é um lixo ...

Answer 11

Como a maioria das fases do processo de desenvolvimento de software de sua iteração funciona melhor.

Primeiro descubra o que seus usuários estão -- o departamento XYZ,

Em seguida, descobrir onde eles se encaixam na organização -- parte do Z divisão,

Em seguida, descobrir o que eles fazem em termos gerais -- gerir fluxos de caixa

Em seguida, em termos específicos -- recolher dinheiro das caixas registadoras, e verificar até fraudes.

Em seguida, você pode começar a conversar com elas.

Pergunte qual é o problema que eles querem que você deseja resolver-você vai obter uma resposta como escrever um bamboozling sistema usando OCR com tubarão technoligies.

Ignorar que responder e perguntar mais algumas perguntas para descobrir qual é o real problema é que-eles não podem ler o que até desliza para reconciliar o dinheiro.

Acordar uma solução real com os usuários-obter uma melhor fita de tinta de fornecedor, ou se conectar a caixas registadoras electrónicas para a rede e enviar os logs para um servidor central.

Em seguida, concorda em detalhes como eles irão medir o sucesso do projeto.

Então, e somente então, propor e concordar com um conjunto detalhado de requisitos.

Answer 12

Gostaria de sugerir que você leia Roger-Pressman do Engenharia De Software:Um Praticante da Abordagem

Answer 13

Antes de ir falando para os interessados/usuários/qualquer um pode ser a certeza de que você vai ser capaz de colocar as informações coletadas em um útil e dias-de forma permanente.

• Usar um som gravador, se ele está OK com a outra pessoa e a informação é volumoso.
• Se você ouviu algo importante e você precisa de algum tempo razoável para escrevê-la, você tem duas opções:peça a outra pessoa para esperar um segundo, ou dizer adeus a essa preciosa informação.Você não vai se lembrar direito, pergunte a qualquer um neuro-cientista.
• Se você detectar que um ponto precisa de uma revisão mais profunda ou que você precisa de algum documento que você acabou de ouvido, certifique-se de que você faça um compromisso com a outra pessoa para enviar esse documento ou marcar outra reunião com uma finalidade específica.Nunca diga "eu vou me lembrar de pedir para que o arquivo xls", porque na maioria dos casos, você não vai.
• Não muito tempo depois da reunião, resumir todas as suas anotações, gravações e pensamentos frescos.Apenas resumir-lo direito.Criar eficaz lembretes para os compromissos.
• Novamente, logo após a reunião, é o momento perfeito para entender por que a reunião que você acabou de fazer foi não tão certo como você pensou no final da reunião.Que é quando você vai ser capaz de colocar um monte de significativa perguntas para outra reunião.

Eu sei que a pergunta foi a perspectiva do pré-encontro, mas por favor, esteja ciente de que você pode trabalhar sobre esta matéria antes da reunião e acabar com uma muito útil, completa e de qualidade de coleta.

Answer 14

Eu tenho usado mapas mentais como uma estrutura de divisão de trabalho) para o ajudar a reunir os requisitos e definir as incógnitas (a #1 projeto killer).Começar em alto nível, e trabalhar sua maneira para baixo.Você precisa trabalhar com os patrocinadores, usuários e equipe de desenvolvimento para garantir que você obtenha todos os ângulos e não perca nada.Você pode não ser o esperado para conhecer todo o alcance do que eles querem, sem a sua participação...você - como um gerente de projeto/BA - a necessidade de envolvê-los (parte mais importante do trabalho).

Answer 15

Há algumas grandes ideias aqui já.Aqui estão algumas levantamento de requisitos de princípios que gosto de ter sempre em mente:

Saber a diferença entre o usuário e o cliente. Os donos de empresas que aprovar o brilhante projeto, normalmente, são os clientes.No entanto, um terrível engano é a tendência de confundi-los, como o usuário.O cliente normalmente é a pessoa que reconhece a necessidade de seu produto, mas o usuário é a pessoa que vai realmente utilizar a solução (e provavelmente irá queixar-se, mais tarde, sobre a exigência de o produto não atender).Ir para mais de uma pessoa

Porque nós somos humanos, e temos a tendência de não lembrar de todos os mínimos detalhes.Você aumenta a sua probabilidade de encontrar perdeu requisitos como você falar para mais pessoas e verificação cruzada.

Evitar especiais Quando um usuário solicita algo muito específico, desconfie.Questionar sempre as tendências e ver se isso realmente vai fazer o seu produto melhor.

Protótipo Não espere até o lançamento de mostrar o que você tem para o usuário.Frequente protótipos (você pode até chamá-los de versões beta) e obter feedback constante ao longo de todo o processo de desenvolvimento.Você provavelmente vai encontrar mais de requisitos como você fazer isso.

Answer 16

Eu recentemente comecei a usar os conceitos, padrões e modelos definidos pelo Instituto internacional de Analistas de Negócios organizaçãoIIBA).

Eles têm um bom BOK (Livro do Conhecimento) que pode ser baixado de seu site.Eles também têm um certificado.

Answer 17

Engenharia de requisitos é um pouco de uma arte, existem várias maneiras de ir sobre ele, você realmente tem que se adaptar ao seu projeto e as partes interessadas.Um bom lugar para começar é com a Engenharia de Requisitos por Karl Wiegers:

http://www.amazon.com/Software-Requirements-Second-Pro-Best-Practices/dp/0735618798/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1234910330&sr=8-2

e um processo de engenharia de requisitos, que pode consistir de um número de passos por exemplo:

• Elicitação - a base para a discussão com o negócio
• Análise e Descrição - uma descrição técnica o objetivo dos desenvolvedores
• Elaboração, de Esclarecimento, de Verificação e de Negociação - refinamento dos requisitos

Além disso, há um número de maneiras de documentar os requisitos (Casos de Uso, Protótipos, Especificações, Modelação de linguagem).Cada um tem suas vantagens e desvantagens.Por exemplo protótipos são muito bons para o surgimento de ideias de negócio e de debate de ideias.

Eu geralmente achar que escrever um conjunto de casos de uso e incluindo wireframes protótipos funciona bem para identificar um conjunto inicial de requisitos.A partir de que ponto é um processo contínuo de trabalho com técnicos e pessoas de negócios de clarificar e elaborar os requisitos.Manter o controle do que foi inicialmente acordado e rastreamento de requisitos adicionais são essenciais para evitar o aumento do escopo.Negociação joga um pouco parte aqui também entre as diversas partes, como por Quebrada de Ferro Triângulo (http://www.ambysoft.com/essays/brokenTriangle.html).

Answer 18

IMO o mais importante primeiro passo é definir um dictornary de domínio-específico palavras.Quando o cliente diz "ordem", o que ele quer dizer?Algo que ele recebe de seus clientes ou de algo que ele envia a seus fornecedores?Ou talvez ambos?

Encontrar as palavras-chave partes interessadas negócio, e deixar-lhes que expliquem essas palavras, até que compreendam o seu significado no processo.Sem isso, você terá um tempo difícil tentando entender os requisitos.

Answer 19

eu escrevi um artigo no blog sobre a abordagem que eu uso:

http://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html

basicamente:perguntas a fazer ao seu cliente antes de criar seu website.

eu deveria adicionar este questionário, a folha está apenas voltada para basic site constrói - se como um negócio de presença na web.história totalmente diferente se você estiver falando de software baseado na web.apesar de alguns ainda é relavant (e.g.questões relativas olhar e sentir).

• LM

Answer 20

Eu prefiro manter a minha levantamento de requisitos processo tão simples, direta e minuciosa quanto possível.Você pode fazer download de um documento de exemplo que eu uso como um modelo para os meus projetos nesta postagem do blog: http://allthingscs.blogspot.com/2011/03/documenting-software-architectural.html