Desenvolvimento e Gerenciamento de Requisitos

Alguns autores denominam o processo de gerenciamento e desenvolvimento de requisitos como Engenharia de Requisitos (Sommerville e Kotonya 1998); outros se referem como Gerenciamento de Requisitos (Leffingwell e Widrig 2000). Na figura eu dividi a Engenharia de Requisitos em duas partes, Desenvolvimento de Requisitos e Gerenciamento de Requisitos.

Desenvolvimento de Requisitos

Podemos dividir o Desenvolvimento de Requisitos em elicitação, analise, especificação, e validação (Abran e Moore 2001). Essas subdisciplinas incluem todas as atividades envolvidas em coletar, avaliar e documentar requisitos para um software ou software produto, incluem as seguintes tarefas:

• Identificar classes de usuários esperadas no produto


• Elicitar necessidades individuais que representam cada classe de usuário


• Entender as tarefas dos usuários e seus objetivos e os objetivos de negócio alinhado com cada tarefa


• Analisar a informação recebida dos usuários para distinguir suas tarefas de requisitos funcionais, não funcionais, regras de negócio, soluções sugeridas, e informação errada


• Alocar parte dos requisitos para componentes de software definidos na arquitetura do sistema


• Entender a relativa importância dos atributos de qualidade


• Negociar a prioridade das implementações


• Traduzir as necessidades coletadas dos usuários em especificação de requisitos e modelos


• Revisar os requisitos documentados

Interação é a chave do sucesso do Desenvolvimento de Requisitos. Paneje múltiplos ciclos de exploração de requisitos, refinando requisitos de auto nível em detalhes, e confirme com os usuários. Isso pode demandar tempo e pode ser uma experiencia frustrante, mas é intríceco para evitar definições nebulosas e nenhum pouco claras sobre o novo software.

Gerenciamento de Requisitos

Gerenciamento de Requisitos significa "Estabelecer e manter um acordo com o cliente sobre o requisitos para o projeto de software" (Paulk et al. 1995). Este acordo está incorporado na especificação de requisitos e modelos. A aceitação do cliente é apenas um pedaço da equação necessária para a aprovação do requisito. Os desenvolvedores também precisam aceitar as especificações e concordarem em construi-las no produto. As atividades do gerenciamento de requisitos são as seguintes:

• Definição de uma baseline (uma fotografia no tempo que representa o atual corpo do acordo sobre a especificação de requisitos)


• Revisar propostas de mudanças de requisitos e avaliar o impacto de cada mudança antes de aprovar


• Incorporar as mudanças aprovadas no projeto de forma controlada


• Manter o plano do projeto com os requisitos atuais


• Negociar o contrato baseada no impacto da mudança dos requisitos


• Traçar requisitos com seu correspondentes no desing, código fonte e casos de teste


• Rastrear o status dos requisitos e as atividades de mudanças no projeto

A Figura abaixo, indica uma outra forma de visualizar a distinção entre desenvolvimento de requisitos e gerenciamento de requisito.

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.

Algumas interpretações sobre "Requisitos"

Um problema com a industria de software é a definição para termos que usamos para descrever aspectos de nosso trabalho. Observadores diferentes podem descrever o mesmo problema como um requisito de usuário, requisito de software, requisito funcional, requisito de sistema, requisito técnico, requisito de negocio ou requisito de produto.
O usuário acredita que requisitos sejam algo como conceitos de auto nível do produto. A noção do desenvolvedor está mais para uma interface detalhada que atenda o usuário. Esta diversidade de definições deixa confusa e frustrante a comunicação.

O conceito chave é que requisitos precisão ser documentados. Já estive em projetos em que a experiência ia junto com a rotatividade dos desenvolvedores. Quando um analista vai consultar o cliente sobre requisitos e ele vai dizer “Eu já falei sobre esses seus requisitos agora me faça esse sistema!” Dessa forma só resta trabalhar com pilhas de e-mails desconexos, conversas de corredor, post-its e outros artifícios informais para tentar conhecer os requisitos.

Algumas Interpretações

O IEEE define requisitos como:

1. Uma condição ou capacidade que o usuário necessita para resolver um problema ou atingir um objetivo.
2. Uma condição ou capacidade que precisa ser conhecida ou processada pelo sistema ou componente para satisfazer um contrato, padrão, especificação, ou outro documento formal.
3. A representação documentada de uma condição ou capacidade em 1 ou 2.

Sommerville e Sawyer definem como:

Uma especificação do que precisa ser implementado. Eles são uma descrição do que o sistema precisa ter, ou sobre uma propriedade ou atributo do sistema. Eles devem ser uma constante no processo de desensenvolvimento de sistemas.

Claramente, não existe uma definição universal sobre o que é requisito. Para facilitar a comunicação, precisamos concordar com uma definição comum para que tanto a equipe de desenvolvimento e cliente fale a mesma língua.

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