Business rules, Process rules, Process, Data, different viewpoints on requirements.

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-whwat should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

Requirements look harmless enough once they have been defined and it can be difficult to imagine the amount of work that may have gone into defining them. Sometimes the issues are simple and requirements are easy to define. More often the business can be very complex and the requirements can be very tricky to define. Often the consequences of getting it wrong are very serious and other times they are easily surmountable. On average more than 60% of all software defects are created in the requirements specification.

To fully understand requirements it is necessary to break them down and consider each on it’s own merit. First of all requirements come from different viewpoints and these angles must be fully considered.
The key viewpoints to consider are: Business rules, Processes, Process rules, Data rules and models, Operating environment internal and external, Culture, Skills, Adaptability.

Business rules

The key to understanding the nature of Business rules is to understand that whatever the business, there are certain rules the business must follow in order to win business, meet legislation, deliver value , get paid and make a profit. These are generally described as Business rules and sometimes they are thought of as business strategy and TOGAF often refers to them as principals..

The importance of business rules can not be overstated, because they provide the flexibility for process to adapt and alter within safe boundaries. A great example of strategy and rules being used in place of process is a football game.  Apart form a few set pieces that can be rehearsed, the bulk of any game is far too fluid to be governed by a process, instead a team of highly motivated people with deep understanding of the strategy and rules adapt and evolve their performance continuously to maximise results.

When we begin a process improvement project, we are doing exactly what that footballer does in every game, we are adapting behaviour to the circumstances while remaining within the stated rules and strategy.

A word of caution about strategy and business rules.
Most organisations fail to upgrade strategy and business rules, but allow senior people to evolve it, often in a very informal way and therefore it is necessary to valiate the current best practice against these rules and update them when necessary via consultation

Often these business rules will be referred to at a high level as the business model, though business rules for our purposes will generally exist at a level one step deeper into the detail and be much broader than  just a business model.
A business rule in a broker model might be that the business only submits to a client, candidate products that match the client’s stated requirements 100%. This might then lead to many more rules that help to better define the high level rule. These rules will most likely be implicit in documents and procedures as opposed to carefully recorded under the heading business rules.

A simple business rule might be that the business charges vat at 17.5% on all sales. Another example might be that the business never offers credit to first time customers, or that it must inspect all of it’s properties at least once a year and provide safety certificates.
A more complex rule might be that all it’s businesses must be visited by a mystery shopper on a Saturday between 12 and 3.pm at least three times a year but no closer than two months apart.

These business rules are not always cast in stone, but they tend to form part of the culture in the business and they often contribute to understanding the capabilities or lack thereof in the organisation. They also reflect the strategies and direction set by the business. Some would say that these business rules are fundamental to what differentiates and defines the business. One way or another they are critical to requirements engineering.

It is also very important to the analyst hoping to deliver well received improvements in how the business runs to understand the consequences of attempting to make changes to these rules. Challenging and changing these rules requires high level sponsorship, deep understanding, tact and respect for the organisation, its people and its essence. It should never be avoided though, when there is a clear opportunity in sight.

Process rules

Process rules are a different entity altogether, but play an equally important role in how a business gets from point A to point B. Process rules are more flexible , less strategic and more tuned into the abilities and preferences of individuals within the organisations. Process rules say as much, or even more about the past where they were born as they do about the future they are intended to support.

A process rule might say that an individual product has to be signed off by the Quality manager before leaving the premises, or that a specific type of purchase is checked individually before being added to inventory.

Complex process rules might suggest that a detailed survey must be produced before a plan of action is presented and only after sign – off by three senior managers can a project begin.

The difference between Business rules and process rules is that Business rules set a strategy for the business, while process rules are one way of delivering on that strategy, but not necessarily the only or the best way.
The power of good process is that while people quickly forget why they do it, they do it without thinking and the process hopefully results in good consistent performance. The downside is that for the same reasons stated above, people continue to follow process blindly long after it has ceased to offer value. This is especially true when that process is enshrined in a system that is inflexible. This fact also makes a very strong case for taking extra care with the design and validation of process, not just in terms of performing well right now, but providing both resilience and adaptability.
The way in which any idea including a process is made reusable is through abstraction and this is a key element in the process modelling element of requirement engineering.
Use cases are the commonest way of abstracting requirements because they are reusable descriptions of things that must be done in a way that is technology and even functionality agnostic.

Requirements

