Requisitos de Software

Engenharia requisito

O processo de coleta dos requisitos de software do cliente, analisar e documentar-los é conhecido como requisito engenharia.

O objetivo da exigência é engenharia para desenvolver e manter sofisticados e "Requisitos de sistema descritivo Especificação" documento.

Processo de engenharia requisito

Trata-se de um processo de quatro etapas, que inclui -

Estudo de Viabilidade
Recolhimento de exigência
Especificação dos Requisitos Software
Requisito de Software Validação

Vamos ver o processo resumidamente -

Estudo de Viabilidade

Quando o cliente se aproxima da organização para obter o produto desejado desenvolvido, ele vem para cima com ideia aproximada sobre o que todas as funções que o software deve executar e que todos os recursos são esperados a partir do software.

A referenciação para esta informação, os analistas faz um estudo detalhado sobre a questão de saber se o sistema desejado e suas funcionalidades são viáveis para desenvolver.

O estudo de viabilidade está focada para a baliza da organização. Este estudo analisa se o produto de software pode ser praticamente se materializou em termos de execução, a contribuição do projeto para a organização, restrições de custo e conforme os valores e os objectivos da organização. Ele explora os aspectos técnicos do projeto e produto, tais como usabilidade, manutenibilidade, produtividade e capacidade de integração.

A saída desta fase deve ser a realização de um estudo de viabilidade que deve conter observações e recomendações para a gestão sobre a existência ou não do projeto deve ser realizada.

Recolhimento de exigência

Se o relatório de viabilidade é favorável à realização do projecto, fase seguinte começa com coleta de requisitos do usuário. Os analistas e engenheiros se comunicar com o cliente e os usuários finais para saber as suas ideias sobre o que o software deve fornecer e quais as funcionalidades que deseja que o software para incluir.

Especificação dos Requisitos Software

O SRS é um documento criado pelo sistema analista depois que os requisitos são recolhidos a partir de várias partes interessadas.

SRS define a forma como o software irá interagir com o hardware, interfaces externas, a velocidade de operação, tempo de resposta do sistema, a portabilidade de software através de várias plataformas, manutenibilidade, velocidade de recuperação após falhas, Segurança, Qualidade, limitações etc.

Os requisitos do cliente são escritos em linguagem natural. É da responsabilidade do analista de sistema documentar os requisitos em linguagem técnica, para que possam ser compreendidos e útil pela equipe de desenvolvimento de software.

SRS deve vir para cima com as seguintes características:

Os requisitos são expressos em linguagem natural.
Requisitos técnicos são expressos em linguagem estruturada, que é usado dentro da organização.
Descrição do projeto deve ser escrito no Pseudo-código.
Formato dos formulários e GUI impressões de tela.
Condicional e notações matemáticas DFDs etc.

Requisito de Software Validação

Após especificações são desenvolvidos, os requisitos mencionados neste documento são validados. Pode ser que o usuário pedir para ilegais, solução impraticável ou peritos podem interpretar os requisitos incorretamente. Isso resulta em enorme aumento no custo, se não morta à nascença. Os requisitos podem ser verificados em relação aos seguintes condições -

Se eles podem ser implementadas na prática
Se eles são válidos e, por funcionalidade e o domínio do software
Se não há qualquer ambiguidade
Se estiverem completos
Se eles podem ser demonstradas

Processo elicitação requisito

Processo elicitação requisito pode ser representado usando o folloiwng diagrama:

Coleta de requisitos - os programadores discutir com o cliente e os usuários finais e conhecer suas expectativas através do software.
Organizar os requisitos - Os desenvolvedores priorizar e organizar os requisitos em ordem de importância, urgência e conveniência.
Negociação e discussão - se os requisitos são ambíguos ou existem alguns conflitos nos requisitos de diversas partes interessadas, se eles são, em seguida, é negociado e discutido com os interessados. Requisitos podem então ser priorizados e razoavelmente comprometida.

As exigências provenientes das diversas partes interessadas. Para remover a ambigüidade e os conflitos, eles são discutidos para maior clareza e exatidão. Exigências irrealistas são comprometidos razoavelmente.
Documentação - todas as ocasiões formais e informais, funcionais e não-funcionais os requisitos estão documentados e disponibilizados para a fase seguinte.

Requisito técnicas Indu

