Arquivo por categoria Engenharia de Requisitos

Medição e Métricas de Software

O papel da medição de software é quantificar alguns atributos de um produto ou de um processo de software. Comparando essas informações é possível tirar conclusões sobre a qualidade do software. Possibilita ainda mensurar se mudanças organizacionais – adoção de novas ferramentas, metodologias dentre outros – estão sendo positivas ou não para os processos de desenvolvimento da mesma. Nesse caso são feitas medições antes e depois da mudança a fim de verificar se a mesma foi positiva ou não para a organização (SOMMERVILLE, 2008).

Majoritariamente, as métricas têm sido adotadas para melhorar processos de gerenciamento da qualidade. Por esse motivo as métricas são utilizadas para mensurar defeitos de programas e processos de verificação e validação.

Todavia, o uso de métricas ainda é relativamente incomum e muitas organizações relutam em adotá-las pois os benefícios não são bem definidos. Isso acontece por que a organização dos processos de software ainda é precária e ainda não estão aperfeiçoados de forma suficiente para usar métricas. Outro motivo é a falta de padrões para as métricas e o fato de muitas empresas não estarem preparadas para introduzir medições sem que padrões e ferramentas sejam antes criadas.

Nesse sentido, Paula Filho (2000)  afirma que escolher medidas adequadas, e ser capaz de coletar, normalizar e analisar estas medidas requer um grau mais avançado de capacitação. Ressalta também que sem medidas, os processos não podem ser avaliados e muito menos melhorados. Por isso mesmo que as medidas sejam rudimentares elas podem ser úteis.

Uma métrica de software é qualquer tipo de medição que se refira a um sistema de software, processo ou documentação relacionada. Alguns exemplos são a medição do tamanho pela quantidade de linhas de código, grau de facilidade de leitura de um trecho de código, numero de defeitos relatados e numero de pessoas-dia necessárias para desenvolver um software (SOMMERVILLE, 2008).

As métricas podem ser classificadas em de controle ou preditivas e ambas podem influenciar na tomada de decisões. As métricas de controle estão associadas a processos de software, já as preditivas estão associadas a produtos de software. Visto que  é quase impossível medir atributos da qualidade de software como facilidade de manutenção, complexidade e facilidade de compreensão, os engenheiros de software medem então atributos internos como o tamanho. Com essas medidas em mãos eles supõe que existam relações entre o que se pode medir e o que se deseja saber. Além disso para que o processo de medição seja confiável, é exigido também, profissionais com grande experiência em estatística.

1.1 O Processo de Medição

A medição de software muitas vezes pode fazer parte de um processo de controle de qualidade. Componentes de um sistema são analisados separadamente, e os diferentes valores de métricas são comparados entre si e com dados históricos de projetos precedentes. As medições anômalas encontradas nesse processo são usadas para enfatizar o esforço de garantia de qualidade.

De acordo com Sommerville (2008) os principais estágios desse processo são:

  • Escolha das medições a serem feitas onde devem ser formuladas questões as quais as medições se destinam a responder e definir as medições importantes para responder essas questões. Medições não relevantes para responder essas questões não precisam ser coletadas.
  • Seleção dos componentes a serem avaliados nem todos os componentes precisam ser necessariamente avaliados, sendo assim é preciso fazer-se uma seleção representativa de componentes realmente importantes.
  • Medição de características dos componentes os componentes selecionados são medidos e os valores e métricas são computados.
  • Identificação de medições anômalas deve-se então procurar por valores incomuns para cada métrica pois eles sugerem a existência de problemas com o componente        que apresenta esses valores.
  • Analise de componentes anômalos os componentes com valores anômalos devem ser examinados para constatar se a qualidade do componente está ou não comprometida. Apesar disso pode haver ainda outros motivos para essa anomalia mas que não comprometam a qualidade.

