Requirements are done…..And the Oscar goes to?

So the first question would have to be, what does “done” look like? At what part of the requirements process do we go for the all important approval signature and hand over our masterpiece to the development and QA folks? Well don’t get me started on approval signatures, the business community will happily sign a document, as they know full well that if they asked for black and you gave them white, they can always change it later.

As BA’s, we have spent time with our stakeholders  to discover what they would like the application to do.  Pretty high level at first, we use our industry knowledge and analytical skills to document their needs in Business and Functional Requirements that take various forms from the written requirements, business flows to screen mockups and maybe even use cases. Traceability is a must in moderation, relating artifacts as they are decomposed as well as giving us the insight into impact analysis so that as future changes occur we can see what elements upstream and downstream are affected….but is that enough? I would say that it is a good start, but developers are still left with the task of interpreting these traced artifacts and developing code. There is still some room for interpretation and the quality folks need a way of unraveling all of this to  create test cases so they can test not only the “happy path” of our well defined Use Cases but also the many alternate flows.

Simulation or visualization of the requirements can certainly help in overcoming this gap between BA speak and the developer’s interpretation of them.   Showing a stakeholder what happens behind the scenes, even just the use case flows and showing them a simulation of the application before development starts has always been a huge benefit in finding gaps and confirming that you have captured their needs in their entirety. But don’t stop there; take advantage of this same visual media to communicate downstream to your developers and QA team. It is like watching a movie versus reading the book, everyone can interpret a book in many ways. If the author has not been descriptive about a certain aspect of a scene, the reader fills in the blanks and uses whatever colors they want; it is part of the pleasure of reading. However, a movie is different.  A movie has to take into consideration every aspect of the scene, and the screen writer has to transform the author’s book and bring to life the words spoken, the scenery and the costumes. Nothing is really left to the viewer’s imagination.

So as you write those requirements and transform the business needs into fully developed requirements that can be easily taken, coded and tested from….think of great movies you have seen, take the time to set the scene,  build the characters and really bring them to life via simulation.

Agilest…..maybe think about a short film or a series of skits.

The Foundation of Good Requirements: Business Rules and Business Requirements

Business rules and business requirements provide the foundation of a project as we embark upon requirements authoring and validation. A proper understanding of these two areas is essential to any project regardless of what method you use to develop them.

In discussions centered on requirements definition there is often a difference in understanding of terminology. Let’s face it, as requirements authors we have developed a language of our own and many times that becomes confusing to our stakeholders, and even worse, confusing for us.

In a recent discussion with several business analysts the topic of Business Requirements vs. Business Rules was raised and there were differences in opinion of what each of these terms meant and where to draw the line between them.

A quick Internet search provided the following definitions:

Business Requirement: A high level business objective of the organization that builds a product or of a customer who procures it.

Business Rule: A policy, guideline, or regulation that defines or constrains some aspect of the business.

So, Business Requirements are, at their most basic level, the desires of the business or the project sponsor. Someone within the business has an idea for a new product or an improvement to existing one that will make the lives of the users better or may be required to adhere to changing rules and regulations in the industry.

Business Requirements need to be written in clear concise language. They should fully express what is trying to be accomplished. Terms like “World-class Website” or “Killer order entry app” really leave a little too much to the developer’s translation. This may mean that you as the BA may need to do some re-wording from what was originally delivered to you from the business in order to ensure that everyone involved with the project has a clear vision of what is trying to be accomplished.

Some examples of Business Requirements might include:

• Reduce support costs by X% within a certain time-frame
• Reduce average times it takes a customer to book a flight on the website
• Achieve PCI-DSS Compliance for the online booking system
• Reduce turnaround time on support calls by X%

A Business Rule is in many ways a constraint or governance item. We have to work within the boundaries of certain business rules, and they have to be taken into account for every aspect of the project we are looking to tackle. A business compliance rule may state: “Customer’s Social Security numbers may not be transmitted in an unencrypted fashion”. Business Rules often originate from regulatory compliance, such as HIPPA, PCI-DSS, Sarbanes-Oxley, NERC, FERC, or any other number of regulatory compliance statutes. They can also be guidelines for regulating bodies, such as the FDA, or Underwriters Laboratories that are necessary in order to achieve certification or even allow the product to be sold in certain countries. Calculations, such as discounts, taxes, premiums, or shipping costs, or other charges that have been designated by the business can also be considered Business Rules. This may also include guidelines and regulations that have been established internally by legal groups, internal audit teams, finance, security teams or other groups within the organization that are concerned with protecting the business and maintaining effective operations.

Business Rules often need to be taken into consideration across the organization or departmentally. These can often be written once and then re-used across projects, as they will typically need to be taken into account with every new project or proposed change. A good way to distinguish a rule from a software requirement is that a Business Rule would apply even if the process were performed manually.

Some examples of Business Rules are:

• All credit card transactions much be conducted in an encrypted fashion

• Only employees who have been granted permission and have authenticated may access the corporate billing system

• Only members of the IT Security Team may access the Authentication Logs

• All online order processing must support HTTPS

The difference between Business Rules and Business Requirements can be very subtle. Regulatory compliance examples are often business rules, but they may also be the driver for an application modernization project.

Business rules and business requirements will dictate how functional and non-functional requirements are authored. They will also affect the development of use-cases and user stories, and even business process diagrams. Ensure that your business rules are understood by the entire project team, including development staff. Business requirements need to be presented in a way that allows the entire team to understand the final goal and reference back to them often in meetings and discussions in order to ensure that you are staying on target.

