____________________________Articles|
____________________________Articles |
 |
Requirements Driven Project PlanningSuzanne Robertson
Suppose you invite some friends to come to dinner next Saturday. You decide to serve a Thai green chicken curry, some coconut rice, a mango salad, a lemon mousse and a selection of cheeses. That, along with some well-chosen wines should make your friends happy. Now you need to plan all the things that you have to do in order to make the dinner a reality. You make a list of all the ingredients and where you will buy them and you identify everything that you need to do in order to prepare the dishes on your menu. The tasks in your plan are based on the details of the dishes that you intend to prepare. In other words you have identified the requirements (in this case the meal you will prepare) and then designed tasks that will help you to meet them. When you base a project plan on the requirements you gain many advantages. You put yourself in a powerful position because the map (the plan) matches the terrain (the real requirements). The tasks that you design are relevant to the real problem that you are trying to solve; you do not have any tasks that are there just because "we always do this on all our projects". If you can map the requirements to the tasks, you are in a better position to respond to changes. You have a basis for making realistic estimates and you can monitor the progress of the project by monitoring the status of the requirements. So What is a Requirement? A requirement is some capability that somebody needs or wants. This is rather a "catch all" definition because there are lots of different types of requirements and there are also goals and constraints which, in some cases, are referred to as requirements. Instead of arguing whether a constraint is or is not a requirement it is more useful to consider which requirements-related components are useful and indeed necessary input to a project plan. Functional requirements are things that a system has to do, like record a fact, do a calculation or make a decision. Functional requirements exist because of the subject matter within the context of the particular system. An airport system would have a functional requirement to record the landing time of a flight, a gardening system would have a functional requirement to fertilise the plants, a bottling system would have a functional requirement to fill the bottles. Non-Functional requirements (sometimes called qualities or attributes) are the qualities that a system has to have. Things like performance, security, usability, maintainability are all non-functional requirements. How fast does the bottling system have to fill a bottle, how convenient must it be for the gardener to fertilise the plants, who is permitted to look at the information about flightsthese are all non-functional requirements. Project Goals are the reasons for doing a project. You can think of these as a type of high level requirement all the other requirements contribute to meeting the project goals. The gardening system might have a goal of increasing the annual harvest of vegetables by 50%, maybe the air port wants to be able to accommodate 20% more passengers and the bottling system wants to reduce the number of defective products by an agreed amount. Constraints are specified influences that affect the way that we meet the requirements. Perhaps the new airport system has to be operational within 1 year, the gardening system must only use organic products and the bottling system has a budget of 1 million Euros. The most common constraints are time, money and specified technology. I agree that constraints are not requirements, however in order to keep a project relevant and on track it is necessary to quantify them and correlate them to the requirements. To make sure that a stated constraint really is a constraint we need to ask the question "why is it a constraint". Why must the gardening system only use organic products? If the answer is because we thought it would be a good idea then it sounds more like a solution than a real constraint. However if the answer is that our environmental policy is to only use organic products then it sounds like a real constraint. A Template for Guidance You can base your project planning and monitoring decisions on your knowledge of the requirements. A requirements specification template is a useful guide for helping your project to look for and organise the requirements. The following is the table of contents of the Volere requirements template. The template is a guide based on our experience with requirements specifications on many different types of project in a wide variety of industries. You can download the template from our web page http://www.systemsguild.com
Volere Requirements Specification Template
Items 1 17 contain different types of requirements-related knowledge. Items 18 to 27 contain project-related knowledge that is derived from an understanding of the requirements. Organising the Requirements The template helps you to discover the requirements but you also need to keep track of how the requirements relate to each other. To use the requirements as a project planning and monitoring tool, the project manager needs to be able to measure how many of each type of requirement we already have and how many more are we expecting to find. These sorts of measures are best done using some kind of automation - there are many different tools on the market. But before you rush out and buy a tool it is best to have a clear idea of what you are trying to measure and why. Figure 1 is a model of the types of requirements knowledge together with the connections between them. Each box represents a class of knowledge about requirements; the numbers refer to the section numbers on the requirements template; the lines between the boxes indicate a relationship between the types of knowledge; the annotations indicate why the relationship is useful. For example there is an Implementing relationship between Business Event and Product Use Case so that we can see which parts of the product implement requirements for which parts of the business. Similarly there is a Detailed Product Tracing relationship between a Product Use Case and potentially many Requirements (and vice versa) so that we can assess how a change to any one of the requirements will affect the product.
Figure 1: A model of the classes of requirements knowledge that a project manager can use to plan and monitor the project.
What's in it for Me? If you gather and organise your requirements so that you can precisely identify the types of knowledge and the relationships between them then you can monitor the completeness and consistency of the requirements and use that knowledge to make and tune your project plan. You can assess how much you already know about the requirements and where the most difficult problems might be lurking, if you start the project by attempting (along with the guidance in the template) to specify items 1 to 8 on the template:
This provides you with a first cut assessment of how much you know about the requirements and identifies the gaps in your knowledge and where you need to go the learn more. You can use this knowledge to design tasks for your project team Jane will investigate business events 1 to 10 and Bill will look after 11 20, meanwhile Cassandra will talk to the stakeholders from the marketing department to gather their aims and ideas for the scope of the product. Figure 2 shows the components of an individual functional or non-functional
requirement. As your project progresses and you gather the detailed requirements
then you can assess the quality of individual requirements and test them
for accuracy, completeness and understandability. Figure 2: You can test individual requirements to ensure that you have all of the necessary components
Each product use case is a cluster of requirements. Providing you keep track of the relationships we have discussed, you can use these clusters of requirements as mechanisms for planning releases of your product. The first version will implement one identified set of product use cases; the next version will add the next ones on the list and so on. Another advantage of this approach is that you can involve testers earlier in the project. Because you have an objective specification of exactly what you mean by a requirement it means that testers can test requirements to ensure that they really are requirements. They can also assess clusters of requirements to determine whether it is possible to build a cost-effective test to test the eventual solution to the requirements. To summarise, I think that the main advantage of requirements driven project planning is that the project manager can use the actual subject matter of the project to make a plan and to react to changes. You can use the requirements to estimate work, design tasks and monitor progress. A defined requirements structure gives you the formality necessary to measure the current state of the requirements. However the formal structure does not force you to work in a procedural manner, it merely provides pigeonholes so that you know where to put particular knowledge when you discover it. So you can always identify gaps and changes in the requirements specification and adjust your plan accordingly. And lastly, because you are writing the requirements in non-technical, albeit precise, language, it means that you can involve the appropriate stakeholders in the parts of the specification that are relevant to them. Your project team can get more accurate answers because the stakeholders understand the requirements rather than having to wait until the product is built and then saying what they really mean.
References: Gause, Donald and Gerald Weinberg. Exploring Requirements: Quality Before Design. Dorset House, New York, 1989. Jackson, Michael. Software Requirements & Specifications: a Lexicon of Practice, Principles and Prejudices. Addison-Wesley Longman, Wokingham, England, 1996. Kovitz, Benjamin. Practical Software Requirements a Manual of Content & Style. Manning, Greenwich CT, 1999. Leffingwell, Dean and Don Widrig. Managing Software Requirements - a Unified Approach. Object Technology Series (Series editors Booch Jacobson Rumbaugh), Addison-Wesley, 2000 Robertson, James & Suzanne. Complete Systems Analysis - the Workbook, the Textbook, the Answers. Dorset House, New York, 1994. Robertson, James & Suzanne. Mastering the Requirements Process. Addison-Wesley, 1999. Weigers, Karl. Software Requirements. Microsoft Press, 1999.
|
