Stakeholder Needs Figure 19 Use Case example essay topic

Analyzing User Requirements by the Unified Process and Total Quality Management Summary successful project demands a correct and thorough requirements analysis. This paper proposes a refined requirements workflow, TQM / UP, to analyze requirements systematically. This workflow integrates five management and statistical analysis tools of Total Quality Management (TQM) -Affinity diagram, Tree diagram, Brainstorming, Pareto analysis and Process Decision Program Chart (PDPC) -into the Unified Process (UP) and helps the team to analyze requirements in a more efficient way. The guidelines I provide are based on my own experiences in an IT company, Interlancer, Limited which is briefly introduced at the latter part of this paper. Educator & practitioner summary would like to thank all of the people at UL for their support and input during this project.

I give special thanks to my project advisor, Mr. John Noonan, for his support and guidance. I would also like to thank my girlfriend, for her enduring support over the past several weeks. Contents Summary 1 Educator & practitioner summary 21 Introduction 52 What are Requirements? 53 Capturing Requirements by UP 63.1 What is UP? 73.1. 1 UP is Use-Case Driven 73.1.

2 UP is Architecture-Centric 83.1. 3 UP is Iterative and Incremental 83.2 The Life of UP 83.3 The Role of Requirements in the Software Life Cycle 103.4 Requirements Workflow in UP 104 A Refined Requirements Workflow: TQM / UP 134.1 Introduction of TQM Tools 134.1. 1 Affinity diagram 134.1. 2 Tree diagram 134.1. 3 Brainstorming 134.1. 4 Pareto analysis 144.1.

5 Process Decision Program Chart (PDPC) 144.2 TQM / UP 144.2. 1 How to Analyze the Problem? 144.2. 2 How to Understand Stakeholder Needs? 174.2. 3 How to Define the System?

184.2. 4 How to Manage the Scope of the System? 194.2. 5 How to Refine the System Definition?

205 A real world case: Interlancer, Limited 215.1 A brief introduction of Interlancer 215.2 TQM / UP in Interlancer 225.2. 1 Analyze the Problem 225.2. 2 Understand Stakeholder Needs 245.2. 3 Define the System 275.2. 4 Manage the Scope of the System 275.2.

5 Refine the System Definition 286 Conclusion 30 Appendix: Glossary of Terms 31 List of illustrations 32 List of tables 32 References 331 Introduction Requirements analysis of a software system is one of the most crucial steps in the software development process. Frederick P. Brooks, Jr. has pointed out that no other part of the work so cripples the resulting system if done wrong and no other part is more difficult to rectify later than requirements analysis. The potential impact of errors in requirements is substantial: o The resulting software may not satisfy users' real needs. o Multiple interpretations of requirements may cause disagreements between customers and developers, wasting time and dollars and perhaps resulting in lawsuits. o It may be impossible to thoroughly test that the software meets its intended requirements. o Both time and money may be wasted building the wrong system. In this paper, I present a refined workflow, TQM / UP, which is to based on UP and TQM to analyze requirements. Section 2 gives a definition of requirements and a most common way to categorize requirements while section 3 briefly describes UP and the requirements workflow in UP.

Section 4 introduces how TQM / UP works. Section 5 takes a real world case, Interlancer, Limited as an example to show how to use TQM / UP to analyze requirements. I conclude with a summary in section 6 as well as the key benefits that TQM / UP takes to requirements analysis. 2 What are Requirements? The I Standard 729 defines requirement as " (1) a condition or capability needed by a user to solve a problem or achieve an objective; (2) a condition or capability that must be met or possessed by a system... to satisfy a contract, standard, specification, or other formally imposed document". .

There are many different kinds of requirements. One way of categorizing them is described as functional and non-functional requirements. Functional requirements specify actions that a system must be able to perform, without taking physical constraints into consideration. These are often best described in a use-case model (Glossary of Terms) and in use cases (Glossary of Terms). Functional requirements thus specify the input and output behaviour of a system. Requirements that are not functional are sometimes called non-functional requirements.

