Curso de Requisitos Módulo 02: Requisitos de Software

Curso de Requisitos Módulo 02: Requisitos de Software
Requisitos de Software, Técnicas de Levantamento, Identificação dos Problemas, Necessidades e Principais Artefatos

Introdução à Gerencia de Requisitos: Visão Geral
Problem Problema Domínio do Problema Discuss how this roadmap represents a roadmap of this course. Traceability allows us to: Assess the project impact of a change in a requirement. Assess the impact of a failure of a test on requirements (that is, if the test fails, the requirement may not be satisfied). Manage the scope of the project. Verify that all requirements of the system are fulfilled by the implementation. Verify that the application does only what it was intended to do. Manage change. Necessidades Características Sistema a ser construído Domínio da Solução Requisitos de Software Managing requirements involves the translation of stakeholder requests into a set of system features. These in turn are detailed into specifications for functional and nonfunctional requirements. Detailed specifications are translated into test procedures, design, and user documentation. Rastreabilidade Procedimentos de Teste Design Docs do usuário

Definições Requisitos Gerenciamento de Requisitos
It is a good idea to have some examples of requirements to make this definition less abstract. Include functional requirements such as would be included in a use-case model. Also include performance, legal, availability, and so on. For an ATM machine, a functional requirement might be “withdraw cash.” An example of a performance requirement might be to validate the customer ID within 5 seconds. Requisitos A condição ou capacidade que o sistema deve possuir. Gerenciamento de Requisitos Uma abordagem sistemática para: Detalhar, organizar, e documentar requisitos. Estabelecer e manter acordos entre cliente/usuário e equipe de projeto nas requisições de mudanças. Definitions: RUP: A requirement describes a condition or capability to which a system must conform, either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document. UML: A desired feature, property, or behavior of the system. Requirements specify what the system must do rather than how the system does it. There are many kinds of requirements. For example, feature requirements are requirements that are directly tied to user needs, and software requirements give the detailed requirements for the software. These different types of requirements are discussed later in the course. Do not expect to “get it right first time”. Requirements management is successful only if it allows for uncertainty of the requirements early in the project. However, requirements management also ensures that requirements become better defined over time.

O que Requisitos de Software especificam?
There has to be enough of the “How” specified to build the right system, but these should be identified as design constraints. Emphasize how requirements describe a solution from the black-box perspective. Sistema Entradas Saídas Restrições de Design Funções A requirement is a capability or condition to which the system must conform. Software requirements provide a “black box” definition of the system. They define only those externally observable “What’s” of the system, not the “How’s.” Of course, there has to be enough of the “How” specified to build the right system, but these should be identified as design constraints. Requisitos não funcionais (Ex.: Performance) (Ex.: Ambientes)

Definições Requisições do Stakeholder Característica
Uma expressão independente de solução de um estado desejado pelo stakeholder da solução ou sujeito ao domínio. Característica Um serviço externamente observável diretamente no sistema que atende a um ou mais requisições do stakeholder. Requisitos de Software Requisito Funcional Um requisito que especifica, de uma perspectiva caixa-preta, como uma solução que interage com o mundo externo. Requisito não funcional Um requisito que expressa, de uma perspectiva caixa-preta, os atributos de qualidade da solução. There is some overloading of terminology between Stakeholder Request and Stakeholder Need. In this course, stakeholder needs and stakeholder requests are essentially synonymous. Stakeholders have certain needs of a solution. Those needs are expressed as stakeholder requests. Restrição Uma limitação no design do sistema ou nos processos usados para construir o sistema.

Exemplo de um Sistema de Registro em Curso
Requisição do Stakeholder Precisa de menor despesa geral no registro. Professores precisam de acesso imediato a grade de aulas. While the class example has not been introduced yet, the students should be able to relate to the examples. Indicate that this is a glimpse to what is about to come during this course. Característica Uma árvore de navegação de visualizar a grade de aulas, por semestre e por turma. Requisito de Software Funcional O caso de uso começa quando o estudante seleciona o comando “register for course”. O sistema apresenta uma lista de cursos disponíveis… Não-Funcional Disponibilidade de 99% dos 24/7(3.65 dias off-line por ano) Restrição Opera no Main Frame DEC VAX da Universidade.

Caracterização das Definições
Just using the word “requirement” to refer to all conditions or capabilities to which the system must conform is not enough. It is useful to think about the different types of requirements encountered. The sub-classifications listed above help categorize the requirements. tipos de Requisitos Características Requisições do Stakeholder Requisitos de Software Restrições de Design Categorizing the requirements helps determine if you have found all the requirements. For example, ask “are there any constraints on the system we have not identified yet?” or “What are the performance requirements of this system?” The following more exhaustive taxonomy is based on: "Process for System Architecture and Requirements Engineering" by Derek Hatley, Peter Hruschka, and Imtiaz Pirbhai (Dorset House Publishing). Based on Leffingwell & Widrig, 1999 Requisitos Funcionais Propriedade medida Velocidade trans. Devem proc. 5 seg Tamanho K bytes Usabilidade tempo de treinamento/ quadros de ajuda Confiabilidade tempo médio de falhas/ tx de ocorrencia de falhas Portabilidade sistemas operacionais utilizados Requisitos não funcionais

Tipos de não funcionais
Produto : confiabilidade,segurança, desempenho, capacidade e portabilidade Organização: métodos, linguagens e ferramenta ex.: linguagem livre Externo : legado de dados q não pertence a organização, legislação

Requisitos de Domínio Características das regras de negócio do sistema
ex.: no Rup tem um repositório para descrever as regras o cliente pode sacar no máximo 5 mil reais por dia - o cliente pode retirar no máximo 3 vídeos por dia - prazo entrega de no máximo de 3 dias para qualquer qtde pega - para usar o TED só com valores acima de 5 mil - o cadastro tem que ser renovado a cada ano - ter cuidado de não colocar validação

Requisitos existem em vários níveis
Necessidades do Stakeholder O que Como Características do Produto ou Sistema O que Como Requisitos de Software O que Como Requirements exist at many levels. Depending upon your perspective, a specification may be a requirement or a design. For example, a stakeholder’s need is a requirement on the system analysts. The requirements analysts produce a list of features that are requirements on the use-case specifiers. The use cases they write must provide a specification of what the system does to implement those features. The use-case specifiers produce a number of use cases that are requirements on the designers. This pattern continues down the chain. In order to produce the correct system solution description, it is important that there be no misunderstanding as to what the needs of the stakeholders are. Therefore, the qualities of requirements play as much a part when capturing stakeholder needs as they do when you write the detailed software requirements. Especificação de Design Procedimentos de Teste Planos de Documentação

Gerência de Requisitos Não é Fácil porque…
Nem sempre são óbvios. Vem de várias fontes. Nem sempre é fácil de expressar claramente em palavras. São interelacionados e relacionados a outras entregas do processo de desenvolvimento de software. Tem propriedades únicas ou valores de propriedade. Mudam. São difíceis de controlar quando em grande número. Ask: What are your key problems? No consistent way to organize or understand user needs. Developers and testers receive poorly defined requirements. Documents are difficult to write, review and update. Applications miss customer expectations. "Feature creep" causes schedule delays and cost overruns. No easy way to review feature priorities and status. Can not quickly trace the impact of requirement changes. Requirements are not communicated to the entire team. Unfortunately, the student can usually identify with one or more of these problems. Failing to manage requirements decreases the probability of meeting the project objectives. Requirements management is eliciting, organizing, and documenting requirements of the system. It is a process that establishes and maintains agreement between the customer and team on changing requirements of the system. Communication is a key factor to a successful project. Requirements management is simple in theory, but difficult in practice. There are many reasons for this. Some include: Customers do not always know what they want. As the number of requirements grows, your ability to keep a handle on them all decreases. Relationships between requirements is not easily managed. People in the IT industry generally have trouble writing in a style that is understandable to people who are not as technically inclined. These challenges can be overcome with the right processes in place.