As described in detail in When is a business case not a business case, the Business requirements are the starting point for a project and provide the motivation for proceeding to the next step. They describe clearly what the business objectives are and they make a first attempt at defining the KPIs that will indicate success. They also describe other constraints such as time to market, ROI, etc that may be very important to the project.

User requirements /Use cases

Business requirements are all well and good, but the next level of understanding involves describing in detail the cases in which people will use a product or system, the goals they will be seeking to fulfil and the constraints on each of these user requirements or use cases. Typically a constraint might involve the time it takes to achieve something, or the level of accuracy.

E.G. A business requirement may be that all paper work is eliminated in the “enquiry to payment“ workflow.

This requirement can easily be measured via a number of valuable KPIs and now a whole list of use cases will emerge such as:

  1. A user must be able to record the details of a new order.

a. A user must be able to check that the stock exists

i. If it is not in stock, user must be able to order it

  1. A user must be able to get an ETA on delivery.

  2. A user must be able to retrieve an instant progress report.

  3. Etc.

You will notice that there is no attempt to describe functionality, just to describe the activities users need to carry out and the goals they need to reach.
The second thing worth noting is that we are not burning daylight hours worrying about the order in which these things happen or who does them and all the other aspects that would complicate a traditional process map.
The difference between use cases and process maps is that use cases are written as building blocks that can be used in any order to build a new efficient process as opposed to an existing process that has to be wrenched from it’s owners and painfully changed amidst powerful opposition. The answer you receive in any area of life will depend heavily on the way he way the question is asked and the context in which it is asked. This is key to the success of the business process designer and the and the use case approach lends itself to more objective questions and more accurate answers.

In addition to this, it is often folly to assume that everything is a process. In reality there is not necessarily any time or order dimension in the way many of these events occur and it is more valuable to look upon the business as a series of events to which users must react with use cases.

In my view a process describes a situation where each activity causes the next decision or step to happen immediately. Process is required to understand the functions that will support many of these use cases, but necessarily to join together, or to explain them.

As-is/To-be

An old and respected technique for achieving this understanding of process is to model the “as-is” processes and then to design improvements based on any combination of the capabilities of the new technologies and changes to the business as a whole.

As previously discussed, Use cases pay no attention to the order in which things happen or the decisions about what comes next. This is the main attraction of use cases as a clean sheet on which to design better processes as opposed to mapping “as-is”, (about to be dumped) processes in great detail before then re-designing them in the face of resistance and contention.

The problem is that an analyst must start somewhere and the approach needs to bring along business stakeholders who may have their own ideas and preconceptions.

Our preference is to define this requirements engineering approach in advance bearing in mind whether the task is closest to a new blue sky system, some process improvements, or solving a business problem.
In the latter case, the AS-is and To-Be approach is likely to be most acceptable while a blue sky project will be more successful starting from use cases and using them to design new processes.

The key ingredient in designing or even just recording process is the complete co-operation and enthusiasm of the stakeholders involved, therefore intelligent and tactful consulting combined with open and understandable methodology that stakeholders can feel part of and buy into is an absolute prerequisite.

There no right and wrong processes, there are processes that are used well and those that are rejected

Consultants dilemna

Consulting is not a job for egotists or perfectionist. Every analyst will have seen the same problem tackled in extremely different ways at different organisations and been dismayed at having to ignore hard won experience in favour of what the current client feels comfortable with. This is a fact of life and one of the biggest stumbling blocks for consultants in every walk of life.
In most cases, as-is modelling will be seen fairly quickly to contribute mainly to actually understanding and recording use cases and the time element will be seen as less important. The critical thing is to find a way of recording this information in a format that promotes discussions and input from stakeholders.

This brings us to the last aspect of user requirements. Acceptance criteria.

Acceptance criteria.

As in all things, you need to start out by defining some sort of success criteria.

No goal posts, no goals.

It’s not rocket science, but success criteria is far too often neglected.

Process that has not been verified is a dangerous base on which to design a solution and likewise the suitability of the process to the people who will need to execute it will need a level of verification.

The only way to achieve this is to agree in advance how this verification will be carried out and how the decision will be made.

Functional requirements

Functional requirements are the next level of abstraction, not the solution. Many people are under the illusion that this is a software specification, but nothing could be less accurate. The Functional specification is a bridge between the totally abstract user requirements and the very detailed technical specifications..

This is the critical time when the technical experts get involved to explain to you the possibilities you had not considered and show how your requirements can be met using existing infrastructure.

