Analyzing User Requirements By The Unified Process And Total Quality Management

Analyzing User Requirements by the Unified Process and Total Quality Management

Summary

A 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

I 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 2

1 Introduction 5

2 What are Requirements? 5

3 Capturing Requirements by UP 6

3.1 What is UP? 7

3.1.1 UP is Use-Case Driven 7

3.1.2 UP is Architecture-Centric 8

3.1.3 UP is Iterative and Incremental 8

3.2 The Life of UP 8

3.3 The Role of Requirements in the Software Life Cycle 10

3.4 Requirements Workflow in UP 10

4 A Refined Requirements Workflow: TQM/UP 13

4.1 Introduction of TQM Tools 13

4.1.1 Affinity diagram 13

4.1.2 Tree diagram 13

4.1.3 Brainstorming 13

4.1.4 Pareto analysis 14

4.1.5 Process Decision Program Chart (PDPC) 14

4.2 TQM/UP 14

4.2.1 How to Analyze the Problem? 14

4.2.2 How to Understand Stakeholder Needs? 17

4.2.3 How to Define the System? 18

4.2.4 How to Manage the Scope of the System? 19

4.2.5 How to Refine the System Definition? 20

5 A real world case: Interlancer, Limited 21

5.1 A brief introduction of Interlancer 21

5.2 TQM/UP in Interlancer 22

5.2.1 Analyze the Problem 22

5.2.2 Understand Stakeholder Needs 24

5.2.3 Define the System 27

5.2.4 Manage the Scope of the System 27

5.2.5 Refine the System Definition 28

6 Conclusion 30

Appendix: Glossary of Terms 31

List of illustrations 32

List of tables 32

References 33

1 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:

* The resulting software may not satisfy users' real needs.

* Multiple interpretations of requirements may cause disagreements between customers and developers, wasting time and dollars and perhaps resulting in lawsuits.

* It may be impossible to thoroughly test that the software meets its intended requirements.

* 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 IEEE 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