Many requirements are non-functional, and describe only attributes of the system or attributes of the system environment. Although some of these may be captured in use cases, those that cannot may be specified in Supplementary Specifications (Glossary of Terms). Non-functional requirements may include: o Usability: human factors, aesthetics, consistency in the user interface, online and context-sensitive help, wizards and agents, user documentation, training materials. o Reliability: frequency and severity of failure, recover ability, predictability, and accuracy mean time between failures (MTBF). o Performance: speed, efficiency, availability, accuracy, throughput, response time, recovery time, resource usage. o Supportability: testability, extensibility, adaptability, maintainability, compatibility, , serviceability, (internationalization). o Design requirement: A design requirement, often called a design constraint, specifies or constrains the design of a system. o Implementation requirements: An implementation requirement specifies or constrains the coding or construction of a system including required standards, implementation languages, policies for database integrity, resource limits, operation environments, etc. o Interface requirements: An interface requirement specifies an external item with which a system must interact and constraints on formats, timings, or other factors used by such an interaction. o Physical requirements: A physical requirement specifies a physical characteristic that a system must possess such as material, shape, size, weight. 3 Capturing Requirements by UP Obtaining requirements for software systems is a conceptually and practically complex activity. In particular, the amount of communication that is required among stakeholders (Glossary of Terms) and analysts often leads to misunderstandings. Stakeholders may forget or not be aware of requirements, and analysts, without the deep domain knowledge of most stakeholders, may not be able to fill in the gaps.

In addition, some requirements and constraints may be so obvious to and expert stakeholder that they do not seem worth mentioning, but the thin spread of domain expertise among analyst teams means that these requirements may not be recognized or incorporated into the development process. The traditional approach to this problem has been to assign intermediaries-analysts-to elicit a list of requirements from each user with the hope that the analyst would be able to see the whole picture and put together a complete, correct, and consistent requirements specification. Analysts typically recorded the requirements in documents that ran to hundreds, sometimes thousands, of pages. But it is absurd to believe that the human mind can come up with a consistent and relevant list of thousands of requirements in the form "The system shall... ". What's more, these requirements specifications did not readily transform into design and implementation specifications.

UP-the outcome of more than 30 years of experience-is a solution to these software problems. It provides developers a well-defined and well-managed process to analyze requirements and develop software. 3.1 What is UP? First and foremost UP is a software development process. A software development process is the set of activities needed to transform a user's requirements into a software system (see Figure 1).

However, UP is more than a single process; it is a generic process framework that can be specialized for a very large class of software systems, for different application areas, different types of organizations, different competence levels, and different project sizes. UP uses the Unified Modelling Language (UML) (Glossary of Terms) when preparing all blueprints of the software system. The real distinguishing aspects of UP are captured in the three key words-use-case driven, architecture-centric, and iterative and incremental. Figure 1 A software development process 3.1. 1 UP is Use-Case Driven software system is brought into existence to serve its users. Therefore, to build a successful system we must know what its prospective users want and need.

The term user refers not only to human users but to other systems. In this sense, the term user represents someone or something (such as another system outside the proposed system) that interacts with the system being developed. A use case is a piece of functionality in the system that gives a user a result of value. Use cases capture functional requirements. All the use cases together make up the use-case model which describes the complete functionality of the system. This model replaces the traditional functional specification of the system.

Based on the use-case model, developers create a series of design and implementation models that realize the use cases. The developers review each successive model for conformance to the use-case model. The testers test the implementation to ensure that the components of the implementation model correctly implement the use cases. In this way, the use cases not only initiate the development process but bind it together. 3.1.

2 UP is Architecture-Centric The role of software architecture is similar in nature to the role architecture plays in building construction. The building is looked at from various viewpoints: structure, services, heat conduction, plumbing, electricity, and so on. Similarly, architecture in a software system is described as different views of the system being built. The software architecture concept embodies the most significant static and dynamic aspects of the system. The architecture grows out of the needs of the enterprise, as sensed by users and other stakeholders, and as reflected in the use cases. Architecture is a view of the whole design with the important characteristics made more visible by leaving details aside. 3.1.