To demonstrate this, let’s return to the example we used in previous articles.

The business wants to win more new customers through leveraging the internet to keep in touch with people who are in the market for their products.

Having resisted the “Ok let’s build a website” response, we define some user requirements.

Customer users need to be able to:

  1. Study the benefits of our product at their leisure without feeling that they will be pestered

  2. Compare our offering to the other major options in the market place

  3. Do a price comparison

  4. Ask questions about the product

Marketing users need to be able to:
5. Make new collateral available to customers within an hour of proof reading it

  1. Know which collateral is most helpful to the customer

  2. Know the customer’s stage in the buying process when she finally say’s hello and reveals herself.

Turning user requirements into functional requirementsRequirement 1 is up for discussion and the options are laid out, we can have PDFs and faxes cued up ready to auto respond to an anonymous request by the customer.
We can build a website with this information.
We can find a way to attract them to a tool they need when making this decision, give it to them free and make sure it keeps our information in front of them.
Etc, Etc

The recommendations will be influenced by the infrastructure already in place and what the stakeholders and the market are most likely to feel comfortable with.

At the end of this exercise we will have a list of functional requirements that sounds like:

  1. The system will provide a way to publish collateral via webpage, MMS, PDF and mail shot in any combination by a creating a single document.
    A good functional requirement will also list the user requirements it meets or contributes to and will include constraints.

What you have hopefully noticed is that this functionality, although crystal clear, makes no mention yet of the actual technology that will be used. That will be left to technical architects.

Data requirementsAnother common aspect of the functional specification is data requirements. These provide yet another abstract view of the business that presents vital detail to the systems architect without placing too many constraints on him/her.

Data requirements will be driven by required outcomes including legislative requirements such as accounting data to KPIs and operational reporting. Data requirements will often reach far beyond the organisation to embrace sharing and integration with partners, supply chains, customers and others as well as obeying conventions and standards that facilitate benchmarking, look-ups and other collaborative uses of data.
Last but by no means least, Data requirements will define the interfaces with existing applications that make the integration work smoothly.
A set of data requirements may include things like:

Data catalogue that gives clear unambiguous naming conventions and rules for how to collect, validate and store data as well as the daa that is required in every process,.
Data Flow Diagram (DFD) that describes how data flows in the system or business.
Entity diagrams that describe the key entities and their relationships.
Yourdon diagrams that show inputs, processes and outputs.Each method has it’s own merits and it’s own uses.
Sophisticated process design methods like six sigma measure the inputs and outputs of small processes to gauge the health of the overall system. Systems integration demands vey detailed and accurate data catalogues in order to get systems working together.

Usability

Only by carrying out usability tests early on can you avoid the expensive mistakes that alienate users and waste lots of time and hence money for the organisation.
My earliest introduction to the potential pilaffs occurred when I rolled out a cutting edge online CRM system that I had designed and built from scratch for a major utility company. It was first and best of breed, we had put a lot of effort into pulling information out of systems of every conceivable type to create a single view and we had done a pretty good job. We had also presented prototypes to the user base, but we had not paid enough attention or asked the right questions.

On roll-out day, none of the risks came to fruition and everything flowed smoothly, but the union representative on the call centre floor called the rollout to a halt pending her problem being resolved.

The problem was this, all users at developed a way of using speed keys to enter data very quickly while handling inbound calls. This meant that they were able to met targets and earn bonuses worth up to 20% extra on their base pay. With the new browser based system, the speed keys were not available and the bonuses were gone. Staff were threatening to leave and a strike was just 24 hours away.

Eventually we negotiated around this, but it took the gloss off an otherwise successful launch and it taught e a lesson that I’m not going to forget in a hurry. You must carry out well orchestrated usability tests on good prototypes in near perfect replications of the end user environment and go the extra yard to find out the problems from the viewpoint of real users.
Once these constraints have been encompassed into requirements and verified in UAT, you will be in a much more solid position to roll out a winning system.

 

Part two Requirements, tests, training, help files

Part three Why no project exists in isolation-what should be done

Part four Business rules, Process rules, Process, Data, different viewpoints

Part five Testing requirements is not optional

Part six Requirements strategy can make or break your project

Requirements look harmless enough once they have been defined and it can be difficult to imagine the amount of work that may have gone into defining them. Sometimes the issues are simple and requirements are easy to define. More often the business can be very complex and the requirements can be very tricky to define. Often the consequences of getting it wrong are very serious and other times they are easily surmountable