When embarking upon a new project, business rules and regulations are often the first sets of requirements authors are dealing with. They determine our next steps and provide an understanding of what it is we are attempting to create, and the constraints we must take into account. They are our foundation for moving forward with our project and define how we will author all of our various types of requirements.

Agile, Use Cases, and You

From a development perspective, I find that use cases provide value because they allow the stakeholders to understand the behavior of the system prior to its being built.  More importantly, use cases list goals that the system will support and thus help determine the scope of the system.  Additionally, use cases account for the things that could go wrong and document how the system should behave with regard to these failures.  Without these alternate flows, error conditions can go undetected until it is time to develop the code and it may end up that the programmer writes in their own logic to account for these failure paths.  Simply put, use cases are an efficient and effective way to communicate the system under definition between the various stakeholders.

So how can you model use cases in an agile environment?  First, focus on keeping it as simple as possible.  A use case is a progression of actions that provide a quantifiable output to an actor.  Another way to look at it is a use case describes ways in which an actor interacts with the system under definition.  You should see a list of actions, which contains the actor trying to do something and receiving one or more responses to that action by the system.  Here is an example of a basic flow of a use case:

1. Customer enters card and PIN
2. System validates card and PIN against the main banking system and displays main screen
3. Customer selects “Withdrawal” and amount
4. System updates the account with the amount and logs the transaction as a “Withdrawal”
5. System delivers card, cash, receipt, and resets.

The goal is to document just enough information about the use case so that the stakeholders understand the behavior of the system.  Also, write the use cases on demand, meaning prioritize (based on goals and scope) and decide which use cases will be addressed in the coming sprints.  You can write use cases as either a business use case or a system use case. I find business use cases are preferred by agile teams.

A business use case is written by business process people to describe the operation of their business. The business use case consists of a generalized, technology-free and implementation-independent description of one task or interaction. A business use case is considered from the point-of-view of actors in relation to a system under definition.  An advantage of business use cases is that they enable you to see the behavior of the system without letting implementation decisions get in the way.  This often leads to a holistic comprehension of the system which allows you to more efficiently reengineer aspects of that system when needed.

A system use case contains high-level implementation decisions.  A system use case can refer to user interface components such as client screens, web pages, or reports.  This is something that isn’t seen in a business use case. Because system use cases refer to user interface components, eventually design issues will come up in your use cases. For example, a design decision is whether your user interface is using browser-based technology or a Windows client.  Because your user interface will work differently depending on the implementation technology, the flow of your system use case will also be influenced.   Honestly, I find system use cases too much for many agile projects.  My advice is to keep your use case modeling as simple as possible and only document system use cases if it adds value to the project.

What is the difference between a use case and a user story?  A user story is a high-level definition that contains enough information for the developers so that they can estimate the level of effort to implement it.  A user story is typically smaller than a use case and may be as short as a single sentence.  There are some thoughts for writing user stories:

• Stakeholders write user stories, not the developers.  This is because user stories need to be simple enough to be understandable, so the subject matter experts should write them.
• Stories can be used to depict a variety of requirements types.  For example, the Customer can withdraw cash from an ATM user story is a usage requirement similar to a use case whereas the Withdrawal history will be available online via a standard browser is closer to a technical requirement.  
• A User story includes an implementation estimate for the effort.
• User stories are prioritized by your stakeholders and you can easily maintain the prioritized list for implementation.

If you have user stories and use cases, there may be a many to many relationship between the two.  A user story can trace to different steps in different use cases, while a use case shows the detail behavior of the system weaving the various user stories together.

It is very easy for use case modeling to become non-agile.  To prevent this from happening, you need to focus on creating use cases that are good enough.  The reason it doesn’t have to be perfect is because in an agile environment you’ll quickly move to writing code based on those use cases.  If you realize that you don’t understand a task or interaction, then you’ll work closely with your stakeholder to get that clarification.  This will allow you to quickly build something that meets the needs of the stakeholders.   Remember, in an agile world, it’s all about software development and not about documentation development.

Tracing Requirements to Source Code

Over the last ten years, I’ve been on the technical end of sales for several requirements definition and management (RDM) vendors.  Some of the products I’ve worked with, as well as several competitive products, promoted traceability from requirements within the solution to the source code residing in a software configuration management solution such as Microsoft’s Visual Source Safe, now Team Foundation Server (TFS) and others.  It got to the point where the market expected this functionality and I started to see it pop up regularly on RFPs and RFIs.  In theory this made sense as end-to-end traceability was and is a widely accepted goal when engineering a RDM process for a development organization.  But in practice, I’ve observed otherwise.

When I consult with customers regarding requirements, the topic of traceability comes up very quickly in the conversation.  After all, traceability is one of the primary drivers behind selecting and implementing a RDM solution as it is extremely difficult, if not impossible to support traceability in a meaningful way with a file based approach (MS Word & Excel, etc.).  However, just because you have the power to trace does not mean you should without rhyme or reason.  There’s an analysis to be performed which should result in a documented traceability strategy for the organization.