3 UP is Iterative and Incremental Developing a commercial software product is a large undertaking that may continue over several months to possibly a year or more. It is practical to divide the work into smaller slices or mini-projects. Each mini-project is an iteration that results in an increment. Iterations refer to steps in the workflow, and increments, to growth in the product. In every iteration, the developers identify and specify the relevant use cases, create a design using the chosen architecture as a guide, implement the design in components, and verify that the components satisfy the use cases. If an iteration meets its goals-and it usually does-development proceeds with the next iteration.

When an iteration does not meet its goals, the developers must revisit their previous decisions and try a new approach. 3.2 The Life of UP UP repeats over a series of cycles making up the life of a system, as depicted in Figure 2. Each cycle concludes with a product release to customers. Figure 2 The life of a process consists of cycles from its birth to its death. Each cycle consists of four phases: inception, elaboration, construction, and transition. Each phase is further subdivided into iterations.

See Figure 3. Figure 3 The five workflows-requirements, analysis, design, implementation, and test-take place over the four phases: inception, elaboration, construction, and transition. Through a sequence of models, stakeholders visualize what goes on in these phases. Within each phase managers or developers may break the work down still further-into iterations and the ensuing increments.

Each phase terminates in a milestone. We define each milestone by the availability of a set of artefact; that is, certain models or documents have been brought to a prescribed state. Figure 3 lists the workflows-requirements, analysis, design, implementation, and test-in the left-hand column. The curves approximate (they should not be taken too literally) the extent to which the workflows are carried out in each phase. A typical iteration goes through all the five workflows as shown for an iteration in the elaboration phase in Figure 3.3. 3 The Role of Requirements in the Software Life Cycle The use-case model is developed over several development increments, where the iterations will add new use cases and / or detail to the descriptions of existing use cases.

Figure 4 illustrates how the requirements capture and the resulting artefacts assume different shapes during the different phases and their iterations: o During the inception phase, analysts identify most use cases in order to delimit the system and scope the project and to detail the most critical ones (less than 10%). o During the elaboration phase, analysts capture most of the remaining requirements so that developers can gauge the size of the development effort that will be required. The goal is to have captured about 80% of the requirements and to have described most of the use cases by the end of the elaboration phase. (Only about 5% to 10% of those requirements should be implemented into the architecture baseline at this point.) o The remaining requirements are captured (and implemented) during the construction phase. o There is almost no requirements capture during the transition phase, unless there are changing requirements. Figure 4 Requirements are done primarily during inception and elaboration.

3.4 Requirements Workflow in UP Requirements workflow is a sequence of activities that describe the procedure of requirements analysis. The requirements workflow in UP is shown in Figure 5. Figure 5 Requirements workflow in UPAs shown in Figure 5, each workflow detail (Glossary of Terms) represents a key skill that need to be applied to perform effective requirements analysis. Analyze the Problem and Understand Stakeholder Needs are focused on during the inception phase of a project, whereas the emphasis is on Define the System and Refine the System Definition during the elaboration phase.

Manage the Scope of the System is done continuously throughout the project. The workflow details are shown in a logical, sequential order. As indicated in the text above, they are applied continuously in varied order as needed throughout the project. Here they are shown in the sequence that would be most likely applied to the first iteration of a new project. Analyze the problem Problems are analyzed to understand problems and initial stakeholder needs, and to propose high-level solutions.

It's an act of reasoning and analysis to find 'the problem behind the problem'. During problem analysis, agreement is gained on what the real problems are and on who the stakeholders are. From a business perspective the boundaries of the solution and any business constraints on the solution are also defined. Understand Stakeholder Needs Requirements come from many sources; for example, customers, partners, end users, and domain experts.

