Beneficios do processo de requisito de alta qualidade

Organizações que implementam engenharia de requisitos de forma efetiva podem garantir muitos benefícios. A grande recompensa vem da redução do retrabalho desnecessário nos estágios finais de desenvolvimento e ao longo do período de manutenção prolongada. O benefício da alta qualidade de requisitos as vezes não é muito obvia, e muitas pessoas acreditam erroneamente que o tempo gasto discutindo requisitos simplesmente vai gerar atraso na entrega do produto.


Ninguém pode prometer corretamente o ROI na aplicação de um processo de requisitos de alta qualidade. Pensando de forma analítica, da para imaginar como a aplicação de um processo bem feito de engenharia de requisitos pode ser benéfico. Primeiro, considere o custo de investir em um melhor processo. Isso inclui o custo da avaliação de suas práticas atuais, desenvolver novos processos e modelos de documentos, capacitação da equipe, compra de livros e ferramentas, e talvez a contratação de consultores externos. Seu maior investimento é o tempo de suas equipes demoram para coletar, documentar, analisar e gerenciar as suas exigências.
Em seguida, basta pensar sobre os possíveis benefícios que você possa desfrutar e quanto tempo ou dinheiro é possível economizar. É impossível quantificar todos os benefícios, mas estes são alguns:

• Menos defeitos nos requisitos
• Redução do retrabalho de desenvolvimento
• Redução de funcionalidades desnecessárias
• Menor esforço
• Desenvolvimento mais rápido
• Redução na falha de comunicação
• Redução do estouro do escopo do projeto (scope creep)
• Reduzir o caos no projeto
• Maior satisfação dos clientes e membro da equipe

Todo projeto tem requisitos!

Frederick Brooks declarou de forma eloquente a regra principal sobre requisitos de software em seu clássico de 1987 de forma bem simples, "Não existe bala de prata: Essência e Acidentes da Engenharia de Software":

A parte mais difícil de construir um software é decidir precisamente o que construir. Nenhuma outra parte do trabalho conceitual é mais difícil do que estabelecer em detalhes dos requisitos técnicos, incluindo todas as interfaces para pessoas, maquinas, e outros sistemas. Não existe outra parte do trabalho que foda tanto com o sistema se for feito errado. Não existe parte mais difícil para refazer.

Todo software ou componente de software tem usuários que contam com suas funcionalidades para facilitar suas vidas. O tempo gasto para entender as necessidades dos usuários é um alto investimento para o sucesso do projeto. Se os desenvolvedores não escrevem requisitos que os clientes concordem, como podem satisfazer seus clientes?

Também é impossível especificar completamente os requisitos depois do inicio da construção. Em alguns casos é possível a aplicação de métodos incrementais e iterativos para escrever requisitos parte por parte, recebendo a aprovação do cliente a cada ciclo de iteração. Mas isso não é desculpa para começar a escrever código antes de escrever a parte dos requisitos referente a iteração. Interagir com código é muito mais complicador que interagir com conceitos.

Muitas vezes as pessoas encaram como um obstáculo gastar tempo escrevendo requisitos, mas escrever requisitos não é a parte mais difícil, difícil é descubrir os requisitos. Escrever requisitos é esclarecer, elaborar e transcrever. O entendimento sólido dos requisitos do produto assegura que seu time vai trabalhar no problema certo e que vão encontrar a melhor solução para o problema. Requisitos deixam você priorizar o trabalho e estimar o esforço e os recursos necessários para o projeto. Sem entender os requisitos você não consegue dizer se o projeto está acabado, determinar se atingiu seus objetivos, ou tomar decisões quando uma redução do escopo é necessária

O que não é Requisito

Especificação de requisitos não incluem desing ou detalhes da implementação , informações sobre o planejamento do projeto, ou teste de informação (Leffingwell e Widrig 2000). As atividades dos requisitos devem ter foco em entender o que o time precisa construir. Projetos tem outros tipos de requisitos, incluindo o desenvolvimento do ambiente de requisitos, agenda ou limitações, a necessidade de um tutorial para ajudar novos usuários a conseguirem ajudar de forma mais ágil para conseguir uma nova release de um produto e levar isso ao ambiente de suporte. Esses são requisitos de Projeto e não requisitos do Produto.

Tipos de Requisitos

Requisitos de software tem três tipos básicos - Requisitos de negócio, requisitos de usuário e requisitos funcionais. Alguns sistemas tem alguns outros requisitos não funcionais.

O modelo na figura ilustra um caminho para pensar sobe os diversos tipos de requisitos. Os círculos representam tipos de informações de requisitos e os retângulos indicam os containers (documentos, diagramas ou banco de dados) onde a informação é armazenada.

Requisitos de negócio representam os objetivos da organização ou do cliente que requisita o sistema. Requisitos de negócio geralmente vêm do patrocinador do projeto, do cliente que adquire, do gerente dos usuários, do departamento de marketing, ou de um visionário do produto. Requisitos de negócio descrevem o porque da organização estar implementando o sistema –Os objetivos que a organização espera atingir. Sugiro armazenar os requisitos de negócio no documento de visão e escopo, muitas vezes chamado de Project charter ou de documento de requisitos do market. Definir o escopo do projeto é o primeiro passo para controlar problemas de quebra de escopo.

Requisitos de usuário descrevem os objetivos do usuário ou tarefas que os usuários precisam executar com o produto. Uma boa maneira de representar requisitos de usuário incluem casos de uso, descrição de cenário, e tabelas de evento-resposta. Requisitos de usuário também podem ser descritos como ”o que o usuário vai ser capaz de fazer com o sistema”. Um exemplo de caso de uso é “Fazer uma Reserva” usando um avião, um carro alugado, ou um site de hotel.

