Random thoughts on being service-oriented

Currently, I work in a support group in the IT department of my company. Our group assists other IT teams by scheduling, assessing impact and coordinating deployments to our production systems. In essence, these are the services we provide. For the purposes of this posting, this is my frame of reference when I say service-oriented.
Random thoughts on improving your customers' experience:

1. Think about things from the perspective of your customers. Perspective is everything after all.
   
2. Take your own medicine - go through the process yourself. Have you ever come across a user interface where you wondered, "What were they (the developers) thinking?!"
   
3. Don't be a cold heartless bureaucrat. It's important to your customer; make sure they know it's important to you.
   
4. Do things which provide benefit and value, not because you're following a checklist.
   
5. The process you steward can be a part of a much larger one. Never forget it. When someone asks for help but it's in another area, make sure you explain to them how the larger process works and your piece in it.
   
6. When you need to pass a client onto another service team, do it personally if possible. Make sure the transition goes smoothly.
7. Acknowledge the requests you've received and set expectations for completion.
8. Provide updates when you're running late and won't be able to meet the expectation.
9. Follow-up afterwards and ask for feedback.
10. People shouldn't use your services because they have to. Don't tell them that. People should use your services because they want to! Be ready to market the benefits in a tangible way.

How are your business analysts doing?

How do you determine how well your business analysts are performing?

There are a few different aspects that can be used to measure your business analysts. When I say measure I mean from the perspective of areas for improvement and to understand the strengths and weaknesses of individual analysts.

Deliverable quality
I already wrote about how to assess requirement quality. Use requirement clarity, completeness, consistency, testability, traceability, modularity, feasibility, design independence and correctness to assess the quality of the deliverables.
Meeting expectations
As part of any engagement, a business analyst needs to set expectations regarding the deliverables.

• What are the work products to be delivered?
• What tools and applications will be used?
• What is the estimated time required to complete the deliverables?
• Who needs to be included in the process?
  

Basically this amounts to a business analyst following through on what they said. However, some leeway is needed to allow for the use of different approaches when the situation warrants it. Flexibility is important afterall.

Soft skills

• Professionalism and conduct
  
• Development of relationships
• Facilitating understanding across the business and IT teams.

Conclusion
Ultimately, the outcome of a project determines its success. When looking at the business analysts involved you can measure them based on three basic areas:

• Quality: Quality of deliverables
• Time: Meeting of expectations
• Resources: Facilitating understanding, development of relationships and professional conduct.
  

Assessing requirement quality

How do you assess the quality of your requirements? We know that requirements change over time. We know that sometimes we are working on projects in areas where we are not subject matter experts. We know that there can be many unknown unknowns. So how do we know we have a solid set of requirements?

A while ago I posted a series on characteristics of good requirements. These characteristics can be used as measurement criteria for quality.

Items to consider:

Clarity - You should be able to provide your requirements to an uninvolved third party and they should be able to understand what you're trying to say.

• Is there a lot of jargon being used?
• Is the language used simple and concise?
• Can alternative meanings be derived (e.g., ambiguity)?

Completeness - Understanding whether a body of work is complete may be a little tricky. If there are common industry models that relate to your project compare and contrast them with what you have. Gaps may emerge that indicate missing requirements.

• Do the requirements provide a sufficient level of detail and understanding to the business need?
• Do you understand the context and how groups of requirements fit in with the entire body of work?

Consistency - Inconsistent messages are like bad driving directions, you may never get to where you wanted to be.

• Are there contradictions in the requirements?
• Is the terminology used consistent in it's meaning?

Testability - Requirements must be determined to be fulfilled or not.

• Is there a way to test the requirement? Are there proxy tests?
• Are there many requirements joined together (e.g., the word "and" is used often)?

Traceability - You can trace forwards and backwards and prove that your needs are being accounted for.

• Can you determine which high-level requirement a low-level one belongs to?
• Can you determine what are the higher-level requirements that lead to a low-level one?

Modularity - Making changes as simple as possible.

• If you have to make a change, do you only need to make it in one place or must you correct many different places in the document?

Feasibility - Add a touch of realism. If you are a marketing company, it is probably not feasible for your team to design a rocket ship.

• How realistic are the requirements based on your understanding of the client's goals, objectives and capabilities?
• Is it even possible to do what is being asked?