It is necessary to know how to determine what the best sources should be, how to access those sources, and how to elicit information from them most effectively. The individuals who provide the primary sources for this information are referred to as stakeholders in the project. Define the System Defining the system means translating and organizing the understanding of stakeholder needs into a meaningful description of the system to be built. Early in system definition, decisions are made about what constitutes a requirement, degree of requirements specificity (how many and in what detail), technical and management risks, and initial scope. Part of this activity may include early prototypes and design models directly related to the most important stakeholder requests. Manage the Scope of the system To efficiently run a project, it is needed to carefully prioritize the requirements based on input from all stakeholders and manage its scope.

Too many projects suffer from developers working on so called 'Easter eggs' (features the developer finds interesting and challenging), rather than early focusing on tasks that mitigate a risk to the project or stabilize the architecture of the application. It is necessary to negotiate the scope of each iteration with the project's stakeholders. It is also needed to control the sources of the requirements, how the deliverable's of the project look, as well as the development process itself. Refine the system definition The detailed definition of the system needs to be presented in such a way that the stakeholders can understand, agree to, and sign off on them.

It needs to cover not only functionality, but also compliance with any legal or regulatory requirements, usability, reliability, performance, supportability, and maintainability. The use-case methodology, often in combination with simple visual prototypes, is a very efficient way of communicating the purpose and defining the details of the system. Use cases help put requirements into a context; they tell a story of how the system will be used. 4 A Refined Requirements Workflow: TQM / UPA lot of work about requirements analysis in UP is dealt with by use cases. But use cases may seem difficult for some team members that are not familiar with them. This could lead to some mistakes during the requirement analysis process.

This section presents a refined requirements workflow, TQM / UP, which is integrated with some basic and comprehensible tools in TQM in order to make requirement analysis easier. 4.1 Introduction of TQM Tools TQM is a management philosophy embracing all activities through which the needs and expectations of the customer and community, and the objectives of the organisation are satisfied in the most efficient and cost effective way by maximis ing the potential of all employees in a continuing drive for improvement. It is a proven technique to guarantee survival in world-class competition and has some statistical process control (SPC) and management tools which are excellent problem-solving tools especially for requirements analysis. 4.1. 1 Affinity diagram Affinity Diagram is used to categorize problems and themes which are hazy and difficult to understand, helping to create order out of chaos. This diagram uses the natural affinity between opinions and partial data from a variety of situations to help understand and structure the problem. 4.1. 2 Tree diagram Tree diagrams are used to break down or stratify ideas in progressively greater detail.

The objective is to partition a big idea or problem into its smaller components, making the idea easier to understand, or the problem easier to solve. 4.1. 3 Brainstorming Brainstorming is a method of free expression and is employed when the solutions to problems cannot be deduced logically and / or when creative new ideas are required. Brainstorming works best in groups. It unlocks the creative power of the group through the synergistic effect (e.g. one person's ideas may trigger the thoughts of another member of the group) and in this way stimulate the production of ideas.

It can be employed in a structured manner in which the group follow a set of rules or in an unstructured format which allows anyone in the group to present ideas randomly as they occur. 4.1. 4 Pareto analysis Pareto analysis is a technique employed for prioritizing problems of any type. It is an extremely useful tool for condensing a large volume of data into a manageable form and in helping to determine which problems to solve and in what order. In this way the improvement efforts are directed at areas and projects that will have the greatest impact. 4.1. 5 Process Decision Program Chart (PDPC) Programs to achieve particular objectives do not always go according to plan, and unexpected developments may have serious consequences.

Considering the system as a whole PDPC is used to anticipate unexpected events and develop plans, counter-measures and actions for these situations. It is based on a tree diagram and uses a questioning technique of, for example, 'What could go wrong?' 'What are the alternatives?' and the listing of actions or counter-measures accordingly. 4.2 TQM / UP TQM / UP is a refined requirements workflow based on UP. It details each workflow detail of requirements workflow in UP and is integrated with above TQM tools. 4.2.

The first step in any problem analysis is to make sure that all parties involved agree on what is the problem that they are trying to solve with the system. In order to avoid misunderstandings, it is important to agree on common terminology which will be used throughout the project. Early on, it is necessary to define project terms in Glossary (Glossary of Terms) which will be maintained throughout the project life cycle. Figure 6 The workflow for problem analysis In order to fully understand the problems, it is very important to know who the stakeholders are (see Figure 6).

Some of these stakeholders-the users of the system-will be represented by actors in use-case models. The affinity diagram is a very good tool to abstract the types of stakeholders-a user, an administrator, a manager or a system-from abundant opinions proposed by team members. The basic steps for identifying stakeholders by an affinity diagram are: a) Make sure very team member know what's the main problems the current system will solve. b) Collect potential stakeholders' information. This could involve interviews with relevant personnel, customers and suppliers, and examination of previously made notes and reports, brainstorming and getting project members to express opinions. c) Each idea and opinion is written on a card or 'Post-It' note. d) The card is placed in a random fashion on the table, board, wall or whatever means is being used to display the data. e) Those cards with similar stakeholders are placed together and separated from the remaining cards.