To fully understand requirements it is necessary to break them down and consider each on it’s own merit. First of all requirements come from different viewpoints and these angles must be fully considered.
The key viewpoints to consider are: Business rules, Processes, Process rules, Data rules and models, Operating environment internal and external, Culture, Skills, Adaptability.

Business rules

The key to understanding the nature of Business rules is to understand that whatever the business, there are certain rules the business must follow in order to win business, meet legislation, deliver value , get paid and make a profit. These are generally described as Business rules.

Often these business rules will be referred to at a high level as the business model, though business rules for our purposes will generally exist at a level one step deeper into the detail.
A business rule in a broker model might be that the business only submits to a client, candidate products that match the client’s stated requirements 100%. This might then lead to many more rules that help to better define the high level rule. These rules will most likely be implicit in documents and procedures as opposed to carefully recorded under the heading business rules.

A simple business rule might be that the business charges vat at 17.5% on all sales. Another example might be that the business never offers credit to first time customers, or that it must inspect all of it’s properties at least once a year and provide safety certificates.
A more complex rule might be that all it’s businesses must be visited by a mystery shopper on a Saturday between 12 and 3.pm at least three times a year but no closer than two months apart.

These business rules are not always cast in stone, but they tend to form part of the culture in the business and they often contribute to understanding the capabilities or lack thereof in the organisation. They also reflect the strategies and direction set by the business. Some would say that these business rules are fundamental to what differentiates and defines the business. One way or another they are critical to requirements engineering.

It is also very important to the analyst hoping to deliver well received improvements in how the business runs to understand the consequences of attempting to make changes to these rules. Challenging and changing these rules requires high level sponsorship, deep understanding, tact and respect for the organisation, its people and its essence.

Process rules

Process rules are a different entity altogether, but play an equally important role in how a business gets from point A to point B. Process rules are more flexible , less strategic and more tuned into the abilities and preferences of individuals within the organisations. Process rules say as much, or even more about the past where they were born as they do about the future they are intended to support.

A process rule might say that an individual product has to be signed off by the Quality manager before leaving the premises, or that a specific type of purchase is checked individually before being added to inventory.

Complex process rules might suggest that a detailed survey must be produced before a plan of action is presented and only after sign – off by three senior managers can a project begin.

The difference between Business rules and process rules is that Business rules set a strategy for the business, while process rules are one way of delivering on that strategy, but not necessarily the only or the best way.
The power of good process is that while people quickly forget why they do it, they do it without thinking and the process hopefully results in good consistent performance. The downside is that for the same reasons stated above, people continue to follow process blindly long after it has ceased to offer value. This is especially true when that process is enshrined in a system that is inflexible. This fact also makes a very strong case for taking extra care with the design and validation of process, not just in terms of performing well right now, but providing both resilience and adaptability.
The way in which any idea including a process is made reusable is through abstraction and this is a key element in the process modelling element of requirement engineering.
Use cases are the commonest way of abstracting requirements because they are reusable descriptions of things that must be done in a way that is technology and even functionality agnostic.

Requirements

As described in detail in When is a business case not a business case, the Business requirements are the starting point for a project and provide the motivation for proceeding to the next step. They describe clearly what the business objectives are and they make a first attempt at defining the KPIs that will indicate success. They also describe other constraints such as time to market, ROI, etc that may be very important to the project.

User requirements /Use cases

Business requirements are all well and good, but the next level of understanding involves describing in detail the cases in which people will use a product or system, the goals they will be seeking to fulfil and the constraints on each of these user requirements or use cases. Typically a constraint might involve the time it takes to achieve something, or the level of accuracy.

E.G. A business requirement may be that all paper work is eliminated in the “enquiry to payment“ workflow.

This requirement can easily be measured via a number of valuable KPIs and now a whole list of use cases will emerge such as:

  1. A user must be able to record the details of a new order.

a. A user must be able to check that the stock exists

i. If it is not in stock, user must be able to order it

  1. A user must be able to get an ETA on delivery.

  2. A user must be able to retrieve an instant progress report.

  3. Etc.