Os dados coletados devem ser mantidos como um recurso organizacional assim como os registros históricos dos projetos. Quando um banco de dados de medição se torna suficientemente grande ele passa a servir de base para comparações entre projetos e métricas específicas podem ser aprimoradas, de acordo com as necessidades organizacionais.

1.2 Métricas de Produto

O foco das métricas de produto são as características do próprio software. Pelo fato de as características facilmente mensuráveis do software não terem uma relação clara e universal com os atributos de qualidade, a organização precisa analisar seu banco de dados para descobrir como atributos do produto de software se relacionam com as qualidades desejadas pela organização.

Nesse sentido Sommerville (2008) divide as métricas de produtos em duas classes:

  • Métricas dinâmicas são aquelas coletadas de um programa em execução. Ajudam a avaliar a eficiência e a confiabilidade de um programa. Quase sempre estão relacionadas com atributos da qualidade de software.
  • Métricas estáticas são aquelas coletadas em representações do sistema como projeto, programa ou documentação. Ajudam a mensurar a complexidade e a facilidade de compreensão e manutenção de um sistema de software. Possuem uma relação indireta com os atributos de qualidade.

Um dos maiores problemas da coleta de dados sobre software e projetos de software reside no fato de que os dados podem ser interpretados de forma equivocada levando a resultados incorretos. A interpretação dos dados sobre um produto ou processo é um método incerto. Os elementos focados pela medição não estão isolados de seus ambientes, e mudanças nesse ambiente podem invalidar as comparações de dados. Além disso, as métricas variam de acordo com o projeto, com as metas da equipe de gerencia de qualidade, com o tipo de software que está em desenvolvimento.

Referências:

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

PMBOK. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK). 4 ed. Pennsylvania: Project Management Institute, Inc., 2008.

PAULA FILHO, Wilson de Pádua. Engenharia de Software:fundamentos, métodos e padrões. São Paulo: LTC Editora, 2000.

Tags: , , ,

Qualidade de Software

Atingir um alto nível de qualidade de produto ou serviço é uma exigência inerente ao mercado. Quando se trata de qualidade de software não se foge a regra e não é aceitável entregar produtos com baixa qualidade e descobrir as deficiências e problemas após entregar o produto ao cliente.

1.1 A Importância da Qualidade de Software

Quando se trata de software, o conceito de qualidade é algo complexo e adotar a mesma definição de qualidade que se aplica a produtos manufaturados não pode ser aplicada sem inconsistência. Para Sommerville (2008) a noção de que o produto desenvolvido deve cumprir com sua especificação quando aplicada ao desenvolvimento de software torna-se ineficaz:

  • A especificação deve considerar as características desejadas pelo cliente e a organização de desenvolvimento pode ter requisitos não incluídos na especificação.
  • Certas características de qualidade não podem ser especificadas sem se tornar ambíguas.
  • É muito difícil descrever uma especificação completa de software. Nesse sentido, mesmo que um produto atenda sua especificação os usuários podem não considerá-lo de alta qualidade.

Evidentemente deve haver um esforço para melhorar as especificações, mas devemos aceitar que elas serão imperfeitas. Devem-se reconhecer os problemas com as especificações impostas e adotar técnicas para melhorar sua qualidade dentro das restrições impostas. Atributos de software como facilidade de manutenção, portabilidade ou eficiência podem ser fundamentais, mas que não são especificados explicitamente, entretanto podem afetar a qualidade percebida do sistema (SOMMERVILLE, 2008). Para Bezerra (2006) algumas das formas de se medir a qualidade de um sistema de software é através de seu desempenho, sua confiabilidade e da utilidade do mesmo.

Nesse sentido cabe aos gerentes de projeto garantir que o nível de qualidade seja atingido. Definir procedimentos e padrões, e garantir que eles sejam seguidos, já são um bom começo, mas não é o suficiente. Gerentes de qualidade reconhecem que existem aspectos intangíveis de qualidade que não se encaixam em padrões. Alémdisso, é importante criar uma “cultura da qualidade” na qual todos se comprometam a atingir um alto nível de qualidade (SOMMERVILLE, 2008).

