Project Management Book

...chapter 2 continued

User Functions Design

A joint team of users and IT having fully defined and documented the requirements, we now move on to the User Functions Design step. The primary output of this step is the User Functions Design (UFD) document which essentially tells the users, the client, exactly what the system will do and how it will look. It is not just pretty pictures of screens and web pages: everything the system will do (edits, calculations, etc) is specified.

Whereas in the requirements document everything was defined strictly in business terms, the UFD describes the IT system (or systems). Every edit, every calculation, every process mentioned in the requirements document is reproduced here in the context of the system design. If the requirements document says a field must be all numeric, that validation check would be described in the UFD as part of the logic behind the screen or web page on which that field is to be entered. Requirements that will be excluded from the design and eventual system must of course be listed with the reasons for their exclusion.

Vitally, all of the requirements that will be satisfied in the delivered system must be incorporated into the User Functions Design (UFD) document.

Much of the evolution of the design should be a collaborative effort between user and IT people. For example, the requirements document would specify the, say, 23 data items that comprise an order. The User Functions Design step will determine whether these are all to be entered on one screen or on several screens, or even on 23 screens. This has to be a conclusion reached both on technical grounds and on usability grounds.

Techniques such as inspection, prototyping and simulation can be adopted to ensure the UFD is complete and correct. We discuss these and other techniques for ensuring the quality of the UFD in the Quality Management chapter.

You might like to ponder this question (which will be answered in the Project Organisation chapter): who should sign off the User Functions Design document and be held accountable for its correctness?

There will be several other outputs from the User Functions Design stage: testing strategy, implementation plan, project plan for the IT Technical Design step, a revised cost benefit case, and you can probably think of many others.

Having finished the UFD document and got it signed off what happens when, later in the project, somebody wants to change a requirement? Which document(s) do you update? You could update both the requirements document and the User Functions Design document. But this clearly has a cost. We would recommend that only the User Functions Design document is updated. In other words, once the User Functions Design document has been completed, the requirements document is archived. Though frankly it doesn't really matter which document or documents you decide to keep updated. What does matter is that you and the team are crystal clear about which document(s) you will keep up to date. This is one of the many decisions you must make at the start of the project, perhaps in that one day meeting in which you hammer out your project's manufacturing process. As with so many things in projects, it doesn't matter how you do it as long as you and the team know which way you're going to do it.

IT Technical Design

The User Functions Design document tells us exactly what the system must do. The IT boffins can now get to work designing the system's internals: objects, databases - the technical mumbo-jumbo. In theory the users have no involvement in this step. In practice the User Functions Design document may not be quite as clear as we would have liked and questions of the users may need to be asked. Further, the techies might come to the conclusion that something specified in the User Functions Design document is just about impossible, or would at least be very expensive to deliver as designed, so they may seek the users' and designers' permission to change it. So the users do need to be on hand during what appears to be a totally technical step.

It's a good idea to have some of the people who will do the IT Technical Design working on the previous step, the User Functions Design: they will spot at that stage things that will be difficult to do technically.

In parallel with this technical design, the users should be engaging in another set of major activities. The users know what system they are going to get and they know when they are going to get it, so they can now begin preparing for user testing, user training, implementation, roll out, etc. These activities should all be an integral part of the project plan.

Build and Test

Churning out code in accordance with the IT Technical Design should be relatively straightforward as long as the requirements and User Functions Design are not being constantly changed and the IT Technical Design was properly done. By contrast, if the requirements and User Functions Design were woolly and/or keep changing, the Build stage can be chaotic.

How much business knowledge do you need to do system testing, assuming there is a high quality and stable User Functions Design document? Not a lot. If we have updated the User Functions Design document as changes came along during the project it provides an unequivocal benchmark against which the system can be tested. More about testing in the Quality Management chapter.

User Acceptance

Note, we do not call this step User Acceptance Testing. In theory no separate user testing should now be needed. We know the system works because System Test proved that it did. In practice it is seldom like that. The users do tons of their own testing and find a mountain of bugs. Is there any other industry in which the customer is prepared to spend a lot of time and money getting the bugs out of a shoddy product delivered to them by a supplier?

And one hopes the days are long gone when User Acceptance Testing is where the users start to redefine their requirements.

The users having accepted the system, we go live, pick up our large bonus for such a successful project and live happily ever after.

It is ever so easy in a software project to claim that the requirements have all been defined when they haven't really and move on having apparently met the milestone. It's equally easy to "finish" the design stage and claim the credit when the design is nothing like complete or correct. Then the proverbial spectacularly hits the fan in the build and test stage and/or when the system goes live. Please don't do it.

Lifecycle

Clearly, we have not sought to describe all 400 or more activities that comprise the software development lifecycle. We have given an overview of the lifecycle and laid stress on the need for user and IT people to work together as a single team, particularly during the Requirements Analysis and the User Functions Design steps. Having the users in isolation write requirements and then give the document to IT who then in isolation write a design document and pass it back to the users for sign off is a recipe for disaster. And getting the users to write the requirements and do the visible parts of the system design (such as screens, web pages and output formats) and pass that document to an IT organisation and say "deliver that" will probably be an even greater disaster.

It is unfortunate that in small, simple software development projects almost any approach will work. The users can define their requirements in isolation and pass them to IT and things will probably work out. The users can even do the design themselves and pass it to IT. Iterative prototyping, DSDM, Extreme Programming - these approaches will all work in certain circumstances - particularly in small, simple, self contained projects with an experienced team. Unfortunate because people's experience that these approaches work means they try them on large, complex projects and find out the hard way that they may not scale up.

Incidentally, techniques such as RAD and DSDM are actually highly structured techniques that work well where applicable. It is when they are misinterpreted as being techniques that require no project definition, no planning, no documentation, no sign offs, etc that they become dangerous.

Whether you call your development process Waterfall, RAD, DSDM, Extreme Programming or whatever really doesn't matter. What matters is that whatever process you're going to use the team understand it.

Whose job is it to ensure that all members of the project team understand the manufacturing process that the project will use? You guessed it, the project manager.


...next

Privacy Policy and Cookies