Requisitos elicitação é o processo para saber quais são os requisitos de um sistema de software através da comunicação com o cliente, os usuários finais, os usuários do sistema e outros que têm uma participação no desenvolvimento do sistema de software.

Há várias maneiras de descobrir necessidades

Entrevistas

As entrevistas são fortes médias para coletar os requisitos. Organização pode realizar vários tipos de entrevistas, tais como:

Estruturado (fechado) entrevistas, onde cada informação a recolher é decidido com antecedência, eles seguem padrão e tema de discussão com firmeza.
Não-estruturados (aberto) entrevistas, onde a informação a recolher não é decidido com antecedência, mais flexível e menos preconceituosos.
Entrevistas orais
Entrevistas escritas
Uma-a-uma as entrevistas que são realizadas entre duas pessoas em toda a tabela.
Entrevistas de Grupo que são realizadas entre os grupos de participantes. Elas ajudam a descobrir qualquer ausente requisito, tal como muitas pessoas estão envolvidas.

Pesquisas

Organização poderá realizar pesquisas entre as várias partes interessadas, consultando sobre suas expectativas e exigências do próximo sistema.

Questionários

Um documento com pré-definidos de perguntas objetivas e respectivas opções é entregue a todas as partes interessadas para resposta, que são recolhidos e compilados.

Uma lacuna de esta técnica é, se uma opção para alguns problema não é mencionado no questionário, o problema pode ser deixado sozinho.

Análise de Tarefas

Equipe de engenheiros e programadores podem analisar a operação para que o novo sistema é necessário. Se o cliente já possui algum software para executar determinada operação, ele é estudado e requisitos do sistema proposto são coletados.

Análise do Domínio

Cada software cai em algum domínio categoria. Os especialistas do domínio pode ser uma grande ajuda para analisar requisitos gerais e específicos.

O "brainstorm"

Um debate informal é realizada entre as várias partes interessadas e todas as suas entradas são gravados para posterior análise de requisitos.

Prototipagem

Prototipagem é o prédio user interface sem adicionar detalhes funcionalidade para o usuário a interpretar as características de produto de software. Ele ajuda a dar uma melhor ideia das necessidades. Se não houver nenhum software instalado no cliente final a referência para o desenvolvedor e o cliente não está ciente de suas próprias necessidades, o desenvolvedor cria um protótipo com base nos requisitos mencionados inicialmente. O protótipo é apresentado ao cliente e o feedback é observado. O feedback do cliente serve como entrada para o requisito encontro.

Observação

Equipe de especialistas visita o cliente organização ou local de trabalho. Eles observam o trabalho real dos actuais sistemas instalados. Eles observam o fluxo no cliente final e como problemas de execução são tratados. A própria equipe tira algumas conclusões que ajuda a formar os requisitos esperados do software.

Características Requisitos de Software

Reunir requisitos de software é a base de todo o desenvolvimento de software projeto. Portanto, eles devem ser claras, corretas e bem-definido.

Um Software completo Especificações de requisitos deve ser:

Claro
Corrigir
Consistente
Coerente
Compreensível
Modificável
Verificáveis
Priorizados
Inequívoca
Rastreável
Fonte credível

Requisitos de Software

Devemos tentar compreender que tipo de requisitos podem surgir no requisito fase de indução e quais são os tipos de requisitos são esperados a partir do sistema de software.

Os requisitos de software em geral devem ser classificados em duas categorias:

Requisitos Funcionais

Os requisitos, os quais são relacionados ao aspecto funcional do software se enquadram nesta categoria.

Eles definem funções e funcionalidades dentro e a partir do sistema de software.

Exemplos -

Opção de pesquisa dado ao usuário a pesquisa de várias facturas.
Usuário deve ser capaz de email qualquer relatório de gestão.
Os usuários podem ser divididos em grupos e os grupos podem ser dadas direitos distintos.
Devem obedecer as regras de negócio e funções administrativas.
Software é desenvolvido mantendo compatibilidade descendente intacta.

Requisitos não-funcionais

Os requisitos, o que não estão relacionados ao aspecto funcional do software, se enquadram nesta categoria. Eles estão implícitos ou esperar as características do software, que permite aos utilizadores fazer suposição.

Requisitos não-funcionais -

Segurança
Efetuar login
Armazenamento
Configuração
Desempenho
Custo
Interoperabilidade
Flexibilidade
Recuperação de Desastres
Acessibilidade

