Document Your User Needs |
 |
 |
 |
| Written by Graham Stoney | |
|
One of the most important documents in the Engineering process is the User Needs or User Requirements document, which describes the needs of the user which the system is intended to meet; and perhaps also those that it explicitly is not intended to meet. This document is written from the point of view of the user, in language and terminology that the user understands. It should avoid Engineering-speak, and should also avoid gratuitous design choices which dictate a particular solution. You want to practise Concurrent Engineering, so there's nothing wrong with developing possible system architectures while drafting a User Needs document, but this document isn't the place to put them. The traditional owner of the User Needs document is the Marketing department, but it needs to be drafted with input from the Engineers to ensure the concept is feasible. If there is no Marketing department, or they don't feel that the document is necessary, then it's better for an Engineer to write it than for it to not exist at all. The User Needs document is one of the main design inputs for the System Requirements. Sometimes the two get confused or merged into one, and it's useful to distinguish between them. Helping maintain this distinction is why I prefer the term User Needs to User Requirements, but the terms are interchangeable. System Requirements, on the other hand, are written in Engineer-speak. There is a step of Requirements Analysis performed to transform the User Needs into a set of System Requirements that will address them. Another distinction between the two is that ultimately verification is done against the System Requirements, while validation is done against the User Needs. User requirements can be ranked according to importance, and later on in the project during the design phase it becomes apparent which requirements will be met, and which will need to be re-negotiated due to feasibility, time or technical constraints. A system may not end up meeting all the requirements identified in the User Needs document but still be worth developing and provide value to its users. This document is important not only because it is the vehicle by which your marketing people have their input into the product development process, but also because it is the basis of agreement amongst your team on what the thing you are building is supposed to do. A project team with no User Needs document most probably also lacks agreement on what the exact purpose of the product is, and this is a major reason why projects fail. Such a project is doomed to wander aimlessly until the project fails because the funding runs out, or the great Engineers leave due to lack of a defined direction. Social Bookmark this page:         
|