Gerenciamento Requer Estratégia
The requirements management plan should serve as your guiding light. It is used to ensure that you know the types of requirements you are going to collect, how you are going to manage the changes and dependencies between them. Developing a requirements management plan is part of the Analyze the Problem Workflow Detail. It is mentioned here to keep the focus of module 4 on problem analysis and developing the Vision. However, realistically developing an RM plan should be part of the Environment Discipline. Emphasize that up-front planning leads to more consistency and to smoother management of the requirements process. Emphasize the importance of producing a requirements management plan that guides the rest of your development process. RM Plan A Requirements Management Plan (RM Plan) should be developed to specify the information and control mechanisms that are collected and used for measuring, reporting, and controlling changes to the product requirements. Before you start to describe the project requirements, you must decide how to document and organize them. As well, you must decide how to use requirements attributes when managing the requirements throughout the project lifecycle. The RM Plan documents all decisions regarding requirements documents, requirement types, guidelines and strategies for requirement attributes, and requirement traceability. As with the Glossary, the RM Plan is a living document. You should start developing it as soon as the project is begun. You add to it as more decisions are made about attributes and traceability. In the activity called “Manage Dependencies,” you further develop the project. Ideally, your organization should have a standard RM Plan that you can adopt and customize for each project. This helps speed up the Inception phase of the project. What is in a Requirements Management Plan? Types of requirements to collect and where you will collect them. Types of attributes to track. Types of requirements to trace. Types of documents to produce. Management guidelines. Handout RUCS10: RM Plan

Gerenciamento de Requisitos efetivo
Manter um claro estabelecimento dos requisitos requer: Boa qualidade dos requisitos Atributos aplicáveis para cada tipo de requisito Rastreamento para outros requisitos e outros artefatos do projeto O OBJETIVO é entregar produtos de qualidade No tempo e no orçamento que atendam As reais necessidades do usuário. Discuss the goal. We are not here to sell tools. The object of the class is to explore high-leverage techniques to meet a goal. Focus on the three key points, which are highlighted in the following three slides. In the bigger picture, why do you care about requirements management? Over the next few pages, you will explore what is meant by quality, on time and on budget, and real needs.

O que é um “Produto com Qualidade” ?
Qualidade: Velhos Conceitos Satisfaz os documentos de requisitos. Passa nos testes de sistema. Adere ao processo de desenvolvimento. Qualidade: Conceitos Modernos Entende todas as necessidades do usuário. Continuamente revisa todos os artefatos para garantir que atendem às necessidades.  Paradigma baseado em atividades Software development has traditionally been focused on delivering a system that implements a complete requirements specification. The old definition of a quality system was when "the system was delivered as specified", which of course does not ensure the system's success in the stakeholders application environment (Return on Investment). This understanding of quality is consistent with an activity management paradigm. That is, you start your project with a detailed project plan following a detailed process. This involves a leap of faith that the process, if followed, will result in quality. Because there was no “thing” to “touch and feel” as the project progressed, reviewing requirements specifications to assess whether the system would really solve the business problem was a subjective process rather than an objective process. System tests were used to verify that the system was correct instead of having the users accept that it helped solve their problem. The process for the development of the system consists of distinct activities, such as requirements, analysis, design, and test. While adhering to process is important, it is important to understand the dimensions of software quality and how it is achieved. The focus then is on the results. Thus, modern software development practices are more focused on understanding what the stakeholders require from a system in order to solve a business problem. The iterative nature of modern software development practices also ensures that there is a continual review and feedback cycle that can refine the requirements as the project progresses. By delivering functional executable versions of the final product at the end of each iteration, the stakeholders can assess and refine their needs objectively instead of subjectively. The focus is therefore, not focusing on the activities, but on achieving results.  Paradigma baseado em Resultados

Dimensões de Qualidade
Componentes do FURPS+ The FURPS acronym represents a portion of the requirement types for which we should be searching; it reminds us to get nonfunctional (URPS) as well as functional (behavioral) requirements. F unctionality Conjunto de características, segurança, e requisitos em geral U sability Fatores humanos estéticos, consistência, documentação R eliability Frequência/severidade da falha, recuperabilidade, previsibilidade, acurária, MTBF P erformance Velocidade, uso de recrusos, throughput, tempo de resposta S upportability Testabilidade Extensível Adaptabilidade Manutenível Compatibilidade Configurável Disponibilidade Instalável Localizável Robustez The FURPS acronym represents a portion of the requirement types for which you should be searching; it reminds us to get nonfunctional (URPS), as well as functional (behavioral) requirements. The “+” after the FURPS indicates constraints that do not fit into any of these categories. Can you think of some other examples of the types of requirements to look for? Note: MTBF = Mean Time Between Failures

Quanto de trabalho nós podemos fazer?
On Time and On Budget Recursos Quanto de trabalho nós podemos fazer? One way to help emphasize this is to draw a triangle. At the top write “Resources.” On the bottom left write “$” and on the bottom right write “Time.” In the middle write “Requirements scope.” Escopo Scope Scope Scope Because your time and resources (people, money, equipment, and so on) are limited, you can complete only a fixed amount of work. To deliver a product “on time and on budget”, you need to figure out how much work you can actually complete with a given scope, budget, and pool of resources. If any one of the four factors change, you need to make adjustments. For example, if you increase scope, you need to increase one or more of the following: time, money and resources. If you reduce the budget, you need to decrease the scope to deliver the system in the same time and with the same resources. Failure occurs if you keep squeezing more and more into the triangle without moving one of these points to compensate. Of course you want to deliver the maximum value, so be as accurate as possible. Tempo $ Orçamento

Atendendo as reais necessidades do cliente
Como sabemos quais são as necessidades? Característica 1: O sistema deve... Característica 2: O sistema deve Característica 3: O sistema deve Característica 4: O sistema deve Característica 5: O sistema deve Característica 6: O sistema deve Característica 7: O sistema deve Característica n: O sistema deve… On the easel, draw a timeline. Ask for a typical release cycle timeframe: 9-12 months is typical. Now put a column of bullets along the left side to represent the original commitments at the beginning of this release cycle representative of original commitments made to customers. Ask: “In your experience, how long would it take to deliver the full set of original commitments?” Usual answers range from 120%-800% or original time period. A normal average is around 180% (matches results of Standish study). Where do we draw our baseline? The key is to under-promise and over-deliver. Ask: “What factors might influence the order in which we rank these?” Typical answers might be: importance to customer, dependencies, risk, level of effort, stability of the requirement. Write these down as an introduction to the need to collect attributes for your requirements. Mention the term “attributes.” (Post this paper on the wall or have it available to refer to later in the course.) Como determinar prioridade? O que é um baseline? How do you reach agreement on what features should be included in our project? What stakeholder needs do they represent? How should they be prioritized? What should you put in the baseline commitment for delivery? “Baseline” means the set of features that constitutes the agreed-upon basis for development and that can only be changed through a formal procedure. Tempo Data de Início do Projeto Data-Alvo do Lançamento

Possibilitar um acordo entre os envolvidos
Emphasize that the goal of requirements management is to come to agreement with the customer on what the system should do. The Requirements Specification is a “proxy” for the customer. This slide introduces the concept of a requirements model that includes both visual diagrams and textual description. Make sure that you understand and stress throughout the course that the “Software Requirements” for our system are based on the text included in the use-case model, especially the details in the use-case reports,and the Supplementary Specifications. O Objetivo Cliente Grupo de Usuários Sistema a ser construído One of the goals of requirements management is to come to agreement on what the system should do. This agreement is expressed in the requirements specification. Because you probably do not have direct access to your customer and user community at all times and because some customers have been known to change their minds, it is important to write down the agreed-upon requirements of the system to be built. The requirements specification is a “proxy” for the customer. Your requirements specification should be complete enough so that you do not need to continually consult with the customer during implementation. Requirements can be viewed as a “proxy” for the customer because the requirements represent the customer. That is, the requirements provide the details of the customer’s desires and agreement on what the system should do. The requirements should be captured in a form that is understandable to both the customer and the development team. The requirements provide the surrogate goal for the development team while building the system, as well as the criteria for acceptance and validation of the system by the customer upon delivery. Verificação Requisitos Objetivos de sistema Requisitos Adapted from Al Davis