Requisitos funcionais especificam a funcionalidade do sistema que os desenvolvedores precisam construir no produto para que os usuários possam executar suas tarefas, satisfazendo também os requisitos de negocio. As vezes chamado de Requisitos de procedimentos, eles são tradicionalmente conhecidos os “deve”: “O sistema DEVE enviar um e-mail com a confirmação de reserva para o usuário”.

O termo Requisitos de Sistema descrevem um requisito de auto nível para um produto que contem múltiplos subsistemas (IEEE 1998c). Um sistema pode ser todo o software ou pode incluir tanto o software e o hardware. Pessoas são parte do sistema também, certas funções de sistemas precisão alocar humanos para iniciar.

Regras de negocio incluem política de corporação, regulamentação governamental, padrões de industria, boas práticas, e algoritmos de computador. Regras de negocio não são requisitos do sistema, elas existem fora da barreira do sistema. Porém, elas determinam quem vai realizar determinado caso de uso, ela também dita que o sistema deve conter determinada funcionalidade para cumprir determinada regra. Muitas vezes as regras de negocio dão origem a atributos específicos de qualidade que precisam ser implementados em determinadas funcionalidades. É possível traçar a origem de um determinado requisito funcional a partir de uma regra de negocio.

Requisitos funcionais são documentados na especificação de requisito de software(ERS), que descreve completamente as expectativas necessárias para funcionamento de um software.

O ERS é usado no desenvolvimento, teste, garantia da qualidade, gerenciamento do projeto, e funções de projetos relacionados.

Atributos de qualidade acrescentam características importantes tanto para o usuário quanto ao programador sobre as funcionalidades do software. Essas características incluem usabilidade, portabilidade, integridade, eficiência e robustez.

Definindo Requisito de Software

Histórias da vida real:

"Alô, Bruno? Quem fala é Maria do RH. Estamos tendo problemas com o sistema que você programou para nós. Um empregado apenas mudou seu nome para Joana Moreira, e não consigo fazer o sistema aceitar a mudança de nome. Pode me ajudar?"


“Ela se casou com um cara de sobrenome Moreira?”


“Não, ela não casou, só mudou de nome. Este é o problema. Parece que só dá pra mudar o nome somente se a pessoa se casar.”


“Exatamente, eu nunca pensei que alguém pudesse mudar de nome. Eu não me lembro de você comentar sobre essa possibilidade no sistema. Por isso que você só consegue acessar a caixa de dialogo “Mudança de Nome” quando houver mudança no estado civil.”


“Eu acredito que você saiba que legalmente uma pessoa pode mudar seu nome quando quiser” respondeu Maria. “Preciso mudar o nome da Joana ou não teremos como fazer o pagamento dela no sistema, é tem que ser feito até sexta-feira. Pode consertar esse bug pra mim?”


“Não é um bug!” Retornou Bruno. “Eu nunca pensei que você precisaria desta funcionalidade. Eu estou ocupado com a nova avaliação de performance do sistema. Eu acho que tem outras solicitações ainda pendentes no sistema [som de passada de papel] “Sim, aqui tem mais uma. Provavelmente consigo terminar sua solicitação até o final do mês, mas nunca até essa próxima sexta-feira.
Me desculpe. Da próxima vês, me peça com antecedência e por escrito.”


“O que devo dizer para Joana?” rebateu Maria. “Ela vai ficar muito puta por não poder fazer seu pagamento.”


“Ei, Maria, não é minha culpa,” protestou Bruno. “Se você tivesse me dito que poderia mudar o nome das pessoas a qualquer momento isso nunca teria acontecido. Você não pode me culpar por não ter lido sua mente.”


Puta e indignada, Maria lamenta, “Claro, bem, esse tipo de coisa que me faz detestar sistemas de computador. Me ligue quando tiver arrumado o sistema, entendeu?”

Se você está do lado do cliente deste dialogo, você sabe como é frustrante usar um software que não deixa vc fazer tarefas simples como mudar um nome. Você também preferiria não ficar à mercê de um programador que você tem que pedir mudanças critica eventualmente.

Desenvolvedores também sabem como é frustrante entender a funcionalidade que o usuário e só depois de ter implementando tudo.

Muitos problemas de software surgem dos atalhos que as pessoas utilizam para documentar, criar acordos e solicitar mudanças nos requisitos. Assim como Bruno e Maria, muitas empresas sofrem com a informação informal que foi passada, comunicação errónea ou falta de comunicação, requisitos definidos de forma inadequada e processos casuais de mudança.

Muitas pessoas não assinam um contrato de construção de uma casa de R$600.000 sem antes discutir extensivamente tudo que querem na casa e todos os detalhes de forma refinada e progressiva. Compradores de casas entendem que fazer alterações no projeto numa casa custa muito caro; e eles não gostam, mais eles entendem. No entanto, as pessoas não têm o mesmo empenho sobre as questões ligadas ao desenvolvimento de software. Erros evitados durante o estagio de requisitos correspondem a 40 a 60 por cento de todos erros encontrados num projeto de software (Davis 1993; Leffingwell 1997).

Requisitos de Software

Estou abrindo com este post uma serie de estudos sobre analise e engenharia de requisitos, tenho certeza que será de grande proveito para quem pensa em fazer a coisa certa antes de refazer a coisa toda heheheh.

Inicialmente pretendo segui os seguintes tópicos:

O básico sobre Requisito de Software

• Definindo Requisito de Software
  
• Algumas interpretações sobre "Requisitos"
  
• Tipos de Requisitos, O que não é Requisito
  
• Desenvolvimento e Gerenciamento de Requisitos
  
• Todo projeto tem Requisitos
  
• Quando Requisitos ruins acontecem para pessoas boas
  
• Benefícios do Processo de Requisitos de Alta qualidade
  
• Características de Requisitos Excelentes