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

Falar com boas maneiras: Esse é o caminho

Materia da Ágilis que achei muito interessante:

Grande parte dos conflitos organizacionais é causada pela maneira como os profissionais falam uns com os outros.

O descuido com a forma do discurso, gestos bruscos e emoções à flor da pele costumam atrapalhar o entendimento do mais importante: a mensagem. E pior: acabam criando novos problemas.
Os conteúdos, por mais desagradáveis que sejam, precisam ser transmitidos de maneira leve e orientadora. As advertências podem e devem ser dadas, mas para orientar, e não para desabafar.

 

Por isso, a arte de dizer o que deve ser dito, fazendo-se entender e sem machucar o interlocutor, é uma competência a ser desenvolvida por todos na empresa.
Enfim, para evitar constrangimentos nas relações profissionais e problemas no resultado do trabalho, lembre-se: tudo pode ser dito, desde que de forma polida, clara e objetiva.


Fonte: Ágilis RH

Change Isn't Free: Impact Analysis

True Stories - The need for impact analysis is obvious for major enhancements. However, unexpected complications can lurk below the surface of even minor change requests. 

A company once had to change the text of one error message in its product. 

What could be simpler? 

The product was available in both English and German language versions. 

There were no problems in English, but in German the new message exceeded the maximum character length allocated for error message displays in both the message box and a database. 

Coping with this apparently simple change request turned out to be much more work than the developer had anticipated when he promised a quick turnaround.

Impact analysis is a key aspect of responsible requirements management (Arnold and Bohner 1996). 

It provides accurate understanding of the implications of a proposed change, which helps the team make informed business decisions about which proposals to approve. 

The analysis examines the proposed change to identify components that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change. 

Before a developer says, "Sure, no problem" in response to a change request, he or she should spend a little time on impact analysis.

Trap - Because people don't like to say "no," it's easy to accumulate a huge backlog of approved change requests.
Before accepting a proposed change, make sure you understand the rationale behind it, its alignment with the product vision, and the business value that the change will provide.

Arquitetura de Software

Hoje fui ao evento chamado Encontro de Arquitetos Brasília aqui na Microsoft Brasília. A palestra do Cambiucci foi muito boa, tirando essa massiva direção da Microsoft sobre as maravilhas do mais novo modelo de negocio da Microsoft (Windows Azure), o conteudo foi bem rico, destaco como um dos pontos fortes do evento, além da bela explanação sobre o azure,  o link para o eBook do Cambiucci.
Ebook Arquitetura de Soluções



Site do Time de Arquitetura da Microsoft Brasil 
ARQCAST DO BRASIL



Trechos do evento (fonte: celular Nokia E71)
Software e Serviços

Arquitetura MS

cirurgia para remover a vesicula

Essa semana viajei a joão pessoa na paraíba para acompanhar a cirurgia de remoção da vesicula de minha mãe. Pelo que vi nas pesquisas que fiz na internet o procedimento atual é menos invasivo porém o risco continua o mesmo. São 4 espetos de churrasco que são utilizados pra visualizar o interior, encher de gás e, cortar, queimar e grampear os órgãos ligados a vesicula. Minha mãe acabou de chegar da operação, vomitou e sente dores no estômago. Acho que ela vai ficar bem, afinal, depois de uma tortura dessas é normal sentir um pouco de dor.
Video

Queries que vou usar mais tarde

Situação:

Tabela de arquivos, com referencia ao caminho físico dos arquivos em campo varchar(255)

Preciso recuperar apenas o nome da imagem, sem o resto do caminho.

Solução:

create function GetNomeImagem(@dsNomeImagem varchar(255))
returns varchar(255)
as
begin
declare @saida varchar(255)
declare @posicao int
select @posicao=charindex('\',reverse(@dsNomeImagem))
select @saida=reverse(SUBSTRING(reverse(@dsNomeImagem),0,@posicao))
return @saida
end

Quando requisitos ruins acontecem para pessoas boas

A maior conseqüência de requisitos ruins é o retrabalho – fazer novamente algo que você já tinha acabado. Retrabalho pode consumir de 30 a 50 por cento do custo total de desenvolvimento (Boehm e Papaccio 1988), e erros de requisitos representam de 70 a 85 por cento do custo do retrabalho (Leffingwell 1997). É bem mais caro corrigir um erro no meio do projeto do que se fosse corrigido um pouco antes de sua criação. (Grandy 1999). Prevenindo erros de requisitos e os identificando logo no inicio, é um esforço super favorável para evitar o retrabalho. Imagine como seria diferente sua vida se pudesse reduzir o retrabalho quase por completo! Você poderia construir produtos de forma mais ágil, construindo mais e melhor no mesmo período de tempo, e talvez até possa ir pra casa ocasionalmente.

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

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