You will notice that there is no attempt to describe functionality, just to describe the activities users need to carry out and the goals they need to reach.
The second thing worth noting is that we are not burning daylight hours worrying about the order in which these things happen or who does them and all the other aspects that would complicate a traditional process map.
The difference between use cases and process maps is that use cases are written as building blocks that can be used in any order to build a new efficient process as opposed to an existing process that has to be wrenched from it’s owners and painfully changed amidst powerful opposition. The answer you receive in any area of life will depend heavily on the way he way the question is asked and the context in which it is asked. This is key to the success of the business process designer and the and the use case approach lends itself to more objective questions and more accurate answers.

In addition to this, it is often folly to assume that everything is a process. In reality there is not necessarily any time or order dimension in the way many of these events occur and it is more valuable to look upon the business as a series of events to which users must react with use cases.

In my view a process describes a situation where each activity causes the next decision or step to happen immediately. Process is required to understand the functions that will support many of these use cases, but necessarily to join together, or to explain them.

As-is/To-be

An old and respected technique for achieving this understanding of process is to model the “as-is” processes and then to design improvements based on any combination of the capabilities of the new technologies and changes to the business as a whole.

As previously discussed, Use cases pay no attention to the order in which things happen or the decisions about what comes next. This is the main attraction of use cases as a clean sheet on which to design better processes as opposed to mapping “as-is”, (about to be dumped) processes in great detail before then re-designing them in the face of resistance and contention.

The problem is that an analyst must start somewhere and the approach needs to bring along business stakeholders who may have their own ideas and preconceptions.

Our preference is to define this requirements engineering approach in advance bearing in mind whether the task is closest to a new blue sky system, some process improvements, or solving a business problem.
In the latter case, the AS-is and To-Be approach is likely to be most acceptable while a blue sky project will be more successful starting from use cases and using them to design new processes.

The key ingredient in designing or even just recording process is the complete co-operation and enthusiasm of the stakeholders involved, therefore intelligent and tactful consulting combined with open and understandable methodology that stakeholders can feel part of and buy into is an absolute prerequisite.

There no right and wrong processes, there are processes that are used well and those that are rejected

Consultants dilemna

Consulting is not a job for egotists or perfectionist. Every analyst will have seen the same problem tackled in extremely different ways at different organisations and been dismayed at having to ignore hard won experience in favour of what the current client feels comfortable with. This is a fact of life and one of the biggest stumbling blocks for consultants in every walk of life.
In most cases, as-is modelling will be seen fairly quickly to contribute mainly to actually understanding and recording use cases and the time element will be seen as less important. The critical thing is to find a way of recording this information in a format that promotes discussions and input from stakeholders.

This brings us to the last aspect of user requirements. Acceptance criteria.

Acceptance criteria.

As in all things, you need to start out by defining some sort of success criteria.

No goal posts, no goals.

It’s not rocket science, but success criteria is far too often neglected.

Process that has not been verified is a dangerous base on which to design a solution and likewise the suitability of the process to the people who will need to execute it will need a level of verification.

The only way to achieve this is to agree in advance how this verification will be carried out and how the decision will be made.

Functional requirements

Functional requirements are the next level of abstraction, not the solution. Many people are under the illusion that this is a software specification, but nothing could be less accurate. The Functional specification is a bridge between the totally abstract user requirements and the very detailed technical specifications..

This is the critical time when the technical experts get involved to explain to you the possibilities you had not considered and show how your requirements can be met using existing infrastructure.

To demonstrate this, let’s return to the example we used in previous articles.

The business wants to win more new customers through leveraging the internet to keep in touch with people who are in the market for their products.

Having resisted the “Ok let’s build a website” response, we define some user requirements.

Customer users need to be able to:

  1. Study the benefits of our product at their leisure without feeling that they will be pestered

  2. Compare our offering to the other major options in the market place

  3. Do a price comparison

  4. Ask questions about the product

Marketing users need to be able to:
5. Make new collateral available to customers within an hour of proof reading it

  1. Know which collateral is most helpful to the customer

  2. Know the customer’s stage in the buying process when she finally say’s hello and reveals herself.

Turning user requirements into functional requirementsRequirement 1 is up for discussion and the options are laid out, we can have PDFs and faxes cued up ready to auto respond to an anonymous request by the customer.
We can build a website with this information.
We can find a way to attract them to a tool they need when making this decision, give it to them free and make sure it keeps our information in front of them.
Etc, Etc

The recommendations will be influenced by the infrastructure already in place and what the stakeholders and the market are most likely to feel comfortable with.