Os requisitos são divididos logicamente como

Deve ter : o Software não pode ser dito sem eles.
Deve ter: aumentar a funcionalidade do software.
Poderia ter : o Software ainda pode funcionar adequadamente com esses requisitos.
Lista de Desejos: Esses requisitos não mapa de quaisquer objectivos de software.

Ao mesmo tempo em que desenvolve software, "deve ter" deverá ser implementada, "deve ter" é um assunto de debate com as partes interessadas e da negação, considerando que 'poderia ter" e "lista de desejos" podem ser mantidos para atualizações de software.

Requisitos de Interface Usuário

UI é uma parte importante de qualquer software ou hardware ou sistema híbrido. UM software é amplamente aceite, se for -

Fácil de operar
Em resposta rápida
Tratamento eficaz erros operacionais
A simples interface de usuário consistente ainda

Aceitação de usuário muito depende de como usuário pode usar o software. UI é a única forma para que os usuários percebem o sistema. Um sistema de software deve também ser equipado com atraente, claro, consistente e ágil user interface. Caso contrário, as funcionalidades do sistema para o software não pode ser usado de forma conveniente. Um sistema é dito ser bom se ele fornece meios para utilizá-lo com eficiência. Interface do Utilizador requisitos são brevemente mencionados abaixo -

Conteúdo apresentação
Fácil navegação
Interface Simples
Responder
Elementos de interface consistente
Mecanismo de Feedback
As configurações padrão
Layout Funcional
Utilização estratégica de cor e textura.
Fornece informações de ajuda
Abordagem centrada no usuário
Com base em grupo as definições de visualização.

Analista Sistema Software

Analista de Sistema uma organização de TI é uma pessoa que analisa a exigência do sistema proposto e assegura que os requisitos são concebidas e documentadas adequadamente e corretamente. Papel de um analista começa durante fase de Análise de Software SDLC. É da responsabilidade do analista para se certificar de que o software desenvolvido atende às exigências do cliente.

Sistema os analistas têm as seguintes responsabilidades:

Análise e compreensão dos requisitos de software
Entender como o projeto irá contribuir para a organização objetivos
Identificar fontes de exigência
Validação de exigência
Desenvolver e implementar planos de gestão requisito
Documentação de negócios, técnicos, processos e requisitos do produto
Coordenação com os clientes a fim de priorizar requisitos e remover e ambiguidade
A finalização critérios de aceitação com o cliente e outras partes interessadas.

Métricas e medidas Software

Software medidas pode ser entendida como um processo de quantificação e simbolizando vários atributos e aspectos do software.

Software Metrics prever medidas de vários aspectos do processo de software e produtos de software.

Software medidas são requisito fundamental da engenharia de software. Eles não só ajudam a controlar o processo de desenvolvimento de software, mas também ajuda a manter a qualidade do produto final excelente.

Segundo Tom DeMarco, (Engenheiro de Software), "Você não pode controlar o que você não pode medir." Pelo seu dizer, é muito claro como softwares importantes medidas.

Vamos ver alguns tipos de software métricas:

Tamanho Métricas - LOC (Lines of Code), na sua maioria calculada em milhares de entregue as linhas de código-fonte, representadas por KLOC.

Função contagem de pontos é a medida da funcionalidade fornecida pelo software. Função contagem de pontos define o tamanho do aspecto funcional do software.
Complexidade Métrica - McCabe, complexidade Cyclomatic quantifica o limite superior do número de caminhos independentes dentro de um programa, que é percebido como a complexidade do programa ou seus módulos. Ele é representado em termos de teoria dos grafos conceitos utilizando fluxo de controle gráfico.
Métricas de Qualidade - os defeitos, os tipos e as causas, consequências, a intensidade da gravidade e das suas implicações definem a qualidade do produto.

O número de defeitos encontrados no processo de desenvolvimento e o número de defeitos relatados pelo cliente depois que o produto é instalado ou entregue no cliente-final, definir a qualidade do produto.
Métricas de Processo - em várias fases do SDLC, os métodos e as ferramentas utilizadas, as normas da empresa e o desempenho do software desenvolvimento métricas de processo.
Recurso Metrics - Esforço, tempo e diversos recursos utilizados, representa recursos métricas para medição.

Previous Page Print Page