Introduction

Team-Fly    

 
Requirements Analysis: From Business Views to Architecture
By David C. Hay
Table of Contents
Chapter 2.  Managing Projects

Introduction

The bulk of this book describes approaches to understanding the true nature of an enterprise. The Architecture Framework provides a way to organize the techniques intellectually in terms of the kinds of things being described. Something besides these techniques, however, is needed to carry out a requirements analysis project. We must know what should be done and when. This chapter describes that process. It lays out the kinds of tasks to be performed, including those that must be done and those that may be skipped .

In many ways, the set of steps described in this chapter is the heart of the book. All the techniques, approaches, and perspectives in the world won't help you with requirements analysis unless you organize the effort correctly. Over the years , this has proved to be the single most difficult aspect of carrying out systems projects. There are no technical problems: there are only "people problems".

A successful projectin any area of endeavorhas the following characteristics:

  • It is completed within the allotted time.

  • It is completed within the allotted cost.

  • It is completed at a predefined performance and technological level.

  • It utilizes assigned resources effectively and efficiently .

This requires careful planning. Project planning takes time, so it is often viewed as a significant costand thus as something to be avoided. The cost of avoiding it, however, is invariably far higher than the cost of doing it.

The task of project management is described in Harold Kersner's 2001 book, Project Management: A Systems Approach to Planning, Scheduling, and Controlling . This book describes the topic much more extensively than can be covered in the few pages of this chapter. Here, however, the key elements that are required specifically for a system development project can be described.

As described in the Introduction, effective management of a systems project requires several things:

  • A close relationship with the project's customersideally via a project champion

  • Effective project management

  • A known and understood set of steps, based on the premise that we must first understand the nature of the company before determining what kinds of computer systems might help it

The first requirement is for a special sort of relationship with the development customers that shows skill in knowing how to capture and represent what they have to say.

Karl Wiegers, in his 1996 book, Creating a Software Engineering Culture , advocates identification of a "project champion" for each project.

Project champions serve as the primary interface between the customer community and the software developers. They are the focal point for collecting requirements from the potential users of a new application. We also expect the champions themselves to provide substantial input to the requirements for the proposed system. The champions also help to define the acceptance criteria that will be used to determine when a product is ready for delivery. The requirements analysis portion of development is now a shared responsibility of the software engineers and the project champions [Wiegers, 1996, p. 66].

Indeed, the project champion should be part of the project management teamwhich leads us to the second requirement: effective project management.

Before going any further, it is important to observe that this book is largely concerned with techniques and technologies. The secret of a successful systems project, however, is not the technology or the techniques used but the skill of the people using them. In the area of project management, some people are very good at getting projects completed. Others are less effective.

The managing of projects is best done as a joint effort between people able to manage the technology and people representing a business with a vested interest in the project. Developing a major computer system involves changing the way an enterprise does its business. For such a project to be successful, it must be driven by the business people who will live with itspecifically, among others, the project champion mentioned above.

The third requirement is a clearly defined set of steps for understanding both the nature of the enterprise and what the enterprise requires from new systems. Here is where the contents of this book come into play. This chapter describes the steps required for success, and the remaining chapters describe the nature of the work to be done during those steps.

Defining steps involves the following:

  • Definition of phases and tasks

  • Specification of the deliverables expected from each one

  • Description of the resources to be used

The first two items are very pertinent to the topic of this book and thus are the primary subject of this chapter. The last item is very specific to your particular organization, so, for the most part, it cannot be discussed in detail here.

One comment about allocating resources is in order, however. In establishing the amount of time and resources to apply to a project, it is important to remember the triangle shown in Figure 2.1. In any project, you can maximize at best two out of three. If you want short development time and high quality, it will cost a lot. If you want short development time and low cost, the quality of the resulting product will suffer. If you want low cost and high quality, it may take a long time to achieve it.

Figure 2.1. The Trade-off Triangle.

graphics/02fig01.jpg

If unpleasant surprises are to be avoided, it is important to clarify the project's priorities at the beginning.


Team-Fly    
Top
 


Requirements Analysis. From Business Views to Architecture
Requirements Analysis: From Business Views to Architecture
ISBN: 0132762005
EAN: 2147483647
Year: 2001
Pages: 129
Authors: David C. Hay

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net