At the end of this exercise we will have a list of functional requirements that sounds like:

  1. The system will provide a way to publish collateral via webpage, MMS, PDF and mail shot in any combination by a creating a single document.
    A good functional requirement will also list the user requirements it meets or contributes to and will include constraints.

What you have hopefully noticed is that this functionality, although crystal clear, makes no mention yet of the actual technology that will be used. That will be left to technical architects.

Data requirementsAnother common aspect of the functional specification is data requirements. These provide yet another abstract view of the business that presents vital detail to the systems architect without placing too many constraints on him/her.

Data requirements will be driven by required outcomes including legislative requirements such as accounting data to KPIs and operational reporting. Data requirements will often reach far beyond the organisation to embrace sharing and integration with partners, supply chains, customers and others as well as obeying conventions and standards that facilitate benchmarking, look-ups and other collaborative uses of data.
Last but by no means least, Data requirements will define the interfaces with existing applications that make the integration work smoothly.
A set of data requirements may include things like:

Data catalogue that gives clear unambiguous naming conventions and rules for how to collect, validate and store data as well as the daa that is required in every process,.
Data Flow Diagram (DFD) that describes how data flows in the system or business.
Entity diagrams that describe the key entities and their relationships.
Yourdon diagrams that show inputs, processes and outputs.Each method has it’s own merits and it’s own uses.
Sophisticated process design methods like six sigma measure the inputs and outputs of small processes to gauge the health of the overall system. Systems integration demands vey detailed and accurate data catalogues in order to get systems working together.

Usability

Only by carrying out usability tests early on can you avoid the expensive mistakes that alienate users and waste lots of time and hence money for the organisation.
My earliest introduction to the potential pilaffs occurred when I rolled out a cutting edge online CRM system that I had designed and built from scratch for a major utility company. It was first and best of breed, we had put a lot of effort into pulling information out of systems of every conceivable type to create a single view and we had done a pretty good job. We had also presented prototypes to the user base, but we had not paid enough attention or asked the right questions.

On roll-out day, none of the risks came to fruition and everything flowed smoothly, but the union representative on the call centre floor called the rollout to a halt pending her problem being resolved.

The problem was this, all users at developed a way of using speed keys to enter data very quickly while handling inbound calls. This meant that they were able to met targets and earn bonuses worth up to 20% extra on their base pay. With the new browser based system, the speed keys were not available and the bonuses were gone. Staff were threatening to leave and a strike was just 24 hours away.

Eventually we negotiated around this, but it took the gloss off an otherwise successful launch and it taught e a lesson that I’m not going to forget in a hurry. You must carry out well orchestrated usability tests on good prototypes in near perfect replications of the end user environment and go the extra yard to find out the problems from the viewpoint of real users.
Once these constraints have been encompassed into requirements and verified in UAT, you will be in a much more solid position to roll out a winning system.

Ed Taaffe is a Senior Consultant in the areas of Improving business through use of technology and hi-tech Product Management

Reblog this post [with Zemanta]

Managing requirement scope

Sometimes the definition of requirements and management of their delivery is described as Scope management.  Scope management is composed of five distinct phases:

  1. Scope initiation
  2. Scope planning
  3. Scope definition
  4. Scope verification
  5. Scope change control

Scope initiation refers to the justification phase. This is when a Product management team create Market requirements and Product requirements documents or a  corporate change team will create a Project mandate and produce a Feasibility study.  It is high level, but it is critical to establish clearly that there is a need or justification and to understand the early boundaries.

Scope Planning is a lot more than it sounds and the danger in glib descriptions like this one is that they can easily lead to not taking the work seriously enough.  This is the time when the established high level need at strategic level or market level is translated into a clear product definition with features that hopefully trace right back to the benfits put forward in the outline business case.
This phase is where the real requirements engineering happens and where the product  design ideation and design phase product development will happen.

You may well be sitting there saying yes, but I only wrote down requirements for a simple off the shelf system and purchased it. Well if that was the case, going through the motions of making sure you understood the  benefits and that the product would really be able to deliver them will have been quick and easy.
 In my personal experience, the purchase of a cheap printer can be fraught with problems unless you go out with a clear scope in mind.

Scope definition.

This is where you either define work packages for the various teams of developers or suppliers, or you place and manage a procurement contract.  Without a sound plan and careful management, the best possible plans and designs can come apart very quickly at this stage as requirements are misinterpreted, deliverables fail to deliver and tests fail to impress.

Scope verification.

