Como para definir os requisitos através de Análise de Negócios
Necessidades e exigências podem parecer que eles significam a mesma coisa, mas há uma diferença quando se trata de análise de negócios: A necessidade é o objetivo, eo requerimento é a decisão sobre se a fazer alguma coisa para atingir aquele objectivo. A necessidade se transforma em um requisito quando alguém reconhece que ter a necessidade não atendida é inaceitável e decide que ele requer a necessidade de ser cumpridos.
Requisitos, quando identificado pela primeira vez, são realmente necessidades, desejos, sugestões ou idéias - até que a pessoa certa decida em contrário. Frequentemente, necessidades, desejos, sugestões e idéias são apresentadas como declarações de requisitos sem pensar do provedor sobre as necessidades, restrições, ou implicações dessa decisão, às vezes, ele é nem mesmo na posição de decidir como ou por que a exigência é adequada ou necessária .
As decisões são tomadas por alguém por um motivo. Capturar e observar que alguém faz que as decisões sobre os requisitos específicos, e quando.
Como você provavelmente já percebeu, a palavra requerimento é um termo muito vago no mundo da análise de negócios. Como resultado, a definição oficial de um requisito listados no Guia do BABOK (conforme especificado pelo IIBA - Instituto Internacional de Análise de Negócios) a seguir:
Nº 147-A condição ou capacidade necessária por uma das partes interessadas para resolver um problema ou atingir um objetivo. # 148- Este ponto reflecte o necessário no negócio de tomada de decisão crucial.
Nº 147-A condição ou uma capacidade que deve ser cumprida ou possuído por um componente da solução ou solução para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos. # 148 Esta parte muda o foco da parte interessada à solução.
Nº 147-A representação documentado de uma condição ou capacidade como em 1 ou 2. # 148- Esta ideia observa que a documentação sobre os requisitos é também chamado de uma exigência. Isso porque a documentação ajuda os analistas, as diferentes partes interessadas, ou consumidores de documentação (As pessoas ler e interpretar a documentação) entender os requisitos para a solução, juntamente com quaisquer componentes eles são responsáveis pela criação.
Porque criadores dos componentes da solução deve aderir às exigências durante o desenvolvimento, a própria documentação torna-se uma exigência.
Requisitos caem em diferentes categorias, em camadas. As categorias principais incluem requisitos de negócios, requisitos das partes interessadas, requisitos da solução, requisitos de transição e requisitos de tecnologia. requisitos da solução incluem requisitos funcionais e não funcionais criadas à mão ou com a tecnologia (que tem seus próprios requisitos técnicos). E quando completa, as soluções são postas em prática por meio de requisitos de transição.
Indo direto de um requisito de negócio diretamente a uma exigência técnica detalhada não é possível. Você deve cascata através de cada camada ou nível de análise conforme o caso, catalogação e categorização que você vá.
Você e sua equipe não são apenas supostamente para projetar qualquer solução no final de tudo isso em cascata através da níveis-você deveria usar os requisitos para projetar um successfulsolution. Você deve investigar profundamente o suficiente para desencadear todo o Requisitos- necessário caso contrário, você pode perder alguns requisitos.
Você pode reutilizar requisitos documentados (e necessidades, para que o assunto) nos níveis de negócios e das partes interessadas (e às vezes a solução)! requisitos reutilizados pode salvar as equipes de projeto e as partes interessadas tempo e dinheiro. Você deve organizar e guardar as suas necessidades de seus projetos (talvez em um repositório corporativo ou centralizada lugar requisitos de referência) no caso de você querer usá-los novamente em outro projeto.
Requisitos que antes eram ser requisitos (para o futuro ambiente de negócios) pode se tornar seu como é requisitos (para o atual ambiente de negócios) e fornecer um novo ponto de partida para o próximo projeto.
Apenas um requisito ausente pode causar problemas com as partes interessadas e membros da equipe e também pode afetar a solução (s) que você constrói. A solução pode estar faltando ou onerosos, criar qualidade ou de apoio preocupações constantes, sofrem buggy ou interfaces de falha, coloque sistemas a jusante em perigo, e resultar em sistemas que são (mais) difícil de apoio, fazendo com que o manual soluções alternativas ou processos adicionais.
Esses desafios podem ferir a satisfação do usuário e do cliente e resultados de negócios, o que pode resultar na diminuição de vendas e um impacto de receita.