This development of related issues and natural clusters is often done by the team members moving the cards around the board in silence. Each group of cards is given a title which reflects the characteristics of its group; the group of stacked cards is then treated as one card. This group card is usually termed the affinity card. f) This process is repeated until all stakeholders are clustered within different groups. g) The group affinity cards are arranged in a logical order and broad lines drawn around them. h) Document the results as actors in use-case model. The next step in this workflow detail is to identify constraints imposed on the system such as software languages, software process requirements, developmental tools, architectural and design constraints, purchased components, class libraries, etc. Tree diagram would be very useful for the project leader to get constrains thoroughly.

Typical procedures of identifying constraints imposed on the system are: a) The problem to be solved is written on a card. Here, the problem is what the constraints are, so we write 'Constraints on the system' on a card and place it on the left-hand side of the board. b) Team members have a brainstorm on how many types of constraints such as software languages, software process requirements, developmental tools, etc. there are in this system and write each type on a card and place directly to the right of the problem statement. In this way the first level of a root and branch relationship is created. c) Each team member asks himself a question like "What constraints the system has in each category?" and writes down what they think on a card. The project leader holds a simple vote to extract useful constraints and put them on the right of each category. d) Document the results as in the Vision document. Figure 7 shows an example.

Figure 7 A tree diagram which shows common constraints on a software project This workflow detail should be revisited several times during inception and early elaboration. Then, throughout the life cycle of the project, it should be revisited as necessary while managing the inevitable changes that will occur in the project, in order to ensure that the correct problems are addressed. 4.2. The first step in this workflow detail (see Figure 8) is to collect information from the stakeholders. It can be done by interview, meeting, questionnaire, etc. After that, the team begins to elicit information got from the stakeholders in order to understand what their needs really are. Tree diagrams can help the team to elicit the stakeholder needs systematically.

The tree diagrams are produced via a team approach and involve the following basic steps: a) Ensure that every team member understands who the stakeholders are. b) Write 'Stakeholder Needs' on a card then place it on the left-hand side of the board, table, wall or what other means is being used to display the data. c) Project members choose the categories from functionality, reliability, performance, supportability, usability, design requirement, implementation requirements, interface requirements, physical requirements according to the information they collected. Each of these categories is written on a card and placed directly to the right of the 'Stakeholder Needs' card. In this way the first level of a root and branch relationship is created. d) Project leader asks team members to write down the stakeholder needs they " ve collected and their own ideas on cards according to the categories on the board and place them on the right of categories cards. In this way the tree diagram is created.

After the above steps are finished, project leader can start discussing the functional requirements of the system, transforming them into outlined use cases and document them in use-case model. Those non-functional requirements, which do not fit easily into the use-case model, should be documented in the Supplementary Specifications. Typically, this activity is mainly performed during iterations in the inception and elaboration phases; however stakeholder requests should be gathered throughout the project. Figure 8 The workflow to understand stakeholder needs 4.2. Problem Analysis and activities for Understanding Stakeholder Needs create early iterations of key system definitions, including a first outline to the use-case model. In this stage analysts identify actors and use cases more completely (see Figure 9), and expand the global non-functional requirements as defined in the Supplementary Specifications.