Para Sommerville (2008) o gerenciamento de qualidade de software pode ser dividido em ter atividades principais:

  • Garantia de qualidade que consiste em estabelecer procedimentos e padrões que conduzam ao desenvolvimento de software de alta qualidade.
  • Planejamento de qualidade selecionar os procedimentos e padrões adequados e adaptá-los a um projeto de software específico o que vai de encontro com recomendações do PMBOK (2008).
  • Controle de qualidade definir e aprovar processos que garantam que os procedimentos e padrões de qualidade sejam seguidos.

O gerenciamento de qualidade fornece uma verificação independente sobre o processo de desenvolvimento de software. Ele deve ser separado do gerenciamento de projeto, para que a qualidade não seja comprometida pelas responsabilidades de gerenciamento relacionadas a prazos e orçamentos. A equipe de qualidade não deve ficar associada à um grupo específico de desenvolvimento, mas sim assumir um compromisso pela qualidade na organização. Os procedimento de garantia de qualidade devem ser documentados em um manual que define o processo de qualidade (SOMMERVILLE, 2008).

1.2 Garantia e Padrões de Qualidade

As atividades de garantia de qualidade definem uma estrutura para atingir a qualidade de software. O que envolve definir ou selecionar os padrões a serem aplicados no desenvolvimento de um produto de software. Sommerville (2008) estabelece dois tipos de padrões que podem ser estabelecidos como parte do processo de garantia de qualidade:

  • Padrões de produto se aplicam ao produto de softwareem desenvolvimento. Podem incluir padrões de documentos, padrões de documentação e padrões de codificação. Aplicam-se as saídas do processo de software.
  • Padrões de processo definem os processos a serem seguidos durante o desenvolvimento do software. Podem incluir definições de especificação, processos de projeto e validação e uma descrição dos documentos a serem gerados no curso de desenvolvimento. Além disso asseguram que os padrões de produto sejam seguidos.

Sommerville (2008) enumera uma série de motivos pelos quais os padrões de software são importantes:

  • Envolvem as práticas mais adequadas. Adquire-se mais conhecimento através de erros e acertos o que evita que os erros se repitam no futuro. Registram a sabedoria que tem valor para a organização.
  • Fornecem uma infraestrutura em torno da qual o processo de garantia de qualidade pode ser implementado.
  • Reduzem o esforço de aprendizados quando um novato entra na equipe e garante que todos adotem as mesmas praticas.

Desenvolver padrões de projeto de Engenharia de Software é difícil e demorado. Equipes de garantia de qualidade que estejam desenvolvendo seus padrões de projeto de Engenharia de Software deverão se basear em padrões nacionais, internacionais e organizacionais. Com base nesses padrões a equipe de garantia de qualidade deve elaborar um manual de padrões, adaptado às necessidades apropriadas a sua organização.

Entretanto, não raramente engenheiros de software julgam esses padrões não são necessariamente apropriados a um projetoem particular. Segundo Sommerville(2008) para evitar esses problemas engenheiros de qualidade que estabelecem os padrões precisam seguir as seguintes etapas:

  • Envolver os engenheiros de software no desenvolvimento de padrões e fazer com que compreendam e se comprometam com eles.
  • Revisar e modificar regularmente os padrões para que eles reflitam as constantes evoluções tecnológicas.
  • Fornecer ferramentas de software que apoiem a adoção dos padrões.

Nesse sentido criar padrões de documentação é uma boa solução e facilita a comunicação entre membros da equipe de desenvolvimento e os clientes.

1.3 Qualidade de Produto e Qualidade de Processo

A qualidade do processo de desenvolvimento afeta diretamente a qualidade dos produtos fornecidos. Isto se deve ao fato de a qualidade de produto estar diretamente relacionada ao processo de produção. É difícil medir atributos de software sem utilizá-lo por um longo período. Os processos por sua vez são relativamente simples de monitorar e padronizar. A melhoria de qualidade focaliza então a identificação de produtos de boa qualidade e nos processos utilizados no seu desenvolvimento. Entretanto, devido a complexidade entre produtos de software e os processos de software, uma mudança no processo não necessariamente conduz a melhoria da qualidade.