I start by asking about the distinct requirement artifacts they use.  As an organization, do you formally distinguish between business, user, functional, and technical Requirements, etc?  Do you employ use cases, process or flow Diagrams?  Do you do screen mockups, etc.?  Once we’ve determined the set of artifacts, the order in which they are typically developed, and who develops them, we can begin to hone in on the trace strategy.  It should also be noted that this may vary by project type within the organization, so we may end up with multiple trace strategies.  However, regardless of project type, with each step/artifact type in the process we are decomposing from a higher level, which has more general information and moving downward to lower level, with more specific detail.  Each artifact type derives the reason for its existence from the one above it.  For example, when detailing a functional requirement it should trace back to one or more business requirements above it (assuming the process goes from BRs to FRs).  If it does not, we naturally have to ask: “Why do we have this functionality?”  The answer should be that our business requirements call for it.  If that’s the case, create the appropriate trace(s).  If it isn’t, then we have an example of “gold plating” or functionality that isn’t needed or called for by the business.

Ultimately, we create and maintain traceability for two distinct reasons: coverage analysis and impact analysis.  When performing a coverage analysis we want to ensure that artifacts at one level are represented or “covered” by artifacts at the level directly below it.  This helps us determine if we’re done with a particular phase in our process.  In the example above, if I have business requirements that don’t trace to functional requirements, then I know those functional requirements either haven’t been created yet. Or if they do exist, we haven’t traced them back to the appropriate business requirements.  Either way, I determine that we’re not done with that phase and there’s more work to be done.

With an impact analysis we want to determine what artifacts will be affected, both upstream and downstream, by a change to a requirement or set of requirements.  Let’s face it, change is inevitable, but it is our ability to manage change effectively and efficiently that will allow us to be successful.  Traceability is the means to this end.  When a change is proposed I follow the trail to see what else may need to change as a result.  The true “cost of change” is the sum of all these things.

So back to the original question at hand, “Where does source code fit into this conversation?”  Everything I’ve discussed to this point resides in the RDM solution while the source code resides in another repository.  Requirement authors write most if not all of their requirements before the source code is created.  Typically, after requirements have been completed and signed off on, the developers are the “consumers” of requirements.  Even if requirement authors had visibility into the SCM system, it is highly doubtful they would have any insight into the relationships between requirements and the source code to create meaningful traces.  Additionally, whereas the requirement artifacts are discreet objects within the RDM repository, an individual source code file can contain thousands of lines of code, representing multiple pieces of functionality.  Think of tracing a business requirement to a functional specification document.  Yes, somewhere in that functional spec is one or more requirements relevant to that single business requirement, but it’s not really a useful trace.

Now, I’m not saying that traceability down to the code files (as well as to the tests) is not valuable.  It is!  I just don’t believe that the requirement authors should try to create these traces in the RDM system.  Ultimately, I believe the requirements should be published into a system like Team Foundation Server and it should be the developers who create the traces to the source code within their environment.  Testers are also “consumers” of the requirements and they will create their test plans as a matter of course.  But it is the testers who should link the requirements to the tests and within their test management system; HP/Mercury’s Quality Center is one example that does exactly that.

Though the request for change can originate anywhere, the actual changes to the requirements themselves should take place in the RDM system and via integrations. These changes should bubble up respectively in the SCM and Test Management systems wherein the practitioners (developers & testers) will be alerted and can take the appropriate action.  Each team has their own working environment relative to the tasks of their role and they shouldn’t have to work in multiple environments.

That is my rather long winded explanation of  why I don’t really see value in having requirement authors create and view traceability to source code (and to do tests) in their RDM solution.  Yes, it is desirable and useful when considering an end-to-end trace strategy, but these traces should reside in the appropriate system, assuming that the organization has in place a SCM system and a test management platform that can accommodate requirement information and trace relationships published to it from the RDM solution.  Having said all this, I don’t consider myself as having the final say on anything and I encourage any and all readers of this post to provide feedback, supportive or otherwise.

 

 

Read any Good Requirements Documents Lately?

Personally, I love reading requirements documents. I put them on my night stand right next to my last car loan contract and all the paperwork from my last home closing. They really do the stuff when it comes to insomnia, sure beats the prescriptions and the wacky side effects. But in all seriousness, let’s think about what these documents are and what they all have in common, (Besides being mind-numbingly boring to read).  All of these documents serve a purpose; the loan documents and title paperwork that we deal with in our personal lives are the standard that we refer to when questions arise. We’ve come to accept these documents and it’s a well known fact that we don’t read them and in many cases we can’t read them, at least not in an intelligible manner without our lawyers present.  Anyway, when was the last time you brought your lawyer to purchase a car? The fact of the matter is, we don’t.  We discuss the terms and assume that the person or organization we are doing business with is trust-worthy and while we might glance through the paperwork, ultimately we trust what was discussed and we sign blindly, and most of the time that works out OK.

So how does that differ from your stakeholders and requirements documents? Well in truth, it really doesn’t. The business (your customers) verbally or written in laymen’s terms explain what they would like: a new website, an update to the customer service app, integration with the new expense system, or any number of other projects. As analysts or project managers we then go off and decide what needs to be done to accomplish this goal; is it feasible (?), does it make sense (?), and if so what are the requirements? We then diligently begin our process of eliciting requirements from the stakeholders, the end users of the product, and any other interested or concerned party. A series of meetings is scheduled to review these during our validation phase and ultimately we create the beloved Requirements Document.  By this point, it truly becomes a document only an analyst or perhaps a lawyer could love. We’ve carefully crafted each line, diagram, and chart to clearly explain and account for each subtle nuance that the project requires, ensuring that we’ve taken the needs of the end users, the business and development constraints into account. We secretly admire the bulk of the document as the result of a lot of hard work. Some of us might even print a copy of it and prominently place it on our desks, hoping that our bosses will come by and be impressed by the sheer volume of our latest work. It’s our baby, or our latest masterpiece and we should be proud.