The followings are some factors to be considered in refining use-case model and non-functional requirements. o Start out by clearly stating what non-functional requirement or use case should be refined. o Generate as many ideas as possible. o Once information is gathered, mutate and combine ideas. o Hold a simple vote to prioritize each idea. o Document the results in the use-case model and Supplementary Specifications. o Choose another non-functional requirement or use case and do again. Figure 9 The workflow for system definition 4.2. The scope of a project is defined by the set of requirements allocated to it. Managing project scope to fit the available resources (time, people, and money) is key to managing successful projects. Managing scope is a continuous activity that requires iterative or incremental development, which breaks project scope into smaller more manageable pieces. The main purpose in this stage is to prioritize the use cases and non-functional requirements to decide which ones should be included in the current iteration.

Using Pareto analysis as the basis for negotiating the inclusion of a requirement is a particularly useful technique for managing scope. It includes the following steps (see Figure 10): a) Make sure every team member clear about the requirements (including functional and non-functional requirements) to prioritize. b) Let everyone prioritize each requirement by category (for example, primary, secondary, nice to have), which have assigned weights (for example, 3, 2, 1). The sum of the priorities for each requirement will be its importance in relation to the other. c) Project leader choose 10-15 requirements which has the highest priorities to tabulate in descending order. d) Arrange these requirements as in a bar chart. e) Construct the Pareto diagram with the columns arranged in order of descending priorities. f) Determine cumulative totals and percentages and construct the cumulative percentage curve. g) Project leader decides which requirements to select in this iteration according to the Pareto diagram and project schedule. The requirements selected will be used by the project leader in planning the iterations and enables the software architect to identify the architecturally significant use cases. Figure 10 The workflow for scope management 4.2. Refining the System definition begins with detailing use cases, and describing the use case's flow of events.

PDPC can be used as the basis for identifying potential events. The key steps are as follows (see Figure 11): a) Project leader choose one use case and give a brief introduction to it. b) Write this use case's name on a card and place it on the top of the board. c) Write down a typical sequence of activities that an actor or a system will do on cards and place them on the second level in order. d) The team brainstorms to determine what could go wrong when some alternatives happen. Write down these alternatives as the third level. e) Think about counter-measures and write them down as the fourth level. f) Define use case's flow of events in use-case model according to PDPC. Simultaneously, non-functional requirements should be revised and detailed. Figure 11 The workflow to refine the system 5 A real world case: Interlancer, Limited This section introduces an IT company, Interlancer, Limited and illustrates some requirements and use-case models of Interlancer as to clarify how to use TQM / UP in reality. 5.1 A brief introduction of Interlancer Interlancer is a newly founded Third Generation Application Service Provider (ASP).

It plans to develop a new product named Virtual Enterprise Engine (VEE). The VEE is a web-based, e-business infrastructure that supports and integrates key functional business processes within a company. Examples of these processes could be: o New product-service development. o Marketing support. o Customer relationship management. o Company database creation-maintenance. o Partners & suppliers management. o Decision support. o Sales pipeline development. 5.2 TQM / UP in Interlancer 5.2. 1 Analyze the Problem We started the project with stakeholder identification.

The stakeholders were identified by affinity diagrams. After discussion, we thought the following people might be our stakeholders (see Figure 12). Figure 12 The initial affinity diagram to identify stakeholders After grouping, we got: Figure 13 The final affinity diagram to identify stakeholders As can be seen from this affinity diagram, the main stakeholders of VEE are Information System Administrator, HRM Department, R&D Department, Financial Department, Sales & Marketing Department, Quality Department, Customer and CEO. According to Figure 13, we got the following use-case model (see Figure 14): Figure 14 Use-case model with actors only for VEE When the stakeholders were clear, we started to identify the constraints imposed on the system. The following is the tree diagram that we got (see Figure 15).