O software não é um produto manufaturado, mas projetado. Seu desenvolvimento é um processo criativo e não mecânico tornando-o significativamente influenciado por habilidades, experiências individuais e fatores externos que afetam diretamente na sua qualidade (SOMMERVILLE, 2008).

Referências:

BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML: Um guia prático para modelagem de sistemas orientados a objetos através da Linguagem de Modelagem Unificada. Rio de Janeiro: Elsevier e Campus, 2006.

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

PMBOK. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK). 4 ed. Pennsylvania: Project Management Institute, Inc., 2008.

Tags: , , ,

Engenharia de Requisitos

Os problemas que os engenheiros de software precisam solucionar, muitas vezes, podem ser muito complexos. Compreender corretamente o problema se torna muito difícil, especialmente se o sistema for novo. E claro, fica difícil definir com clareza o que o sistema deve fazer. A descrição das funções e das restrições são os requisitos do sistema. O processo de descobrir, analisar, documentar e verificar os requisitos recebe então o nome de Engenharia de Requisitos (SOMMERVILLE, 2008).

1.1 Características da Engenharia de Requisitos

O termo requisito não se aplica de forma consistente a indústria de software. Isso se deve ao fato de em alguns casos os requisitos serem encarados como uma declaração abstrata de uma função que o sistema deve fornecer ou uma restrição do sistema. Em outros casos ele é uma descrição detalhada de uma função do sistema (SOMMERVILLE, 2008). Em todo caso deve-se levar em conta que uma boa Engenharia de Requisitos é um passo fundamental para o desenvolvimento de um bom produto (PAULA FILHO, 2000).

Se uma empresa deseja estabelecer um contrato de desenvolvimento de um grande projeto a princípio ela deve fazer definição de requisitos relativamente abstrata (PAULA FILHO, 2000). Isso possibilita que os diferentes fornecedores apresentem propostas sugerindo diferentes maneiras de atender as necessidades organizacionais do cliente. Evitando ainda, que soluções predefinidas sejam adotadas em detrimento das particularidades organizacionais. Uma vez que o contrato esteja firmado o fornecedor deve então preparar uma definição de sistema bem detalhada. O que facilita a compreensão por parte do cliente e possibilita também validar o que o software fará (SOMMERVILLE, 2008).

Durante a Engenharia de Requisitos podem aparecer alguns problemas decorrentes da falta de uma separação nítida entre os dois diferentes níveis de descrição. Esses níveis podem ser distinguidos utilizando-se os termos requisitos de usuário para os requisitos abstratos de alto nível e requisitos de sistema para indicar a descrição detalhada das funcionalidades do sistema. Pode ser produzida ainda uma descrição mais detalhada associando a Engenharia de Requisitos às atividades de projeto. Para Sommerville (2008) esses dois níveis de requisitos e a especificação de projeto de software podem ser definidos do seguinte modo:

  • Requisitos de usuário são declarações em linguagem natural e diagramas contendo as funcionalidades e as restrições sob as quais o sistema deve operar. Esse documento é escrito para gerentes do cliente e dos fornecedores que não tenham conhecimento técnico detalhado do sistema.
  • Requisitos de sistema detalham funcionalidades e restrições. Esse documento pode inclusive servir como um contrato entre as partes envolvidas no projeto. Ele é escrito para os profissionais técnicos de nível sênior e para gerentes de projeto
  • Especificação de projeto de software é uma descrição abstrata do projeto de software na qual se acrescenta mais detalhes aos requisitos do sistema. Esse documento é escrito para os engenheiros de software que desenvolverão o sistema.

1.2 Requisitos Funcionais e Não Funcionais