Design Independence - Requirements should be agnostic of technology and speak only of business need.

• Do the requirements answer the "what" questions or the "how" questions?
• Are the requirements trying to fix a problem with an existing system rather than defining a business need?

Correctness - Everything must be in accordance with legislation and client guidelines.

• Is everything legal? What guidelines or legislation must be followed?
• Is everything ethical?

Epilogue

When examining requirements documentation these questions can help you get a grasp on the quality of the requirements. High quality requirements contribute significantly to better products. A previous post, Why you need good requirements, explained the rationale for wanting solid documentation and the potential consequences of poor requirements.

The sweet smell of success

How do you know a project delivered what it was supposed to? How do you measure success?

For a project, you need more than simply stating requirements and then delivering them. You need to be able to show how your deliverable is providing benefit.

• Did your project provide the benefits you expected?
• Are you realizing more benefit than expected?
• Are you not realizing the gains you envisioned?
  

Targets or performance metrics are setup to be used for the purpose of determining the success or failure of a project. Some projects are intended to save money by automating inefficient processes while others are intended to improve productivity. Business processes have key metrics that show their relative health and performance. Depending on the nature of your situation, some sample metrics may include:

• Calls handled per hour
• Transactions per minute
• Average transaction time
• Sales per transaction
• Concurrent users

When establishing measurement criteria there are a few pieces of information that you need to consider:

1. Your company's current performance level. Viewing trends over time is better than a snapshot, however, this assumes that ongoing monitoring has been setup. Trends may indicate improving or declining conditions.
2. Understanding how companies with similar processes perform. This will give you an idea of the norm.
3. How much you believe the initiative can improve your key processes. Make sure that you are realistic with your expectations. If your company severely underperforms the industry average it may not be realistic to expect that you can overperform the industry after an initiative. It will take a lot of time to catch-up and then surpass the industry average.

In a previous post, Defining requirements by priority, I wrote on utilizing expected benefit and natural dependencies between components to determine which requirements you would gather first. In order to calculate the benefits, you would have had to understand how well your company is performing and how much you think you may improve performance (cost or whatever the key measure is.) In essence, your key performance metrics may already be buried within your calculations.

I feel that your key performance indicators should be identified early in the initiative. If you do not know the important drivers, how are you going to improve your business?

The good, the bad & the ugly... And the road ahead

I could not think on a better title than a play on an old Clint Eastwood spaghetti western for this post. So without further ado, let's start!

During the last 6 weeks, I have provided some tips and guidelines on how to prepare (high-level) requirements documentation. I have also talked about some of the common pitfalls to avoid. Regardless of what tools or applications one uses to manage a body of requirements, these guidelines will be relevant. The focus of this post will be to dove-tail all of that material in an eloquent fashion. In essence, this post will summarize and serve as an index of my previous posts.

The Good
The purpose of these habits is to promote understanding on a few different levels:

Each requirement statement is understood by all affected parties. To accomplish this requirements must be clear, feasible, correct & complete.

Each requirement fits in and does not conflict with any other requirement. Consistency within the body of work must be maintained.

Each requirement can be traced backwards and forwards easily. This improves the ease of verifying them as well as encouraging modularity.

High-level (business) requirements answer the question, "What should the system do?" not, "How should the system do it?" In other words, they must be design independent.

The acid test is, "Are my requirements readily understood? Can someone who is not familiar with my project, read my requirements and understand what I am trying to accomplish?"

The Bad
To appreciate each pitfall, it is important to have an understanding of its impact.

Requirements are less clear when:

• They are ambiguous.
• There is excessive rambling.
• They contain vague or speculative references.
• They contain many possibilities.

Requirements are more difficult to test when:

• Multiple requirements are squished into one big one.
• They are ambiguous (surprise, surprise!)

Requirements can lose consistency when:

• They contain escape clauses.
• Different types of requirements are mixed together in one document.

Requirements are unattainable when:

• They are composed of wishful thinking and dreams.

It becomes very clear that these requirement pitfalls contribute to a lack of understanding. Which in turn will be detrimental to success.

The Ugly
Now I want to focus on why requirements are important. Requirements are the foundation for the other phases of a system development lifecycle.

Requirements are also viewed as the primary reason for project failure with estimates ranging from 50% to as high as 70-80%!

Requirement gathering occurs at one of the earliest stages of a project lifecycle but the impacts of problems are felt downstream during the design, build, implement and post-implementation periods. The later a requirement error is discovered, the more costly it is to fix.

This is simply because the later an error is uncovered, the more backtracking will be needed (an obvious need for solid traceability if ever there was one) to correct it. When a requirement is incorrect, the functional specifications will suffer from the same deficiency, likewise the design documentation will perpetuate it once again and finally, even the actual code itself will have the same problem.

If an error is discovered late in the development cycle, the costs may have risen anywhere from 10% to 100% (or worse) to find and fix versus if the error was discovered earlier.

The road ahead
The guidelines I have proposed are just that... guidelines. There is considerable interdependency between them. Each guideline should not be viewed as a singular item, but rather as a factor that will contribute to the success of the requirements gathering and articulation process.

Using all of these tips will, in itself, not guarantee success. Success is never guaranteed. Projects are often subjected to things beyond their control, however, requirement management practices are controllable.

These guidelines will help one bridge communication and understanding gaps. Then, the rest will be left to your wits, skills and resolve as a business analyst. Enjoy the ride!

Bad Practices - Part V - Possibilities & Dreams

Suggestions or possibilities
In my last post, requirements were defined as needs. Note that there is a significant difference between a need and a possibility. One must be wary of the language used to define requirements. Avoid using terminology such as: may, might, should, ought, could, perhaps or probably. Either a client wants something or they do not want it.

In the past, I have seen language used to indicate the importance of a requirement. For example, "must", indicated that without this requirement being fulfilled the project would not deliver maximum benefit while, "could," indicated that this feature would be nice to have but is not necessary. This method works however, I suggest using something like mandatory, need-to-have and nice-to-have to show how important a requirement is to a project.

Avoid wishful thinking
Business users want everything to be perfect. A system will always be available, never fail, never slow down and be future proof. Unfortunately the last time I checked, I did not live in a utopian society. Murphy's law is something one must be vigilant against. What does this have to do with requirements?

The implication is that one must never interpret wishful thinking or impossible terms as requirements. A customer may want 100% reliability, but as a business analyst, one must recognize that this is not achievable.

Bad Practices - Part IV - Speculative & Vague Terms

On speculation
Avoid using generalizations and speculative words such as often, normally and typically. A requirement must not include any speculation at all.

On dictionary.com, a requirement is defined as, "Something that is required; a necessity." On Wikipedia, the definition is, "a singular documented need of what a particular product should be or do." The common theme is that requirements define needs. When defining a solution to a problem, speculation has no place. It is either do or do not, there is no maybe (or try, as Yoda in The Empire Strikes Back would say.)

On being vague
One common mistake that people make when taking down requirements is to use informal and unverifiable terms. What do the terms: user-friendly, flexible, easy-to-use, fast, and intuitive mean to you? Do you think these terms mean the same thing to someone else? Generally, no! So when different people see these types of terms, people will generate their own interpretations on what they mean. The net result is that the requirement is not clearly understood.

Look at the picture below. What do you see? Do you think other people may see something different than you? If two people can see the exact same picture but come up with different interpretations of it, what would make anyone think that people can read the same requirement and (because of subtle vageries) come up with the same understanding?

No jargon please

Another suggestion I have is to avoid using the jargon of the company one is working with. While understanding the jargon and nuances of a specific company shows some level of understanding, one must realize that jargon does not mean anything to people who are not familar with the company. If a company employs a lot of contractors to help with projects, using excessive jargon increases the learning curve.

Bad Practices - Part II - Multiple Requirements

One of the things I have frequently mentioned in my previous posts is that requirements must be stated as simple atomic statements. I have shown how this simple practice enables one to readily verify that requirements have been met. Another positive consequence of atomic requirements is that overall modularity and traceability is enhanced.

Sometimes when trying to state a requirement, one actually states 2 or more within the same sentence. This happens because when people talk and write people tend to use conjunctions such as and, or, with, and also. Conjunctions indicate areas where multiple requirements exist. What one needs to do is ascertain whether eliciting the items separately allows someone to understand better.

For example, one can state the following,

• Articulation 1 - "The screw must be 4.5 centimeters long and must be able to withstand a temperature of 500 degrees Celsius."

Consider another articulation of the same information,

• Articulation 2a - "The screw must be 4.5 centimeters long."
• Articulation 2b - "The screw must be able to withstand a temperature of 500 degrees Celsius."

Let's look at how the articulation of requirements impacts the ease of verifying, tracing and overall modularity of the body of work. Consider two common situations:

• One aspect is met but the other aspect cannot be met. - The screw is 4.5 centimeters long but cannot withstand 500 degrees Celsius.
• One of the requirements has been changed. - The temperature the screw needs to withstand has been reduced to 400 degrees Celsius but the 4.5 centimeters length is still required.

For articulation 1:

• Part of the requirement is met and part is not. So is it 50% met or does it fail completely? How does one measure this?
• All requirements linked to this one must be examined to ascertain the impact of the change. If there are 5 children requirements, all five must be checked.

For articulation 2:

• The first requirement is met and the second fails.
• Only the requirements that are children of the second one must be examined to determine if changes are needed.

In both cases, articulation 2 yields better results. Now, the problems with having non-atomic requirements are clear.

Bad Practices - Part I - Ambiguity

I have been focusing on good practices to employ when gathering and articulating requirements. For the next series of posts I will be discussing things to avoid. The first bad habit would be to introduce ambiguity to requirements.

Requirements are intended to further understanding. Great care must be undertaken to ensure that their meaning is understood. What happens when they are not clear?

One can say, "To maintain the ecological & environmental balance within the facilities, when using transportation services ensure the facilities remain in a locked-down state.” Alternatively, one can say, “When you enter & exit the building, close the door.” By using excessive language, the underlying meaning can be lost or misinterpreted.

If one has to go over a requirement three, four, five or more times; the requirement is most-likely unclear and ambiguous. Even worse, what if everyone thinks they understand but their interpretations are all different? What is the consequence of this to a project?

My tips for reducing ambiguity are:

1. Be brief. Revise. Rewrite. (Sounds familiar - See my post 3 simple rules for business writing.)
2. Try to view the requirements from the perspective of someone else.
3. Review with different users.

The acid test for understanding - Can someone who has no knowledge of my project understand what is going on by reading my requirements?

Good Requirements - Part VIII - Design Independence

I have seen people call requirements by names such as: business requirements, functional requirements, functional specifications etc... To me a rose is a rose is a rose.

I normally use a very simple document structure to store my requirements. The level of detail increases as one moves from the Business Strategy to the High-Level Business Requirements to the Functional Requirements and finally to the Functional Specifications.
This setup allows for full traceability.

The high-level business requirements and functional requirements should be written to be design independent. This is one of the most important guidelines that should be followed. High-level requirements must answer the what question. If high-level business requirements try to answer the how question, it may bias or jeopardize the solution.

One of the problems with allowing a high-level requirement to be design dependent is that the true requirement may be obfuscated. Consider this, on one requirement gathering session I was told that, "We need the ability to clear the cache (on a server.)" After a lot of investigation, I found out that the actual need was, "the ability to publish content to a web site." If the original articulation of the need was used, the final solution could have been very different and not met the need.

That is the pitfall that one can run into when high-level requirements are not design independent.

Good Requirements - Part VII - Feasibility

To summarize the previous 6 posts:

1. Present requirements as simple, eloquent and atomic statements. By doing this, one increases the clarity and ease of testing them.
2. Define a structure for your requirements. This will allow one to determine the completeness of a body of work as well as make it easier to attain consistency.
3. Another benefit of a defined requirement structure is that it can make one's body of work more traceable. End-to-end traceability increases confidence.

This post will talk about requirement feasibility. For requirements, feasibility means that a requirement can be accomplished within cost and schedule. Personally, I find determining whether a requirement is feasible or not to be a difficult thing.

There are no easy guidelines for determining what is feasible. People, groups and companies have different competencies; thus what is feasible for one group may not be feasible for another group.

During the initial requirements gathering stages, I suggest focusing on making requirements succinct and complete. I feel that the requirement gathering process should answer the question, "What do you need?"

To determine if something is feasible or not, is an attempt to answer, "How do we do it?" By adhering to my previously mentioned guidelines, one will allow solution architects and system designers to understand and attempt to answer this question.

Good Requirements - Part VI - Traceability & Modularity

Have you ever found yourself having to respond to questions like:

• What requirement drove this feature?
• How did we implement this requirement?
• Is this requirement associated with others? Which ones?
• Can you show me how you met my needs?

Answering these questions is much easier when one's requirements are fully traceable. Traceability implies that requirements are uniquely identifiable and can be tracked. Traceability must go backward and forward (i.e., from user tests and design documents back through to high-level requirements and vice versa) for maximum benefit. Being able to show this, reinforces to the business community that their needs are understood and illustrates how they will be met.

The picture above illustrates how high-level requirements have been decomposed into low-level requirements. The screenshot is of Telelogic DOORS. The information in the High-Level Requirements column and the information in the Low-Level Requirements column exist within separate documents. Using this view, one can see whether there are low-level requirements defined for a high-level requirement. This will show one where work still needs to be done. The little arrows indicate that there is a link between a requirement and another one.

Another benefit of requirements management tools is the ability to see what requirements are affected when a requirement is changed. View the picture below and note that if one changed the Color Availability requirement one may possibly have to modify the 3 children of this requirement. Also note that the acceleration, emission standards and security features requirements (and their children) will not need to be modified.

I have found full blown start-to-end traceability to be a nightmarish task within MS Word and MS Excel. I strongly suggest that one makes use of the latest requirements management tools available. See my Good Requirements - Part IV - Be Consistent posting for some commercial products. Requirement management tools allow one to see the relationship between requirements and thereby manage them more effectively.

Good Requirements - Part V - Be Verifiable

At some point in a project the question, "Did we meet the requirement?" will be asked. This seems like a simple yes / no question, but sometimes, there is no eloquent answer. At times, development staff may produce something similar but not as articulated while at other times the articulation of the requirement itself will make it difficult to verify success. In this posting, I will be focusing on how to articulate requirements to enhance the ability to verify that they have been met.

Consider the following two examples:

Example 1 - A traditional "prose-like" articulation of requirements
A sports car that goes from 0-60 mph within 5 seconds, meets local emission standards and has a 6 speed manual transmission system. There will be a 6 disc CD changer and a DVD player available.

Example 2 - An atomic articulation of requirements
Accelerates from 0-60 within 5 seconds.
Meets local emission standards.
Available with a 6-speed manual transmission.
Option for a 6-disc CD changer.
Option for a DVD player.

Now, suppose that the car accelerates from 0-60 in less than 5 seconds, meets emission standards (in the applicable locals), has a 5 speed manual transmission and has a 6 disc CD changer but no DVD player. In example one, is the requirement met or not? Fully? 60%? Yes? No?

In the second example it is very clear that the 1st, 2nd and 4th requirements have been meet while the 3rd and 5th requirements have not been met.

The point I am trying to express is that by stating requirements as simple atomic statements the ability to easily verify them is enhanced significantly. All requirements must be testable. At the end of the day, one must show a solution adheres to its specifications. This is imperative towards building credibility with one's clients.

Good Requirements - Part IV - Be Consistent

If requirements are used to define how a system should function or behave (in the case of non-functional requirements, system characteristics), what does it mean when requirements conflict? Ok, that was a rhetorical question. Stated plainly, the answer is that there will be confusion about what to do.

When one gathers requirements, one will generally talk to a few different people. During the course of this exercise inconsistent requirements may be collected. Unfortunately, most of them are not discovered immediately. By itself, a requirement is neither consistent nor inconsistent. That judgment is determine when requirements are examined against each other.

One way that conflicting requirements can be discovered is by ensuring that requirements are categorized properly and then reviewed category by category. Anyone who as gone through the painful exercise of ensuring consistency throughout a 100+ page MS Word document can understand why categorization and physical grouping is helpful.

I suggest using a requirements management product such as Telelogic DOORS, IBM Rational Requisite Pro or Borland CalibreRM when one is working on projects. All of these products provide good requirements management capabilities such as versioning, status, approvals and linkages (to complementary requirements.)

Good Requirements - Part III - Be Clear

If one is ambiguous and confusing when articulating requirements, there is almost no chance that an optimal solution can be reached. After all, the goal of requirements is to clearly articulate the needs of a system. If one does not have clear requirements, what exactly is being developed?

Being clear may sound easy to do but understand that people may interpret the same thing in different ways. Simple terms such as cold, hot, small, tall, fast and easy-to-use mean different things to different people. 10 degrees Celsius may be cold to one individual yet hot to another.

One may not even realize that a lack of clarity exists because everyone thinks they understand a statement perfectly. So how does one ensure that there are no misunderstandings?

1. Use exact terminology and language. Some examples of clear requirements are, "The screw must be 4.5" long," and, "The screw must be able to withstand 450 degrees Kelvin." Note how much more clear those two statements are than the following one, "The user interface must be user-friendly." What does user-friendly mean exactly?
2. Use short sentences and simple language. Writing requirements is not like writing prose. In fact, requirements do not even have to be complete sentences!
3. Hold informal and formal review sessions with the providers of the requirements and the recipients of the requirements (i.e., business & IT groups.) Go over all of the requirements, including the ones that look blatantly obvious.
4. Be anal! If there is even a remote chance that someone can misunderstand a requirement, they will!
5. Clear up any issues ASAP.

The goal is effective communication. This means no misconceptions, misrepresentations or misunderstandings.

Good Requirements - Part II - Be Complete

Every requirement that is produced should express a whole idea or statement. Not multiple ideas and not parts of one.
Consider the following:

1. The screw must be 4" long, require a Philips screwdriver and be able to withstand 500 degrees Kelvin.
2. The screw is for woodwork.

The first statement has multiple components to it. If one meets 2 of the 3 parts, would one consider the requirement to be met? It is easier to look at the requirements when they are decomposed into separate statements such as, "The screw must be 4" long. The screw will require a Philips screwdriver. The screw will be able to withstand a temperature of 500 degrees Kelvin."

The second statement tells one what the screw will be used for however, it does not provide any additional details. Is the screw for holding together arts and crafts or will the screw be required to support load bearing structures such as shelves and chairs? The requirement does not provide sufficient clarity.

Complete requirements aid understanding which increases the likelihood that a viable solution can be provided.

As an aside note:
One practice that I employ is to create my initial set of requirements at a very high-level. As the requirement gathering process continues I will decompose a high-level requirement into more atomic statements. I find this to be a useful exercise because some of my stakeholders enjoy seeing the big picture while others want to look at the details. This practice allows me to be able to meet both of their needs. There are also traceability gains from doing this, but that will be discussed another time.

Good Requirements - Part I - Be Correct

As I was developing as a business analyst, I encountered guidelines that helped me articulate requirements more effectively. The origin of these guidelines was a small card from a company that became a part of Telelogic AB. I would like to share this knowledge with you.

Be Correct
A requirement must be technically and legally possible. One must not violate any legal parameters placed on the company and system in question. A company's legal counsel and government agencies should provide a good foundation for information about legal considerations. Remember that ethical considerations must also be taken into account.

I have heard people say that given time and resources (i.e., money and people) any problem can be solved. Personally, I do not subscribe to this way of thinking. When I was in university I took a course entitled Intractability & Computability; I did quite poorly, but that is besides the point. The premise of Intractability & Computability was to determine whether mathematical problems could be solved algorithmically. What I soon discovered (other than I had issues spelling the name of the course) was there were problems for which one could not reach the best solution. An optimal solution could be achieved in some cases but not the best solution. An example of this type of problem is what is referred to as the traveling salesperson problem (TSP). The traveling salesperson problem is considered np-hard.

The problem is as follows:

• A salesperson must visit X cities.
• The salesperson must minimize the distance traveled.
• The salesperson must only visit any city once.
• All cities must be visited only once.
• The trip ends when all cities are visited and the salesperson returns to the starting city.

1. Figure 1. Shows the cities and the distances that to be traveled.
2. Figure 2. Shows a path that would be undertaken (assuming A is the start.) The path was chosen by selecting the route to a city that has not been visited and has the shortest distance. Using this methodology, the optimal path is ABCDA, which is 19 units long.
3. Figure 3. Shows another path, ABDCA, which was chosen by me that is only 14 units long. This is a better path than the optimal solution, but the mathematical algorithm was unable to find it.
   

Another good reference for the TSP problem is Mathworld.

While I would not expect to encounter situations where the best solution cannot be discovered in practice, one must be cognizant that such situations can exist. How does this tie back to the be correct guideline? TSP is an example of a problem where it is not technically possible to find the best solution, merely an optimal one. Always remember a requirement must be stated in a manner that allows it to be technically and legally possible.