The why of business analysis

What is the role of business analysis? One might say that the goal is to help provide better solutions to meet business problems or capitalize on opportunities. Someone else may say that the goal of business analysis is to allow an organization to improve and develop. I think that the answer is more basic than that. To me, the objective is simply to communicate ideas.


Eureka! The objective is to communicate
This sounds like a very easy thing to do but it really is not. First off, a business analyst must understand what business clients need. Gathering this information can be a very tedious process. Sometimes business clients are merely listing out symptoms of a problem but not the actual root cause. In other cases, clients just do not feel that they need to provide much information, "It's obvious to me, why isn't it obvious to you?"

Business clients speak in their native tongue; full of company jargon, industry jargon and obscure references. Even worse, sometimes a lack of objectivity is apparent and rose-colored glasses are used. However, through diligence and perseverance a body of requirements will take shape.

Now it is time to relay the business clients' needs to the IT groups. These groups have their own subtle nuances. IT groups also make use of their own set of terminology. Sometimes the same terminology and expressions that worked so wonderfully with the business clients leave IT groups completely dumbfounded. Have you ever seen the, "That's got to be the dumbest thing I've ever heard," facial expression? Or perhaps the, "In English please," expression?

Eureka! The job is to translate!
It is almost like a business analyst has to act as a translator; deciphering ancient Greek and translating it into modern English so it can be enjoyed by a specific audience. Perhaps that is the objective of business analysis; to translate (ensure the clear communication of ideas.)

In closing
Have you ever attended a meeting where two people saw the exact same thing, got into a heated argument about who has the correct interpretation, and you sat there stunned because they sounded like they were both arguing for the same thing?

A zebra is a white horse with black stripes. No, a zebra is a black horse with white stripes. At the end of the day, they both represent the same thing.

The two parties simply could not understand each other. They needed someone to bridge the gap. To translate and facilitate the communication of ideas.

They need a business analyst!

The business analyst & the business systems analyst

In the past, I have asserted that when gathering high-level business requirements, one must aspire to be design agnostic. This is because the consequences may be severe if an inappropriate solution influences a requirement set.

Eventually, there will come a time when a solution must be defined. As a project progresses through the design stage of a system development lifecycle, the methodology, tools, 3rd party applications and approach have already been agreed upon. At this time, requirement documentation becomes much more detailed.

The BA vs. the BSA
So what is the difference between a business analyst (BA) and a business systems analyst (BSA) anyway? I've worked at a few different companies and seen the two terms used synonymously. But from company to company, there is a vast disparity in meaning.

For me, the distinction lies with whether the analyst is more closely aligned with the business side of things or with the IT side. Business analysts interact with the business to understand what is needed. The BA then liases with the design team (or through a BSA) to transfer knowledge of the business' objectives and needs.

Contrast this with business systems analysts who create specifications (to fulfill the business requirements) and interact more closely with the development & design staff. A BSA will generally tend to have more technical expertise than a typical BA.

Determine the skill set needed
Because of the varying composition of project teams and skills, individuals in BA or BSA roles may be asked to perform many different types of duties (as well as aspects of a BA and BSA role.) Rather than debate whether someone is a BA or a BSA, focus on how he or she has been involved in past projects.

During the different stages of a system design lifecycle, what was the role that was played?

Does the role require someone to be involved at the inception stage of a project or is the majority of the role to provide IT teams with specifications?

Does the role require a significant amount of client interfacing or does the role require significant technical knowledge?

What gaps in the team is one trying to fill?

Spend time understanding what is needed rather than what to call the role.

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 III - Escapes, Rambling & Mixing

I would like to write a little bit about other requirement pitfalls. By avoiding these bad practices one should be able to keep from making a faux pas.

Avoid escape clauses
When one uses statements that contain words such as: if, when, but, except, unless or although, one is introducing many potentially complex conditions. These conditions allow out clauses that can keep one from meeting the underlying needs. A picture found in an earlier posting really illustrates the massive confusion this causes. Instead of adding clarity to life why do many street signs just add to complexity?

Do not ramble
Employ the KISS (keep-it-simple-stupid) protocol. Avoid using long rambling sentences that utilize arcane language and unreachable references. No good can come of this. Remember the 3 keys to effective business writing. No one ever said that requirements need to be stated as complete sentences!

Do not mix different types of requirements
As a project moves from its early stages and into the development phases, high-level requirement documentation is used to develop more low-level functional specifications and low-level business requirements. Avoid writing documentation where high-level requirements are intermingled with low-level requirements. In other words, do not mix user, system, business & design requirements. This makes things very confusing and difficult to manage.

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.

What are requirements? SDLC?

Functional Requirements

In order to understand what requirements are, it is necessary to know why one needs them. Basically, requirements are statements that indicate what a system needs to do in order to provide a capability (i.e. utility or benefit.) Requirements are generally prepared during the early stages of a project's system development lifecycle (SDLC.)

There are many different SDLC methodologies that are used in practice. They range from heavy-weight ones, such as the Rational Unified Process (RUP), Waterfall and Spiral methodologies to more agile methodologies such as Extreme Programming (XP), SCRUM and Crystal. Regardless of the methodology employed there are generally six basic phases (note the descriptions oversimplify the activities that occur during each phase):

(1) Discovery - "What needs to be build?" Where the bulk of the analysis (requirement gathering) occurs.

(2) Planning - Perform planning to determine the tools, procedures, budget and resourcing needs.

(3) Design - "How are we going to get a solution?"

(4) Build - Develop the solution.

(5) Implement - Deploy the solution into production.

(6) Warrantee - Monitor the solution to ensure that it functions properly, is reliable and predictable.

Requirements describe what users want a system to be able to do. Thus, well defined requirements are critical to the success of a project.

A large majority of all software defects and failures are directly attributed to bad requirements!

In practice, the percentage of errors during a project's SDLC are higher during the analysis phases than the later stages. Furthermore, the cost to fix an error increases the later the error is discovered. Put another way, the cost to fix an error during the implementation stage is several magnitudes larger than the cost to fix the same error during the analysis stage.

I have seen many different names used for requirements documentation including: business requirements, user requirements, functional requirements etc... Individual organizations will use these terms differently. Personally, I view the disctintion between different types of functional requirements to be based on the level of detail provided.

For example, a high-level (business) requirement may be, "The ability to maintain a product catalog." A lower-level requirement (functional specification), would be, "The ability to specify a date range dictating when a product is available." A good practice is to avoid mixing different types of requirements together in the same document.

Non-Functional Requirements

Most of this post deals with functional requirements. There is another type known fittingly as non-functional requirements. Non-functional requirements describe system characteristics such as:

(1) Productivity - How much a system aids users? For example, "We used to be able to handle 10 complaints in an hour and now we can handle 12."

(2) Performance - How fast should the system be?

(3) Capacity - How much traffic must the system be able to handle?

(4) Scalability - How easily can the system be expanded to handle increased throughput?

(5) Availabilty - Does the system need to be 24/7, weekdays only etc...?

(6) Recoverability - How quickly should the system be made operational after an outage?

(7) Integrity - How predictable and reliable should the system be?

(8) Exception handling - How will processing exceptions be handled?

(9) Logging - Do we need to have audit trails of activities?

(10) Security - What are the security characteristics?

(11) Manageability - How easy is it to manage the system?

(12) Useability - What interfacing is required for end-users?

(13) Interoperability - Does the system need to be able to interface with other systems? How?

(14) Extensibility - Can the system be expanded to support new functionality?

(15) Maintainability - How readily can the system be understood? How extensive is the documentation.

(16) Upgradeability - How easy is it to upgrade the system?

(17) Portability - Can the system be moved to other platforms easily?

(18) Deployability - How can the system be deployed? In components or all at once?

(19) Data Currency - How up-to-date should the information be? Real-time?

(20) Data Retention - How long does data need to be kept for?

(21) Internationalization - Does the system need to support multiple time zones, languages and standards?

Summary

• There are functional and non-functional requirements.
• Requirements are important to the success of a project.
• Requirements can be stated at varying levels of detail.

My next few posts will outline suggestions on how to write more effective requirements. Thanks for taking the time to read my blog.

P.S. I would also like to thank the colleague of mine who created the list of non-functional requirements that I have represented in my post!

3 simple rules for business writing

In order to communicate effectively in a business environment, clarity is required. This is one of the most desirable qualities for business writing. Some basic tenets that one should follow are:

(1) Be brief.
(2) Revise.
(3) Rewrite.

I know this seems overly simplistic but remember one's purpose is to communicate a clear, decisive message and not to prove one's eloquence and mastery of language.

Make more effective presentations

I freely admit that I am not an expert at delivering impactful presentations. In fact, I am not very good at all. However, I want to change that. Perhaps I do not know what are the best things to do, but I can recognize what works and what does not work when I see it. I have sat through too many ineffective presentations (re: boring & long.) During many of these times, I have had to work hard to supress my yawns.

As I have no desire to cure insomnia (via bad presentations), I am diligently trying to improve this skill. Two excellent web sites I have come across are Presentation Zen and Beyond Bullets.

I know now that my PowerPoint slides do not represent the totality of my message. PowerPoint is simply a tool. An easy to misuse tool, but a tool nevertheless.

I can honestly say that I see a huge before and after difference in my own productions. My presentations are more clear, simple, eloquent, effective and engaging. Of course, I'll need some audience feedback to confirm this but I know I am on the right track.

Below are two samples from different presentations that I prepared that attempt to convey the same message.

Originally, I packed lots of information onto my foils (or slides). Some of the problems with this foil are: (1) People read it rather than listen to me. (2) There is too much information. (3) There are multiple thoughts. (4) What is it trying to say? (5) When projected, black text on a white background can be difficult to read. If you are sitting 100 feet away could you even read this foil?

Now, I have broken apart the original slide into many distinct ones. Each has its own purpose and only one message. Much more elegant and simple. Also, it is easy to understand the purpose of the slide. Of course, all other pertinent information from the first foil is maintained; I merely stored it in the foil's notes.

This was my first attempt on what I hope will be one of many.