Essay writing, free sample essay topics, research papers

You are welcome to search the collection of free essays and term papers. Thousands of essay topics are available. Order unique, original custom papers from our essay writing service.

Sample essay topic, essay writing: Analyzing User Requirements By The Unified Process And Total Quality Management - 3094 words

NOTE: Essay you see on this page is free essay, available to anyone. We strongly do not recommend using any direct quotes from these essays for credit - you will most probably be caught for copying/pasting off the Internet, as it is very easy to trace where the essay has been taken from by a plagiarism detection program. You are welcome to use these samples for your research, but if you want to be sure that your essay is 100% original and one of a kind, we highly recommend to order a custom essay from us.

.. 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 lifecycle.Figure 6 The workflow for problem analysisIn 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

Order custom essays brand-new and 100% original, tailored to your needs, price quote

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 projectThis workflow detail should be revisited several times during inception and early elaboration. Then, throughout the lifecycle 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.2 How to Understand Stakeholder Needs?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 needs4.2.3 How to Define the System?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 definition4.2.4 How to Manage the Scope of the System?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 management4.2.5 How to Refine the System Definition?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 system5 A real world case: Interlancer, LimitedThis 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 InterlancerInterlancer 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 Interlancer5.2.1 Analyze the ProblemWe 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 stakeholdersAfter grouping, we got:Figure 13 The final affinity diagram to identify stakeholdersAs 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 VEEWhen 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 system5.2.2 Understand Stakeholder NeedsThrough 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 needsFigure 17 The second step in building a tree diagram to understand stakeholder needsFigure 18 The final tree diagram to understand stakeholder needsNow, 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 onlineFigure 20 Use Case: Make decision onlineFigure 21 Use Case: Analyze sales results5.2.3 Define the SystemWe 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 online5.2.4 Manage the Scope of the SystemWe 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 DLog in 1 2 2 1Log out 1 1 1 1Buy products 3 2 2 3Refund purchased items 1 2 1 1List products 3 3 3 3Edit personal profile 1 1 2 1Order products 1 2 1 1Table 1 Priorities of seven sub use cases in Use case: Buy products onlineFrom Table 1, we got the Pareto chart like Figure 23:Figure 23 Pareto chart for seven sub use cases in Use Case: Buy products onlineFrom 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 DefinitionAfter 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 productsAccording to this PCPC, we can easily get detailed Use Case: Buy products with flow of events.Use Case: Buy productsUse case: Buy productsActors: CustomerPurpose: Capture an online sale and its paymentOverview: 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 Response1.

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 information4. 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:Line4: System detects failure to collaborate with external system. Signal error to Customer and ask Customer for alternate payment. Line5: System receives payment denial. Signal denial to Customer and ask Customer for alternate payment.6 ConclusionIn 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' stage, 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' stage, 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' stage, it allows the team understand a requirement comprehensively.o During 'Manage the Scope of the System' stage, 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' stage, it helps the team anticipate the customer and the system's potential activities and draw a robust use-case model.Appendix: Glossary of TermsGlossary 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 illustrationsFigure 1 A software development processFigure 2 The life of a process consists of cycles from its birth to its death.Figure 3 The five workflows-requirements, analysis, design, implementation, and test-take place over the four phases: inception, elaboration, construction, and transition.Figure 4 Requirements are done primarily during inception and elaboration.Figure 5 Requirements workflow in UPFigure 6 The workflow for problem analysisFigure 7 A tree diagram which shows common constraints on a software projectFigure 8 The workflow to understand stakeholder needsFigure 9 The workflow for system definitionFigure 10 The workflow for scope managementFigure 11 The workflow to refine the systemFigure 12 The initial affinity diagram to identify stakeholdersFigure 13 The final affinity diagram to identify stakeholdersFigure 14 Use-case model with actors only for VEEFigure 15 The tree diagram for constraints imposed on the systemFigure 16 The first step in building a tree diagram to understand stakeholder needsFigure 17 The second step in building a tree diagram to understand stakeholder needsFigure 18 The final tree diagram to understand stakeholder needsFigure 19 Use Case: Buy products onlineFigure 20 Use Case: Make decision onlineFigure 21 Use Case: Analyze sales resultsFigure 22 Detailed Use Case: Buy products onlineFigure 23 Pareto chart for seven sub use cases in Use Case: Buy products onlineFigure 24 PDPC for Use Case: Buy productsList of tablesTable 1 Priorities of seven sub use cases in Use case: Buy products onlineReferences[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 Larman, 1998. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall, NJ.[4] Dale H.

Besterfield, 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. The Six Sigma Handbook: A complete Guide for Greenbelts, Blackbelts, and Managers at All Levels.

McGraw-Hill, US.

Research paper and essay writing, free essay topics, sample works Analyzing User Requirements By The Unified Process And Total Quality Management

Top

Essay help, free essay samples:

Holes, Estranged Labor, The Godfather, Gene Manipulation, Fascism - Alternative Approach, The Whiskey Rebellion, Louis Armstrong: From Childhood To Adulthood, The Legalization Of Marijuana, Here Is New York, Invisible Man Comparative Essay, Hamlet: Inner Turmoil, Marijuana, The Significance Of International Sports, Electronic Payment Method, Past Experiences Shape Identity, Mortar Exam 0341, The Role Of Husband And Wife In The Middle Ages, and much more...