Quais fatores contribuem para o sucesso do Projeto?
Use these figures to emphasize that requirements and user involvement play a critical role in ensuring project success. Back this up with your own war stories or ask the class for their experiences in a project that succeeded or failed because of requirements issues. Emphasize the “Clear Business Objectives.” (This is a good tie in to the business modeling course.) Your business objectives (or business goals) are what focuses the activities that you embark on. Every software project should be supporting some business objective. Otherwise, why are we doing it? Are we wasting our money? Business objectives and Business goals are the same thing. (Objective and goal are synonyms.) In subsequent modules, we refer to business goals to be consistent with an upcoming version of RUP. The full Chaos Report for 1995 is on the Standish Group Web site: Directions for ordering later reports are also given. 10. Outros aspectos 9. Estimativas confiáveis 8. Uso de métodos formais 7. Requisitos básicos firmes 6. Infra de Software padronizada 5. Escopo controlado 4. Objetivos Negociais claros 3. Gerente experiente 2. Envolvimento do Usuário 1. Suporte da Gerência Executiva Os Dez Motivos Fatores de Sucesso 28% dos projetos são completados no orçamento e prazo. 49% dos projetos ultrapassam as estimativas iniciais. - Tempo estoura em média 63%. - Custo ultrapassa em média 45%. 23% dos projetos são cancelados antes de sua conclusão. Notice that numbers 2, 4, 5, 7, 8, and 9 are related to requirements management. These items are covered in this course. The Standish Group surveys the IT industry every two years, beginning in Their Chaos Report provides insight into the success or failure of projects. The 2001 Chaos Report analyzed the historical data of past CHAOS reports and identified the latest factors for project success. Comparing the results of surveys over previous years, the Standish Group concludes that there has been decided improvement in the IT field. Project success rates are up across the board 28% (overall success rate in 1994 was 16% and in 1998 it was 26%), while cost and time overruns were down. Despite this progress, The Standish Group research shows that challenged and failed projects remain the norm, and the cost of failed projects is staggering. Executive management support has replaced user involvement for the first time. According to the Standish Group: “Without a staunch project champion with a solid business vision, projects can drift into a technical or political abyss.” The CHAOS ingredients for the recipe for success are: “Reduce requirements to a bare minimum, providing constant communication systems and coupling those with a standard infrastructure. Mix these with good stakeholders, an iterative process, project management tools, adherence to key roles, and success is practically in the oven.” The 2001 Chaos Report also reinforced that project success is positively correlated with small project size, short project duration, and small team size. Small projects are easier to manage and plan: “… no more than four people, for no longer than four months at a cost of less than $500,000.” Standish Group, ‘01 (

Tamanho é importante Sucesso pelo Tamanho do Projeto Taxa de Sucesso
The Standish Group believes that three key metrics can pinpoint a project’s success potential: project size, team size, and project duration. This information is significant because it shows that the larger your project, the more important it is to manage your requirements. It is important to convey the point that no project over $10M succeeded! Taxa de Sucesso (%) The Standish Group believes that three key metrics can pinpoint a project’s success potential: project size, team size, and project duration. Although one school of thought would argue that larger projects with more funding and resources should be more successful and should produce more function, the reverse appears to be true. Smaller projects tend to be more manageable. How does this relate to requirements management? Smaller projects have smaller teams. Smaller projects have fewer requirements. Smaller projects have fewer communication issues. Smaller projects are easier to manage. Smaller projects usually target more focused business objectives. It is an interesting paradox that, although we know what we are doing wrong, we still continue to make the same mistakes and projects continue to fail. Does this mean that, if you are on an ambitious project that has a large team and is running over many years you are destined to fail? Absolutely not! But it does mean that if you fail to mitigate the risks these factors present, you will be more likely to fail. Effective requirements management goes a long way to mitigating these risks. Note: The latest CHAOS report did not provide enough specific data to allow this chart to be updated. While the data are a little old, they still support this statement in the 2001 report: “… This year’s CHAOS recipe calls for no more than four people, for no longer than four months at a cost of less than $500,000. …” Standish Group, ‘99 (

O alto custo dos Requisitos Errados
A regra do Use this slide to explain the rule. Before you get to the actual costs, illustrate the costs with some real examples. Ask if there is anybody in the class who writes requirements specifications. Ask him/her what he/she needs to correct an error in a requirement BEFORE the Requirements Specification is released for the first time. The answer is probably to get approval and to change the text. Then ask if somebody in the class is a tester. Ask him/her what he/she needs to do to correct an error found during acceptance test. The answer is probably very lengthy. The difference in cost between fixing a requirement initially and during testing. Now explain the rule with the pyramid. The figures are the order-of- magnitude relative costs of fixing a requirement error during requirements capture, coding, and testing. Mention the Boehm and Grady studies that found similar relative costs. Avoid getting caught up in the fractions and other details. Help students understand that requirement errors are obviously the most expensive cost if they are not discovered until later in the lifecycle. Em tempo de Requisitos .5 - 1 “All together, the results show as much as a 200:1 cost ratio between finding errors in the requirements and maintenance stages of the software lifecycle.” Design 2.5 Codificação 5 10 Teste Unitário 25 Teste de Aceitação The most expensive errors to correct are those introduced at Requirements Time and not found until after release to the customer. These same errors are also the least expensive to correct if found during Requirements Time. The longer they exist, the more expensive they become. The figure shows the order-of-magnitude relative costs of fixing a requirement error during requirements capture, coding, and testing. Note: This formula is based on a waterfall process model. While an iterative process should reduce the cost of requirement errors, it still holds true that the later an error is found in the process, the more expensive it is to fix. 100 Manutenção Custo relativo para reparar erros: Quando Introduzidos X Quando reparados. Boehm 1988

Ajuda para Projetos serem bem sucedidos
Emphasize that you need to pay attention to the factors that the Standish report noted: involve users and get complete requirements specifications. Key concepts of use-case modeling: actors and use cases. Use cases help projects succeed because they give us the real requirements, from the user’s own perspective: who uses the system and what do they want to accomplish with the help of the system. Use cases are a key mechanism in managing requirements throughout the development process. One bullet that we could add to this slide if there were room is “Project Management.” The CHAOS report found that effective project management is also key to successful projects. Análise dos Problemas Entender o Problema. Obter o entendimento com os stakeholders. Estabelecimento claro dos objetivos de negócio. Elicitação de Requisitos Identificar quem utilizará o sistema (atores). Elicitar como o sistema será usado (casos de uso). Gerenciamento de Requisitos Especificar os requisitos de forma completa. Gerenciar expectativas, mudanças, e erros. Controlar quebra de escopo. Listar todos os membros da equipe. In order to help projects succeed, pay attention to the factors that the Standish report noted, especially, “Involve users, get complete requirements specifications, and obtain a clear statement of business objectives.” Do not waste time solving the wrong problem. You need to make sure you understand all the user’s needs. As you’ll see in the following module, use cases are a way to organize requirements from a user perspective. All of the requirements for a user to accomplish a particular task are gathered together in a single use case. The use-case model is the collection of all the individual use cases. Because use cases are specified from the user’s perspective, the use-case model is ideal for communicating the proposed system’s functionality and behavior to the customer or user. How do you know that you are developing the right system? Ask the users and the customer if the use-case model is what they want to do with the system. The use-case model is also key to developing the right system. What do your designers design to? They design a system that allows users to do the tasks specified in the use-case model. What do your testers test? They test to make sure that the system is able to perform all the use cases. What will the user documentation look like? It documents how to do all the tasks in the use cases. Could you use help in these areas with your current requirements management process?

Envolvendo toda a Equipe com os Requisitos
Use this slide to seed discussion for ideas for involving the product development team during requirement activities. Desenvolvedores, Testadores, e Autores Ajuda a desenvolveder as práticas de gerenciamento de requisitos. Monitora a aderência às boas práticas. Verifica o processo de elicitação. Documenta requisitos. Participa das revisões sobre os requisitos. Participa como membro do Comitê de Controle de Mudanças (CCM). Revisa as matrizes de rastreabilidade. Verifica qualidade, testabilidade, e completude. What are some of the ways members of different groups of the development team can be involved in your requirements activities? What are the advantages of involving the whole product development team during requirement activities? The main advantage is that the team gains a better understanding of the requirements and why they are important to the client. What are some other advantages? Most recommendations regarding standards for the software development process include a strong recommendation to involve the development team in requirement activities. For instance, the recommendation is included in the Capability Maturity Model (CMM).

O resultado é pior quando a qualidade é baixa
This is a transition slide to the “Qualities of Requirements” slide. Quality can be measured in many ways. Some examples are: system availability, bugs, and response times. However, another dimension of quality is the quality of the requirements set. In the next few pages, what makes a quality requirement is discussed. Meeting the customer’s real needs is one of the goals of developing a system. As quality decreases, the ability to meet the customer’s needs also decreases. If the system is not meeting the customer’s needs, then the perceived value of the system diminishes. The examples of quality listed above are all observable in the delivered system. They are a bi-product of the quality of the requirements that are implemented. A system can be no better than the requirements used to specify that system. ? ? ? ?

Qualidades do Conjunto de requisitos de software
Correto É a descrição correta sobre o que o sistema deve fazer. Completo Descreve todos os requisitos significantes para o contexto do negócio e do usuário. Consistente Não está em conflito com outros requisitos. Não ambíguo Está sujeito a apenas UM entendimento. These are the qualities of requirements within a requirements set (Software Requirements Specification in RUP. We have not introduced SRS yet, but you can mention it if you wish.) Use the questions in the student notes to illustrate the kinds of issues that people should think about when writing good requirements specifications. These qualities of good specifications apply whether you are using a traditional approach or a use-case approach. It is always good to keep these qualities in mind from the very beginning of a project. Writing your SRS with these qualities in mind ensures quality at all stages of development. Correct Does every requirement state something required of the system? “A set of requirements is correct if and only if every requirement stated therein represents something required of the system to be built.” Davis (1993) It is not possible to determine if a requirement is correct simply by reading the requirement. The correctness is verified by a subject-matter expert during a review. Complete Does the set of requirements include all significant requirements, whether related to functionality, performance, design constraints, attributes, or external interfaces? Have the expected ranges of input values in all possible scenarios been identified and addressed? Have responses been included to both valid and invalid input values? Do all figures, tables, and diagrams include full labels, references, and definitions of all terms and units of measure? Consistent Is it internally consistent, with no subset of individual requirements described which are in conflict? (Examples: Vision document, the use-case model, and the Supplementary Specifications.) Unambiguous Does each requirement have one, and only one, interpretation?

Qualidades do Conjunto de Requisitos (cont.)
Briefly review this list that is continued from the previous slide. This list of qualities for a good Software Requirements Specification is completed on the next slide. This information comes from Leffingwell and Widrig, 1999, pages Use the questions in the student notes to illustrate the kinds of issues that people should think about when writing good requirements specifications. Verificável Pode ser testado sem grandes custos. Classificável por importância e estabilidade Pode ser classificado por importância para o cliente e estabilidade do requisito em si. Modificável Mudanças não afetam a estrutura do todo. Rastreável A origem de cada requisito pode ser apontada. Claro Compreendido por usuários e desenvolvedores. Verifiable Is every requirement stated verifiable? Is there some finite cost-effective process with which a person or machine can check that the software product meets the requirement? Ability to Rank Requirements Has each requirement been tagged with an identifier to indicate either the importance or stability of that particular requirement? Modifiable Are the structure and style of the requirements in the software requirements set (use cases, supplementary specification, or software requirements specification) such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style? Has redundancy been identified, minimized, and cross-referenced? Traceable Does each requirement have a clear identifier? Is it distinguishable from non-essential statements in the requirements set? Is the origin of each requirement clear? Is backward traceability maintained by explicitly referencing earlier artifacts? Is a reasonable amount of forward traceability maintained to artifacts spawned by the requirements set? For example, test cases. Leffingwell & Widrig (1999). IEEE , § 4.3.2, 1994

Qualidades de um Requisito: Verificável
Um requisito é verificável se: É algo finito, em que uma pessoa ou máquina (com custo viável) pode checar se o produto atende ao requisito definido junto ao usuário. Discuss each of the requirement statements and ask, “Is this testable?” What does it mean to “support”? Just logged on? What if they’re all accessing the same database record at the same time? What does it mean to “respond”? Display a little hourglass signal? (That may be okay for a big operation.) And what about “in 500 msec”? What if it is 490 msec? Maybe refer to an RGB value or a pantone color number. What does 24x7 really mean? Are there allowable scheduled outages for maintenance? What is an acceptable number of times the system can crash in a year? If it does go down, what is the an acceptable outage time? When you ask these questions you usually find that an acceptable availability is much lower. For example, if 24 hours of downtime a year is acceptable, then this is still 99.73% availability! Most importantly, how can you test 24x7? What is “view data”? For RequisitePro, for instance, this may be very clear and may be a testable requirement. - O sistema suporta acima de 1000 usuários simultâneos. - O sistema deve responder a qualquer consulta em 500ms. - A cor deve ser um agradável verde sombreado. - O sistema deve estar disponível em 24 x 7. O sistema deve exportar visões dos dados em formato texto, separado por vírgula de acordo com o IEEE. Look at each of the above requirement statements and ask, “How can you measure that this requirement has been met?” Use your glossary to define key terms. Estes requisitos são verificáveis? Se não, qual o melhor modo de definí-los? IEEE , § 4.3.2, 1994

Qualidades de um requisito: Rastreável
See student notes. Requisições do Stakeholder Características Traceability (as defined by your RM Plan) allows you to determine the origins of any requirement. Software is expensive and difficult to develop. It is, therefore, important that you only deliver a solution that solves the business problem no more and no less. Traceability is bi-directional. In the example, you can trace from Stakeholder Requests to Features and vice versa. A requirement that does not directly fulfill a stakeholder’s need is scope creep. The ability to trace the origins of a requirement is an important quality measure. A stakeholder request that you cannot trace to some implementation means some requirements have been missed. Traceability allows us to: Assess the project impact of a change in a requirement. Assess the impact of a failure of a test on requirements (that is, if the test fails, the requirement may not be satisfied). Manage the scope of the project. Verify that all requirements of the system are fulfilled by the implementation. Verify that the application does only what it was intended to do. Manage change. Casos de Uso Suplementar

Qualidades de um Requisito: Não ambíguo
Let’s go into a little more depth about writing unambiguous specifications. O requisito é não ambíguo se tiver apenas uma interpretação. “A deve ir de B para C” Requisito A Each stakeholder should have the same interpretation of what a particular requirement means. Some hints for writing unambiguous requirements are: Use natural language for most of the specification. Write as clearly and concisely as possible. Organize the requirements into use cases so that the context of the requirement is clear. The context often eliminates the ambiguity. Use pictures, diagrams, and dialogs to further illustrate the intent and features of the application. Augment with formal techniques to fully define the functionality. Always start by describing the requirement using natural language or text. Do not immediately jump into structured or formal techniques unless it is needed for understandability by the readers. Use the Glossary. “A deve ir de B para C” “A deve ir de B para C” ref - IEEE 830

O que NÃO é um Requisito? Como realizar os requisitos.
O Modelo de Design espefica componentes de um sistema ou suas interfaces com outros sub-componentes. Como saber se os requisitos estão sendo atendidos. Um Test Suite contém um conjunto de scripts de teste e logs de teste. Quando os requisitos atendem. O Plano de desenvolvimento de software especifica cronograma, planos de verificação e validação, e planos de gerenciamento de configuração. Design Verificação The Design model is an object model describing the realization of the use cases and serves as an abstraction of the implementation model and its source code. The Design model is used as essential input to activities in implementation and test. The Test Suite is a package-like artifact used to group collections of Test Scripts, both to sequence the execution of the tests and to provide a useful and related set of Test Log information from which Test Results can be determined. The Test Suite and the requirements set are usually separate documents because they have different authors and audiences. However, some customers, such as the U.S. Military, may require that the requirements set include the Test Suite. A Test Script is the step-by-step instructions that realize a test, enabling its execution. Test Scripts may take the form of either documented textual instructions that are executed manually or computer readable instructions that enable automated test execution. The Software Development Plan is a comprehensive, composite artifact, which gathers all information required to manage the project. It encloses a number of artifacts developed during the Inception phase and maintained throughout the project. Dados de Projeto

RUP: Um Framework para Gerência de Requisitos
Transition slide to the Requirements Management discipline. The Rational Unified Process® or RUP® product is a framework for a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget. The RUP provides eight disciplines that provide guidance on everything from business modeling to project management. The purpose of the Requirements discipline is to provide guidance on: Establishing and maintaining agreement with the customers and other stakeholders on what the system should do. Providing system developers with a better understanding of the system requirements. Defining the boundaries of (delimit) the system. Providing a basis for planning the technical contents of iterations. Providing a basis for estimating cost and time to develop the system. The RUP is a framework because no two projects are developed the same way. Each project has different development needs. You therefore create a “development case” for each project. This development case describes which activities you perform and when you perform them, and which artifacts you produce.

Disciplina de Requisitos: Detalhes do Workflow
This is the first time we look at the workflow details within the Requirements Discipline in RUP. The workflow details are exactly the activities we are studying in this course. Go through the workflow details, and how they fit in the Requirements discipline. If you are presenting this course onsite at a company not using RUP, discuss the activities they use to accomplish the objective of analyzing the problem. Refer back to the requirements pyramid on slide 2-3 and illustrate how the RM discipline provides a path through the pyramid. This diagram shows the Requirements Discipline in the Rational Unified Process. The major activities in the Requirements discipline are called workflow details. What are the major activities for requirements management in your own software development process?

Papéis e Artefatos These are the roles (formerly called “workers”) and artifacts involved in the entire RUP Requirements discipline. You can give a brief description of the role of each of these roles in the project. Roles are probably not job titles, rather roles that individuals play throughout the development of the product. Do not go into too much detail on the artifacts. They are covered later in the course. In the RUP, the system analyst role leads and coordinates requirements elicitation and use-case modeling by outlining the system's functionality and delimiting the system. For example, establishing what actors and use cases exist and how they interact. The requirements specifier role details the specification of a part of the system's functionality by describing the requirements aspect of one or several use cases and other supporting software requirements. The requirements specifier may also be responsible for a use-case package and maintain the integrity of that package. It is recommended that the requirements specifier responsible for a use-case package is also responsible for its contained use cases and actors. Another important role in the Requirements discipline is the requirements reviewer (not shown here), who plans and conducts the formal review of the use-case model and other requirements. You will describe these roles and artifacts as you go through the MRMUC course.

Quais artefatos são usados
Onde o problema é definido? Onde os stakeholders e usuários são listados? Onde os ambientes e plataformas são identificadas? Visão Onde os requisitos não funcionais estão localizados? Especificação Suplementar Especificações de Caso de uso Onde os casos de uso são mantidos? There are a number of different artifacts that you need to work with when managing your software requirements. Above is a brief list to help you visualize what goes where. Your Requirements Management Plan dictates what artifacts you use to capture your requirements. The RM Plan should be treated as a first-class-citizen and used to guide you through the requirements process. Onde o vocabulário comum está descrito? Glossário Onde as Necessidades e Requisições dos stakeholders são capturadas? Requisições do Stakeholder

Onde estamos na disciplina de Requisitos?
Show the Analyze the Problem workflow detail and how it fits in the Requirements discipline. Emphasize that this part of the Requirements discipline is performed when the problem to be solved is not already well-understood. If you are presenting this course onsite at a company not using RUP, discuss the activities they use to accomplish the objective of analyzing the problem. Use the pyramid you drew on easel paper to further position this module. Point to the problem and the problem space. Where does the Analyze the Problem detail workflow fit in our development process? This diagram shows the Requirements Discipline in the Rational Unified Process. In this module, we study the workflow detail called “Analyze the Problem.” It is a part of the Requirements Discipline that is performed when the problem to be solved is not already well-understood. Where is the “Analyze the Problem” activity done in your own software development process?

Análise do Problema: Atividades e Artefatos
Point out the roles, activities, and artifacts. The part of the workflow diagram given here shows the major activities and output artifacts. When discussing this slide, point out that the artifacts listed all benefit from the work we do in analyzing the problem. Much of this is used in the Vision document, which we continue to develop in the next two modules. You can point out that the Requirements Attributes start to be collected at this time. This is discussed in detail in the Managing Scope module. The first step in any problem analysis is to make sure that all parties involved agree on what the problem is that needs to be solved, or opportunity that will be realized by the system. In order to help avoid misunderstandings, it is important to agree on common terminology which will be used throughout the project. Starting early in the lifecycle, define your project terms in a glossary which can be maintained throughout the life of the project. To fully understand the problem(s) that needs to be addressed, it is very important to know who the stakeholders are in the conceptual vision for the project. Note that some of these stakeholders, the users of the system, are represented by actors in your use-case model. The primary artifact in which you capture the information gained from your problem analysis is the Vision, which identifies the high-level user or customer view of the system to be built. In the Vision, initial high-level requirements identify the key features it is desired that the appropriate solution will provide. These are typically expressed as a set of high-level features the system might possess in order to solve the most critical problems. Key stakeholders should be involved in gathering the set of features to be considered, which might be gathered in a requirements workshop. The features can then be assigned attributes, such as rationale, relative value or priority, source of request and so on, so that dependencies and work plans can begin to be managed. To determine the initial scope for your project, the boundaries of the system must be agreed upon. The system analyst identifies users and systems represented by actors which interact with the system.

Análise do Problema We begin by looking at the “Develop Vision” activity. The first part of developing a vision for a product is to analyze the problem. Ask: “How many people here studied Computer Science?” “How many remember taking a course in compilers?” “How many of you remember taking a course in figuring out what the problem is that you’re trying to solve?” This is not usually taught in traditional computer science education. É o processo de entender os problemas do mundo real, e como eles se relacionam com as necessidades dos stakeholders, e propor soluções para atender a estas necessidades. Qual o objetivo da Análise de Problemas? Ter um melhor entendimento antes de começar o desenvolvimento. Identificar as causas-raiz. Ajudar na identificação da solução. Evitar o: “Sim, mas…” Minimizar o trabalho extra. What is the problem, really? Step back and analyze what problem our system addresses. There may be many different solutions that could fit our Problem Space. Our first step is to understand the problem, identify the best solution, and figure out the stakeholders’ needs in this area. Why is this important? First, if you want to satisfy the customer’s real needs, you must understand what problem they are trying to solve. You want to avoid hearing a “Yes, but...” when you deliver the final product, for example: “Yes, it meets the requirements, but it does not solve my problem.” Second, if you want to avoid extra work, it pays to focus on the real problem and focus on the part of the problem that you actually need to solve. Solving the wrong part of the problem means you might have to go back and redo much of your work. Third, understanding the problem is the first step in understanding the requirements. Customers often describe the problem in terms of their own needs, but each need can be associated with a high-level requirement: In the problem statement, the subject is the customer “I need to …” In the corresponding requirement, the subject is the system “The system provides …” Qual o problema real?

Definição do Problema (Problema)
This definition of “problem” comes from Gause and Weinberg. They have an excellent discussion of problem analysis. See student notes about what to emphasize. The gap between the current situation and the desired state is the problem. Is it really the problem? Ask: “How do you think we can alter a person’s perception of a problem?” Answer: It is possible to alter a problem definition by shifting the perceived or desired situation. Some example answers: “Cost can alter a desired situation.” “Training can alter your perceived situation.” Um problema pode ser definido como uma diferença entre as coisas como são percebidas e como são desejadas. (Problema) If a difference does not exist between what you perceive you have and what you desire to have, then there is no problem. In our process, we first need to understand if there really is a problem. This definition of a “problem” is different from many other ways to define the word “problem.” It addresses the gap between our perceptions of what our customer wants and what they actually desire. One advantage of this definition is that it emphasizes that there are many ways to solve a problem: Change the customers’ perception of what they have now. For example, many of the requests for enhancements that Microsoft gets are for features that already exist. Change the customers’ current desire. For example, if the customers find that what they want will cost millions of dollars over their budget, then maybe they will scale back their desires and focus on solving a simpler problem. Change the gap between what customers want and what they actually desire. A software solution is usually an attempt to narrow the gap. Percebido Desejado

Passos para a Análise do Problema
Briefly run through this list and explain that we will do each in the coming slides. Identificar os stakeholders. Entender as causas-raiz. Chegar a um entendimento sobre os problemas. Identificar as restrições do sistema e do projeto. Identificar e validar a solução em relação as causas-raiz. Definir a fronteira (escopo) do sistema. Above is a list of activities that you go through when performing a problem analysis. Start by identifying stakeholders for the problem. These stakeholders are people who are affected by the problem. Next, understand the root causes for the problem (the real problem behind the problem). Once the real problem (root cause) has been identified, get all your stakeholders to agree to a description of the problem. Armed with a description of the problem, identify any constraints that may be imposed on any solution. These constraints typically limit the solution you may provide. Next, identify possible solutions for the problem. It is important that you identify more than one possible solution. By doing this, you can then compare and contrast the solutions to find the best possible solution. An additional step not described above is to expand the set of stakeholders to include those affected by the specific solution you have identified. The final step is to define the boundary of the solution. This is used to limit the scope during Understand Stakeholder’s Needs.

Roadmap da Análise de Problemas
Problema de Negócio Identifique stakeholders para o problema. Análise da Causa-Raiz. Idéia de Solução ou Oportunidade Emphasize: No matter how you start your project (business problem or an idea for a system), it is important that you go through the same steps to make sure the solution adds business value. In this slide, the boxes show the stages and the arrows show the activity being performed to get to the next stage. Use this to help describe: There are two sets of stakeholders, one set for the problem and another (expanded) set for the solution. The connection between problem analysis and business modeling. The best solutions are the ones that clearly solve a business problem. Relate this slide back to the Standish slide that mentions a clear statement of business objectives is key to project success. Business Goals is used here to tie it to RUP. Business Goal and Business Objective are synonyms. Note: Each transition arrow relates to upcoming slides. Read the subsequent instructor notes to see how to relate all problem analysis activities back to this slide. Problema de Negócio Definido Problema Atual identificado e definido Entendimento dos Problemas no Contexto dos Objetivos de Negócio. Problema validado/ajustado This slide shows the two typical approaches to defining a system. One approach is where someone has an idea or recognizes a need and develops a product to solve that problem. The other stems from the realization that there is some problem that needs solving. In the case of the former, an analysis of the business problem is often implied or thought out informally. No matter which perspective you start from, it is important to understand where the system fits in the context of the goals of the organization. Failing to do this could mean you develop a system that adds little or no business value. In fact, it is possible that the wrong system could impede an organization from achieving its business goals. Note: The Standish Group uses the term Business Objectives. The Rational Unified Process uses the term Business Goals. They are the same thing. A common reason for project failure is that people start with a solution idea and head straight to development. When the project starts to fail, they almost always back track through this workflow. Escolher as melhores soluções para alcançar os objetivos. Reavaliar qual é a melhor idéia de solução. Elicitar Requisitos Melhor solução identificada Expandir a lista de soluções do stakeholder.

Stakeholders: Definições
By “materially affected” we mean that the system has real importance, or great consequences for the individual. Stakeholder Um indivíduo que é materialmente afetados por uma saída do sistema ou do projeto que está produzindo o sistema. Representante do Stakeholder Um stakeholder representa um ou mais stakeholders. Eles estão diretamente envolvidos na direção, concepção, e no escopo do projeto. There are many sources of requirements. Requirements may come from anyone with an interest in the outcome of a project. It is important to determine who those sources are early in your analysis. End users are the most obvious group to consider, but there are many others that should be included: for instance, who will maintain the system; who has an economic interest in the outcome; who will develop, test, and support the product. Failure to consider some of these stakeholders can lead to unexpected project costs and failures. For example, you might release your project and have the Helpdesk manager saying: “The system is too complicated. We’re losing money on support because our customers cannot use the system.” A Manager of Installations: “It takes too long to install, so we’re losing money with each installation; we can’t bill for the extra time.” You have to consider the input of these stakeholders as part of the early evaluation process. To keep the size of your stakeholder list manageable, it is important that you identify one or two people to represent each stakeholder type. The stakeholder representative should be a domain expert and have the authority to speak on behalf of the group they represent. Some example stakeholders are: Sponsors: Business managers, financiers, shareholders, champions, sellers, marketers, steering committee members, investors. Authorities: Legislative authorities, standards organizations, organizational governance departments, external and internal regulatory bodies, domain experts, technology experts.

Identificar os Stakeholders
Relate this slide back to the “identify stakeholders for the solution” transition on the “Problem Analysis Roadmap” slide. Emphasize the importance of knowing who has the problem. Who is materially affected by solving the problem? The students develop a list of stakeholders for the class project in the exercise at the end of the module. At this point, just have them mention some example of stakeholders for their own projects. If they have trouble coming up with some of their stakeholders, focus on an example of your own, such as an ATM or the e-Bay online auction system. All users of the system are stakeholders because they are materially affected by the system. But there are some stakeholders (for example, stockholders) who are probably not actors because they will never use the system. Make sure your students mention some stakeholders who are not also actors, such as managers or clerks not interacting with the system, and stockholders. Cada grupo de stakeholders precisa de um representante. Nem todos os grupos de stakeholders precisam ser consultados. Vários irão fornecer os requisitos. Clientes, usuários, administradores do sistema Vários podem não fornecer requisitos. Acionistas da empresa Part of analyzing the problem is understanding who has the problem. You need to understand the real stakeholders in your project, in addition to the customer who is paying the bill. Make sure you consider all those affected by the outcome of the system, including stock shareholders, system maintainers, and developers. It is important to consider which stakeholders are sources of requirements. While we must identify all our stakeholders, it is important to focus your efforts where you receive the best return. Some of your stakeholders will not provide you with many or any requirements (for example, shareholders). While these interests certainly need to be considered and represented, you should focus your efforts accordingly. For example, if a system is mission critical, then a shareholder is certainly a stakeholder, but will they have any meaningful requests of the system? Generally, they will not. Who are possible stakeholders for your own projects? Quem destes são stakeholders nos seus projetos?

Descrever Stakeholders no Documento de Visão
Digitador Representante Kelly Hansen Descrição Usuário Tipo O digitador é tipicamente um técnico com conhecimentos em informática. O digitador é treinado e experiente no uso do atual sistema batch de registro. Responsabilidades O digitador é responsável por administrar o cadastro de cursos para cada período letivo. Isto inclui a supervisão administrativa e de permissão de acesso aos dados. Critério de Sucesso Conseguir manter o banco de dados de estudantes e professores, e abrir/fechar cursos para matrícula. Envolvimento A responsabilidade primária dos digitadores será manter o banco de dados de estudantes e professores, e abrir/fechar cursos para matrícula. Também será requerido da área de matrículas…. Entregas Gestor de Revisão – especialmente nas funcionalidades requisitadas pela área de Matrículas. Comentários/ Preocupações Nenhum The example above is an extract from the Stakeholder Profiles section of the Vision. This is an example of a very thorough profile. You may or may not wish to go into this level of detail when describing your stakeholders.

Quais problemas estão por trás dos problemas?
Relate this slide back to the root cause analysis of the “business problem” transition on the “Problem Analysis Roadmap” slide. A fishbone diagram is a method for Root-Cause Analysis. Explain the fishbone technique. Show how to use the fishbone diagram to explore the root causes of the problem. Begin with the customer’s stated problem on the right hand side. Then ask, “Why?” Fill in the contributing causes on the “bones” of the diagram. After the fishbone diagram is filled in, you can choose the key contributor(s) and expand them further using the same technique. Keep asking “why” until the question becomes trivial. Further demonstrate the idea of a fishbone diagram by developing a second-level fishbone diagram. On easel paper, draw another diagram, and put “Need more banking locations” as the problem on the right-hand side of the diagram. Ask for contributing causes to this problem. Answers may be “Need banking nearer residential areas,” “Need cheaper facilities,” etc. Then go on to the Pareto slide to talk about how to the focus on the main contributing causes. Emphasis: You may discover more than one simple problem involved. See student notes (last two paragraphs.) Técnicas do Diagrama de Espinha de Peixe Problema de negócio que foi percebido. Quer privacidade quando sacar Morosidade Sem banco à noite Clientes insatisfeitos com nossos serviços. “Customers are dissatisfied with our service.” Is this really the true problem? The fishbone diagram is one method for finding the “root cause” of a problem. The spines are contributing causes to the problem. Once the root causes have been defined, focus on the ones that contribute most to the problem. You can then further explore the most important root causes to reveal contributing factors to these causes: expand each rib by building spines branching off the rib, or do a separate second-level fishbone diagram with a first-level root cause as “the problem.” What you often discover is that there may be more than one simple problem involved. Instead, there may be many dimensions to and perceptions of what the problem really is. You may need to help the customer focus on the dimensions of the problem that they most need to solve. You help the customer focus on the problem that really needs to be solved. Once you have a list of problems, you then need to perform a little analysis to identify the best solution to the biggest contributors to the problem. This step comes after you have all agreed to the main contributing problems. Filas grandes e lentas nas filiais Bancos nos aeroportos Mais pontos de atendimento Liste as causas que contribuem para o problema detectado. Continue perguntando “Por que?” (expanda cada raia).

Análise do Problema – Validando a solução
Técnicas do Diagrama de Espinha de Peixe Relate this slide back to the root cause analysis of the “business problem” transition on the “Problem Analysis Roadmap” slide. A fishbone diagram is a method for Root-Cause Analysis. Explain the fishbone technique. Show how to use the fishbone diagram to explore the root causes of the problem. Begin with the customer’s stated problem on the right hand side. Then ask, “Why?” Fill in the contributing causes on the “bones” of the diagram. After the fishbone diagram is filled in, you can choose the key contributor(s) and expand them further using the same technique. Keep asking “why” until the question becomes trivial. Further demonstrate the idea of a fishbone diagram by developing a second-level fishbone diagram. On easel paper, draw another diagram, and put “Need more banking locations” as the problem on the right-hand side of the diagram. Ask for contributing causes to this problem. Answers may be “Need banking nearer residential areas,” “Need cheaper facilities,” etc. Then go on to the Pareto slide to talk about how to the focus on the main contributing causes. Emphasis: You may discover more than one simple problem involved. See student notes (last two paragraphs.) Solução percebida para os problemas. Quer privacidade quando sacar Sem banco à noite Morosidade Mais Máquinas de Auto Atendimento. “Customers are dissatisfied with our service.” Is this really the true problem? The fishbone diagram is one method for finding the “root cause” of a problem. The spines are contributing causes to the problem. Once the root causes have been defined, focus on the ones that contribute most to the problem. You can then further explore the most important root causes to reveal contributing factors to these causes: expand each rib by building spines branching off the rib, or do a separate second-level fishbone diagram with a first-level root cause as “the problem.” What you often discover is that there may be more than one simple problem involved. Instead, there may be many dimensions to and perceptions of what the problem really is. You may need to help the customer focus on the dimensions of the problem that they most need to solve. You help the customer focus on the problem that really needs to be solved. Once you have a list of problems, you then need to perform a little analysis to identify the best solution to the biggest contributors to the problem. This step comes after you have all agreed to the main contributing problems. Mais pontos de atendimento Filas grandes e lentas nas filiais Bancos nos aeroportos Liste as razões que justificam a solução. Continue perguntando “Por que?” (expanda cada raia).

Foco nos que mais contribuem – Lei de Pareto
One way of focusing on the most important root causes of a problem is the Pareto Principle, or “80-20 rule.” Vilfredo Pareto, a turn-of-the-century Italian economist, studied the distributions of wealth in different countries, concluding that a fairly consistent minority, about 20 percent of people, controlled the large majority, about 80 percent, of a society's wealth. This same 80/20 distribution has been observed in many other areas and has been termed the Pareto effect, Pareto Principle, or Rule. The Pareto effect operates in quality improvement: 80 percent of the problems usually stem from 20 percent of the root causes. Pareto charts are used to display the Pareto principle in action, arranging data so that the few vital factors that are causing most of the problems reveal themselves. Concentrating improvement efforts on these few has a greater impact and is more cost-effective than undirected efforts. The top 20 percent of the root causes are the problems you want to solve. These root causes are captured in the problem statement. 80% 20% do esforço originam em 80% de benefício. Benefício One way of focusing on the most important root causes is the Pareto Principle, or “80-20 rule.” A Pareto chart ranks the contributing causes in the order of their contribution to the problem, so it is easy to see the largest contributors. A Pareto diagram can also be thought of as a “Fishbone diagram with numbers. ” Assign a weight to each bone and then graph it. Notice that in the example, 80% of the problem is caused by the top two contributors. Where do the percentages come from? In some situations, you can measure how much each factor contributes to a problem. For example, if a mail order business is getting too many products returned, the business can ask each customer why the items were returned and tabulate the factors contributing to returns. In other situations, the percentage contributions are estimates. For example, if a business is investigating the need for ATM machines, they can use focus groups to estimate the perceived problems associated with a lack of such facilities. In many cases, rough estimates are used rather than hard data. In some cases, the top contributing causes are obvious. Focus on the top contributing causes rather than coming up with solutions to minor factors. 20% Esforço Classifique por ordem. Use a regra do para focar nas principais causas responsáveis pelas grandes porções de problema. 5 10 15 20 25 30 35 40 45 50 Contributing Causes Banking at Night More banking locations Banking at airport Queues too long Privacy while banking Other Reasons % Contribution

Compreender o contexto maior do problema
Relate this slide back to the “understand the problem in the context of the business goals” transition on the “Problem Analysis Roadmap” slide. This is a good opportunity to mention the Standish slide in Module 1. The Standish Group emphasizes the importance of a clear statement of business objectives, but unfortunately this is the most important step that is often overlooked. A clear statement of your business’ goals helps focus the system’s features and prevents scope creep. Identifying a set of features without an understanding of the problem either: Solves problems that do not exist or Does not solve the problem Or both In the case of independent software vendors, they appear to be not solving a problem as much as they are recognizing and capitalizing on an opportunity. However, they are solving someone’s problem. If these steps are not performed for ISVs, then they are more likely to produce a system that looks like it will solve a problem until it is deployed. Then users are more likely to say “That’s great, but it would be really useful if it did ….” A falta de entendimento do negócio e seus objetivos aumenta o risco. O problema está em algum componente do processo/empresa? A equipe entende qual o domínio do problema? A solução do problema cria oportunidades de melhoria do processo? Armed with a clear definition of the root causes to the business problem, it is important to ensure that the solution supports the business both operationally and strategically. A new system might also provide the organization with the opportunity to improve the way it operates. To do this, a more thorough understanding of the business may be required. Business modeling is a tool that you can use to help you answer these questions. Some reasons to perform business modeling are: To identify what to automate in a business. To show how a tool can be used in the business. As the first step in re-engineering the way a business currently conducts business. Some reasons to skip business modeling are: The product is a commercial product, rather than a contract (such as MS Word). The product’s domain is well understood by the development team and clients.

Disciplinas de Modelagem de Negócio e Requisitos
To truly understand a problem you must understand the broader context of the environment the problem exists within. Business modeling is a tool you can use to help you understand the bigger picture. The Rational Unified Process provides a discipline that guides you through the business modeling activities.

Modelos de Negócio Modelo de Organização estrutural e dinâmico.
Processos de Negócio Estrutura Organizacional Papéis e responsabilidades Visualize a organização e seus negócios. Ajude a entender os problemas atuais. Identifique potenciais melhorias. Derive e valide os requisitos de sistema necessários à Organização. To develop the right business requirements, it might be necessary for us to explore the business and document how it works. Why do organizations make business models? To help derive the correct requirements that solve the business problem. To understand the environment in which a solution will be deployed. What does a business model consist of? See list on slide. Use examples to bring the idea of a business model to life. For example, for a traditional stock brokerage: Business processes include: brokering stock transactions (buy and sell stock) and reporting stock sales to the IRS. Organizational structure include: the sales department, the back office. Roles and responsibilities: for example, brokers take customer orders, place orders with stock exchanges, etc. Products: for example, transaction processing. Events include: take a customer order, place an order on a stock exchange, receive confirmation, notify customer of sale price, etc. Produtos Entregas Eventos Business models enable us to consider the broader context. Even when we are focused on a specific application to be implemented, a business model enables us to develop the correct solution that solves the business problem. The purposes of business modeling are to: Understand current problems in the target organization and identify improvement potentials. Understand the structure and the dynamics of the organization in which a system is to be deployed (the target organization). The business model provides a visual and textual model of the organization and its processes. Ensure that customers, end users, and developers have a common understanding of the target organization. Derive the system requirements needed to support the target organization. To achieve these goals, the business modeling describes a vision of the target organization. Based on this vision, the business model defines the processes, roles, and responsibilities of that organization. If a business model is available, it can provide important input into the requirements elicitation process. It provides a context for system requirements, and it promotes a common understanding of the needs of the target organization(s).

Descrever o problema no Documento de Visão
Requisições do Stakeholder In this module, we are focusing on defining the high level documents: the Vision document. Definição do Problema Documento de Visão Here is the requirement structure you use in the class and the specification artifacts in which they are captured. In this module, you focus on defining the Vision for the product. Especificação Suplementar Modelo de Caso de Uso Especificações de Design Especificações de Manual do Usuário

Documento de Visão As mesmas informações para gerência, marketing, e equipe de projeto. Fornece o feedback inicial do cliente. Promove uma compreensão única do produto. Define escopo e prioridade em alto-nível das requisições do stakeholder e suas características. Um documento em nível de sistema que descreve o “que” e “porquê” do produto. Stress here that the primary purpose of *any* document is communication! If not, then why have it? Who is the audience? A stapled Vision for the class project is included in the materials. Students use this document to complete various exercises. The primary purpose of any document is communication. You should always be aware of who is reading the document and ensure that they understand its content. The Vision document provides a high-level (sometimes contractual) basis for the more detailed technical requirements. There can also be a formal requirements specification. The Vision captures very high-level requirements (features) and design constraints. It gives the reader an understanding of the system to be developed. It provides input to the project-approval process and is, therefore, intimately related to the Business Case. It communicates the fundamental "whys and whats" related to the project, and it is a gauge against which all future decisions should be validated. In general, the Vision document is read by managers, funding authorities, use-case modelers, and developers. The Vision is a system-level document that describes the “what” and “why” of the product or application. Focuses on: Describing the problem Goals and objectives of the system Identifying and describing the stakeholders User needs Target markets User environments and platforms Product features Visão

Estrutura do Documento de Visão
Go over the outline briefly to focus on the kinds of information the Vision Document records for a project. At this point, it is useful to open RUP and show them an example Vision document template. Point out how the template guides you through filling out the document. Have the students turn to the stapled vision document. Briefly run them through the contents of the Vision. Here we are “showing them the dog house before we ask them to build it.” Tie the template in to the topic of this module by pointing out that the Vision is the high-level definition of the system to be built. Introdução Posicionamento Descrições do Stakeholder e Usuário Visão Geral do Produto Características do Produto Restrições Faixas de Qualidade Precedência e Prioridade Outros Requisitos do Produto Requisitos de Documentação Anexo 1 – Atributos das Características The main activity in the Analyze the Problem Workflow Detail is to develop the Vision for the system. The Vision contains a description of the problem and the high-level definition of the system. This outline shows the major sections of the Vision document. As you can see, the Vision provides a wealth of information about the product to be built. In the Develop the Vision activity, make sure you understand and record the decisions made with your customer about all of the kinds of information in the defined by the Vision template. This information is gathered together in constructing your Vision for the product to be built. This slide summarizes the major activities you have done and how they contribute to the Vision. A sample Vision document can be found in the Student Handouts.

Obtendo o Entendimento do Problema
Descrição do Problema The problem statement helps define the “real” problem by summarizing key issues about the problem. Emphasize that a problem statement can help gain agreement among all stakeholders on the parts of the problem that will be solved. Go over the problem statement chart and the example problem statement given in the student notes. Students use the problem statement as a template for developing a problem statement for the class project (in Exercise 4.1). Note that we’ve seen how to develop several of the individual parts of the problem statement already. Where do the spines of the fishbone diagram go? [Answer: in the description of the problem.] How do we know which spines are worth noting in the problem statement? [Answer: use the Pareto Principle.] Who are our key stakeholders? O problema de (descreva o problema) (os stakeholders afetados pelo problema) afeta O impacto disto é que (qual o impacto do problema) Uma solução de sucesso seria (listar vários benefícios-chave de negócio para uma solução de sucesso) It is often useful to have the group agree on a short, clear statement of the agreed-upon problem that our product addresses. Example: (for a customer support system) The problem of untimely and improper resolution of customer service issues affects our customers, customer support representatives, and service technicians. The impact of which is customer dissatisfaction, perceived lack of quality, unhappy employees and loss of revenue. A successful solution would provide real-time access to a trouble-shooting database by support representatives, and facilitate dispatch of service technicians, in a timely manner, only to those locations that genuinely need their assistance. Visão

Identificar as Restrições
Now that we’ve discussed how to identify actors, finish the discussion of how to develop a vision for the problem we are solving. Ask the class, “What types of constraints have you experienced in your projects?” Let them use this slide as a prompt for ideas. Example answers: The project cannot cost more than $1,000,000 to develop and deploy. Deployment includes the cost of installation and training. The system is to be deployed onto an iceberg in the Artic Circle. The system must, therefore, operate without fault in extreme Arctic temperatures. The system is to be deployed in all government offices across the European Union. (This is not a system constraint, but a project constraint. How do you go about eliciting requirements from people who speak so many different languages?) When eliciting requirements, recognizing that someone’s job will be lost by deploying the system means you might have to be objective about the information they give you. Are they trying to ensure that the system fails? De ambiente Econômicas Políticas Constraints were defined in the Introduction to MRMUC module. Project constraints have the potential to severely impact the ability to successfully provide a solution. Sometimes a constraint may loom like an iceberg. On the surface, there may not appear to be much to it, but on close examination the iceberg may have a large potential impact. Maybe it will not be enough to sink the ship, but it may be enough to knock you way off course! The types of constraints you identify may also influence our choice of elicitation techniques. This is particularly true of political constraints. What types of constraints have you experienced in your projects? Técnicas Viabilidade Sistêmicas

Identificar as melhores soluções de negócio
Relate this slide back to the “choose the best solution(s)” and “reassess the solution idea really is the best solution” transitions on the “Problem Analysis Roadmap” slide. The business solution should address the root causes. You should analyze the root causes and identify the best solutions that solve the problems. Sometimes the solution you identify is not be a technical solution. Identificar as várias soluções para os problemas principais. Técnico, não-técnico, ou ambos. Escolher a que: Melhor resolve as causas-raiz. Suporta os objetivos de negócio. Obter os requisitos que permitem implementar a solução. Once you have all agreed on the problem, you should determine which solution is the best solution. There may be more than one solution to a problem. The key is to come up with the best one.

Definir a fronteira da solução de sistema
Outros sistemas What are the interfaces to outside systems for our project? What’s part of the system? What’s not part of the system? Which of these are actors? Usuários Sistemas Legados Novo Sistema When you define the boundaries of a system you must consider what existing resources you can leverage (other and legacy systems). Who uses the system? Who maintains the system? Who receives the output of the system? (Reports.) How do you communicate with other systems? (Communications.) How do the capabilities of the new system overlap or replace any existing system? What are the interfaces to outside people or systems for your project? Based on our definition of actor, which of these are actors? Relatórios Comunicações Manutenção

Atores ajudam a definir a fronteira do sistema
How can use cases help us figure out these boundaries? Emphasize that an actor is outside the system, so the system does not include the functionality the actor does. Explain the example and the second example on the next page. PC PC Servidor Servidor PC PC An actor is a user of the system but is not part of the system to be developed. A user can be a person or an external system. Identifying the actors helps to define the boundaries of the problem to be solved. Because an actor is not part of the system to be built, you do not have to build the functionality that an actor represents. So, by identifying the actors, you help identify the boundary of the system to be built. If we are developing the client software for the PCs, then the User would be the actor. If we are developing only the server software, then the PC is the actor. PC Quem é o ator? Os módulos do sistema ou o usuário? Usuário

Capturando o Vocabulário comum do sistema
Definir os termos usados no projeto. Ajudar a previnir mal-entendidos. Another important part of beginning a project is to start identifying the common vocabulary. Have students look at the Glossary in the Appendix. How might this help you throughout this course? And afterwards? What do the italicized words indicate? (Other terms defined in the glossary.) Also, mention the Glossary in RUCS2. Do not bother looking at it now because it is very simple, but tell students it is there for reference in the RUCS section of the Student Workbook. Glossário Capturar o Vocabulário Comum Começar o mais cedo possível. Continua durante todo o projeto. Another important part of beginning a project is to start identifying the common vocabulary. Look at the Glossary for a sample. There should be one Glossary for a system. This document is important to all stakeholders, especially when they need to understand and use terms that are specific to the project. There is a sample glossary RUCS2 section of the Student Workbook. All textual descriptions of the system, especially use-case descriptions should use and refer to the terms defined in the glossary. In some cases, you may build a domain model to further visualize the terms in the glossary.

Visualize o Glossário como um modelo de Domínio
Explain the example (see student notes). Emphasize that you may or may not find a visual model like this useful. You definitely want to capture the business terms and objects in a glossary. You may want to represent some of the glossary items in a domain model. Ask students if this domain model helps them understand the RU e-st system requirements. Domain modeling can be used as an alternative to a full business modeling activity. Subset of Business Model Domain modeling benefits: Develops key business objects rapidly Formalizes the vocabulary for the project Simplifies reasoning about different terms Describes relationships between terms Provides visual representation of relationships 1..2 1..* 1 * Cliente Acao Cliente. Transacao A domain model provides a visual model of key business objects that are captured in the glossary. The benefit of a domain model is that the relationships between the glossary terms can be represented visually, thereby improving the stakeholders domain understanding. This is an example of part of a domain model for the RU e-st system. It shows that there are trading customers, trading accounts, and trading transactions. There are three types of trading transactions: market transactions (buy/sell at the current market price), limit transactions (buy/sell at a specific price), or transfers between trading accounts. The numbers on associations between objects indicate how many objects a particular object can be related to. This diagram shows: One trading customer must have one account and can have an unlimited number of accounts. One account is owned by either one trading customer (a single account owner) or two trading customers (a joint account). One transaction (for example, one order to buy stock) is associated with a single account. One trading account can have an unlimited number of transactions associated with it. Transacao geral Limite Credito Transferencia

Curso de Requisitos Módulo 02: Requisitos de Software

Apresentações semelhantes

Apresentação em tema: "Curso de Requisitos Módulo 02: Requisitos de Software"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Curso de Requisitos Módulo 02: Requisitos de Software

Apresentações semelhantes

Apresentação em tema: "Curso de Requisitos Módulo 02: Requisitos de Software"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback