Curso de Requisitos Módulo 03: Requisitos de Software

Curso de Requisitos Módulo 03: 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). Requisitos Funcionais Based on Leffingwell & Widrig, 1999 Requisitos não funcionais

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

Entender Necessidades: Atividades e Artefatos
The key stakeholder needs are documented in the Vision document. In RUP, the objective now is to collect and elicit information from stakeholders in the project. This information can be regarded as a "wish list" that is used as primary input in defining use cases and supplementary requirements. This workflow detail is performed mainly during iterations in the Inception and Elaboration phases. However, stakeholder requests should be gathered throughout the project by reviewing change requests following your Change Request Management process. You should be aware of incoming stakeholder requests throughout the product lifecycle, to make sure you continue to address your stakeholders’ real needs. The key activity is to elicit stakeholder requests and determine the requested features of the system. The primary outputs are a collection of prioritized Stakeholder Needs and Features, as well as the attributes associated with them. These outputs are recorded in the Vision document. Also, during this workflow, you discuss the system in terms of its use cases and actors. Another important output is an updated Glossary of Terms to facilitate a common vocabulary among team members.

Quais são as fontes de Requisitos?
Especif. de Requisitos Modelo de Negócio Planos de Negócio Objetivos Pessoais See student notes. Parceiros Cliente Analista Usuários Domínio do Problema You need to capture requests from all stakeholders and specify how these requests are addressed. Although the system analyst is responsible for gathering this information, many people contribute to it: marketing people, users, customers-anyone who is considered to be a stakeholder in the project. Other examples of external sources for requirements are: Statement of work Request for proposal Mission statement Problem statement Business rules Laws and regulations Legacy systems Business models Any results from requirements elicitation sessions and workshops Visitas ao Site Experts no Negócio Analistas de Mercado Infos Competitivas Requisições Iniciais Relatórios de Erro Mudanças de Requisito

Requisitos Ad-hoc vindos de um cliente
Como é o Processo? Cliente Requisitos Ad-hoc vindos de um cliente Membro do Projeto Emphasize that gathering requirements is an iterative process. It is a process of exploration and discovery, both for the development team and for the client. Emphasize that every time the requirements specifications are rejected, you get new information. One consultant we know sometimes begins the process by giving his customer a specification that is purposely wrong. The customer is then forced to think through his requirements in order to correct it. We’re not recommending such an extreme strategy, but it is interesting to hear that it often works very well. Especificação de Requisitos Rejeitado pelo cliente Especificação corrigida The traditional approach to developing requirements specifications is to strive to get it right the first time and almost always failing in some fundamental way. Modern software development practices recognize that the specifications will almost constantly be wrong in some way, and identify ways to best mitigate the risk as the project goes forward. Continuous discussions should occur between development and the customer until an agreement is reached on the requirements of the system. Expect to rework the requirements until you gain agreement with the customer and the other stakeholders in the project. Some people tend to see each rejection as a failure to get the requirements correct. We encourage you to think instead of the advantages of having the requirements rejected: every time your specifications are rejected, you get new information. When a client says what they DO NOT LIKE, they are giving you important information about what they want instead. This process of rejection helps the client focus on what is important to their organization. Rejeitada Novamente Especificação corrigida Aprovado pelo Cliente

Quais problemas podem ser encontrados?
Stakeholders Tem uma idéia pré-concebida da solução. Não sabem exatamente o que querem. Não conseguem articular o que querem. Pensam que sabem o que querem, mas não reconhecem o que sugeriram quando da entrega. Analistas Eles acham que entendem mais sobre os problemas do usuário do que o próprio usuário. Todo mundo Todo mundo vê as coisas sob seu ponto de vista. Todo mundo é politicamente motivado. Ask: What are some of the problems you have encountered in determining your stakeholder needs? Keep the discussion relatively short. This is a good time to relate the story of the five blind men and the elephant. If you are unfamiliar with the story you can find it here: ? ? What are some of the problems you have encountered in determining your stakeholder needs? Stakeholder Analista

Expressando as Requisições do Stakeholder
STRQ STRQ STRQ STRQ The point to get across in this slide is “stakeholders will often state their needs in a way that makes them sound like features. But they are NOT features. They are not features, they never were features, they just sounded like features.” Another example you can use: Needs: a mini-problem “I need to assess the status of my project.” Features: a capability of the system “I want a trend report that shows the rate issues are being opened and resolved.” At this stage: Both are stakeholder requests Should be recorded and negotiated for inclusion STRQ STRQ “Estudantes precisam de acesso fácil das grades” “Relatórios podem ser impressos” Jumping to solution mode is a common problem we humans have. It is because of this that, when you elicit needs from your stakeholders, you often get them expressed as features instead of a statement of what the stakeholder needs from any solution in order to solve the business problem. What do you do with these needs expressed as features? Do you tell the customer to “hold off – we’ll get to those later”? No. At this stage, it is a stakeholder request and should be recorded as one. At the appropriate time you should assess whether it is valid and then create a feature requirement for it. The text of the new feature may be identical to the text of the stakeholder request. (In the USA DoD standards, the process of copying the text of a requirement to the next level is called allocation. If you reword the requirement when you create it at the next level, it is called derivation.) To understand the need behind a request expressed as a feature, you can perform some problem analysis. For example: “The defect tracking system shall provide a project status trending report.” This is a stakeholder request expressed as a feature. To understand the need that drives this feature, ask “why?” The answer could be something like: “I need to be able to understand if defects being raised faster than they are being resolved.” This is the real need behind the feature, a sub-problem if you like. Either way, you should record every request and then send it through a standard approval process before it is included in the system. Stakeholder requests expressed as features require a little more analysis to test whether they are valid and that they support the business goals of the system. “Os resultados de fim de ano devem ser enviados por para os estudantes” “Listas das turmas são enviadas por após matrículas” “Professores precisam saber quem está matriculado”

O Artefato de Requisição do Stakeholder
Vem dos stakeholders. Tem todas as requisições do stakeholders. É consolidado de várias fontes. , especificação de requisitos do cliente, guardanapos, quadro branco, planilhas, e etc. Usados pelos membros do projeto para criar requisitos e funcionalidades do sistema. Pode conter referências para qualquer tipo de fonte externa. Requisições do Stakeholder Because there are so many sources and formats of stakeholder requests, it is common that they are copied and stored in a database. So although we discuss a “Stakeholder Requests Artifact,” there may be no document that is maintained. Instead, the stakeholder requests are maintained directly in the database. They are then extracted from the database and assembled into a document. Documento de Visão Stakeholder requests come from many sources in many different forms. The most common form is a customer requirements specification. But requests also come via , meetings, informal discussions over lunch, etc. All of these requests need to be recorded somewhere and negotiated for inclusion into the project. One way is for your stakeholder or Product Champion to add it to the requirements management repository as a stakeholder request. It would immediately have a status of “proposed.” The stakeholder requests must then go through a formal negotiation for inclusion in the project. (Failure to do this could lead to massive scope creep.) One problem you will have is that some requests come in documents (usually earlier in the project), and then other requests come in different forms, such as . Managing these different forms can be difficult. A solution to this is to maintain all stakeholder requests in a database. If you are using a tool like RequisitePro, adding the requirements to the database from a document is a simple process. Subsequent work directly in the database is also a simple task. Esp. Supl. Modelo de Caso de Uso Espec. Design Docs do Usuário

Técnicas para Elicitar Requisições do Stakeholder
What follows is a crash course in elicitation techniques. We have selected the techniques on our list because of their usefulness in our experience. We briefly discuss each topic in turn. Beyond the techniques we discuss, there are many other techniques, such as: Production software Task analysis Most techniques discussed in this module are generally useful for eliciting information. We discuss them from the perspective of eliciting needs and features, but the same techniques can be used for all types of requirements (needs, features, software requirements), and at many levels of detail. Note: Use this slide to discuss the different elicitation techniques. If you want additional information on any of the techniques, the Appendix has content about workshops, interviews, questionnaires, role playing, and storyboards. Revisar especificações de requisitos do cliente Workshop de Requisitos Workshops de Casos de Uso Brainstorming e redução de idéias Entrevistas Questionários Role playing Protótipos Storyboards These elicitation techniques are useful for gathering information about stakeholder needs. The techniques can also be used very effectively for gathering information about feature requirements or detailed software requirements. Many of these techniques can be used together. For example, a requirements workshop brings stakeholders together. At the requirements workshop, the participants may brainstorm for new ideas, or they may sketch out the use cases for the system to be built. There are many excellent resources available to learn more about each of these elicitation techniques. The following list provides just a few resources that you can use: Requirements Workshop: Requirements By Collaboration. By Ellen Gottesdiener. Addison-Wesley. ISBN: Interviews: Exploring Requirements: Quality Before Design. D. Gauss & G. Weinburg. Dorset House. ISBN: Questionnaires: Exploring Requirements: Quality Before Design. D. Gauss & G. Weinburg. Dorset House. ISBN: Role Playing: Child's Play: Using Techniques Developed to Elicit Requirements from Children with Adults. N. Millard, P. Lynch, and K. Tracey., Proc. of 3rd Int’l. Conf. on Requirements Eng. (ICRE '98), Colorado Springs, USA, April 6-10, 1998.

Revisar as Especificações do Cliente
See student numbers. Identificar Requisitos. Reconhecer e rotular: Comportamentos da Aplicação Atributos comportamentais Questões e Suposições Perguntar ao cliente. Revisão dos Requisitos Project teams sometimes receive their requirements in a document directly from their customer, especially when contracting to do a job. In this case, it is important to review the customer’s specification to determine what you believe to be the stated requirements. The identified requirements then need to be taken back to the customer to be verified; any issues noted must be addressed and resolved. Keep in mind who wrote the specification. The specification is inevitably written from the author’s perspective. Introductory and overview sections of the specification are important for general understanding of the specifications. Those sections are less likely to contain requirements, but keep in mind there might be misplaced requirements.

Brainstorming Produza o maior número de idéias possíveis.
Emphasize that brainstorming is a way to quickly generate as many ideas as possible. See student notes for other key points. Regras do Brainstorming Esclareça o objetivo da sessão. Gere o maior número de idéias possíveis. Deixe a imaginação voar. Não permita críticas ou debates. Mescle idéias. Brainstorming is a way to quickly generate as many ideas as possible. In the idea generation phase, the emphasis is on quick generation of ideas. In the idea reduction phase, the emphasis is on combining ideas and focusing on the most promising ideas. In order to encourage people to contribute ideas, it is important to finish with idea generation before doing any pruning or criticizing of ideas. Ideas may start to change as people hear ideas and come up with variations on them. This is good because some of the best ideas are those that build on the expertise and creativity of many people in the group. One technique: This is a four-step process. None of the steps should be skipped! Brainstorm the Features that the new Software System should realize. Cover a wall with yellow sticky notes. Classify the Stickies: This process must be done with no talking! Invite everyone to move around the stickies and group those that describe a single feature. Additional stickies can be added at this time, but no one can talk to anyone except to the Facilitator. Name that Feature: the facilitator then looks at each group of stickies, reads the stickies out loud, and helps the group name that feature. Affinitizing only gets you percent in the right groups. Naming the groups realigns the groups. Get rid of some and split up others. You almost always end up with groups. Prioritize the Features: It is critical to understand which are the key features that the software must support. Use a process, such as bullet voting. It is quick and easy and almost always ends up with a clear bell curve.

Brainstorming: Vantagens e Desvantagens
Usado a qualquer tempo, em qualquer lugar. Bom para grupos. Bom para coisas de alto-nível e pressuposições. Bom para algum nível de automação. Desvantagens Se aplica mais a processos em grupo. Não sistemática na forma “clássica”. Description: the requirements engineer asks a group of stakeholders to generate as many ideas as possible with an emphasis on generation rather than on evaluation. Preconditions: a suitable group of stakeholders. Strengths: good for eliciting high-level domain entities and questioning assumptions which might otherwise have constrained approaches considered. Tool support available for some varieties. Weaknesses: susceptible to group processes; unsystematic in "classic" form, though some varieties overcome this.

Redução de Idéias: Podar e organizar
The affinity diagram is used to organize the results of a brainstorming session into manageable groups. It is based on the relationship between the items found during brainstorming. It is a creative, rather than logical process. After all the ideas are collected on the board the participants get up and move the cards or notes into groups that appear to be similar ideas. It is important that this be done silently. A rough guideline is that you will find seven to ten groups. Continue this activity until everyone agrees on the grouping. The participants then discuss the relationships between the grouped items and identify a name for each group of cards or notes. Often one of the cards within the group serves as a title for the entire group; if not, create one and place it over the group. If there are any items that fell into a miscellaneous group, see if they now fit one of the designated groups. Those titles that were selected for the groups can now be studied to gain a better understanding of the original problem. A good reference for affinity diagrams is: H. Beyer and K. Holtzblatt, "Contextual Design: Defining Customer-Centered Systems," Morgan Kaufmann Publishers, 1997. Afine Diagramas

Redução de Idéias: Priorize Idéias
Priorize idéias restantes. Vote Votos cumulativos Compre idéias Voto único Aplique avaliações Critério Não ponderado Ponderado After the idea gathering and pruning are over, organize and evaluate them. There are many ways to evaluate. Go through all the prioritizing methods. The “RU bucks” are a way to do cumulative voting. Each person in the workshop receives a fixed number of dollars. A person gives one “vote” for an idea by putting a dollar on a particular idea. The faces on the dollars are: Ivar Jacobson, Grady Booch and Jim Rumbaugh. If you have time in the class, demonstrate one way of prioritizing idea by having students vote with bucks. Use cumulative voting, where each student gets 3 votes. Have students raise their hands for each item they vote for, and write the number of votes on each idea’s post-it note. What are some ways cumulative voting can be “cheated”? Someone puts all their money on their item which is unpopular with everyone else. What would have been better ways to pay for the features in the previous exercise? Perhaps using “critical”, “important”, “useful” and weighting the Now, what do you do after you have gathered all these “great ideas”? After the idea gathering and pruning are over, organize and evaluate them. There are many ways to evaluate them. One technique you can use to generate a pareto-like diagram is to use a process where the group “buys features”. Buying ideas is a way to do cumulative voting. Each person in the requirements workshop would receive a fixed number of dollars. A person gives one “vote” for an idea by putting a dollar on a particular idea. For example, use cumulative voting, where each person gets three votes. People raise their hands for each item they vote for. The facilitator writes the number of votes on each idea’s post-it note. This method can be abused if someone puts all their money on their item which is unpopular with everyone else. An alternative to voting is to apply names such as “critical”, “important”, “useful” and weighting the Rational University “bucks”

Definição do Sistema: Atividades e Artefatos
The key definitions of the system are the features in the Vision document and the use cases and actors in the use-case model. The purpose of this workflow detail is to: Align the project team in understanding the system. Perform a high-level analysis of the results from collecting stakeholder needs. Document the results formally in models and documents. Typically, the Defining the System workflow detail is only performed in iterations during the Inception and Elaboration phases. Problem Analysis and Understanding Stakeholder Needs create early versions of key system definitions, including: The Vision document. A first outline to the use-case model. The requirements attributes. In Defining the System, the focus is identifying features, actors, and use cases more completely.

Posicionamento do Produto
Comunica a intenção e importância. Review the parts of the Product Position statement for the sample project (see student notes). In the next exercise, the students develop the Product Position Statement for the class project. The student notes have an example product position statement. (cliente alvo) Para Que (declare oportunidade e necessidade) O (nome do produto) É um (tipo de produto) (estabeleça os benefícios, que levaria a investir no produto) Que Diferentemente The product position statement summarizes the unique position the product intends to fill in the marketplace. It emphasizes the intent and importance of the product. A product position statement’s intent is to sell the idea in just a few words. It should have impact and be to-the-point. The complete statement should fit on one page of the easel paper. Sometimes the product position statement is called an “elevator pitch” because of the following scenario: You are stepping into an elevator and have two minutes alone with the V.P. You want to spark his/her interest in this product. You want him/her to look at the Vision document when it shows up on his/her desk. (concorrente) Nosso (diferença para o concorrente) produto Dica: Use declaração do problema como ponto de partida. For Rational Software's existing and prospective customers Who need to get timely solutions to their technical problems while using our products The TSXWEB is a Technical Support External Web Site That brings the latest technologies to the Web and allows for 24X7 technical support, from finding solutions to participating in case activity, in a self-help Web environment, thus passing the control to the customer Unlike the traditional non-Web alternative Our product will provide easy-to-use, accessible, on-line product support that is not dependent on human support personnel

Capture os Requisitos de Software
Requições do Stakeholder Requisições de Stakeholders The relationships between the different artifacts and the use-case-model artifacts. Requisições Chave do Stakeholder e Características Documento de Visão Requisitos de Software Especificação Suplementar Modelo de CSU Especificação de Projeto Especificações de Documentação do Usuário

Passos para criar o Modelo de Casos de Uso
1. Identifique atores e casos de uso. - Descrição Breve. 2. Rabisque cada caso de uso. - Fluxo básico de Eventos. - Fluxos alternativos. 3. Detalhe cada caso de uso. - Detalhe os fluxos de eventos. - Estruture cada fluxo do CSU. - Adicione Detalhes. Condições Pré e Pós, requisitos especiais, relacionamentos, diagramas de caso de uso, e etc. Your use cases will go through brief iterations during development. At this point in development, you are concerned with identifying and briefly describing your use cases. Later, when you refine the system definition, you will detail and structure the use cases’ flows of events. When writing the brief description for a use case you should strive to capture the purpose of the use case and the value it provides to its actors or stakeholders. A brief description should really be no longer than two paragraphs. If it is longer, you may have invested too much time in it. For each brief description, ensure that it captures: Business justification for its existence – the value it provides to the actors and stakeholders. An overview of a couple of the key scenarios. After reading a brief description a reviewer should be able to describe the business reason for its existence as well as a brief overview of some of the key scenarios. An example for the Register for Courses use case is: This use case enables the Student to register for courses at the beginning of a semester. The system allows students to select from a variety of courses that the student has prerequisites for. During the registration process the student can browse current course listings, and add and remove courses from their enrolment list. Once the student has submitted their selections the student cannot make any more changes.

Efetuar Negociação Conta
Exemplo de Diagrama Efetuar Negociação Conta Gerenciar Portfolio This use-case diagram is for the RU e-st system. If you are using the RU e-st system as the class project, use the diagram to compare with the students’ solutions. Note: The sample solution is only one of many possible solutions. If you are doing a class project different than the RU e-st project, use this diagram as an example of a use-case diagram. You may want to show them the example diagram before they do Exercise 6.2 for their own class project. For questions to address, see the Student Notes and the questions at the end of Exercise 6.2. Regarding the question: “How do you know what is done in each use case?” The answer is that you do not know from the diagram. This is a good lead-in to the need to develop the flow of events. Rede Financeira Sistema de Cotações Obter Cotação Executar Negociação Sistema de Negociação na Bolsa Cliente de Negociação Distribuir Notícias Here is a sample (not necessarily optimal) solution, which brings up a lot of questions that need to be answered by the customer or user: Are the use cases too small? For example, should you combine the Manage Portfolio Use Case and Review Account Use Case? Does the diagram cover all activities? For example, in which use case do you think notifying the IRS of sale of stock is done? How do you know what is done in each use case? Note It is not a complete solution; it covers only the goals mentioned in the initial requests. The complete sample solution can be found in the Student Workbook, RUCS4: Use-Case Model Survey. Sistema de Notícias Rever Conta Operador Agendador

Esboço de cada caso de uso
Animation is automatic; structure the flow into steps with either bullets or numbers. Review the basic concepts for developing a use-case outline. See Student Notes. Ask: Why do you think we number the steps in the flows? Answer: It makes the sequence easier to understand. It helps you identify specific steps. Nome do Caso de Uso Descrição Breve Fluxo Básico 1. Primeiro Passo 2. Segundo Passo 3. Terceiro Passo A1 Fluxo Alternativo 1 A2 Fluxo Alternativo 2 A3 Fluxo Alternativo 3 Numerar os passos Estruturar o fluxo em passos Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later you add in the descriptions. The outlines are not official documents, but a start toward developing a document. The outlines would probably be sketched on easel paper at a requirements workshop. The basic flow shows the major steps in accomplishing the goal of the use case. The alternative flows show alternative behavior: what may go wrong and optional behavior.

Porque esboçar casos de uso?
Esboço Muito Peq.? Tamanho do Caso de Uso Muito Grande? É mais de um caso de uso? ? Some of the reasons to outline your use cases are: Iterative development reduces risk. For the same reason we do not implement the whole system in one hit, we do not develop the detailed requirements all at once. Avoid getting bogged down in too much detail too early. You do not know everything at once. Outlining helps you discover what you don’t know. Outlining use cases creates a rough draft for fully specifying your use cases. Outlining helps determine whether the use case is too small on its own or too big to be just one use case. It might also help decide whether the use case is actually more than just one use case. Once you write out your steps, you might find that they really belong in another use case. If the outline shows that the use case does not have much to it, it may not be a use case at all. Outlining adds value to finding all possible alternate flows. Esboçar ajuda a identificar fluxos alternativos Caso de Uso

Fluxo de Eventos (Básico e Alternativo)
This slide adds more depth about basic and alternative flows. Review some reasons to have alternative flows of events. Ask: “Why not just put all the descriptions of all the options into the basic flow of events?” Answer: Because it would be hard to read, like reading a flowchart in text form. The basic flow of events should be relatively short and very easy to read (like a single story). Typically, most of the other descriptions are located in alternative flows. A short example may help to illustrate the different kinds of subflows (see Student Notes). Um fluxo básico Cenário do Caminho Feliz Cenário de sucesso do início ao fim. Vários fluxos alternativos Variantes regulares Casos ímpares Fluxos excepcionais (erros) The outline of the flow of events for a use case has two main sections: Basic Flow of Events. Alternative Flow of Events. The outline is used as a base when you start to write the full use-case specification. Structure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up or finish. The basic flow of events should be relatively short and very easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. Most of the other details go into alternative flows. You can think of the alternative flows as “detours” from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are: Regular variants: Handle freshman enrollments differently. Odd cases: Handle registering for over 25 credit-hours differently. Exceptional (error) flows: Invalid student ID Number. You develop both the basic and alternative flows in the outline you make in the Find Actors and Use Cases activity. Note, the diagram above is informational only and is not a valid UML diagram. Fluxo: um conjunto de passos seqüenciais.

Representando fluxos básicos e alternativos
Passo 1 <Nome do Caso de Uso> 1. Descrição Breve 2. Fluxo de Eventos 2.1 Fluxo Básico Passo 1 Passo 2 Passo 3 Passo 4 2.2 Fluxos Alternativos 2.2.1 A1 … 2.2.2 A2 … 2.2.3 A3 … 2.2.4 A4 … 2.2.5 A5 … A5 A1 A2 Pas. 2 A3 A4 Passo 3 The basic and alternative flows of events are captured in sections of the use-case specification. Each flow has its own section in the use-case specification. The steps in each flow are listed within the flow’s section. Passo 4

O que é um cenário? Fluxo Cenário
When planning a project, we need to decide which use cases or which flows we plan on building in the current iteration. If you have enumerated the scenarios for a use case you can use those as a planning mechanism. You allocate a scenario to an iteration. Fluxo A scenario describes an instance using the system (an instance of a use case). It is one path through a use case flows from its beginning to one of its end points. Each use-case has a web of flows of events with a scenario being a particular path through the web. When you describe this path, you are describing a scenario of the use case. The scenario might involve the basic flow and any number of alternative flows in any number of combinations. In the above example, the bold lines highlight some possible scenarios for the basic and alternative flows previously described. How many scenarios are needed? Simple answer: As many as one needs to understand the system being developed. You should elaborate the scenarios of the interesting and high-risk use cases. Scenarios can be used to understand, as well as to validate the use-case flows of events. Some people write scenarios first and extract use cases, while others find use cases first and validate those use cases by writing scenarios. Scenarios make excellent test cases. Cenário Fluxo: um conjunto de passos sequenciais. Caso de Uso: Um repositório com a descrição de todos os fluxos. Cenário: Um conjunto ordenado de fluxos que vem do início do caso de uso até seus pontos finais.

Capturando os cenários do Caso de Uso
Capture os cenários na especificação de caso de uso em sua própria seção. Dê um nome a cada cenário. Liste o nome de cada fluxo em cada cenário. Coloque os fluxos em seqüência. Exemplo do Cenário de Caso de Uso Obter Cotação Cenário “Conexão do servidor caiu.” Fluxos: “Fluxo Básico,” “Sistema de Cotações Indisponível.” This style came from Kurt Bittner’s and Ian Spences’ book. Documenting scenarios is useful because, although you write flows (basic, alternative, subflows) in a use case, you implement and test scenarios. Each scenario captures a family of test cases. Each test case in the family follows the same path through the use case, but use different data values to ensure all the boundary conditions are tested. Give the scenario a descriptive name and list the flows (in order) that make up the scenario. Scenarios should be captured in a separate section of your use-case specification or as part of your test cases. The benefit of capturing the scenarios in the use-case specification is that all the information required for analysis, design, and test is co-located with the use-case description. Scenarios do not contain details of the data that is input to or output from the system. That information forms part of your test cases. Note: Currently the RUP use-case specification template does not contain a section for listing scenarios. You can customize the templates if you wish to capture scenarios in your use-case specifications. According to the book Use Case Modeling by Kurt Bittner and Ian Spence, “Capturing scenarios is useful for a number of reasons: The scenarios will match your test cases. Scenarios are what actually gets performed, so they are useful for discussing what the system will do in practice. Scenarios are useful for analysis and design, since they help the developers think about how the system will be used.”

Esboçe o fluxo de eventos
This is a good list of questions for students to use in developing their own flow of events. Suggest that the students mark this page so they can find it easily. Use lots of examples to illustrate the differences between the types of alternative flows. There is a different question to identify each type. What variations or options do we need to consider? What unusual circumstances must be handled a bit differently? What can go wrong? The point is to be able to identify all of the alternatives needed in a use case. Fluxo Básico Quais eventos iniciam o caso de uso? Como o caso de uso termina? Como o caso de uso repete um comportamento? Fluxos Alternativos Há situações não obrigatórias que ocorrem? O que pode acontecer de estranho? Quais variantes podem acontecer? O que pode estar errado? O que não pode acontecer? Que tipos de recurso podem ser bloqueados? Here is a list of questions to help you make decisions about the details in the flow of events. Alternative flows describe how the system should behave when things go wrong or when unusual things happen. When working on the alternative flows, questions regarding the behavior of the system are bound to surface. List these questions and have the users answer what the system is supposed to do, and how they expect to interact with the system in each scenario. Understanding the alternatives is an important step in clarifying the requirements. At this point in the process, however, it is enough to identify the alternatives without describing them in detail.

Desenho passo-a-passo: Obter Cotação
Fluxo Básico 1. O cliente se autentica. 2. O cliente requisita a obtenção de uma cotação. 3. O cliente seleciona o botão de negociação de ações. 4. O cliente obtêm a cotação desejada. 5. O sistema apresenta a cotação. 6. O cliente obtêm outras cotações. 7. O cliente sai do sistema. Fluxos Alternativos A1. Cliente de Ações não identificado. A2. Sistema de Cotações indisponível. A3. Sair. Go over the outline. This is a first draft for the use case, and we develop more detail later. For those not familiar with stock trading, you might need to explain that a “quote” refers to getting the currently traded price of a stock. Points for discussion: What can you tell about the use case by looking at this outline? What questions might you have about this use case that are still not defined? Existem outras alternativas? This is an example of a step-by-step outline for a use case. It shows a step-by-step outline for the Get Quote use case from the RU e-st system. The basic flow shows the major steps. The alternative flows show optional behavior. Notice the level of detail in this example. Remember, this is just a brief step-by-step outline to help understand what functions are contained in the use case. Further describe these steps in Module 8, Refine the System Definition.

Packages (Pacote): Organize o Modelo de CSU
Package Raiz A model may be too large to view as a single unit. A package is a grouping mechanism to break your model into smaller pieces. Illustrate the idea of grouping a use-case model into packages with a real example. If you do not have a real example, you may use the RU e-st example. We could formally break it into two packages as illustrated in the two diagrams in the RU e-st Use-Case Model Survey. Primary use cases are the customer-oriented use cases, and secondary use cases are the maintenance-oriented use cases. Use-Case Packages A package is a general-purpose grouping mechanism in UML. If your model is too large to view as a single unit, you can break your model into packages. A package in a use-case model may contain use cases, actors and relationships; and perhaps other, smaller packages. There are many ways to organize your packages. For example, one package might contain a particular actor and all the use cases that the particular actor can perform. Another popular grouping is to have each package contain all the use cases related to a particular feature. If you are using packages, the Use-Case-Model Survey has a separate subsection in Section 3 for each package. Each subsection contains an overview of the package and the lists of Actors and Use Cases in the package. In the book Use Case Modeling, a suggested guideline for organizing your model is: Each use-case package should contain 3 to 10 smaller units (use cases, actors, or other packages). 0-15 units: No use-case packages needed. 10-50 units: Use one level of use-case packages. >25 units: Use two levels of use-case packages. Note: The quantities overlap because it is impossible to give exact guidelines. Atores Use-Case Packages Use Cases

Refinar a definição do sistema: Atividades e Artefatos
The workflow detail addresses: Describing the use case flow of events in detail. Detailing Supplementary Specifications. Developing a Software Requirements Specification, if more detail is needed. This workflow detail furthers the understanding of project scope reflected in the set of prioritized product features (often described in the Vision) that it is believed can be achieved by fairly firm budgets and dates. The output is a more in-depth understanding of system functionality expressed in refined, detailed requirements in specification artifacts, and outlined user-interface elements. The specification artifacts can take the form of detailed use cases and Supplementary Specifications, and in some cases a formal Software Requirements Specification may be developed. This work typically starts by reviewing the existing actor definitions and if necessary least briefly describing the actors, then continues with detailing the use cases that have been previously outlined for each actor. Whenever the requirements specifications are changed, regular reviews and updates to the associated requirements attributes should be done as shown in the Manage Changing Requirements workflow detail.

O que são restrições de projeto?
Refer back to the definition of a constraint in Module 2: “A limitation on the design of the system or process used to build the system.” In module 4, we discussed project constraints. Now we are talking about design constraints. Some project and system constraint examples: 1. (Process) The system must be developed using the Rational Unified Process. Rationale: The company has achieved CMM level 4 because of the adoption of RUP. 2. (Process) A customer representative must be present at the development site. All requirements must be ratified by the on-site customer representative. Rationale: The paying customer has mandated it. 3. (Design) The middle tier of the system must be developed in Java. Rationale: The developers involved with that part of the system only know Java. Um requisito que se refere ao projeto e/ou arquitetura do sistema é uma restrição de projeto. Distinguir de outros requisitos. Colocá-la em uma seção especial do Documento de Requisitos. Identificar a fonte de cada uma. Documentar a razão de cada uma. Exemplos. Um algoritmo de uso obrigatório. O uso de um determinado produto de banco de dados. A linguagem de programação que deve ser usada. As stated in Managing Software Requirements: A Unified Approach, “Requirements should not include information about the system design or architecture. Otherwise, you may accidentally have restricted your team in pursuing whatever design options make the most sense for your application.” Make sure that you can understand and make clear which requirements are constraints on the design. The purpose of this activity is to try and identify the “project icebergs.” Icebergs are those things that, on the surface, appear much more trivial than they are. Unlike the Titanic, they do not always sink your project, but they may knock it way off course. You should also make sure you understand the rationale for each design constraint. If the reason for the constraint is someone’s personal preference, then it should be challenged. If, however, the constraint has been imposed by the customer or legislature and non-adherence to the constraint affects your ability to be paid (or you could be sued), then it should be noted as a constraint and stored in the Constraints section of the Vision. By separating the constraints, you can help ensure that they are distinguished from other requirements. An example of a design constraint: Constraint:The middle tier of the system must be developed in Java. Rationale: A previous implementation provides a set of wrappers for the existing mainframe infrastructure that was developed in Java. Java must be used in order to leverage the existing investment.

O Dilema do O Que-Versus-Como
Questão: Como especificar um requisito de projeto? Resposta: Depende de seu ponto de vista. Note: The graphic on this slide was also used in Module 4 to explain a slightly different point. See student notes for example. Necessidades O que Como O homem de cima É o Homem do outro andar.” Características O que Como A question that frequently comes up when writing requirements is, “How can I write a requirement that tells the audience ‘what’ do to without specifying ‘how’ to do it?” Unfortunately, there is no one right answer. It depends on the intended point of view of the particular document reader. Example When writing the Vision document, the “what” are the user needs, and the “how” are the features. For the Use-Case Specifier, the “what” are the features, and the “how” are the software requirements, use case specification or supplementary requirements. For a Designer, the “what” is the use-case specification, the “how” is the design model. For the Coder the “what” is the design model, the “how” is the code. Casos de Uso O que Como Espec. Técnica Procedimentos Teste Planos Documentação Davis, 1993

Características levam a Requisitos de Software
Períodos de negocição podem ser digitadas em dias, semanas e meses. Remind the students about what was discussed in module 6, slide 6 (6-6). Features map to the software requirements that exist inside a use case. Informações de tendências serão apresentadas em um gráfico de linhas apresentando tempo em x, e nº de defeitos em y. Caract 63 – o sistema de acompanhamento de defeitos irá fornecer informações de tendências para ajudar o gerente de projeto a ter conhecimento do andamento Imprimir Relatório de Status The features that you identified for the system (see Module 6) drive the definition of the software requirements. The software requirements may be specified in many forms, including use cases and declarative sentences. There is no clear mapping between features and use cases. It could be 1:1, 1:n or n:1. Gerente de Projeto Operador

Como especificar requisitos funcionais?
Use os casos de uso e setenças declarativas. Ambos são necessários para entender um sistema de complexidade relevante. Dê preferência a casos de uso, onde apropriados. Now that we’ve talked about what is in an SRS, let’s get to the specifics of defining the software requirements. Use cases have the advantage of showing a whole sequence of system behaviors, which gives a context to each requirement of what the system should do. However, there may be situations where use cases are not appropriate. (This is a lead-in to the following slide.) O sistema pode … O sistema deve … O sistema deve ... + There is no one right answer to the question of how to write requirements about system functionality. For many projects, the answer is a mix: some functional requirements are expressed in use cases, and others are expressed in declarative statements. How does the analyst decide when to use use cases and when to use declarative statements of requirements? The mix varies greatly from organization to organization and from project to project. When deciding whether particular behavior is best modeled with use cases, consider: Context of the application and the project. Skills and comfort level of the developer organization. Client preferences and environment. Risks in your project and how best to address those risks. Casos de Uso Sentenças Declarativas Qual escolher?

E sobre requisitos que não estão em Casos de Uso?
We’ve been talking about use cases for specifying detailed software requirements. Now let’s talk about specifying the detailed software requirements in declarative statements. Review the hints for writing good detailed software requirements in declarative statements. Emphasize the need to keep them simple and easy to understand. Escreva uma sentença declarativa que não esteja em caso de uso. Use uma palavra-chave que para ajudar na identificação, por exemplo “deve.” Numere e dê um título a cada requisito. Agrupe requisitos relacionados. Use language the team easily understands. Use uma estrutura de setença simples. Adjetivo + Substantivo. Seja conciso e claro. Descreva o requisito em 1 a 3 sentenças. Torne o requisito completo. Use termos do glossário. Use cases may contain many of the detailed functional software requirements. But many other detailed software requirements (both functional and nonfunctional) are best stated in declarative sentences that are independent of use cases. Note: subject and active verb does not necessarily apply to non-English languages. The point is to strive for a name that clearly, concisely and unambiguously describes what the actor intends to use the system for. When specifying software requirements as declarative statements, keep each requirement short and easy to understand. Number and title each requirement so you can refer to it easily, especially when you are reviewing it. Requirements presented in a context are easier to understand. Grouping related requirements together provides some context. For example, all requirements about reliability may be grouped together. Both hierarchical relationships and packages can be used to group declarative statements of software requirements. Remember that the requirement specifications are for the users to read. Requirements have to be written for the user. Do not alienate them by using language they do not understand. Use simple sentences, with a straightforward sentence structure: subject followed by active verb and object. Use terms from your glossary. The advantage of using a keyword, such as “shall,” to identify each requirement is that it is immediately clear which statements are requirements and which are merely additional text. The disadvantage is that the use of a keyword in some requirements may sometimes make them stilted or more difficult to understand.

Requisitos Funcionais em Sentenças Declarativas
In the use-case approach, functional requirements (what the system actually does) are usually stated in the use cases. However, sometimes (as in the example), a detailed functional software requirement is more easily handled in a declarative statement. Alguns requisitos são mais fáceis de entender em sentenças declarativas. Exemplo do sistema RU e-st Localização: SUPL120: O sistema RU e-st deve suportar a apresentação de todas as mensagens e menus no idioma escolhido pelo usuário a qualquer hora. Os idiomas suportados devem ser Inglês, Espanhol, Francês, Alemão, e Sueco. Some functional software requirements are difficult to describe within the context of a use case. These functional requirements can be stated declaratively in the Supplementary Specifications. For example, localization requires that messages to the user are displayed in the user’s preferred language. In each step of each use case that displays a message, you could say something like, “The system prompts the customer, in their preferred language, to enter their personal details.” As well, you can make a single declarative statement that applies to all displays in the entire system. For example, when describing the requirements for a language compiler, you will find that there are many requirements for compiler switches that are better described declaratively. One such switch could be to tell the compiler to select between optimizing compilation for an Intel® Pentium® II or an Intel Pentium III. Because there is not interaction with the user for these switches, these requirements are better specified declaratively.

Onde as sentenças declarativas são especificadas?
Supplementary Specifications contain the declarative statements that are not readily captured in the use cases of the use-case model. Refer to the Supplementary Specification in the Student workbook (RUCS8). Open RUP and show an example of the template. Mention that there are different opinions about where to place declarative statements. Some people like to put all their declarative statements in Supplementary Specifications, even if the requirement pertains to a specific use case. That is, they never use the “Special Requirements” property in use cases. The reason is that it is easier to find the declarative statements if they are all together. The disadvantage is that the use case description must then refer to the special requirements for the use case, which are outside the use-case specification. If an organization is not using a use-case approach, then the Software Requirements Specification (SRS) does not have a section for use cases. The remaining part of the SRS is the equivalent of the Supplementary Specifications. That is, the SRS is organized according to the Supplementary Specifications template. Se o requisito se aplicar ao caso de uso: Especifique no caso de uso Na seção “Requisitos especiais” O requisito se aplica a uma parte do sistema: Especifique na Especificação Suplementar If a declarative statement applies to a particular use case, then it is usually specified in the “Special Requirements” property of the use-case specification for the particular use case to which it applies. For example, for the Get Quote use case in an RU e-st system, there may be a nonfunctional requirement about the maximum allowable time for the system to respond to a request to get a quote. This performance requirement may be placed in the “Special Requirements” property of the Get Quote use case. Supplementary Specifications contain the declarative statements that are not about a particular use case. For example, for the RU e-st system, the Supplementary Specifications may contain a nonfunctional requirement that the system must be able to run with either MS Internet Explorer or Netscape Navigator. Does the requirement apply to multiple use cases? Replicate the requirement in each use case, or put it in the Supplementary Specification. The decision as to the best location is based on conjecture and guided by experience. Tip: If you are using a tool like RequisitePro®, a useful technique for storing supplementary requirements is to locate them in the database and then use SoDA® to create a Supplementary Specification for you.

Variações nos Requisitos Funcionais
Mention that the RUP Supplementary Specification is based on the IEEE System Specification document template, minus a section called “operational scenarios”. So for clients that prefer functional specifications, you could adopt the standard IEEE template and put the use-case model survey in the Operational Scenarios section. Use cases have the advantage of showing a whole sequence of system behaviors, which gives a context to each requirement of what the system should do. However, there may be situations where use cases are not appropriate. Use examples of real projects to illustrate the idea that the ratio of use cases to declarative functional requirements varies. Talk about a “typical” situation, which has a lot of use cases and very little use of declarative functional requirements. Then talk about another situation, which has only a few use cases and a lot of declarative functional requirements. The student notes give a few examples or use your own. Nonfunctional requirements, such as performance requirements, are almost always specified with declarative statements. Specifying nonfunctional requirements is covered later in this module. Backus Naur Form (BNF) is a notation to describe the syntax of a given language. O sistema com um pequeno comportamento externo observável. How much of the functional requirements do you specify with use cases and how much in declarative statements? It varies from project to project. Some projects have many use cases, and only have a few declarative statements. In other projects, it is just the opposite. It depends on the amount of externally observable behavior in the system. Our preference is to model functional requirements with use cases, because of the advantages mentioned throughout the course. For example, in the RU e-st system, the Get Quote use case shows the whole sequence of behavior to get a price quote. Each system behavior is a functional requirement. The sequence gives context to the functional requirements. But not all behavior is best modeled with use cases. For example, you could describe functional requirements for a Java compiler with use cases, but standard Backus Naur Form (BNF) would be more appropriate and concise. Another example, suppose you are adding localization functionality to an existing product so that messages display in the language of the user’s choice. You could change existing use cases to describe the multi-language display of messages, but you might prefer to write a few declarative functional requirements instead. Some clients insist on the traditional approach of specifying all requirements in declarative statements. You must develop the traditional SRS, but you can also make use cases for your developers. You may want to maintain all requirements in two different formats (declarative and use cases), and then trace between them to help keep them consistent. The disadvantage is that you have double work to keep two copies of the requirements. Instead, you may develop only a few illustrative use cases to show central functionality and architecturally significant use cases. Nonfunctional requirements, such as performance requirements, are almost always specified with declarative statements. Specifying nonfunctional requirements is covered later in this module. O sistema com muito comportamento externo observável.

Por que detalhar casos de uso?
Para especificar os requisitos de software. Criar a especificação que deve ser implementada. Esclarecer detalhes importantes do fluxo de eventos. O que um ator faz. Como o sistema deve responder ao ator. Quais informações são trocadas. Descrição de informação adicional. Pré-Condições Pós-Condições The actions that the system does are the software requirements: they are what the user wants the system to do. Stress here what the software requirements are and relate this back to the pyramid of requirement types. Detailing the use-case description is where the “real work” in use-case modeling occurs. The outline of the flow of events in each use case that you developed earlier lacks important details. The main purpose of detailing a use case is to elaborate the step-by-step outline of the flow of events. In addition, specify other properties of a use case, as shown on the template on the previous slide. Without a detailed description of the flows of events, it is nearly impossible to implement a solution. The reason is that the use-case outline did not contain any real software requirements. Instead, the outline just contained a high-level description of what the system does. The detailed flow of events includes what the actor does and what the system does in response. The actions that the system does are the software requirements: they are what the user wants the system to do.

1. Procure atores e casos de uso.
Detalhe um caso de uso 1. Procure atores e casos de uso. Review the Use-Case Specification template from RUP. This topic was introduced and discussed in the Introduction to Use-Case Modeling module. The slide and student notes are almost the same as in the Introduction to Use-Case Modeling module. The repetition is intended to remind students about use cases and to introduce this section on detailing of use cases. 2. Detalhes do caso de uso. <Nome Caso de Uso> 1. Descrição Breve 2. Fluxo de Eventos Fluxo Básico de Eventos Fluxos Alternativos 3. Requisitos Especiais 4. Pré-Condições 5. Pós-Condições 6. Pontos de Extensão 7. Relacionamentos 8. Diagramas de Caso de Uso 9. Outros diagramas e itens Esboço This is a template for a Use-Case Specification. In the “Find Actors and Use Cases” activity, you identified the use cases and sketched a step-by-step outline for each use case. Now you are ready to begin the “Detail a Use Case” activity. For each use case, start with the step-by-step outline and gradually add detail to each step. You want to understand what really happens so you don't miss anything. Typically, you begin with refining the Basic Flow and then refine the Alternative Flows. Work together with users to revise and detail the outline. Expect to revise the outline and the details many times. There is no minimum or maximum size for a use-case specification. It needs to big enough to contain an unambiguous and concise description of how the system behaves. Be sure your description is complete and that you have answered all the questions that people may have about the events in the use case. The Use-Case Specification describes the details of a particular use case. In addition to the Flow of Events, there are other properties that detail a use case. Rational recommends that you use a standard template for your use-cases, such as the one shown here (from the Rational Unified Process). Whether or not you have any properties within the section, stick to the standard outline. Adicione Detalhes

Detalhe o fluxo básico de eventos
Obter Cotação 1.1 Fluxo Básico 1. Cliente se autentica O caso de uso se inicia quando o cliente se autentica. O sistema valida login e senha do cliente. O sistema apresenta uma lista de funcionalidades. 2. O cliente seleciona a função “Obter Cotação” O cliente escolhe obter uma cotação. O sistema apresenta uma lista de símbolos de cotação e nomes de seguros. 3. O Cliente seleciona o seguro O cliente seleciona de uma lista de seguros ou informa o símbolo de seguro para a cotação. 4. O sistema obtêm a cotação do sistema de cotações O sistema envia o símbolo de cotação para o Sistema de Cotações, e recebe uma resposta do sistema de cotações. O sistema apresenta a tela correspondente da cotação (veja em campos apresentados na Especificação Suplementar) ao cliente. Estruture o fluxo em passos Animation: Starts automatically after 2 seconds. Review the example of a basic flow for RU e-st. Remind students that this topic was introduced and discussed in the Introduction to Use-Case Modeling module. The student notes are the same as the corresponding slide in the Introduction to Use-Case Modeling module. The repetition is intended to remind students about writing flows of events and to prepare them for the exercise in writing detailed flows of events for the class project. Detail the use case by defining the basic flow of events. Structure flow into steps. Number each step. Describe each step in 1-3 sentences. Make each step a roundtrip event. Numere e dê títulos a cada passo Torne cada passo um conjunto de eventos There are many styles for writing flows of events. One of the styles Rational® uses is to number and title each step. This gives the reader an overview of the flow without all the details and can refer to a step when it is being reviewed. There are many other styles. You can encourage consistency in style by specifying acceptable style guidelines when you write your Use-Case Modeling Guidelines. When you detail each step in the outline, be sure to describe the flow of events, not only what the system is doing. A suggestion for how to enforce this is to start every step with “When the [actor] ... ” Rational recommends making each step in the flow of events show a roundtrip of events, usually in the form of messages: What the actor does: <Actor> messages <System> , and What the system does in response: <System> messages <An Actor> ... Making each step a roundtrip ensures testability, ensures adherence to the purpose of a use case, and makes sequence diagrams far easier to develop and read. However, observe that step 3 is not a roundtrip of events. In this particular case, it made the use case description easier to read if we described the user action on its own. You should strive for roundtrip descriptions, but they are not always be practical. Some interactions are system-controlled. That is, after the user’s initial request to begin the use case, the system controls the interaction: the system asks for information and the user supplies information. The system asks for additional information and the user supplies it, and so on. In these cases, a roundtrip within a step would begin with system actions and then have the user response. Descreva passos (completamente e claramente)

Gerenciar Detalhes Saber quem vai ler. Escreva para a caixa preta.
Points to emphasize: You should strive for black-box, but you cannot avoid white box. Some white-box text might improve understandability because it makes the use case more concrete. Refer back to the slide that discusses design constraints. By specifying the “How,” you are actually imposing design constraints on the development team. Caixa preta Caixa Branca Saber quem vai ler. Escreva para a caixa preta. Algum texto de caixa branca pode melhorar o entendimento porque torna o caso de uso mais concreto. A black-box use case contains no description of the system’s internal processing. A white-box use case contains descriptions of the system’s internal processing. The problem with black-box use cases is that sometimes the description becomes too trivial to be of use. This is particularly true in systems where there is little externally observable behavior. The problem with white-box use cases is that by describing the internal processing you can accidentally influence the design of the system by stating what the system does inside and when it does it. Sometimes it is useful to provide a little internal description because it gives some context to the next interaction with an actor. The question that has plagued use-case authors for many years is: “Just how much detail is enough when writing a use case?” The answer is that you should adapt the amount of detail to suit your audience. A user is typically interested in a black-box description of the system. A subject-matter expert would be interested in much more information. Often there are important details that the designer should not be left to “figure out,” rather a detailed knowledge of the domain is required to describe what the system does. This is an example of where tool support can help you manage the detail. You can use the features of your word processor to turn on or turn off the detail based on your audience. An example of this is the “hidden text” feature in Microsoft® Word. Internal descriptions are written in a style that uses hidden text that can be suppressed later. When writing your use cases, you should strive as much as possible for black-box use cases. If you do need to add internal processing information, you should do it with caution and attention to your audience.

Estruturar os fluxos de caso de uso
Organização interna do caso de uso. Melhora legibilidade. Torna os requisitos mais fáceis de entender. Documente os estilos aceitáveis nos Guias de Modelagem de Casos de Uso. People often think structuring the use case only deals with «include», «extend», and generalize. This is not the case. The internal structure of the use case text is by far the most important type of structuring you can perform. The internal structure deals with how you describe repetitive behavior, the use of conditional statements, numbering techniques, subflows, and internal cross references. You need a style that is going to make it easy to write and maintain the use-case descriptions, while at the same time making the life of the implementers and testers easier. Writing a use case description should not be a “free for all” approach. For the same reasons organizations have coding standards to promote understanding and productivity, it is important to ensure consistency of the use case descriptions with use-case modeling guidelines. The structure of your use cases is one of the most important and overlooked features of your requirements set. Often teams focus on structuring the model itself (this is covered in module ten) instead of focusing on the internal organization of the information within each specification. Your use-case modeling guidelines should describe acceptable use case styles. Things to consider standardizing are: General format of a flow (paragraphing). Labeling and numbering conventions. How do you repeat behavior? How do you describe optional behavior? How do you describe data in forms? How do you map to business rules? How do you reuse behavior? Whether descriptions of internal behavior are allowed. Which features of your Word processor will you use to maintain internal cross-references? Model structuring guidelines («include», «extend» and generalization).

Numeração e Referência Cruzada
Estilo do RUP Estilo de Tag 1. Customer Logs On {Trading Customer Logs on} There are many styles used for writing use cases. The style you choose should take into consideration the capabilities of your authoring tool, promote clarity, and ease the authoring and maintenance process. Use cases typically have a great deal of cross-referenced information within them. The overhead of maintaining this cross referencing is what typically causes use cases to become out of date. In both of the above cases, cross-referencing can ease the authoring process by ensuring that the correct labels are used and updated. If you change the text or location of the label, then the location that references the label is also updated. Word processors, such as Microsoft® Word and Adobe® FrameMaker®, have powerful book marking and cross-referencing capabilities that can ease the maintenance of cross references. The RUP style use case shown above has the advantage that an overview of the flow of events can be obtained by reading the headings. If you want the detail you look at the subflow under each heading. The disadvantage of this approach is that internal cross references can be hard to maintain automatically if you insert a heading (high-level step). The Tag style does not have the overview capability, but is easier to maintain because referenced locations are marked with a label. Inserting steps has no effect on the location of the label. The tag is identified visually by enclosing the text in braces. The tag can be cross referenced by name from other locations in the use-case specification. You only need to create a label for locations that need to be referenced from some other part of the use case. This style is typically easy and fast to author and requires little configuration of the document template. In {Trading Customer logs on}, In Step 1, Customer Logs On, in

Detalhe fluxos alternativos
Alternative Flows A3 Request Additional Quotes In Step 3, Customer Gets Quote, in the Basic Flow, if the customer wants additional quotes. The use case continues at Step 3. A4 Quit If at any time the Trading Customer decides to quit. The use case ends. A5 Unknown Trading Symbol In Step 3, Customer Gets Quote, in the Basic Flow, if the system cannot recognize the trading symbol, the system notifies the Trading Customer that the trading symbol is not recognizable. The use case continues at the beginning of Step 3. Fluxos alternativos A3 Requisitar cotações adicionais No passo 3, Cliente obtêm cotação, no Fluxo básico, se o cliente desejar cotações adicionais. O caso de uso continua no passo 3. A4 Sair A qualquer tempo o Cliente de Negociações pode sair do sistema. O caso de uso termina. A5 Símbolo de negociação desconhecido No passo 3, Cliente obtêm negociação, no Fluxo Básico, se o sistema não reconhecer o símbolo de negociação, o sistema notifica o ator que o símbolo não existe. O caso de uso continua do início do passo 3. Descreva o que Acontece Animation: One mouse click starts the animation of focusing on Location, Condition, Action, and Resume Location details in the flows. Describe the process of defining alternative flows. Use one section for each alternative flow. A specific alternative flow occurs at a specific step in the basic (or other) flow. A generic alternative flow can occur anywhere in another flow. Ask: Which examples of alternative flows on this slide are specific and which are generic? Localização Condição Ações There are always different ways to structure the text. The main goal is to make the document easy to read. Describe the alternative flows in their own section, not within the basic flow (although some have found it useful to add pointers where these may be inserted for clarification purposes). This slide shows both specific and generic alternative flows from the RU e-st example. A specific alternative flow occurs at a specific step in the basic (or other) flow. A generic alternative flow can occur anywhere in another flow. For specific alternative flows, the following information is detailed: The start location in the basic or another subflow where the alternative flow is triggered. Example, “In Step 3 of the Basic Flow.” The condition that triggers its start . Example, “If the line goes down.” The actions taken in the alternative flow. Where the basic or another subflow is resumed after the alternative flow ends. Example, “Resume at Step 7 of the Basic Flow.” If the use case ends in the alternative flow, state that “The use case ends.” in the alternative flow. For generic alternative flows, there is no start location because a generic alternative flow can begin anywhere. Resuma a Localização

Evite Comportamento Condicional em série
Torna os cenários difíceis de entender. Mais difícil de implementar e testar. Prefira fluxos alternativos. It is common to see conditional statements such as IF-THEN-ELSE-ENDIF in use-case descriptions. The primary reason for including conditional statements in a use-case flow is that they are very natural and convenient to write. However, every time you include a conditional statement you add a level of complexity to the use case. This is because the reader needs to keep in mind the condition that got them to the subflow. With one level of condition this is easy, but as you add more conditions, the level of complexity goes up an order of magnitude. For example: IF a THEN do something IF b THEN do something else ELSE do something else again ENDIF Implementing and writing test scripts for use cases that make excessive use of conditional statements is difficult and prone to error. A far better approach is to use alternative flows. There are tradeoffs. A use case with many alternative flows becomes difficult to read because the flows are fragmented throughout the document. The side effects of over use of conditional statements far outweighs this problem.

Evite comportamento repetitivo em série
Torna os cenários mais difíceis de identificar. Mais difícil de testar e implementar. Prefira fluxos alternativos. Repeating behavior is a common requirement when writing use-case descriptions. The example above provides three common styles. Notice that the keywords are in upper case. This style is used to make control points of the description stand out from the rest of the text. This is useful for testers when writing test scripts. The common structure in all of the examples is that there is a condition that is tested and a location to branch to if the condition is true. The problem with using “looping constructs” in the use-case description is that it is harder to identify the alternative path. This means that testers and implementers can more readily make mistakes. Another approach to the three examples above is to use alternative flows to repeat the behavior. In that case, you would have an alternative flow called “Customer Wants More Quotes” and have it resume at Step 3. Choose one style for all use cases in your project and document that style in the use-case modeling guidelines. This ensures consistency and promotes readability of your use cases.

Fluxos alternativos X Comportamento Condicional em série
Emphasize that alternative flows should be the preferred method of writing conditional or repetitive behavior. Fluxos alternativos Prós Pode ser usado em qualquer lugar onde haja comportamento condicional. REPITA-ATÈ, SE-ENTÃO-SENÃO-FIM-SE Torna os cenários fáceis de identificar. Isto ajuda a implementação e ao teste Contras Aumenta a complexidade de manter referências. Comportamento condicional em série Mais de fácil de lidar nos fluxos com pequenas variações. Difícil de identificar cenários, testar e implementar. It has been reported that percent of software is written to cater for error and abnormal conditions. This figure is similar when writing use cases. In a use case, the scenario (when everything goes right) is described in the Basic Flow. Everything else that happens (errors, exceptions, regular variations) are described as alternatives to the basic flow. If you included all the alternatives in the basic flow, you would have such a vast number of condition statements and loops that the requirements would start to look like code and be impossible to understand, implement, and test. Alternative flows are used to describe the variations from the “happy day” scenario (when everything goes right). They have the benefit of making each flow easier to understand, implement, and test in isolation. Unfortunately alternative flows have the disadvantage of making the use-case description fragmented and harder to maintain the internal references. This is a small price to pay when you consider the benefits of making your requirements easier to understand. Alternative flows can be used in place of looping constructs of conditional statements, thereby reducing the complexity of the flows. When you use alternative flows, the importance of identifying your scenarios becomes even more apparent. When you implement a use case, you do it one or more scenarios at a time. Ensure that all your alternative flows are included in at least one scenario so that it is implemented and tested.

Visualizar comportamento alternativo
Cliente Sistema Sis. Cotação While activity diagrams provide a nice way to visualize alternative behavior, they quickly become messy and difficult to maintain. Activity diagrams also take longer to develop (and therefore cost more) than a use case because most authors spend too much time making sure everything is lined up and no lines cross on the diagram. In most cases activity diagrams are not required. Activity diagrams can be used to visualize alternative flows. It is important that you make use of swim lanes. If you do not, then the activities float in a “semantic emptiness” because they cannot be anchored as a responsibility of any one or thing. Compare the following example with the one above.

Sub-fluxos Melhora a clareza. Permite reuso intermo dos requisitos.
Diferente dos fluxos alternativos, são chamados explicitamente. Sempre retorna para a linha de onde foi chamado. One way you can describe a subflow to students with a programming background is to use the analogy of a subroutine call. You call a subflow, and when it completes, it always returns to the line after the call. When a particular flow becomes overly complex, a common practice is to factor out the complex flow and place it in an included use case (Covered in module 10). While the author had the best intentions of reducing the complexity of the flow, he/she functionally decomposed the system and made it harder to understand the requirements of the system. The reader now has to look in two documents to understand the requirements. An alternative approach is to use subflows (or named subflow in the book Use Case Modeling by Kurt Bittner and Ian Spence). A subflow can be thought of as an “internal include.” Benefits to this approach: The flow is still contained in the same use-case specification. The flow can be used to increase clarity by factoring out complex flows. The flow allows the reuse of flows within the same use case. This is because subflows can be called from multiple places. The difference between an alternative flow and a subflow is that alternative flows insert themselves into another flow. The flow it inserts itself into has no knowledge of the alternative flow. An alternative flow may also resume at any place within the use case. A subflow is explicitly called from a flow. When a subflow complete it always returns to the line after it was called from. It is similar in concept to a subroutine call in some programming languages. Subflows are not listed as part of a scenario. By definition, if the calling flow is in the scenario, the subflow is also in the scenario. As with any other flow, a subflow may have alternative flows. Fluxos Alternativos Subfluxos

Exemplo de Subfluxo This is not the best example of a subflow. You would normally choose a more complex flow to factor into a subflow. It exists only to serve as an example of how to write a sublfow. Refer the students to the handout RUCS6.2 for a much better example of subflows. This is an example of how to write a sublfow. Notice that subflows have a section of their own in the use case specification. In this style, the subflows have an identifier in front of them (S1, S2 , and so on) to help identify them as subflows. Unlike alternative flows, subflows do not need a line that says where they return to because they always return to the line after they were called. In the example, once the subflow S1: Obtain Course Information completes, the flow will resume at 4. Select Course. The Execute Trade Use-Case Specification (RUCS6.2) in the Student Workbook has a complete example of a subflow that is referenced from multiple locations in the document.

Mantenha a interface do usuário fora do caso de uso
Texto não é bom para descrever tela. Casos de uso desconhecem tela. Descreva tela durante Análise com protótipos: Modele a iteração com tela via protótipo Palavra a EVITAR There is truth in the saying “a picture is worth a thousand words.” Use cases were never intended to describe a user interface. Describing a visual thing textually is always open to interpretation and very hard to review. For example, picture a bucket. You may imagine that it is a plastic container with an open top and it has a handle. But someone else may imagine it as being made of metal, has a handle, is painted red, and has the word “Fire” written on it. Everyone interprets descriptions differently. For the same reason, user interfaces are best described visually. Another reason to keep a user interface out of a use-case description is that the requirements of the system may be the same regardless of the technology used to interact with its surroundings. For example, we could implement the RU e-st system on a 80x24 character text terminal or on a system running Microsoft® Windows® The use cases should not be different, regardless of the implementation. Consider the use-case description for a mobile phone. One of the use cases may be “Receive Call.” In this use case, the system needs to notify the user that there is an incoming call. Typically use-case authors would write “The system rings the phone,” but with modern phones the ring tone could be turned off. In fact, the phone could ring, vibrate, display a message on the screen or any combination of the three, depending on which features have been enabled. In this case, the use-case description should be “The system notifies the user of an incoming call. Refer to the special requirements for a description of how the system can notify the user.” In the special requirements, there would be a matrix of how the system can notify the user versus the features that have been enabled in the system. This tells the implementer and tester that this is configurable and the notification method is based on the system’s configuration. Palavras para usar Clique Arrastar Form Abrir Fechar Combo Botão Campo Drop-down Pop-up Rolar Navegar Registro Janela Pergunta Escolhe Inicia Especifica Submete Seleciona Começa Apresenta Informa

Use o glossário efetivamente
Implementação Caso de uso Entrar com informações do cliente O sistema requisita ao cliente que informe seus detalhes cadastrais. O cliente informa seus detalhes cadastrais. O cliente cria uma conta. Describing how actors interact with forms is common in use cases. There are many techniques authors use, such as placing them in the flow or in the special requirements. For example: 5. Enter Customer Info The system prompts the Customer to enter their Name, Address (two lines), City, State, Zip code, and Phone number. The Customer enters the information. The Customer creates the account. This style has a tendency to distract the reader from the real requirements and is harder to maintain. The safest method is to use the glossary. This ensures that there is only a single place to maintain the information. It also ensures consistency if the same data is used in multiple use cases. It also makes the use case description cleaner and easier to read. The glossary can be used by your database and user interface designers more effectively. While you should always strive to use the glossary, an alternative approach is to specify the detailed data requirements in the “Special Requirements” section of a use case or place them in the supplementary specification artifact. Glossário Detalhes Cadastrais: informações que identificam unicamente e fornecem informações de contato para um cliente localizado nos EUA. A informação consiste de: Nome, 2 linhas de endereço, cidade, estado, cep, e telefone para contato.

Pré-condições Descreve em qual estado o sistema deve se encontrar para o início do caso de uso. Não é o evento que inicia o caso de uso. Reduz a quantidade de validação necessária. Opcional: Use somente se necessário para melhorar o entendimento. Obter Cotação Pré-condição O sistema RU e-st deve se estar conectado com o Sistema de Cotação antes do início do caso de uso. A precondition for a use case is a condition in the system that must be true before the use case can begin. For example, the list of course offerings must be available before a student can register for courses. Otherwise, the student could not select from the course list. A precondition is not the event starting the use case. For example, if a use case is written in such a way that logging on to the system is the first event in the use case, then logging on is not a precondition. But if a use case is written so that logging on must happen before the use case begins, then “The user has logged on to the system” would be a precondition. Preconditions reduce the need for validation inside the use-case flows. In the example, you do not need to test that the course offerings are available anywhere in the use-case flows of events because, by definition, they must have been available or the use case could not execute. Preconditions do not describe things outside the system. For example, “The customer has a valid PIN” would be an invalid precondition. Validating the PIN is something the system does in the use case. Preconditions are optional. They are only used if they are needed for clarification. Note: Preconditions can also be used at the beginning of an alternative flow or subflow. More commonly, they are used only on the basic flow. An example of using a precondition on an alternative flow is to describe security. If only certain actors can perform a given flow, you could attach a precondition to that flow to ensure the user has the appropriate authentication to perform the flow.

Pós-Condições Descreve em qual estado deve estar o sistema ao fim da execução do caso de uso. Estado garantido de quando terminar o caso de uso. Pode conter variações. Opcional: descreva somente se necessário para melhorar o entendimento. Executar Previsão Pós-condição Ao fim do caso de uso todas as contas devem estar atualizadas para refletir as transações que ocorreram. A postcondition is a condition that is guaranteed to be true after the use case ends. It must be true for a use case regardless of which alternative flows were executed. It should not be true only for the main flow. If something fails, you cover that in the postcondition by saying, "The action is completed,” or “if something failed, the action is not performed,” rather than just "The action is completed." Postconditions can be a powerful tool for developing use cases. You must first define what the use case is supposed to achieve (the postcondition). Then describe the different ways to reach this condition (the flow of events needed). Note: Postconditions can also be used at the end of alternative flows or subflows. But more commonly only one exists to describe the postcondition for the use case no matter how it ends.

Seqüência do caso de uso com pré e pós Condições
As described in the book Use Case Modeling by Kurt Bittner and Ian Spence, “Use cases do not directly communicate with one another. The only way for use cases to interact is via the state of the underlying system. Use cases can check the state of the system at ay time, or wait for the state of the system to change, or can even be dependent on the state of the system via the use of preconditions.” For example, you may have a use case called “Manage Session,” which handles authenticating a user when he/she logs on and then creates a session based on his/her user profile. When he/she logs off the system, the use case cancels the session. This use case starts with a precondition that there are no current active sessions in the system. When it authenticates the user, it sets the system sate to “active session.” The use case then waits until the user logs off. When the user logs off, it changes the system state to “no active session.” In order to ensure the user has logged onto the system before you start another use case, you would use a precondition of “There is an active session in the system.” (Note: active session should be in your glossary.) This has effectively ensured that the Manage Session use case has been run prior to the other use case. Preconditions can only test the state of the system. For example, you cannot have a precondition that states, “Use Case A must have been executed before Use Case B can begin.” Note: Never draw an arrow between use cases as is shown in the example. The arrow in the slide illustrates the relationships between pre- and postconditions in two use cases. Casos de uso não interagem.

Outras propriedades dos casos de uso
The optional properties are used only if there are items of that kind to discuss. For example, there may be no special requirements. These are the rest of the properties of a use case. Requisitos especiais Relacionado a este casos de uso, não coberto pelos fluxos. Geralmente não funcionais, dados, regras de negócio. Pontos de Extensão Nomeia com conjunto de locais nos fluxos onde há comportamento de extensão a ser executado. Relacionamentos (Use-Case-Model) Associações com atores e casos de uso. Diagramas de Casos de Uso Modelo visual de todos os relacionamentos envolvendo o caso de uso. Outros diagramas e encapsulamentos Interação, atividade, ou outros diagramas. Special requirements are requirements relating to this use case that are not covered by the flow of events but that could influence the design of the system. These are usually nonfunctional constraints for the use case, such as reliability and performance. Extension points name a set of places in the flow of events where extensions can be attached. Extensions and extension points are discussed in a later module. Relationships list all the associations that the use case has to actors and to other use cases, with brief descriptions where applicable. You have already studied the “communicates-association” between an actor and a use case. Relationships between a use case and another use case is discussed in a later module. Use-case diagrams: You may choose to illustrate how a use case relates to actors and other use cases in a use-case diagram (in unusual cases more than one diagram) owned by the use case. A diagram is useful if the use case is involved with many actors or has relationships to many other use cases. A diagram of this kind is of "local" character because it shows the use-case model from the perspective of one use case only. Other diagrams and enclosures can be included if they help to clarify the use case. For example, interaction or activity diagrams can be used if they help to clarify the flow of events.

Dicas para casos de uso Descreva apenas eventos visíveis ao ator:
What level of detail should go into the use-case specification? Detail your flows until everyone has a common understanding of the requirements. For example, a use case such as Execute Trade is much more complex than a use case such as Login. Most people understand the concept of login. You typically find that people understand the requirements of the login use case with less detail. The Execute Trade use case however, requires much more detail. Therefore, some use cases have more detail than others. This guide helps practitioners get out of a common rut, which is they detail their use cases to death and never move on. Descreva apenas eventos visíveis ao ator: O que o ator faz. O que o sistema responde ao ator. O que o caso de uso fornece de valor ao ator. Casos de uso podem ter diferentes níveis de detalhe. Detalhe até que cada stakeholder tenha um entendimento comum dos requisitos de sua perspectiva, e então pare. Use termos e vocabulário comum a todos. Use linguagem precisa. Describe what the system does only if it is externally observable. The externally observable events are the software requirements or the things the system is required to do to satisfy user needs. In contrast, the things the system does that are not externally observable are really the responsibility of the system designers. Each use case must provide a result of value to some actor. Each use case should be a complete flow of events until the actor’s goal is achieved. If you have a use case that is too small, combine it with other use cases to make a complete flow that results in value to an actor. For example, in a Course Registration System, a use case called “Enter Student ID” does not by itself result in value to the student actor. It should probably be made into a part of a larger use case, Register for Courses, which does result in value to the actor. What level of detail should go into the use-case specification? Detail your flows until everyone has a common understanding of the requirements. Do not make the designers guess at details. The developers only know what the customer really wants if it is specified in the use case. For a use case that all stakeholders have a thorough domain understanding, you will find that you might be able to get by with just an outline. For use cases that not all stakeholders have a good understanding of the domain, you need to have more detail in the use-case description. Do not detail use cases for the sake of it. You want to move onto analysis and design as quickly as possible, while ensuring everyone understands the requirements. Unclear expressions may hide important information. Do not wait to understand the system. Be clear and accurate.

Checkpoints para casos de uso
As iterações e trocas com os atores estão claramente descritas? A seqüência de comunicação entre atores e casos de uso estão em conformidade com as expectativas do cliente? Está claro como e onde os fluxos de caso de uso começam e terminam? Subfluxos estão modelados com precisão? 

E sobre os requisitos não funcionais?
O “URPS” do FURPS Usabilidade Robustez (Confiança) Performance Suportabilidade Conformidade com as Leis e Regulamentos IMMETRO ANVISA BC ISO Restrições de Projeto Sistema Operacional Ambientes Compatibilidade Padrões de Aplicação URPS requirements may be in either a particular use case or in the supplementary specifications. F unctionality Feature set Capabilities Generality Security U sability Human factors Aesthetics Consistency Documentation R eliability Frequency/Severity of failure Recoverability Predictability Accuracy MTBF P erformance Speed Efficiency Resource usage Throughput Response time S upportability Testability Extensibility Adaptability Maintainability Compatibility Configurability Serviceability Installability Localizability Robustness The URPS of FURPS specify the nonfunctional requirements of the system. They typically describe the quality aspects of the system. What other types of nonfunctional requirements need to be specified? Requirements must be verifiable. If you cannot verify that you have met the condition or capability, then it is not a requirement. In this case, it is better to specify as a constraint or goal and then create a requirement that can be tested. For example, how can you verify “the system must be available 99.9% of the time over a 12 month period?” Do you run a test harness for a year? I hope not. Instead, specify it as a goal and then create a testable requirement that the customer agrees to. For example, “The system must be available, under load, 100 percent of the time over a one week period. During this time there must be no degradation of the following system resources: memory, available file handles, and disk space.”

Exemplo: Requisitos não funcionais
O sistema RU e-st O sistema deve fornecer cotações de preço com um atraso máximo de 15 minutos. E quanto aos outros? Onde cada um deles devem ser especificados? Two examples from the RU e-st stock trading system.

Especifique Requisitos de Usuabilidade
Usabilidade é a facilidade com que o software pode ser aprendido e operado por um usuário. Requisitos de Usabilidade incluem: Requisitos de tempo de treinamento, tempos de tarefas mensuráveis. Habilidades do usuário (iniciante/avançado). Comparação com outros sistemas conhecidos pelo usuário. Help on-line, dicas, necessidades de documentação. Conformidade com padrões. Exemplos: Windows, guias de estilo, Padrões de Tela An example of a usability requirements mapping use cases is Microsoft’s Accessibility option in the Windows control panel. Discussion: How can you “quantify” usability so it can be testable? How can you “quantify” usability so it can be testable? The ISO9241 specification provides a similar definition of usability: The effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments. Toda a documentação do usuário deve estar em conformidade com o Manual de Estilo para Documentos Técnicos da Microsoft® .

Especifique requisitos de Confiabilidade
Confiabilidade é a capacidade que um software tem de se comportar consistentemente da maneira aceitável pelo usuário. Requisitos de Confiabilidade incluem: Disponibilidade (xx.xx%) Acurácia MTBF (xx hrs) Max. bugs per/KLOC (0-x) Discussion: How can we quantify reliability so that it is testable?” How can we quantify reliability so that it is testable? MTBF – Mean Time Between Failures KLOC – Thousand Lines of Code The example given is an accuracy requirement. The subsystems in the space probe need reliable/accurate measurements in order to ensure that the probe will not plummet into the surface of the planet or miss the planet entirely. O relatório de velocidade da cápsula não tripulada de Marte deve ser em unidade de metros por segundo e estar entre 1 até 1e6.

Especifique Requisitos de Performance
Discussion: How can you “quantify” performance so that it is testable? Performance é a medida de velocidade ou eficiência de um sistema em execução. Requisitos de performance incluem: Capacidade Throughput Tempo de resposta - Memória - Modo de degradação - Use de recursos limitados - Processador, memória, disco, banda de rede How can you “quantify” performance so that it is testable? The example is based on a Network Sociability Guidelines standard that is used in an Australian telecommunications company. The requirement is in place to ensure that any new application that is brought on line has a predictable impact on the corporate WAN. “Each user action” means any keyboard of mouse action. So, for example, if the user clicks an OK button, the client and server are allowed no more than four protocol exchanges. Each exchange is limited to a maximum of 512 kilobytes of data. Não há mais do que 4 protocolos de troca, tamanhos não menores do que 512k bytes cada, entre cliente e servidor para a troca de dados.

Especifique requisitos de Suportabilidade
Discussion: How can you “quantify” supportability so that it is testable? Here are examples of observable standards and tools that may be specified to enhance supportability. Suportabilidade é a capacidade do software em ser facilmente modificável para acomodar melhorias e reparos. Requisitos de suportabilidade incluem: Linguagens, SGDB, ferramentas, e etc. Padrões de programação. Manipulação de erros e padrões de relatório. Difícil de especificar Se não mensurável ou observável, assim não é requisito. É uma restrição de projeto? É uma intenção ou um objetivo? How can you “quantify” supportability so that it is testable? Here are examples of observable standards and tools that may be specified to enhance supportability. The supportability area is the hardest to specify as observable or measurable requirements. Often these items are stated as design constraints, or, they may be stated as intent and goals in the Vision document. An example of a supportability requirement is: “The Web system must remain available to users while it is being upgraded.” This requirement would have a significant architectural impact on the system.

Como descrever protocolos de comunicação
Make this following point very clear to the students: You may need to define a communication protocol if the actor is another system or external hardware. Especifique um protocolo de comunicação se o ator é um sistema externo ou um outro hardware. A descrição do caso de uso pode estabelecer se um determinado protocolo é usado. Se o protocolo é novo, ele será totalmente descrito no desenvolvimento orientado a objetos. You might need to define a communication protocol if the actor is another system or external hardware. The description of the use case should state if some existing protocol (http, tcp/ip) is to be used. If the protocol is new, you must fully describe it during the object-model development.

Estruturar Modelos de Casos de Uso
Discuss how to structure the use-case model. It is really re-structuring since the use-case model already has a structure before you begin the “structuring” activity. RUP terminology is just “structuring.” Emphasize that you do not want to begin structuring until the customer and developers have identified and approved the details of almost all use cases. And even then, do not restructure very much, since it adds complexity to the model (more use cases, more relationships between use cases). Structuring is available for situations that really need it, but it should not be overused. Como estruturar modelos? Transformar partes de casos de uso em novos casos de uso. Por que estruturar o modelo de casos de uso? Simplificar os casos de uso originais. Tornar mais fácil de entender. Tornar mais fácil de manter. Reuso de Requisitos. Compartilhar pelos diversos casos de uso. The single most important reason for structuring a use-case model is to achieve effective reuse of requirements without sacrificing clarity or comprehension. Thereby simplifying their maintenance. Structuring the use-case model can help you handle changing requirements, such as added functionality or isolating changes to a particular requirement. It is important not to start structuring the use-case model until you have a set of requirements the user understands and agrees to. Make sure you do not start these too early, or you may confuse the customer (or yourself).

Relacionamentos entre CSUs
There are three types of use-case relationships that exist in UML 1.3. The hollow arrowhead without a label is the UML symbol for generalization. Note the term “base” use case. The base use case is the original use case from which behavior is factored out. The use case that represents the modification is the “addition” use case. If students ask, you may want to mention that in UML 1.1, these relationships were somewhat different. It is worth mentioning because students see the UML 1.1 relationships in books, such as UML Distilled, by Martin Fowler. In UML 1.1, the include relationship was called “uses,” the extend relationship was called “extends,” and generalization of use cases did not exist. Definitions and examples of each type of relationship are provided on the following slides. Include Extend Generalização «include» The purpose of structuring the use-case model is to extract behavior from one use case that can better be represented in a separate use case. Examples of behavior to factor out are: Common behavior Optional behavior Exceptional behavior Behavior that is to be developed in later iterations. To structure the use cases, there are three different kinds of relationships: Include relationship Extend relationship Generalization relationship The use case that represents the modification is called the addition use case. The original use case that is modified is called the base use case. We give definitions and examples of each type of relationship on the following slides. For reference and for further information, see the white paper Structuring the Use-Case Model. «extend»

O que é um relacionamento de Include?
O relacionamento entre um caso de uso origem com um caso de uso incluído. O comportamento do caso de uso incluído é explicitamente incluído dentro do caso de uso de origem. The include relationship connects a base use case to an inclusion use case. The inclusion use case describes a behavior segment that is inserted into a use-case instance that is executing the base use case. The base use case explicitly includes the inclusion use case. The base use case can depend on the result of performing the inclusion, but neither the base nor the inclusion may access each other's attributes. The inclusion in this sense is encapsulated and represents behavior that can be reused in different base use cases. Inclusão «include» Origem

Relacionamento de Inclusão
Obter Cotação «include» Explain the example: the include relationship, the diagram, and the text. Ask: What are some advantages to factoring out the behavior of identifying a customer into a separate use case? Ask: What are some disadvantages? The full example is located in the Student workbook. If you have time, bring the full example up on your screen and walk the students through it. Note: This example is just for teaching purposes. All of the use cases have been simplified from what they would be in “real life.” Trading Customer Executar Negociação «include» Identificar Cliente Outro caso de uso «include» Caso de Uso de Identificar Cliente 1. Autenticar 2. Validar autenticação 3. Entrar com senha 4. Validar senha A1: Autenticação inválida A2: Senha errada A3: Caso de Uso de Obter Cotação 1. Inclui “Identificar Cliente” para verificar a identidade do cliente 2. Mostrar Opções. O Cliente seleciona “Obter Cotação” 3. ... In this example, the Identify Customer use case contains all of the behavior that involves logging on to the system and entering a password. This behavior can then be extracted from all of the use cases that require customer identification, such as: Execute Trade Transfer Between Accounts Transfer With Banks Each of these use cases now simply «include» the new use case, Identify Customer. Note: Overuse of «extend» and «include» leads to a model that is functionally decomposed and therefore harder to test and implement.

Execução de um relacionamento de inclusão
Totalmente executado quando o ponto de inclusão é alcançado. Caso de Uso Base Instância de Caso de Uso The behavior of the inclusion is inserted in one location in the base use case. When a use-case instance following the description of a base use case reaches a location in the base use case from which include relationship is defined, it instead follows the description of the inclusion use case. Once the inclusion is performed, the use-case instance resumes where it left off in the base use case. The include-relationship is not conditional. If a use-case instance reaches the location of the “include” statement in the base use case, the included use case is always executed. But if a use-case instance never reaches the location in the base use case where the include relationship is defined, the included use case is not executed. If you want to express a condition that only sometimes includes a use case, you need to place the include statement in an alternative flow of the base use case. Caso de Uso Incluído

Por que utilizar um relacionamento de inclusão?
Emphasize that the keyword for remembering when «include» may be applicable is “common.” inclusão Cortar comportamento comum entre 2 ou mais casos de uso. Evitar descrever o mesmo comportamento duas vezes. Assegurar comportamento igual em vários outros pontos. Cortar e encapsular comportamento comum. Simplificar fluxos de eventos complexos. Cortar partes não primárias do comportamento. «include» Base Por que? If several use cases share the same behavior or a particular subflow is overly complex, then you can factor out the shared or complex behavior into an inclusion use case. If a part of a base use case represents a function of which the use case only depends on the result and not the method used to produce the result, you can factor that part out to an addition use case. The addition is explicitly inserted in the base use case, using the include relationship. Some organizations use a rule of thumb that every flow of events should be no more than a certain length, typically one page. If a flow gets to be longer than one page, you can often shorten it by doing the following: Identify a subflow that has its own goal and coherent set of steps. Remove the subflow from the original flow. Encapsulate the subflow in a new use case. «include» the new use case in the original flow.

O que é um relacionamento de Extend?
A useful way to explain how extension use cases work is to compare them to alternate flows. Remind the students how the basic flow has no knowledge of its alternate flows. An alternate flow explicitly inserts itself at the point the flow occurs. Also, an extension use case can extend the base use case at multiple places. Conecta um ponto de extensão de um caso de uso a um ponto do caso de uso base. Insere um ponto de comportamento extensível para um caso de uso base. Insere apenas se uma condição for verdadeira. Insere no caso de uso base um ponto de extensão nomeado. The extend relationship connects an extension use case to a base use case. You define where in the base use case to insert the extension by placing a reference in the extending use case to a named extension point in the base use case. The extension use case can often be abstract, but it does not necessarily have to be. Base «extend» Extension

Relacionamento de Extensão: Exemplo RU e-st
Explain the example: the extend relationship, the diagram, and the text. We could have included the Get News behavior as an alternative flow within the base use case, Get Quote, but we chose to make it a separate use case instead. Ask: What are some advantages to factoring out the behavior of extending use cases into separate use cases? Ask: What are some disadvantages? The textual example is located on the next slide. The full example of the structured versions of Get Quote and Get News use cases are located in the Student workbook. If you have time, bring the full example up on your screen and walk the students through it. This example is just for teaching purposes. All of the use cases have been simplified from what they would be in “real life.” Cliente de Negociações Obter Cotação «extend» «extend» Obter Notícias In this example, the Get Quote use case has been extended with other services, such as Get News and Get Expert Predictions. Both getting news and getting predictions are optional behaviors. There are two reasons you would typically extend the behavior in this manner. You are developing two versions of the system. The requirements specific to customer A are in one extending use case (Get News) and the requirements specific to customer B are in the other extending use case (Get Expert Predictions). The requirements common to both customers are in the extended use case (Get Quote). You are developing generation two of a product, and you want to visually highlight where the changes in requirements are as well as make the updated requirements easier to identify. Note: Overuse of «extend» and «include» leads to a model that is functionally decomposed and, therefore, harder to test and implement. Sistema especialista em cotações Obter Previsões Sistema novo

Relacionamento de Extensão
Caso de Uso Obter Cotação Fluxo Básico: 1. Incluir “Identificar Cliente” para verificar identidade do cliente. 2. Apresentar Opções. 3. Cliente seleciona “Obter Cotação.” 4. Cliente obtêm cotação. 5. Cliente obtêm outras cotações. 6. Cliente faz logs off. A1. Sistema de cotação fora … Pontos de Extensão: O ponto de extensão “Serviços Opcionais” ocorre no passo 3 do Fluxo Básico e passo A1.7 no fluxo alternativo Sistema de cotação fora. Caso de Uso Obtêm Notícias Este caso de uso extende o caso de Obter cotações, no ponto de extensão “Serviços Opcionais.” Fluxo Básico: 1. Se o cliente selecionar “Obter notícias,” o sistema pergunta ao cliente o intervalo de tempo e a quantidade de itens de notícia. 2. O cliente informa os dados. O sistema envia o símbolo de cotação de ações ao sistema de Notícias, recebe a resposta, e apresenta as notícias ao cliente. 3. O caso de uso Obter cotações continua. A1: Sistema indisponível A2: Sem notícias para a cotação da ação … Discuss the example. Be sure to point out the main parts of the extension relationship: The definition of the extension point in the base use case. The reference to the extension point in the extending use case that tells where to attach the extension in the base use case. The condition in the extending use case that controls whether the extension occurs. Using named extension points is a way of planning for the “dynamics of requirements.“ They are placed where you expect the requirements to change. In this example, the Get News use case extends the Get Quote use case. The extension point “Optional Services” in the base use case (Get Quote) tells where the extending use case is performed. The extension point is a “hook” at which extending use cases can be attached. The base use case does not need to be modified with knowledge of the use cases that extend it. The “hook” is placed at a logical spot for extensions, whether or not there actually are any extensions. Using named extension points is a way of planning for the “dynamics of requirements.“ They are placed where you expect the requirements to change. The base use case does not need to know it is being extended. The Get News use case references the extension point in the base use case. The extending use case needs to know and reference the extension point and other details in the base use case. The Get News use case is only performed if the condition “If Customer selects ‘Get News’” is true. More than one use case can be attached at an extension point. In the example, it makes sense to attach both the Get News use case and the Get Expert Predictions use case at the extension point “Optional Services” in the base use case (Get Quote).

Execução de um Extend Executado quando o ponto de extensão é alcançado e a condição de extensão válida. Instância de Caso de Uso Caso de Uso Base When a use-case instance performing the base use case reaches a location in which the base use case has an extension point defined for it, the condition on the corresponding extend relationship is evaluated. If the condition is true or it is absent, the use-case instance follows the extension (or the insertion segment within it that corresponds to the extension point). If the condition of the extend relationship is false, the extension is not executed. The extension use case may, just like any use case, have a basic flow of events and alternative flows of events. The exact path the use-case instance takes through the extension depends on what has happened before in the execution (the state of the use-case instance) and what happened in interaction with the actors as the extension was executed. Once the use-case instance has performed the extension, the use-case instance resumes executing the base use case at the point where it left off. Ponto de Extensão Caso de Uso Extendido

Por que usar um relacionamento de Extend?
Explain the main reasons to use an extend relationship. Emphasize the key word “optional” for when to use the «extend» relationship. Discuss the Make Phone Call example. Ask: What functionality has been added to making a phone call in recent years? [call waiting, call forwarding, etc.] Note: Call waiting and call forwarding could be added as alternative flows to the existing Make Phone Call Use Case. Ask: Why might it be a good idea to make them their own use cases? [Make Phone Call Use Case is probably already too big and is already finished, and we do not want to redo it. Call Waiting is optional, separate from rest of Make Phone Call, and is also big.] Ask: What would the condition be for executing the Call Waiting Use Case if it is an extension to the Make Phone Call Use Case? [The callee phone is busy and callee has call waiting installed and voice mail box is not full.] Recortar comportamento excepcional ou alternativo. Executado somente sob certas circunstâncias. Recortar simplifica o fluxo de eventos no caso de uso base. Exemplo: Disparar Alarmes. Adicionar Comportamento de Extensão. Comportamento desenvolvido separadamente, possivelmente em versão posterior. Base «extend» Extensão If there is a part of a base use case that is optional you can factor that part out to an addition use case in order to simplify the structure of the base use case. The addition is implicitly inserted in the base use case, using the «extend» relationship. You can also use an «extend» relationship to show the changes and additions to requirements for different versions of the product. Version 2’s requirements could be located in an extension use case, thereby making the requirement changes visually explicit. The extension is conditional, which means its execution is dependent on what has happened while executing the base use case. The base use case does not control the conditions for the execution of the extension. Those conditions are described within the extend relationship. The extension use case may access and modify properties of the base use case. The base use case, however, cannot see the extensions and may not access their properties. The base use case is implicitly modified by the extensions. You can also say that the base use case defines a framework into which extensions can be added, but the base does not have any visibility of the specific extensions. The base use case should be complete in and of itself, meaning that it should be understandable and meaningful without any references to the extensions. However, the base use case is not independent of the extensions because it cannot be executed without the possibility of following the extensions. The base use case has no knowledge of the use case that extends it and, therefore, cannot see the properties of the extending use case. The extending use case knows which use case it extends and can see all the properties of the base use case.

Caso de Uso Concreto versus Abstrato
Explain the concepts of abstract and concrete use cases. Which ones can the actor actually do? The most important thing to note on this slide is the Hint text box. Going back to the Make Phone Call example of extend relationship: Representing the optional behaviors for Call Waiting and Call Forwarding as extension use cases is a correct use of the extend-relationship, because the base use case, Make Phone Call, is meaningful in itself. You do not need to read the descriptions of the extension use cases to understand the primary purpose of the base use case, because the extension use cases are optional. Call Waiting and Call Forwarding are abstract use cases because they could not be done (instantiated) on their own. Make Phone Call is a concrete use case because it is done on its own. Abstract use cases do not have an actor initiating their actions, but it is reasonable that they may have supporting actors. Um caso de uso pode ser concreto ou abstrato. Caosos de Uso Abstratos (A & D): Não tem de ser completos. Existem somente em conjunto com outros casos de uso. Não possuem sua própria instância. A «include» Dica: Mesmo retirando todos os casos de uso abstratos você ainda é capaz de entender o sistema B C When you extract behavior into an included or extended use case, these new use cases are most often the kind that are never executed alone; they always exist as part of another use case. They are abstract use cases, but a concrete use case can: Include another concrete use case. Be extended by a concrete use case. You may want to avoid this confusion by having guidelines that state that all extending and included use cases are abstract. Business decisions must be documented in your QA Plan. «extend» Concrete use cases (B & C): Tem que ser completos e claros. Possuem suas próprias instâncias. D

Por que não estruturar o Modelo de Casos de Uso?
Inclusão - A solução é mais difícil de ver quando o casos de uso é fragmentado. - Decomposição de Caso de Uso. - Diminui entendimento. - Aumenta complexidade. - Aumenta esforço de revisores, testadores e desenvolvedores. - Nem todos os stakeholders estão confortáveis com o formato. - O Modelo de caso de uso se parece com o design. «include» Base «extend» Extensão Por que não? Filho

O que é Generalização de Ator?
Note direction and hollow arrowhead of the generalization arrow. Atores podem ter características comuns. Múltiplos atores podem ter papéis ou propósitos comuns ao interagir com os casos de uso. Pai A user can play several roles in relation to the system, which means that the user may, in fact, correspond to several actors. To make the model clearer, you can represent relationships among actors. The shared role is modeled as a parent actor. The children actors inherit the common roles of the parent. A parent actor may be specialized into one or more child actors that represent more specific forms of the parent. Neither parent nor child is necessarily abstract, although the parent in most cases is abstract. A child inherits all of the relationships of the parent. Children of the same parent are all specializations of the parent. This is generalization as applicable to actors. A specific example on the following page. Filho 1 Filho 2

Generalização de Atores
Pai: Medical Worker Servidor Hospitalar pode ler prontuário Filhos: Doutor, Enfermeira, Auxiliar Doutor, Enfermeira, e Auxiliar podem ler prontuário Explain this example, using the student notes. Note: We could not think of a meaningful example of actor generalization for the RU e-st example.To make good use of actor- generalization, you need a much richer set of actors than we have in the RU e- st example. So, we switched for this one example to a Hospital Record Keeping System. This example is adapted from a real application. The child actors could be further specialized. For example, Doctors can be Surgeons, General Practitioners, or Radiologists. Each of these types of Doctor actors may have specific use cases that only they can perform. There are very few instances where actor- generalization is used in practical experience. Agendar Operação Doutor There are many actors (roles) that interact with a hospital record-keeping system, including doctors, nurses, and aides. Some use cases can be done by many actors. For example, there may be ten different actors in a hospital who can all read patient charts. You could have ten communicates-associations (represented by 10 lines) between each of the ten actors and the Read Chart use case. Or, you could simplify by defining all ten actors as children of a parent actor called Medical Worker. Then, you only draw a single communicates-association between the Medical Worker and the Read Chart use case. All of the child actors, such as doctors, nurses, and aides, inherit the capability to do the Read Chart use case. The medical worker actor participate in lots of other use cases, such as the Ring for Security use case and Record Temperature on Chart use case. The child actors, such as doctors, nurses, and aides, inherit the capability to do all of these use cases. Why even have the child actors? Each actor (role) can participate in some other use cases that the other actors cannot. For example, only Doctor actors can perform the Schedule Operation use case. So, you draw a communicates-association between the Doctor actor and the Schedule Operation use case. You cannot draw a communicates-association between the Medical Worker actor and the Schedule Operation use case because the other children of the medical worker (such as nurses and aides) cannot perform the Schedule Operation use case. Servidor Hospitalar Enfermeira Ler Prontuário Auxiliar

Por que generalizar atores?
Ask: “Are we modeling inside the system?” (no) Note: This association should not be used very often. Remember that our primary goal is to model the system, not its surroundings! Note direction (and open-head arrow) of generalization arrow. Simplifica o relacionamento entre vários atores e casos de uso. Mostra que o comportamento do pai é herdado pelos filhos. Representa diferentes níveis de segurança. Pai Filho 1 Filho 2 There are many uses for actor generalization. Specifically, there are two common reasons: Simplify the diagrams when multiple actors all perform the same use case. When you get many actors performing the same use case you end up with a “chop stock” effect of lines all pointing to the same use case. Usually you can identify some common role that each actor is performing, create an abstract actor for the role and then use a single communicates association. To show different security levels for actors participating in a use case. When used in conjunction with preconditions at the start of different flows, you can represent that certain flows can only be performed by certain actors.

Atores concretos versus abstratos
Um ator abstrato contém a parte comum dos papéis. Não podem ser instanciados. Exemplo: Ninguém terá o cargo: servidor médico. Um ator concreto pode ser instanciado. Lauren é Doutora. Daniel é enfermeiro. Funcionário de Medicina Doutor Enfermeira

Guias para a modelagem de casos de uso
The Use-Case-Modeling Guidelines are the place to record your decisions about use-case style and modeling rules. Stress that structuring should not be done too early in the lifecycle. In fact, it may not have to be done at all, and for beginning users it should be discouraged. The Use-Case-Modeling Guidelines can help enforce the idea that structuring should not be done too early in the lifecycle. Only begin structuring after the users have understood and agreed to the basic use cases. Notações para usar e não usar. Por exemplo, quando usar relacionamento de generalização. Papéis, recomendações, estilos, e como descrever um caso de uso. Recomendações de quando começar a estruturar os casos de uso(não tão cedo). Here is a proposed outline of a Use-Case-Modeling Guidelines document: Brief Description: A brief description of the role and purpose of the Use-Case-Modeling Guidelines. References: A description of related or referenced documents. General Use-Case-Modeling Guidelines: This section describes which notation to use in the use-case model. For example, you may have decided not to use extends-relationships between use cases. How to Describe a Use Case: This section gives rules, recommendations, style issues, and how you should describe each use case.

Curso de Requisitos Módulo 03: Requisitos de Software

Apresentações semelhantes

Apresentação em tema: "Curso de Requisitos Módulo 03: 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 03: Requisitos de Software

Apresentações semelhantes

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

Apresentações semelhantes

Sobre projeto

Feedback