We then present this Requirements Document to our stakeholders who initiated the project and seek their approving signature. We discuss this in a meeting and the document is then presented for signing, but like our car purchasing analogy the document signing has become ceremonial. The stakeholder trusts that you understood the requirements and assumes that the signing is nothing more than a necessary step. But is it? Do they understand the constraints that development has placed on the project? Do they know that the end users requested a very different approach to the way the screens are configured? Just like buying a car or closing on a home, they give it a cursory glance, or perhaps hope that their team has read it in depth and would surely advise them if something was amiss. If this were the case why do the industry analysts consistently throw out numbers ranging from 20%-60% of each project budget is spent on re-work? The culprit is usually identified as poor requirements. Poor requirements? We worked for 8 weeks on that document, it was 160 pages long, we accounted for everything. How could we have ‘poor requirements’?

The answer is not poor requirements, but rather that once all parties were involved in the elicitation process the project began to change. With each new person giving their input to the requirements, it changed the goals and results of what the stakeholder had originally imagined when they first presented it to you. Given that they did not thoroughly read through the initial presented requirements document, they were not aware of what the new version of the project looked like. So development hosts the first review session of the product and the stakeholders are shocked.

“This is not what we contracted!” they say.

“But it’s all right here in the Requirements Document, you signed it.”

“Well it’s not what we wanted, it needs to be re-done.”

Start the re-work counter.

So, what can be done? Well many shops have switched to Agile to try and catch this a little sooner, and it can work well, but you still need defined requirements for the overall project and you need to understand what each sprint will entail (we still want successful sprints). Perhaps the problem is in the requirements process itself. Some have called for the “death of the requirements document”. In the near future, I don’t see the requirements document going away. It serves a purpose, but not to communicate requirements to stakeholders, just like the loan documents we sign don’t communicate the terms, of our loan, interest rates, or payments dates. There still needs to be a record of the work that is being performed, and there needs to be a form of acceptance.

What needs to change is how we present these requirements to our stakeholders; hosting visualization sessions, presenting mock-ups and wireframes with functionality built-in that give our stakeholders a real-world feel of the final requirements and how they may have evolved through the inputs of others. We might want to use process diagrams, use cases, or other tools to tell our story. The fact of the matter is we need to tell a story, not present a contractually binding document and hold our stakeholders feet to the fire when this goes wrong (we’ll save that for car salesman and realtors). Once this is understood through communication and we all agree on what it is we are embarking on. We can then, once and for all use the requirements document for what it is best suited for, a place to sign our name that signifies agreement amongst all parties before we drive off in our shiny new car, or take the keys to our new home, or begin development on that new much needed new application or update.

Don’t fear the Use Case

Working with many organizations, I've discovered that there are always a few people who are afraid of use cases.  This is mostly because they have never had training on how to build one.  Below are some guidelines that I use to coach these folks in writing use cases.

First of all, what is a Use Case?  A use case describes a system's behavior as it responds to a request from a stakeholder under various conditions.  Your stakeholders will provide input, validation, and final approval of the use cases.  Use cases add value because the stakeholders get to see the exact behavior of the system.  More importantly, use cases contain goals that the system will support, hence clarify the scope of the system.  It becomes an efficient way to communicate the system under definition between the various stakeholders.  Another value that use cases add is coming up with of all the things that could go wrong and documenting how the system should behave to the failures.  Without these alternate flows, error conditions go undetected until it is time to program the system.  What usually happens is that the programmer will write whatever they think is logical (with the best of intentions), but will probably result in failure during the use of the system.   As the saying goes, the path to hell is paved with good intentions.

Not all use cases look alike.  Business process people write business use cases to describe the operation of their business, while the design teams write system use cases to break down the requirements to small subsystems.  A business use case is written to show what the processes do to achieve their business goals.  A system use case is written to specify the function or the service that the system provides to a stakeholder. Always remember that system use cases are black-box use cases that do not describe the guts of the system.  This forces you to focus on what the system must do versus how it is to be done.  Leave the "how" to the hardware and software development teams.

Use cases are requirements that describe the behavior of the system, but they do not all constitute of the requirements.  I would say a quarter of your requirements are use cases, and do not represent other requirements such as external interfaces, data, business rules, quality of service, glossary, implementation, technical, integration, performance, etc.  However, use cases should connect many of the other requirements through traceability.  Think of use cases as the framework that links information in different requirements.

If a quarter of my requirements are use cases, then how much time should one spend on them, considering you have other requirements to define.  I always follow the simple "accuracy to precision" model.  What do I mean by that?  Here is an example that I learned from one of my software engineering professors that shows how accuracy and precision are not the same.  If I tell you that π = 9.141593, then my number is precise, but not accurate.  But if I tell you that π is around 3, then I am accurate, but not very precise.  Using the above analogy for each of my use cases, I begin with 3 and then I delve into the .141xxx as time and project permits.  I start by stating the primary actor and then list all the secondary actors, and each of their goals the system will support.  I also write a short description of the use case describing the interaction with the primary actor.  Validate this with your stakeholders for accuracy and completeness.  It is surprising how many use cases are already wrong because they weren't accurate or how many were missed because not all of the stakeholder's goals were included.  After the initial validation, you can prioritize and assign these use cases to individuals and releases.  For the use cases that are selected to be written, they need to precisely describe the main success scenario/basic flow.  Review and validate these basic flows with your stakeholders to make sure that the system is behaving in the interests of the stakeholders and meeting their goals.  Once you know your basic flows meet your stakeholder's needs, then you can start listing all the failure conditions and alternate flows.  Verify this with your stakeholders to make sure your list is accurate and you haven't missed any important what-if scenarios.  This will also help you prioritize the failure conditions and alternate flows that you want to add detail.  This is very tedious work, but I often find missing requirements or goals that were not initially given to me by the stakeholders.  I know your time is limited, so working in the above flow will help you manage your accuracy and precision level.

There is no standard template for documenting use cases.  I find the below core parts of a use case to be utilized (more or less) by organizations:

Use case name 

Level:  Business or System

Goal:  You MUST have a goal.  The goal should be a description or a list of what the primary actor will achieve within this use case.

Scope:  You can describe the service or the part of the system that will be defined by the use case.

Summary/Overview: A short description of the use case interacting with the primary actor.

Actors:  An actor can be a person/role, organization, computer system, data, etc. - anything acting on the system.

• Stakeholders:  They are 100% interested in the behavior of the use case.  They may or may not interact in the use case, but the outcome of the use case affects them.
• Primary Actor - This is a stakeholder that acts on the system to achieve a goal.
• Secondary Actors - These are stakeholders that are acted upon by the system.  In other words, these actors provide a service to the system so that the primary actor can achieve its goal.

Triggers:  This describe the event(s) that causes the use case to get started

Preconditions: This describes all the conditions that are true before the use case starts.

Postconditions: This describes the change(s) in state of the system after the use case completes, positively and negatively.

Basic flow/ Main Success Scenario: This is the top down description of the typical set of actions in which the goal(s) is delivered.  Any one step can describe an interaction between the primary actor and the system, between system and secondary actors, or a validation step to protect a goal of the actor.  Each step should use simple grammar that clearly shows the Actor - Verb - direct object structure, and it should move the process forward in the use case.  Finally, I find Miller's Law (7 +/- 2) to be a good heuristic to use to determine how many steps should be in a use case.  Use cases with more than 10 steps in the basic flow can get cumbersome for review because some of these steps will have alternative/error flows that have to be validated in context of the basic flow.  I find the most common mistake in use case writing is leaving out the subject of the action step.  Here are a couple of examples of poorly written use cases using one of my favorite examples, the ATM.

Use Case mistake - not showing system action - This use case shows everything the actor does, but does not show the system's reaction.

1. Customer enters card and PIN
2. Customer selects "Withdrawal" and amount
3. Customer takes card, cash, and receipt
4. Customer leaves

The system should always respond to an actor's action. Ever present in a use case is the cause and effect relationship between the actor and system.

Use Case mistake - not showing the actor - This use case is written from the system's perspective and does not show the actor's behavior.

1. Reads ATM and PIN
2. Sets transaction type as "Withdrawal" and amount
3. Delivers card, cash, and receipt
4. Logs the transaction

Use Case fix - This use case names all the actors and their actions.

1. Customer enters card and PIN
2. System validates card and PIN against the main banking system and displays main screen
3. Customer selects "Withdrawal" and amount
4. System updates the account with the amount and logs the transaction as a "Withdrawal"

1. System delivers card, cash, receipt, and resets.

Alternative flows/Extensions/Exceptions/Errors: These are all the other flows.  It starts with a condition/trigger and a goal for the alternative flow.  It contains a sequence of action steps describing what happens for that condition/trigger.  It ends with the success or failure of the extension goal.  An alternate flow can end in several ways: a successful end; a total failure; ending goes back to a previous step in the basic flow (looping); or ending remerges somewhere in the next steps of the basic flow (fan-out/fan-in).

You can apply use cases on almost any project that requires you to define the behavior of a system.  The standard template to write the use case is selected according to each project's needs.  Projects that are short or quick will need less detail versus projects that are detailed, expensive, or distributed.  Finally, a central repository will allow you to define, validate and manage the use cases and all the other linked requirements in context of each other.

 

 

No Parking after 2'' Snowfall

 

Much to the astonishment of my warm-weather relatives in Texas, Alabama, and California, I live in an area of the country that receives about 4 feet of snow each year. As with most snow-blessed (or snow-cursed, depending on your point of view) regions, my municipality takes great pride in its ability to minimize the impact of our inevitable snow events. We scoff when our sunbelt brethren are, quite literally, frozen in their tracks by light, slushy glazes. Famously, a local mayoral election turned on this very issue in the late 1970's.

In the hours before flakes begin to fly, a fleet of snow removal vehicles take to the streets and begin the tedious work required to keep the roads freely flowing. To simplify their work, a complex patchwork of "Snow Routes" have been drawn up, and you know you're on one when you see one of these ubiquitous signs:

It seems like such a simple message, doesn't it? "When it snows 2 inches, don't park here." But in conversations with friends and neighbors, I am surprised to find there is no common consensus about what this actually means. Here are just a few of the interpretations and objections I have heard:

• How are we measuring two inches of snow? What if it snowed only one inch on my street, am I still in violation?
• What if it only snowed an inch, but the wind blew the snow around, does that still count?
• Every street has these signs. Where am I supposed to put my car? Am I supposed to drive around aimlessly until it stops snowing?
• Why 2 inches? Don't they mean two inches or more? Or am I safe once the snow gets to 3 inches and beyond?
• Do they mean 2 inches in an hour? A day? 2 inches since they last cleared the street?
• When can I park again? After they clear the street? Technically, that is still "after 2" snowfall"...

I admit, some of these are silly, and readily answered. But the point here is that, from a single, succinct message, there is so much ambiguity, so much room for interpretation. And the cost of not getting the interpretation correct is a parking ticket, and possibly a towed vehicle; an inconvenience and aggravation for sure, but hardly the end of the world.

Now take this a step further, and suppose that, instead, the sign read something like a typical business requirement. Something like, "The system shall allow the user to browse through a list of available services." The ambiguity, room for interpretation, and lack of clarity is magnified many times over, in comparison with our simple sign. One way to add clarity is to decompose the requirement into finer levels of detail, successively defining each piece of the requirement into atomic levels of text, whose meaning is clearly understood by everyone. Indeed, many companies do just this. They end up with giant spreadsheets of requirements with 10 or more hierarchical layers and thousands of rows. It takes time to thoroughly review these types of documents, and business stakeholders tend to lack the necessary bandwidth to do so. Likewise, downstream consumers like developers, QA personnel, consultants, and technical writers are often awed by such lists, but don't necessarily understand the requirement any better. This requires that they interpret the ambiguous requirement in their own way, which may or may not meet the original business need. If they miss the mark, the resulting rework will cost significantly more than a parking ticket.

Another approach would be to recognize, as our No Parking sign illustrates, that natural language is often an imprecise means for communicating even simple concepts. Most people process and retain greater information detail when it is communicated in multiple forms. Many of the objections I listed above could be assuaged by adding diagrams, and / or public service announcements showing which conditions warrant a parking ban, and what to do about it. Likewise, adding clarity to requirements requires that we not only add detail to the text, but we also provide additional clarity through other communication means. Perhaps a business process is required to add context; or a user interface may be deployed on a use case step to specifically define system behavior as it meets the requirement goal. Communicating multiple aspects of a requirement is not easy, but a lifelike simulation that incorporates all these aspects can ensure all facets of the requirement are understood.

The equivalent, from a snow removal standpoint, would be a perfect understanding of the factors that produce significant snow events, resulting in accurate forecasts months ahead of time. Wouldn't that be something? With a warm, sunny forecast known well in advance, I might even be able to convince my relatives to come visit us some January.

Avoiding Project Rework - Measure twice and cut once

"Measure twice and cut once!" That was my father's mantra on the job site. He was a contractor, building houses, garages, assorted additions, porches, etc. It was his company and he had a small crew. In the summer when school was out, I often got to tag along with him. I'd pound nails, lug wood or roofing shingles, or just go around tidying up the construction site. When I got older I was allowed to operate the table saw, making cuts to the dimensions called down from ladders and scaffolding by my father and others. "Measure twice and cut once" was about making a small investment to avoid waste; the waste of time and material. Take the extra couple of seconds to measure a second time and ensure that the cut you make will produce a board that can be used the first time. A fraction of an inch too long and you have to walk the board back down, mark it up again, and shave off the excess while a person stood idle waiting for you to get it right. Make a cut just a fraction of an inch too short and you have to toss the board aside and cut a new one.

Thirty years later I too am in the construction business...of a sort. Developing software may seem very different and far removed from building a house, but I believe there is more in common than not. Consider requirements for example. If you don't invest the time and effort to capture and communicate a project's requirements effectively, the result will be wasted in the form of very costly rework. The Standish Group's "Chaos Report", an annual analysis of our industry and how we perform, consistently reports rework (on average) in the 40-60% range of total project spend. If my father built a house where 50% of the cost to the owner was in fixing things that he didn't get right the first time, he never would have built a second one, plain and simple. But yet, it appears to be "normal" or at least acceptable for our line of construction.

As a matter of full disclosure, I work for a software company with a requirements definition and management solution. However, this isn't a subtle (or not so subtle) attempt to pitch my product. Rather, it's an attempt to focus on the exact nature of the problem we all have a vested interest in solving. During sales cycles with prospective clients, I am often asked by a decision maker if implementing our solution will save time in the requirements process. My answer is no, implementing our solution is not going to make your existing people and process 10-15% faster or anything along those lines. If anything, it will probably add time to your existing process as there is a learning curve with anything new. However, I also add that this isn't what we as a vendor or they as a customer should be focused on at present. That isn't the problem. In fact, from a development organization's perspective, it should be acceptable, even desirable to DOUBLE the time it takes to execute on requirements, IF they can get them right the first time around.

Consider that on average only 3% of a project's cost is actually spent on the requirements process and that spending more (all things equal) will yeild better results (1). On a project that ultimately costs $1 Million, that figure would be $30k. We also We also know from the Standish Group that on average, $500k of that $1 Million total is wasted in the form of rework. Let's say we double the spend on requirements to $60k with the result that it drives out half of the rework or $250k. That is over a 400% return on investment and I don't know of any business man or woman that would forgo that rate of return.

What constitutes an increase in the requirements spend? It could be as simple as allowing the same people with existing process and tools more time to do their job. You could invest in process improvement initiatives or technology or both. You can train your existing practitioners in the use of new techniques such as use cases, storyboarding, diagramming, visualization, etc. You might consider an approach that breaks out requirements as a discipline into a center of excellence in much the same way that PMOs arose around project execution in years past.

But again, this article isn't so much about the solution as it is about shining the light on the problem. What we want/need to solve is the problem of waste or rework in our projects. Solve the requirements problem (the cause) and you solve the rework problem (the effect). As organizations we should be eager to invest in solutions (people, process & technology) relative to the requirements process. It really is as simple as "measure twice and cut once".

1. Hooks, Ivy F., and Kristin A. Farry. Customer-Centered Products: Creating Successful Products through Smart Requirements Management . New York: The American Management Association, 2001.

How to Be Awesome At Being A BA

 

Chances are, if your career has landed you in the role of a business analyst, it was probably by accident.

Even if it wasn't, I'm willing to make another guess: You've probably never received any sort of formal BA training, and you're wondering if there is even such a thing.

How did I do?

The roles of BAs vary, for the most part, based on the size of the company: Simply put, BAs seem to do more in smaller organizations. But in any sized company, I believe that I have observed some traits that are consistent across the most skillful and, dare I say, awesome BAs that I have had the pleasure of meeting.