Sommerville (2008) classifica os requisitos de sistema de software como funcionais, não funcionais e como requisitos de domínio:

  • Requisitos funcionais definem as funcionalidades do sistema como deve reagir em condições específicas e como se comportar em determinadas situações. Podem ainda declarar o que o sistema não deve fazer.
  • Requisitos não funcionais são restrições sobre serviços ou funções oferecidas pelo sistema. Dentre elas destacam-se restrições de tempo, sobre o processo de desenvolvimento e de padrões. A descrição das restrições complementa a definição de requisitos (PAULA FILHO, 2000).
  • Requisitos de domínio são restrições originárias do domínio da aplicação do sistema e refletem características do mesmo. Podem ser requisitos funcionais ou não funcionais.

A distinção entre esses diferentes tipos de requisitos não é tão clara como sugere essas definições. Um requisito pode parecer-se inicialmente não funcional, mas que quando desenvolvido com mais detalhes pode dar origem a uma série de novos requisitos funcionais. Ao discutirmos sobre requisitos devemos levar em conta que na realidade a distinção entre eles é artificial (SOMMERVILLE, 2008).

1.2.1 Requisitos funcionais

Os requisitos funcionais descrevem a funcionalidade ou os serviços que se espera que o sistema realize em benefício dos usuários (PAULA FILHO, 2000). Eles variam de acordo com o tipo de software em desenvolvimento, com usuários e com o tipo de sistema que está sendo desenvolvido. Requisitos funcionais podem ser expressos de diversas maneiras e, como já foi dito acima, em diferentes níveis de detalhamento. Os requisitos funcionais de usuários definem recursos específicos que devem ser fornecidos pelo sistema (SOMMERVILLE, 2008).

É natural para um desenvolvedor de sistemas interpretar um requisito ambíguo para simplificar sua implementação. Entretanto isso pode não ser necessariamente o que o cliente necessita. Surgem então novos requisitos e é necessário realizar alterações no sistema, o que afetará diretamente o tempo e o custo do projeto.

Inicialmente a especificação de requisitos funcionais deve ser completa – deve definir todos os requisitos de usuário e refletir as decisões de especificação tomadas – e consistente – os requisitos não devem ter definições contraditórias (PAULA FILHO, 2000). Entretanto, na realidade, em sistemas complexos e grandes, é quase impossível atingir a consistência e a completeza dos requisitos. Isso ocorre, principalmente, em função da complexidade inerente ao sistema e porque as pessoas possuem diferentes pontos de vistas em relação a um problema. Esses problemas somente emergem após uma análise mais aprofundada. À medida que os problemas vão sendo descobertos, deve se ir atualizando o documento de requisitos (SOMMERVILLE, 2008).

1.2.2 Requisitos não funcionais

Os requisitos não funcionais são aqueles que não dizem respeito diretamente às funcionalidades fornecidas pelo sistema. Podem estar relacionados a propriedades de sistemas emergentes, como confiabilidade, tempo de resposta, espaço em disco, desempenho e outros atributos de qualidade do produto (PAULA FILHO, 2000). Às vezes podem dizer respeito ao sistema como um todo. Isso significa que na maioria das vezes eles são mais importantes que os requisitos funcionais individuais. Se uma falha em cumprir um requisito funcional pode comprometer parte do sistema, uma falha em cumprir um requisito não funcional pode tornar todo o sistema inútil (SOMMERVILLE, 2008).

Nem sempre os requisitos não funcionais dizem respeito ao sistema de software a ser desenvolvido. Muitas vezes requisitos não funcionais podem restringir o processo utilizado para desenvolver o sistema. Requisitos de processo podem abranger desde uma especificação de padrões de qualidade a ser utilizada no processo até uma especificação de ferramentas as serem utilizadas.

Os requisitos não funcionais surgem de acordo com as necessidades dos usuários, em razão de restrições orçamentárias, de politicas organizacionais, pela necessidade de interoperabilidade com outros sistemas de software ou hardware e até mesmo em função de fatores externos. Esses últimos podem ser por exemplo de natureza legal ou de segurança.

