Alex continues to blog valuable insights into the art of capturing requirements...
Typically requirements analysis begins with some sort of user requirement document (URD) and often engineers consider this to be the only source of input. In modern development, however, customers are producing fewer requirements but, instead, becoming more capability driven. What this means is that, rather than identify a long list of “The system shall…” statements, customers are identifying gaps within their capabilities and asking industry to propose an appropriate solution. In order to effectively handle this absence of a URD it is vital that engineers take the time to identify and investigate the needs of the system stakeholders.
So what is a stakeholder? As my title suggests, in this context, it is not Buffy the Vampire Slayer; nor is it the waiter at your favourite restaurant. A stakeholder represents anyone who has an interest in the system for some part of its development or operation. The obvious stakeholders are those who are paying for its development and those who need to use the system but is that where it ends? What about internal stakeholders? I know that whenever I develop anything that Derek looms over my shoulder wanting to know if the deadline will be met and whether I’ve blown the budget or not (naturally I never do). As a requirements engineer I have to take into account, not only those whom the final product will be delivered to but also those who will take my work and further the development; designers, implementers, testers – they are also my customers.
Successful development is based on good communication. Regardless of how your system functions, the project has failed if it doesn’t meet the needs of your stakeholders and the only way to guarantee that it will is to involve them in the development process all the way through. Learning how to ask the right questions is as important a development skill as understanding the technology on which the system is going to be based.
No comments :
Post a Comment