This is best started at the earliest possible time. Ideally it starts as soon as there is a single deliverable that can be tested alone.  This is the process of verifying that the deliverable performs, that it meets performance specifications and finally that the end product is capable of delivering the benefits.

Scope management.

This is another part of the project that can continue right through the process. It is the positive act of keeping  everything form the earliest designs to the final deliverables within the scope that was agreed and signed-off and just occasionally invoking a change request procedure to accommodate a truly great idea or a serious oversight.

These five activities applied judiciously to the definition and delivery of a product of any kind will greatly increase the likelihood of success and reduce the risk of failures.

Ed Taaffe

 

Write software requirements specification

Since the Dotcom boom we have all come to know and love them. Their USP is: “One eyed man in the land of the blind” their value proposition is” I won’t blind you with science because I don’t understand it myself”. Yes they are the product managers of the software world, the IT directors, the Gadget Barons. Luckily for us they know what we want before we do. They will tell you that requirement engineering is for Nimbies and that suggestions from users are too dumb to take seriously. Allowing a mere human to write software requirements specification is not something they would easily consider.

I suspect that GBs also exist in the white goods arena. I have no idea what all the buttons and programs on my microwave or washing machine are for. The GBs also are firmly ensconced in my supermarket, where I pay for two loaves and take one because I can’t eat two and these gurus are convinced that selling me two at a discount will make me happier. Perhaps they are thinking of the sales of exercise bikes after all the overindulgence, or maybe they themselves eat a lot of bread.

We read with horror that 80% of government projects fail, but can you believe that in the hard bitten commercial world almost as many new product launches also fail. If you don’t, then you haven’t been paying attention.
Microsoft claimed recently that the majority of new feature suggestions from users were actually for features that already exist. Surely this tells you something about communication with users. What’s the betting that these features were included in response to user need?
Ok, now we’ve touched on one of the buzzwords and our world will never be the same again. Why should we build products that are user focused? Dumb question I agree, but this message still has not made it’s way through to 80% of the marketing world and possibly 99% of the software world. I believe I know a little about why this problem persists. You see there is a unique relationship between a product, its users and it’s stakeholders. I describe this as the UPS Triangle™. User- Product-Stakeholder.

The ultimate driver here is the stakeholder which is often a board of directors, and shareholders, or in political terms it is senior civil servants, ministers and citizens. Products can’t begin with user demand as the nice diagrams would suggest. Henry Ford never had a deputation of frustrated horse-riders turn up and demand he invent a motor car. This is why the GBs have a real part to play, they are the visionaries willing to spot a potential opportunity and pull together the support and finance to explore it and to make it happen. The people who provide the finance and take the risk are the people who want and deserve the reward and this is what makes them stakeholders.

Here however, lies the twist. To deliver this reward users have to agree that your product gives them value and become customers. That’s why it is a mutually dependent triangle. The confusion domes when the Product manager loses sight of this triangle and agrees to satisfy the stakeholder directly, hence ignoring the user and ultimately failing to deliver a successful product. On the other the side of the equation, if you leave product development to salespeople they will give away everything to the customer forgetting about profit and lifecycle management.

You can’t have much of a conversation with a marketing type without stumbling across the term “perceived value”.(PV) What they are referring to here is the “reason to buy your product”. Just think of it as another currency. The more of this PV you give to your customer the more of their currency they will be happy to give to you. That’s the ten second MBA, all you ever need to know about business. (link to value creation blog)

The profit is in the P. That’s right you see perceived value is in the mind therefore it can be created relatively cheaply and maintained even more cheaply, whereas products have to be manufactured packaged and delivered and depend on supplies of other commodities. E.G. A Ferrari costs much the same to make as a Jaguar, but it sells for immensely more, because it’s PV is such that wealthy men will gladly part with buckets full of wedge just to be seen driving one.

In this case, which is likely to be more important? what users want you to deliver or what stakeholders want you to deliver. Whose perception is likely to drive product sales, the stake-holder’s or the user’s.

So what is the concluson?

The Gadget Barons are annoying but they are also necessary. Users perceptions is where the gold lies. Perceived Value (PV) is where the profit is made. The more PV we can offer in our product the more £ the customer will be willing to pay.

The first rule of product development is to manage the UPS triangle and reward stakeholders by maximising PV to the customer. If you want to write software requirements specification which will lead to winning products then you must forge and maintain the right balance between Stakeholders, users and technologists.

Ed Taaffe