Sommerville (2008) classifica os requisitos não funcionais em:

  • Requisitos de produto que especificam o comportamento do produto. Podem restringir, por exemplo, a liberdade dos projetistas a utilizar uma determinada linguagem.
  • Requisitos organizacionais que são procedentes de políticas e procedimentos adotados nas organizações do cliente e do desenvolvedor. Especifica que o sistema deve ser de acordo com um processo-padrão da empresa.
  • Requisitos externos que abrange tópicos advindos de fatores externos ao sistema. Dentre eles destacam-se os requisitos de interoperabilidade, os requisitos éticos e os requisitos legais que devem ser observados a fim de garantir que o sistema opera de acordo com a lei.

Um problema dos requisitos não funcionais é que geralmente eles são de difícil verificação e quantificação em uma primeira versão do produto (PAULA FILHO, 2000). Podem ser escritos para refletir os objetivos gerais do cliente como usabilidade, recuperação à falhas ou rapidez de resposta ao usuário. Esses requisitos são problemáticos na medida em que abrem a possibilidade e múltiplas interpretações e claro discussões quando o sistema é entregue (SOMMERVILLE, 2008).

O ideal é que os requisitos não funcionais sejam expressos de forma quantitativa utilizando-se métricas que possam ser testadas. Algumas das principais métricas para testar os requisitos não funcionais são, a velocidade, o tamanho, a usabilidade, a confiabilidade, a robustez e a portabilidade.

Todavia a especificação quantitativa de requisitos também se mostra problemática uma vez que os clientes podem não conseguir traduzir suas metas em requisitos quantitativos. Não há, por exemplo, uma métrica capaz de mensurar a facilidade de manutenção. Por esse motivo, os documentos de requisitos podem incluir declarações de metas junto aos requisitos. Elas são úteis, pois fornecem pistas quanto as prioridades dos clientes. Entretanto essas metas podem ser mal entendidas e não serem objetivamente verificadas.

Requisitos não funcionais podem entrar em conflito e interagir com outros requisitos funcionais do sistema. Muitas vezes pode ser impossível equilibrar diferentes requisitos não funcionais sendo necessário sacrificar um em detrimento de outro de maior importância para a aplicação. É o que Sommerville (2008) chama de encontrar uma “compensação” para minimizar o impacto no sistema como um todo de uma escolha por atender um determinado requisito não funcional em detrimento de outro. De forma similar o PMBOK (2008) afirma que com frequência são necessárias compensações entre os requisitos e os objetivos do projeto. Destaca ainda que essas compensações irão variar de projeto para projeto.

É recomendável que requisitos funcionais e não funcionais sejam diferenciados em um documento de requisitos; embora isso não seja fácil. Se os requisitos não funcionais forem definidos separadamente dos requisitos funcionais será difícil relacioná-los. Por outro lado se forem definidos juntos, será difícil separar considerações funcionais de não funcionais e delinear requisitos que dizem respeito ao sistema como um todo. Sendo assim é preciso encontrar um equilíbrio adequado que irá depender do tipo de sistema. O ideal é que seja criada uma seção separada no documento de requisitos listando aqueles que claramente se relacionam (SOMMERVILLE, 2008).

1.3 Requisitos de Domínio

Os requisitos de domínio são derivados do domínio da aplicação do sistema que podem ser novos requisitos funcionais em si, podem restringir os requisitos funcionais existentes ou estabelecer como devem ser executados cálculos específicos. Muitas vezes esses requisitos refletem fundamentos do domínio da aplicação (SOMMERVILLE, 2008). Sem uma compreensão satisfatória desses requisitos pode ser impossível fazer o sistema operar de forma satisfatória (PRESSMAN, 2006).

Esses requisitos são expressos com o uso de uma linguagem específica do domínio da aplicação e, geralmente, de difícil compreensão para os engenheiros de software. Os especialistas do domínio podem, por julgarem óbvio, deixarem de fornecer informações importantes e como resultado o requisito pode não ser implementado de forma satisfatória (SOMMERVILLE, 2008).