The tree diagram shows that there are three kinds of constraints imposed on the system. They are software language, architectural and design constraints and purchased components. The software languages that we can use are limited to html and asp, while the software must be web-based and internet phone service should be bought from other companies. Figure 15 The tree diagram for constraints imposed on the system 5.2. 2 Understand Stakeholder Needs Through some interviews with our potential customers and some questionnaires, we got a lot of stakeholder needs.

We began to elicit the stakeholder needs by tree diagram. The followings show the procedures of building a tree diagram (see Figure 16, Figure 17 and Figure 18). Figure 16 The first step in building a tree diagram to understand stakeholder needs Figure 17 The second step in building a tree diagram to understand stakeholder needs Figure 18 The final tree diagram to understand stakeholder needs Now, we can document non-functional requirements-usability and reliability-into Supplementary Specification and get the following refined use-case model (see Figure 19, Figure 20 and Figure 21): Figure 19 Use Case: Buy products online Figure 20 Use Case: Make decision online Figure 21 Use Case: Analyze sales results 5.2. 3 Define the System We spent nearly two weeks to refine outlined use cases as shown above and expand 40% of non-functional requirements by brainstorming. Figure 22 shows one of the detailed use cases, Buy products online.

Customer can log in and log out the system. When he logs in, he can edit his own profile. Customer can also list products' description, order products that he wants, refund purchased items if some defects are found and buy products by credit card. Figure 22 Detailed Use Case: Buy products online 5.2. 4 Manage the Scope of the System We divided elaboration phase into three iterations, which last two weeks each. In each iteration, some major requirements (including functional and non-functional requirements) are chosen to do further analysis.

Take Use Case: Buy products online as an example. This use case includes seven sub use cases: Log in, Log out, List products, Buy products, Edit personal profile, Order products and Refund purchased items. We decided to include three sub use cases in iteration 1 and leave the rest to iteration 2. The key procedures of choosing requirements by Pareto analysis are as follows (see Table 1 and Figure 23): Each team member voted on seven sub use cases. The result is shown in Table 1.

Use cases Person A Person B Person C Person Log in 1 2 2 1 Log out 1 1 1 1 Buy products 3 2 2 3 Refund purchased items 1 2 1 1 List products 3 3 3 3 Edit personal profile 1 1 2 1 Order products 1 2 1 1 Table 1 Priorities of seven sub use cases in Use case: Buy products online From Table 1, we got the Pareto chart like Figure 23: Figure 23 Pareto chart for seven sub use cases in Use Case: Buy products online From this Pareto chart we can see that List products, Log in and Buy products cover nearly 69% of all priorities, so we included these three sub use cases in iteration 1.5. 2.5 Refine the System Definition After prioritizing, we decided to detail three use cases-List products, Log in and Buy products-with flow of events in iteration 1. Figure 24 shows the PDPC for Use Case: Buy products. Figure 24 PDPC for Use Case: Buy products According to this PDPC, we can easily get detailed Use Case: Buy products with flow of events. Use Case: Buy products Use case: Buy products Actors: Customer Purpose: Capture an online sale and its payment Overview: Customer opens shopping cart webpage and click 'Pay'. The system records the purchase items and asks Customer input credit account information.

On completion, system delivers items to Customer. Preconditions: Customer must have completed the Log in use casePostconditions: Sale is saved. Accounting and Inventory are updated. Commissions recorded. Products are successfully delivered. Typical Course of Events: Actor action System Response 1.

Customer opens shopping cart webpage and presses 'Pay' 2. System calculates the total amount of money and asks Customer input credit account information. 3. Customer enters his credit account information 4. System sends payment authorization request to an external Payment Authorization Service System, and requests payment approval. 5.

System receives payment approval and records it with credit payment. 6. System asks inventories to deliver products and tell Customer when he can get products. Alternative Courses: Line 4: System detects failure to collaborate with external system. Signal error to Customer and ask Customer for alternate payment. Line 5: System receives payment denial.