So, instead of looking at any methodologies behind business analysis (there's plenty out there already), in this article I intend to examine those characteristics of the awesome business analyst, and point out some specific tools and resources that I guarantee that you can use to make yourself awesome (or awesomer, as the case may be).

In a nutshell, the role of the business analyst is to capture, organize, and communicate large volumes of information.

Let's start with the capturing part.

Capturing

To record information, you use a computer: You know, that thing you sit in front of all day? How good are you at using it, really?

Learn how to type faster.

I know this sounds like a no-brainer, but it astounds me how many people still hunt and peck for letters on a keyboard. At the very least, at this point you should know how to type without looking at the thing. If you're not there yet, take lessons, or just force yourself not to look at your keyboard; that's how I learned (and look how I turned out!).

Use technology to take shortcuts.

...after all, that's what technology is for, isn't it?

Start by spending less time with your mouse. What you don't realize is that you're constantly costing yourself time by using the mouse, especially when you don't have to. Your mouse has two buttons, and your keyboard has, what, a million? Those magical keys can do so much more than simply put letters on the screen!

Windows has a ton of built-in, time-saving keyboard shortcuts that you may already be using, that work in pretty much any application you use. Here are my favorites:

* First, there's the old standbys: Copy (Ctrl+C), Paste (Ctrl+V), and Undo (Ctrl+Z).
* Then there's some for getting around Windows faster: Switch Between Open Programs (Alt+Tab), Show Desktop (Windows+D), Run (Windows+R), Open Explorer (Windows+E).

Want more? Here's a rundown of keyboard shortcuts for Windows.

The tools you're using also have keyboard shortcuts of their own; by all means use them. You can typically find a list of time-saving key combinations in the User Guide.

If you have the ability to, there's also some tools you can install that will speed things along even further:

* Use a text expander. Texter is one such tool. What this little beauty of a utility does is run in the background as you use other applications, and when you type something like "tss" it expands it to "The System shall", or whatever you tell it to. The beauty of it is that it works in any application where you type, be it Word, your email, your web browser... or your favorite requirements workbench.

* Use email templates. Chances are you probably bang out a lot of emails that look similar to one another: "You'll find the answer here...", or "Talk to the following people about these areas...". You can use Texter, or Outlook Templates, or even just keep a text file handy (accessible via a shortcut) with a bunch of common responses, to do this. The trick is to not sound like a robot, so be sure to add at least a bit of personalization and warmth to it.

* Search first. Don't trust whatever filing system you came up with yesterday, as that may no longer apply today. While Outlook's email search capability has improved over the years, it's still not as lightning-fast as Xobni, or Lookout.

In general, what I'm recommending is to look at the repetitive tasks you do every day, and think about ways you may be able to automate them, or at least ways you can get faster at them. (So, basically, do for yourself what you already do for your business!)

Organizing

As you capture all that information, in all of its various forms, you also need to organize it, so you can later communicate it effectively. But, let's take care of something, first:

Organize yourself.

Your job requires you to talk to a lot of people in order to discover your business's needs, and then to communicate them. Unfortunately, this requires time-consuming activities such as those dreaded meetings, and frequent distractions such as constant stream of emails - the combination of which prevents you from actually getting your real job done.

Combat this!

* Manage your time. In particular, guard that time wasted by meetings. Block off your calendar for meetings with yourself. Ask why you end up in the meetings you get invited to. By the same token, don't waste other people's time: Provide an agenda, a clear reason as to why you needed certain people to attend (make it clearly optional for everybody else), and aim to end the meeting as soon as you can while still achieving its goal.

* Reduce distractions. This is probably my biggest pet peeve: It's time to turn off those vibrations, or blasted little pop-ups that let you know you have a new email every five minutes. There's no reason why you need to know about every email when you can't act on the majority of them right away; you've got your job to attend to, remember? Other tricks such as email filters, and BlackBerry Contact Alerts help to weed out the important people from the noise.

* Manage your tasks. Adopt a task management system. Once you learn a process, it will help not only your professional life, but also your personal one. I'll defer to an article I wrote on my blog about this. Once you've done this, read, and apply the principles of Getting Things Done.

* Manage your inbox. Adopt a dead-simple filing system, such as The Trusted Trio, and discipline yourself.

Get good at structuring your thoughts.

When considering what groceries to buy, you might work through a stream of consciousness, as follows:

"I need spinach, and a couple pounds of cheese. My Mother also really likes that frozen casserole we had the last time she was here. What was it called again? I'll probably recognize it when I see it. Hmmm. On second thought, I probably don't need so much cheese..."

Instead of writing it out that way, you take the time to list each item out in a nice, orderly list. Why? Because it's easy to read, and to check off (process) as you make your way around the aisles. Yet, a lot of communications we receive really is just a stream of consciousness.

How can you make this sort of structured thinking a habit? I believe that it can start with improving the communications you spend the majority of your day writing: Your email.

Here are some of my suggestions for composing better email messages:

* Include the thing you want me to make sure I see at the top of the message.
* If you have several questions to ask, list them out and number them, so I can respond to each one easier.
* Clearly list out the actions you want me to perform.

For more tips, buy a book on writing email, such as this one. (I haven't read it, but the reviews seem overwhelmingly positive! If you have any to suggest, feel free to mention them in the comments.)

Your good email habits are bound to carry over to the other part of your job: Actually writing requirements.

Communicating

Learn to write more betterer.

Outside of work, and your email client, consider spending time writing about something you're passionate about.

Start a blog about gardening. Write about your Lego collection. Tell everybody about that time that thing happened.

You only get better at expressing yourself by writing more.

Learn to network.

Your job is also about making connections and knowing the people in your organization.

Connect to other people in your company via LinkedIn. This is an innocent way of saying hello, without really saying hello.

For those of you who consider yourselves introverts, or are just shy about approaching strangers, I heartily recommend Leil Lowndes' How To Talk to Anyone.

Learn to think in flows.

I'm going to suggest something here that some of you may consider controversial. Are you ready?

Take a simple programming course.

This will, at the very least, get you to start thinking in terms of processes, and breaking down things into a step-by-step, logical series of events. This is a concept that a fair amount of BAs I have encountered have some trouble wrapping their heads around.

Remember that you're a translator, so knowing both the language of the business, and the "language" of your implementers is vital to bridging that gap effectively.

Learn to think like a designer.

In case business analysts don't do enough, they also frequently have to play the role of a designer.

In this area, I suggest reading books on user interface design, starting with The Design of Everyday Things.

Another way to look at design is that of "selling" information: Think through how to best present the data you have, and how to make it look good. To help here, pay attention to things like templates you like, to print advertisements in magazines and the layout of designs on bus shelters; examine the fonts chosen, and the structuring of the information it's aiming to convey.

How Are You Awesome?

I hope you find something in all of this somewhat useful. If you have any of your own tips to offer, please post them below!

Photo by SeeMidTN.com (aka Brent)

 

 

 

 

 

 

For unity's sake, clean up those requirements documents!!!

It's easy enough to tell a story, but what happens when the consumer's comprehension of the story determines how it will turn out. Imagine a book that automatically changes the ending based on the reader's understanding of what the author was attempting to say. Inevitably, no two readers would share the same ending. There would always be differences of opinions and the value of the story could be drastically reduced if the author wasn't extremely precise in what was written.

 The Business Analyst is an author and the ending to the story they write will vary based on how the story is understood. The Analyst sits between the Business Partner and the IT group, and authors a story based on what they understand the Business Partner to need. This story then gets handed to IT and their job is to go and write the ending. As we all know, in this type of story, the ending is rarely what the Business Partner or the Analyst expected.

Although there are many factors that contribute to an unhappy ending, I want to focus in on the topic of unity. As a parent I'm often looking at my kid's room and saying, "For goodness sake, they need to clean this room." When I look at most requirement documents I think, "For unity's sake, they need to clean up this document." Unity is what holds the story together and gives it a clear and precise context. Every story needs context in order for the reader to relate and connect. If the document feels like a scrambled jumble of parts and pieces, the reader will never connect with the story. If they don't connect, they can't provide the feedback that's so desperately needed before IT starts to write the ending.

To accomplish unity in a document you must do the following:

1) Always provide a consistent look, feel, and structure - a template
2) Leverage hyperlinks in the document so it's easy to navigate to related elements - easy navigation
3) Clearly identify how the different elements relate to each other - rich context

The reader needs to understand how a goal is accomplished (Use Cases), how each step used to accomplish the goal relates to the needs of the Business (Business Requirements) and the tasks of the users (User Requirements). How the system steps in the Use Case drive the System or Functional requirements. What UI Mockups should be used for a given step in the process, and so on. When all these different pieces are in unity throughout the document, then, and only then, can the Business Partner drive precision into the story, (via feedback) so that the IT Group can write the most accurate ending.

Although I agree with Chris Gurney's post, "The Big Freaking Document Must Die," until Analysts adopt better tools that help tell a more unified story, via visual simulation of requirements, or at least generate documents with unified content, we're stuck manually creating documents. But keep in mind, especially with manual documents, it's not just about having content, it's about unity of content. Content alone is useless, unified content is easily understood and opens the door to precision. And when the reader is writing the ending, precision is king.

So, for unity's sake, clean up those documents.