What does “best practices” in Requirements Management mean?
It is so interesting to me that everyone talks about wanting training in “best practices”. This term is often used to describe the kind of consulting we might provide as well. What does that really mean? I believe all of us have fed into the myth that best practices can be the basis for training individuals. Best practices are not trained, they are experienced.
If we compare the best practice approach to nature, we know that it not only the strongest but the most prolific species that survive. That’s one of the reasons it is so difficult to change processes in an organization. Think about that for a moment. The strongest and most prolific probably describe the majority of individuals you have in just about any group in your organization. I have seen this over and over in the System Engineering field. The strongest and most prolific engineers have often been doing their job for many years and have a specific way they do this job. Asking them to try new techniques and tools is often futile, as they don’t know how this is going to improve the already wonderful job that they are doing. Their practice is going to survive if we continue to shove a best practice approach at them.
So what do we do? Best practices start with our own personal experience. All of the books you pick up and read around best practices are about the author’s personal experience in some area, whether it is use cases, requirements elicitation, system engineering, testing, etc. At some point an organization decides that it needs a consistent process across the organization. There are lots of good reasons for doing this. So a group is formed to come up with a process that reflects these best practices. Since there are many best practices in the group, guess who usually wins?The strongest and most prolific. And the resulting best practice usually results in a compromise between the best practice group and those in the organization who perform this role. Studies indicate it takes about five years to actually role out this process across the organization. Then along comes the consultants who notice these practices. They may see an opportunity for business and so they get behind the practices that will lead to more business for them. They begin to show up in conferences and trade shows touting these practices and writing books. (Think about the Agile approach.) Because they are looking for business they are focused on the practices that will provide the most business for them. We are always in search of best practices so we don’t need to know how often it works, just that it CAN work. And so we continue to push that practice throughout the organization, hoping to realize all of the benefits that have been talked about over the years.
We must remember that best practices are based on hindsight. The best practices for your job are developed as you learned about that job. We can certainly learn from each other. That is not the point of this discussion. The point is that we need to base our best practices primarily on our own practical experience. We must be discerning in how we apply best practices to our jobs and our organizations. Just don’t accept best practices because someone wrote a book about it or spoke about it a conference. Research the practice and determine the environment in which they were fostered. Is this environment comparable to the one you are in today? Often there is little commonality. Choose the tidbits from the best practices that apply to you and your job and will provide real benefit to you. Start with slight changes and build on the practice as it is applied in your organization. Know where it has succeeded and where it has failed and learn from this. Remember that if you have strong and prolific objectors to the practice, you will need someone with a practical understanding of the practice to help the objectors see how this practice can help them. Listen to them and address their concerns. Don’t just ignore them and hope they will go away. They will not.
In other words, just saying the words “best practice” does not mean it will be a best practice for you.
How to improve your Requirements Definition?
Any time a change is made to either a process or the tools that are used to support the process, there is a learning curve that will impact the time required to perform that process. As you begin to think about improving your requirements definition process, keep in mind that there will be effort associated with this change. In most cases there is decrease in productivity as the work begins to progress. This decrease is often called the “J-curve”. As users attempt to change the way they do a particular task, they reach a point where they feel it is just simply too hard to make the change. The temptation here is to revert back to the old way of doing things just to get the task completed. Without a plan for overcoming this hurdle many organizations fail short of their goal to make this change. This challenge is true for both processes and tools.There are two strategies that can accelerate skills or tools adoption.
First, there is the depth approach. In the in-depth approach a core group of people are selected and are trained on the new process or tool and continue to receive mentoring as the cross the chasm from training to work on a real project. Mentors are often outside consultants with an expertise in the specific skills area. It is important to have experts available to help practitioners begin to use their new skills on a live project. This core group is fairly small and the intention is to use them as consultants for new projects who will be using the new skills. They become experts who move from project to project to help those individuals use their new skills.
The breadth approach focuses on a sound foundation of best practice skills that will be refined over time. In this approach mentors are brought in to provide this foundation of best practice skills, often through standard training in the specific skills area. Usually standard processes and templates are defined and documented for use by the various project teams. The initial training is provided to a large group of individuals versus the smaller, focused group mentioned in the depth approach. As projects begin to use the new skills and learn more about how their specific tasks are impacted, these results are fed back into the best practice foundation so it can be refined over time.
Whatever method you choose to manage this effort, it is critical to successfully making the required changes. Without a plan, these changes often fall to the wayside when the crunch of schedule and budget are felt. Making these kinds of changes requires discipline, support, and determination. Each project must be continually assessed to make sure the new skills are being used.
Think about a simple change to your requirements definition process. Who are the experts you can rely on internally? Do you need outside assistance for training and/or mentoring? Where will you go for this training and mentoring? Is your process well documented today or are you starting from ground zero? What is your plan for making sure you are successful (depth, breadth, both)? What is the timeframe for the change?
“Insanity is doing the same thing over and over again and expecting a different result”. (Albert Einstein) If you feel that way, begin making changes that will give you the results you would like.
Tips for better Requirements Gathering
If you are interviewing users and basically say “Trick or Treat – give me some good requirements” guess what you will get? You will get a hodgepodge of things that the users would like to see. Some will be important to you and some will not. You will have to sort through all of those needs and sort them into categories. We usually call those categories features. Some of those features will be pertinent to the project and some will not. So if you are beginning to gather requirements why not be more focused in the questions that you ask? Do some research and look at any information available that is pertinent to the system. Identify end users (you don’t have to trick or treat in the entire subdivision, focus on a couple streets where the really good treats are given) and set up meetings with them.
Identify processes that are affected by the project – which ones are changing, which ones are new, are any no longer needed? Ask the users what processes are working well for them? Work to understand how they are doing their job today.
Second, once you have sorted the requirements into features, you will need to prioritize those features. What are the customer “favorites” for getting done first?Sometimes we fail to really prioritize and end up working on the easy parts of the system first, instead of focusing on parts of the system that are high risk or not well understood.
At the end of the project, revisit what happened. We might ask if we went on the right streets, if we followed the process or deviated for some reason, did we get as much candy as we expected? What worked well? What changes could be made to improve the process? Did we get the expected end results? Were the users satisfied with the product?
3 Tips to train your team on Requirements Management
Asking someone who’s never written or managed requirements to follow a robust and complex requirements process is like asking that five-year-old to play Beethoven’s Moonlight Sonata. And since we often don’t provide any training or mentoring, let’s ask them to learn to play that piece on their own. That’s what we are doing when we throw our analysts into a complex requirements process.
I suggest we consider training our team. Let’s stop thinking we all just “know how to do our job”. It isn’t true. We can learn to play that piece on our own. I would suggest instead of taking five years, it would have taken me ten years on my own. And so it is with our requirements engineers and analysts. We can let them learn on their own. Or we can give them some training, mentoring, and time to practice.
Of course, key to making this work (no pun intended) is having some kind of process defined that we use to train our analysts. I used to hate that “process” word, but it is important. Here are some suggestions for turning your new requirements analysts into expert requirements analysts quickly.
- Provide training for your analysts around your specific process, using your requirements and deliverables, so the training is more real. Generic classes around requirements definition and management are great, but they must be in line with the processes you are following in your organization. If you are working with an outside consultant, expect that there will some effort in customizing the training for you, but it will be worth the investment.
- Assign a mentor to your new analysts. Let someone who has “been there done that” and has the wounds and scars to prove it help the new analyst and show them the ropes. This will help eliminate that “tribal knowledge” thinking. Let them assist in elicitation sessions, review requirements documents with the analyst, and be a resource for them.
- Let the analyst practice. That may not seem too practical, but don’t start a new analyst on a project that is critical to the company or one that has so much history and controversy around it that it will be difficult to move forward. Let them “practice” on a simple and well understood project to get their feet wet.
7 Tips to write Better Requirements
Writing requirements has been a challenge for us for many decades now. Why is it so difficult? Well, one of the reasons is the challenge of the requirements language. We know we need to write requirements in a manner that can be read and understood by the reader. If we are writing user requirements, the reader is a business owner, end-user, or stakeholder and the focus on writing in a “natural” language. The problem with a “natural” language however, is that is very imprecise and likely to be misconstrued or misunderstood. How do we bridge that gap?
I am amazed at the number of analysts I speak with that resist any kind of structure in their requirements writing. They appear to be quite happy with their unstructured approach that usually consists of descriptive paragraphs and sentences that imply many additional requirements. Their readers like this method they argue. The problem is that once these “requirements” are handed over to developers or systems analysts there is usually a lot of discussion back and forth to clarify what these requirements really mean.
I believe there is a compromise to be made here.
Here are some tips to help bridge this gap.
- Write in active voice, making sure one of the actors is the subject of every sentence.
- Make sure every sentence is a complete and grammatically correct sentence with a subject, verb and predicate.
- Clearly specify what information is passed between actors.
- Maintain a consistent level of detail. For example, for user requirements, an end-user should be the subject of every sentence. For system requirements, a system should be the subject of every sentence.
- Every requirement should describe clear success criteria. For example, “The user shall be able to view the Audit Log Report”.
- Every requirement should state a single action and objective. Watch out for excessive use of “and” and “or”. For example, “If the last Friday of the month and the payment is due on the 31st, and if the 31st is the last Friday of the month, then submitting the payment on that day after 6pm eastern time will result in a late payment”. I challenge you to understand that one!
- A requirement should not have an escape clause. For example, “The system shall determine the number of login attempts, except when the user has clearly entered an incorrect username”.
4 Tips to help you manage complex Customer Requirements
How would you handle this scenario? A customer has stated that they want the system to be user friendly. I call this a complex requirement because it is effectively a collection of many unique requirements. Elicited requirements should be at an atomic level. In other words, each requirement should be a unique and complete thought. But what is the best way of getting to this level with the customer? Reality (and experience) tell us that that many requirements are actually much more complex than stated.
Remember that we should not expect the customer to give us any good requirements. They are supposed to provide us the problem they want to be solved. If this is not clear then we need to need to ask them! They are the experts of the problem. If we pursue this statement a bit more we may find that the requirement is that the Customer must train 500 people in three months to use the new system. Of course it must be user friendly. But what the Customer really needs is a way to ensure new users can be trained quickly. That may change the focus of the solution – user manuals, online training, tutorials, etc.
So let’s take that simple request for a user friendly system. Here are some of the problems.
- A Customer doesn’t want a workshop to determine what user friendly means. The Customer wants us to think for them. After all we are their “consultants”.
- The Customer doesn’t know completely what they want. They haven’t thought through exactly what user friendly means to them. They may have added this because it’s a good idea and everyone else is doing it.
- The Customer is too busy to provide quality input to us. Ask them to spend half an hour talking about what user friendly means to them and they may simply decline to spend the time.
- The Customer may not have determined all of users who are looking for a user friendly system. In other words, he may not have identified everyone who might want to determine if the system is user friendly (e.g. corporate customers, non-corporate, experienced users vs. inexperienced users, foreign customers, etc.).
There are some things that can be done to mitigate the risk associated with a requirement of this type.
- Do some prototyping of screens and show them to the user. Ask them specifically if they think these are user friendly. Then capture the aspects of the screens into a set of user interface requirements.
- Create your own definition of user friendly. Define the criteria and use these to define your user acceptance tests. Provide these to the customer to review.
- Keep pursuing your understanding of the problem. Don’t be afraid to keep asking questions and delve into the real reason behind the customer’s requirement.
- Make sure you have clear criteria to measure the requirement. Without it, you will never pass the requirement in the Customer’s eyes. And without it, the requirement is of no use at all.
Uses Cases in Requirement Management
Use cases are an effective tool in documenting how the user does their job. Often called “as is” and “to be”, these narratives help ensure that we understand how the user does their job today (as is) as well as how they may envision doing their job tomorrow (to be). Use cases are becoming more and more popular as analysts continue to struggle with the issues around the relationship of requirements.
However, sometimes use cases are used effectively during requirements elicitation and definition, but get lost when the transition is made to requirements management. If you think about the steps in a use case, each step describes an action by either the user or the system. Depending on the granularity you want in your requirements and traceability, consider making each step in the use case a requirements statement. Take the following simple use case as an example.
The System displays the account information to the Customer.
The Customer reviews the account information.
The Customer selects the Pay Option.
The System displays the payment options to the Customer.
It is pretty clear from this use case that there are two System steps and two Customer (i.e. User) steps. If we extract the two System statements and, if required, add “shall” to them we get the following two system requirements:
The System shall display the account information to the Customer.
The System shall display the payment options to the Customer.
These two requirements begin to form the basis for the system requirements. These system requirements will likely be decomposed into many system requirements, but we can trace them directly back to the system steps in the use case.
Remember that use cases contain very valuable information for systems analysis and development. Use cases are never really finished since they must be continually reviewed throughout development to make sure they accurately reflect how the product behaves when it is delivered. Make sure that use cases are not put on a shelf, but are traced to both tests and system requirements.