Signal denial to Customer and ask Customer for alternate payment. 6 Conclusion In this paper, a refined requirements workflow, TQM / UP, is presented, which is based on the requirements workflow in UP as well as some management and statistical analysis tools of TQM. After the introduction of TQM / UP, a real world case: Interlancer, Limited is illustrated to show how this framework works in the reality. I argue that TQM / UP can take the following benefits to requirements analysis: o During 'Analyze the Problem's tage, it allows the team to creatively generate a large number of ideas and then logically group them for problem understanding. It helps the team detect stakeholders thoroughly. o During 'Understand Stakeholder Needs's tage, it encourages team members to think systematically, split complex problems into small, simple ones and makes the identification of system constraints and stakeholder needs easier. o During 'Define the System's tage, it allows the team understand a requirement comprehensively. o During 'Manage the Scope of the System's tage, it helps the team clear about which requirements are the most important in current iteration and put efforts on the requirements which have the greatest impact. o During 'Refine the System Definition's tage, it helps the team anticipate the customer and the system's potential activities and draw a robust use-case model. Appendix: Glossary of Terms Glossary The Glossary defines important terms used by the project. stakeholder An individual who is materially affected by the outcome of the system.

Supplementary Specifications The Supplementary Specifications capture the system requirements that are not readily captured in the use cases of the use-case model. Unified Modelling Language (UML) A language for visualizing, specifying, constructing, and documenting the artefacts of a software-intensive system. use case A description of a set of sequence of actions, including variants, that a system performs that yields an observable result of value to a particular actor. use-case model A model that describes a system's functional requirements in terms of use cases. workflow detail A grouping of activities which are performed in close collaboration to accomplish some result. The activities are typically performed either in parallel or iteratively, with the output from one activity serving as the input to another activity. Workflow details are used to group activities to provide a higher level of abstraction and to improve the comprehensibility of workflows. List of illustrations Figure 1 A software development process Figure 2 The life of a process consists of cycles from its birth to its death. Figure 5 Requirements workflow in UP Figure 6 The workflow for problem analysis Figure 7 A tree diagram which shows common constraints on a software project Figure 8 The workflow to understand stakeholder needs Figure 9 The workflow for system definition Figure 10 The workflow for scope management Figure 11 The workflow to refine the system Figure 12 The initial affinity diagram to identify stakeholders Figure 13 The final affinity diagram to identify stakeholders Figure 14 Use-case model with actors only for VEE Figure 15 The tree diagram for constraints imposed on the system Figure 16 The first step in building a tree diagram to understand stakeholder needs Figure 17 The second step in building a tree diagram to understand stakeholder needs Figure 18 The final tree diagram to understand stakeholder needs Figure 19 Use Case: Buy products online Figure 20 Use Case: Make decision online Figure 21 Use Case: Analyze sales results Figure 22 Detailed Use Case: Buy products online Figure 23 Pareto chart for seven sub use cases in Use Case: Buy products online Figure 24 PDPC for Use Case: Buy products List of tables Table 1 Priorities of seven sub use cases in Use case: Buy products online

Bibliography

1] Alan M. Davis, 1993.
Software Requirements: Objects, Functions, and States. Prentice-Hall, New Jersey. [2] Barrie G. Dale, 2nd Ed., 1994.
Managing quality. Prentice-Hall, NJ. [3] Craig L arman, 1998.
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall, NJ. [4] Dale H. Bester field, 2nd Ed., 1999.
Total Quality Management. Prentice-Hall, Inc., New Jersey. [5] Grady Booch, James Rumbaugh, and Ivar Jacobson, 1998.
Unified Modelling Language User Guide. Addison-Wesley, MA. [6] Ivar Jacobson, Grady Booch and James Rumbaugh, 1999.
The Unified Software Development Process. Addison-Wesley, MA. [7] James Rumbaugh, Ivar Jacobson, and Grady Booch, 1998.
Unified Modelling Language Reference Manual. Addison-Wesley, MA. [8] Philippe Kruchten, 2nd Ed., 2000.
The Rational Unified Process: An Introduction. Addison-Wesley, MA. [9] Thomas Pyzdek, 1999.