1.4 Requisitos de Usuário

Os requisitos de usuários descrevem os requisitos funcionais e não funcionais de forma compreensível pelos usuários do sistema que não têm conhecimentos técnicos detalhados. Devem especificar somente o comportamento externo do sistema evitando o quanto for possível das características do projeto de sistema. Podem ser escritos em linguagem natural, formulários e diagramas simples e intuitivos. Entretanto de acordo com Sommerville (2008) podem surgir alguns problemas quando os requisitos são escritos em linguagem natural:

  • Falta de clareza não é fácil utilizar a linguagem natural de forma precisa e sem ambiguidades sem acarretar em um documento de difícil leitura.
  • Confusão de requisitos os requisitos funcionais e não funcionais, os objetivos do sistema e informações do projeto podem estar definidos de forma obscura.
  • Fusão de requisitos vários requisitos distintos podem ser unificados em um único requisito.

Uma boa pratica é isolar requisitos de usuário de requisitos de sistema caso contrário os leitores podem ser sobrecarregados por detalhes técnicos que não lhes são relevantes. A fim de minimizar divergências na elaboração requisitos de usuário Sommerville (2008)  recomenda que:

  • Se crie um formato-padrão e certifique que todas as definições de requisitos estejam de acordo com ele.
  • Utilize a linguagem de forma consistente, distinguindo requisitos obrigatórios dos desejáveis.
  • Ressalte partes importantes dos requisitos.
  • Evite o uso de jargões técnicos.

1.5 Requisitos de Sistema

Requisitos de sistema são descrições mais detalhadas dos requisitos de usuário. Podem servir de base para um contrato de implementação e devem especificar completa e consistentemente todo o sistema. São utilizados como ponto de partida para o projeto do sistema. Inicialmente eles deveriam definir o que o sistema deveria fazer e não como ele teria de ser implementado. Entretanto de acordo com Sommerville (2008) isso é quase impossível por diferentes motivos:

  • A definição de uma arquitetura inicial do sistema pode ser definida para auxiliar a estruturar a especificação de requisitos.
  • Frequentemente os sistemas devem interagir com outros sistemas restringindo o sistema e consequentemente gerando novos requisitos.
  • O uso de um projeto específico pode ser um requisito externo de sistema.

A linguagem natural é frequentemente usada para escrever especificações de requisitos de sistema. Todavia, de acordo com Sommerville (2008) quando ela é usada para especificar requisitos de forma detalhada isso pode provocar problemas:

  • A linguagem natural está sujeita a ambiguidades
  • Uma especificação de requisitos em linguagem natural é muito flexível permitindo dizer a mesma coisa de diferentes formas.
  • Não existe nenhum meio fácil de padronizar especificações de requisitos escritos em linguagem natural.

As especificações de requisitos escritas em linguagem natural estão sujeitas a divergências. Frequentemente, elas só são descobertas em fases posteriores do processo de software. As soluções, quase sempre, levam a um aumento no custo e no tempo do projeto.

Enfim, as informações dos documentos de softwares irão variar de acordo com o tipo de software em desenvolvimento e da abordagem adotada para fazê-lo. E nada mais são que esboços (PRESSMAN, 2008) que podem ser usados para descrever as funcionalidades de um sistema. Dependendo da abordagem escolhida o documento de requisitos irá variar no enfoque e no tamanho. O documento poderá ter desde uma simples definição geral do escopo para um dado processo até um documento extremamente detalhado para outro processo. A decisão de qual adotar caberá aos engenheiros de software e sua decisão frente às características do sistema.

Referências:

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

PMBOK. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK). 4 ed. Pennsylvania: Project Management Institute, Inc., 2008.

PAULA FILHO, Wilson de Pádua. Engenharia de Software: fundamentos, métodos e padrões. São Paulo: LTC Editora, 2000.

Tags: , , ,