I’m not a lover of requirements documentation. I’ve discussed this at length before - see Why Do Requirements Change? and The Documentation Myth. However requirements and even requirements documents do have a part to play in the development process. This fact has been brought home to me recently while working with ‘Requirements by Bullet Point’ and ‘Requirements by Project Name.’
These two conditions arise when people try to take short cuts with documentation. In the first case, Requirements by Bullet Point (RBBP), somebody lists ‘the obvious’ requirements, or the ‘things we all know’. In the second, Requirements by Project Name (RBPN), people come to believe the project name conveys all the requirements necessary, unfortunately, the same name tends to mean different things to different people.
What such requirements miss is that the devil is in the detail. Every line of code in a software product contains multiple decisions. A product with 10,000 lines of code contains millions of individual decisions. Some, many, of these decisions relate back to the requirements. When this information is not available the guys writing the code have to guess. When developers have to guess it is the business which suffers.
Agile development lends a whole new twist to the problem because it specifically sets out to deal with changing requirements. But some people believe this means you can start out with no requirements. In traditionally waterfall projects requirements came at the start so projects should not proceed without them. Thats the theory but in practice such projects also fall pray to RBBP or RBPN.
The problem isn’t helped by developers who believe requirements are not necessary, after all, developers know best. Occasionally this is true, normally it occurs with very technical products or where a developer is themselves an expert in the field. The danger is always that developers mistake what they want to do, or what they can do, with what needs doing. What needs doing (the requirements) always needs to be rooted in what the business or market wants and needs.
To make things worse requirements often play multiple roles in a project. Not only are they technical requirements but they are also part of a legal contract and a financial rewards (and penalties) system. When they are called on to fill these multiple roles things just get more complicated.
The problem is that requirements (and I extend this to include specifications here) are just plain difficult for all the reasons I outlined in Why Do Requirements Change? and The Documentation Myth and more.
I think the solution is to recognise that project requirements are an ongoing, evolving, entity. They are not written once and set in stone, they are a continuing process not an event. Or to put it another way, they are a Dialogue not a Document. And to have a dialogue you need multiple people. One of these people needs to be the owner of the requirements, these may be called the Product Manager, the Product Owner, a Manager or a Business Analyst.
The important point is there needs to be someone who is charged with having these dialogues and ensuring a consistent view emerges. Consistent doesn’t mean unchanging but it does mean it remains fairly stable and only changes when new facts or events emerge.
This person needs to be hold an ongoing dialogue with all the stake-holders: the customers, the end-users, the developers, the market, the wider organisation and even the software itself, by looking at it, evaluating it and looking at its competitors. Somebody needs to be charged with knowing what the product needs to be and articulating that view.
Requirements documents have a part to play too. The process of creating the document is an learning exercise for the product owner. In writing the document they are forced to research the subject and pull all their thoughts together in a logical order. For other people the document shows that somebody has done their due diligence and thought about the issues.
Unfortunately too many people in too many companies believe a static document, or RBBP, or RBPN or thought-transference is sufficient to get a software product created. Waterfall had it partly right in this respect, you need requirements to a project, you need to know what you are trying to do, but you need to constantly keep asking and re-asking that question and stating the answer.
These two conditions arise when people try to take short cuts with documentation. In the first case, Requirements by Bullet Point (RBBP), somebody lists ‘the obvious’ requirements, or the ‘things we all know’. In the second, Requirements by Project Name (RBPN), people come to believe the project name conveys all the requirements necessary, unfortunately, the same name tends to mean different things to different people.
What such requirements miss is that the devil is in the detail. Every line of code in a software product contains multiple decisions. A product with 10,000 lines of code contains millions of individual decisions. Some, many, of these decisions relate back to the requirements. When this information is not available the guys writing the code have to guess. When developers have to guess it is the business which suffers.
Agile development lends a whole new twist to the problem because it specifically sets out to deal with changing requirements. But some people believe this means you can start out with no requirements. In traditionally waterfall projects requirements came at the start so projects should not proceed without them. Thats the theory but in practice such projects also fall pray to RBBP or RBPN.
The problem isn’t helped by developers who believe requirements are not necessary, after all, developers know best. Occasionally this is true, normally it occurs with very technical products or where a developer is themselves an expert in the field. The danger is always that developers mistake what they want to do, or what they can do, with what needs doing. What needs doing (the requirements) always needs to be rooted in what the business or market wants and needs.
To make things worse requirements often play multiple roles in a project. Not only are they technical requirements but they are also part of a legal contract and a financial rewards (and penalties) system. When they are called on to fill these multiple roles things just get more complicated.
The problem is that requirements (and I extend this to include specifications here) are just plain difficult for all the reasons I outlined in Why Do Requirements Change? and The Documentation Myth and more.
I think the solution is to recognise that project requirements are an ongoing, evolving, entity. They are not written once and set in stone, they are a continuing process not an event. Or to put it another way, they are a Dialogue not a Document. And to have a dialogue you need multiple people. One of these people needs to be the owner of the requirements, these may be called the Product Manager, the Product Owner, a Manager or a Business Analyst.
The important point is there needs to be someone who is charged with having these dialogues and ensuring a consistent view emerges. Consistent doesn’t mean unchanging but it does mean it remains fairly stable and only changes when new facts or events emerge.
This person needs to be hold an ongoing dialogue with all the stake-holders: the customers, the end-users, the developers, the market, the wider organisation and even the software itself, by looking at it, evaluating it and looking at its competitors. Somebody needs to be charged with knowing what the product needs to be and articulating that view.
Requirements documents have a part to play too. The process of creating the document is an learning exercise for the product owner. In writing the document they are forced to research the subject and pull all their thoughts together in a logical order. For other people the document shows that somebody has done their due diligence and thought about the issues.
Unfortunately too many people in too many companies believe a static document, or RBBP, or RBPN or thought-transference is sufficient to get a software product created. Waterfall had it partly right in this respect, you need requirements to a project, you need to know what you are trying to do, but you need to constantly keep asking and re-asking that question and stating the answer.
Good work, thank you
ReplyDelete