Tag: BABOK

The Top 5 Mistakes in Requirements Practices and Documentation

Written by Angela Wick on May 28, 2012. Posted in Articles.

In my work with dozens of organizations improving business analysis practices, the following are the most common themes I see hindering the great value that good business analysis practices can provide.

1) Lack of collaboration and review of requirements

Collaboration and review of requirements should be an ongoing process of meeting, discovering, and collaborating to share information and context. Verifying that requirements met the needs of others to guide further work and validating that the requirements will add value to the business are critical pieces to this review and collaboration.

The mistakes I typically see in this area are teams that “gather” and “collect” requirements from stakeholders rather than using proven successful elicitation, discovery, and validation techniques. Following a “gather” and “collect” mindset sets a team up to jump to the solution too quickly before truly understanding the business needs and value required by the stakeholders.

The BA is often assigned to the project after business needs and values have already been discussed and the stakeholders pressure the BA to just move forward. This is the most important time for a BA to use powerful collaboration techniques that help the stakeholders feel that they are not restating the same information but are improving the business value proposition the project is set out to achieve.

Some teams see requirements reviews as sufficient collaboration. With requirements reviews I often see the following:
• Lack of review
• Reviewed, but missing critical stakeholders and consumers of requirements
• Reviewed but as a formality, and stakeholders struggle to truly understand requirements documentation

Ideally for requirements reviews to be successful, those using and signing off on requirements need to be fully engaged in reviewing requirements, verifying they are understandable, cohesive, and usable for the further work to be done, and validating the business value and intent of the requirements. To achieve this, BAs need to ensure that documents are presented and communicated in ways that are understandable to all audiences and the review process engages all audiences to fully participate in the review.

2) Not differentiating between capabilities, rules, project tasks, and design

Many requirements documents that I see in a large number and variety of organizations are missing the essence of what requirements are. The mistake I see is requirements documents lifting project tasks, detailed technical design, and business rules without listing the context and capabilities needed. This sets the project and solution up for a multitude of missed requirements and missed value to stakeholders. Business and solution requirements are capabilities needed by a solution to achieve a desired change in the business. They are not project tasks lists, technical design details, or bullet lists of business logic. Focusing on the true requirements instead of the project tasks and design will shorten the requirements timeline.

Project tasks need to be in a project plan of some sort, and design should be happening progressively as requirements are discovered and must account for feasibility and alternatives. Design needs to be differentiated from what the requirements are, and this can occur in a separate document or not, but it needs to be differentiated. It is no fun to manage requirements change when the requirements document is really tasks and design; this will cause more change management administration than needed. Requirements change becomes much more manageable when it is truly business and solution requirements that are changing. Changing design details and project tasks is likely to happen with more frequency and may not impact the end result, and a failure to differentiate can cause costly rework and unneeded administrative tasks.

Business rules are critical to successful requirements, but I often see requirements only in the context of business rules, and sometimes up to 90% of a requirements document is a listing of business rules. Business rules listings without the context of processes, people, data definitions, sets, projects up for missed requirements, inefficient and inconsistent implementation of business rules. Understanding the business rule outside of technology enablement is crucial to improving the consistency and efficiency of business rules. Differentiating business rules from requirements is critical to understanding and analyzing the capabilities needed to implement the rules.

3) Lack of context and visuals

Context and visuals provide our requirements readers with brain candy. Many studies show that visuals are consumed by the brain much faster than text and help depict relationships, whereas text is processed in a more linear fashion in our brains. Cognitively, visuals are proven to be more effective than text at increasing a reader’s comprehension and retention. On the other side, visuals without text can be too ambiguous. So, why do so many requirements documents lack visuals and context that would help readers comprehend and retain the very information BAs are asking them to approve? As Bas, visuals are sometimes present but often are too complex to engage our readers and need to be simplified. Sometimes our visuals as BAs are design oriented rather than intended to help readers understand context, interactions, and relationships.

Great requirements are documented in a way that allows the reader to choose the level of detail they would like to consume, provide visuals and context of varying levels of detail needed to guide further work, and provide text that clearly traces the visual and context representing the text.

4) Too much focus on the as-is current state

Projects and business analysis work is about changing the way organizations operate. It amazes me how much time is spent on documenting the as-is; I am not advocating ignoring the as-is or current state, because it is needed to understand the gaps that must be crossed to get to the future desired state. The challenge and mistake I see teams making is never getting to defining the gaps and future state. And, sometimes all of the context and visuals are about the current state with nothing showing the context or visuals for the future state.
Our requirements need to understand the current state, but the requirements themselves should represent the gaps and future state. We are not asking our stakeholders to approve the current state. Instead, they are asking us to help them change, hence we need to define the future state. Our requirements need to answer the questions: Why are we spending money on this solution? What value will the solution bring?

There are many statistics out there about the percentage of functionality in current systems that is not used; the numbers typically range between 60-80%. This raises the question of why we would document requirements for the future the way the system works today when 60-80% is not even used today? After all, today’s system was likely designed 10, 20, or even 30 years ago and we can’t possibly compete in todays business environment by developing solutions based on functionality designed for business years ago. After all, how will this take the organization into the future?

Great requirements practices and documents show how the current state is going to change, what the future state is, and the gaps to get there. There are many areas of solutions where the current rules, process, and technology will be leveraged in the future state, and this is where we need to ensure we are focused on the future by defining what pieces will move forward, and we shouldn’t spend too much effort on current state items that will not carry forward. This is done by identifying the current state at a higher level and questioning if this piece will continue to add value in the future state vision. At that point, a BA should only go into details if the value is justified.

5) Allocating requirements too early to the applications they will be implemented in

When evaluating business analysis practices and how they align with software development processes, I often see that the requirements are being allocated to software applications before the requirement itself has much context or elaboration. Understanding the requirement and business need is needed before we can specify what system or application will be changed or built to implement the requirement. The practice of assigning the technology to a requirement before the BA is assigned or before the requirement is vetted defeats the purpose of business analysis in many ways. This practice also makes requirements change a huge challenge. As we discover and elaborate requirements, we often find that the initial idea on implementation is not feasible or optimal. If the requirements process has already allocated the requirement, it takes a change request to change that in some organizations. This is where the process hinders good business analysis. Many times this practice is not in the control of a BA, but I do believe that a BA can collaborate with others, and elicit and document requirements in a technology-agnostic manner to facilitate the discovery of other ways to implement requirements.

Great requirements practices focus on the user, process, rules, events, data, and non-functional needs before deciding which exact implementation technology will be used. This allows the team to discover the true business need and explore options and alternatives that may not have been previously thought of. It also helps ensure feasibility prior to committing to a specific solution design.

Let me know your thoughts on the common mistakes in requirements practices and your challenges in these areas.

Don’t forget to leave your comments below.

Requirements Development 101

Written by Zenobia Godschalk on February 15, 2011. Posted in Articles.

Many organizations that I work with understand that better requirements engineering practices would alleviate many pains in their current software development lifecycle (SDLC). But some of these organizations don’t know how to improve their practices because, I believe, they don’t fully appreciate the world of requirements engineering. So I am writing this article to describe, at a high level, the components that make up requirements engineering. Once the components are understood, then organizations can see what is missing or what needs to be modified in their current environment to arrive at a better practice.

First, let’s define the term requirements. There are millions of web sites that can give you this definition, so I went with Wikipedia (http://en.wikipedia.org/wiki/Requirement). It states that “a requirement is a singular documented need of what a particular product or service should be or perform”. This, to me, means there are many, many kinds of information that fit into this thing called “requirements”. To simplify the matter, let’s start breaking down these kinds of information into categories, or different “types” of requirements. At a minimum, an organization should collect these types:

Business Requirements -describes the values this project will provide the organization once it is finished. Some organizations have a vision and scope document, while others just roll it into the generic Business Requirements Document (BRD).
User and Functional Requirements, and Business Rules – these describe what the software needs to do and what the development teams need to build. Some organizations have a Use Case or Functional Requirements Specification (FRS) document, while others have it in the one BRD.
System and Data Requirements, Quality Attributes, External Interfaces, and Constraints – these types are just a handful of non-functional requirement types that you can collect. Some organizations have a Software Requirements Specification (SRS), while others have it in that BRD, which seems to be looking pretty big right now.

Now that we know what to collect, we need to understand how to collect them. Requirements engineering is broken down into two activities: requirements development (RD) and requirements management (RM). I find most organizations do requirements management well. This is to say, they can manage changes to a set of baselined requirements that have been identified to a specific release. What I find is most organizations have a hard time setting a standard practice around requirements development. I will spend the rest of the article describing this activity. RD is broken down into the following sub-activities:

Elicitation – this involves interviewing the stakeholders and determining their needs. This is not writing down everything they say. Stakeholders will not know everything they need the first time you interview them. What they do know, may not fit into the scope of the project or may not be in agreement with the next stakeholder you interview, or may even be wrong. Therefore, elicitation is an iterative and inventive activity. Think of yourself as a detective that asks the questions that gets the stakeholders to think of missing or new requirements that are within the scope of the project. A good way to get the stakeholders to open up is to ask all the “What if …” questions. Another very useful technique to use is to ask “Why?” These questions can reveal missing or unspoken requirements or offer additional details to enhance the understanding of a requirement. Creating these types of dialog is an effective way to increase the completeness and quality of the requirements versus just writing down everything that they say.
Analysis – this involves developing detailed requirements from elicitation. These detailed requirements don’t need to be just textual in nature. They can be of different forms, such as business process diagrams, data models, use cases, and prototypes. By gaining greater detail, you will also discover missing requirements. Analysis offers an effective way to recursively refine the understanding of the initial elicited requirements. This is also where you will settle priorities of requirements between stakeholders and arbitrate between conflicting requirements. Because the analyst is the communication hub with all the stakeholders, it is a good idea to identify key decision-makers that will have the final yea or nay power when conflicts arise. This will become even more important when you communicate the requirements downstream to the testers and developers, therefore quick and efficient conflict resolution process is important.
Specification – this involves documenting the various types of requirements, which can be textual or graphical. It is usually a good idea to have a few documentation standards for vision and scope document, FRS, SRS, BRD, etc. Many analyst web sites have examples of these types of document standards.
Validation – this involves making sure that the requirements are correct and will meet the stakeholders’ needs. One good way to validate requirements is to have the stakeholders develop user acceptance criteria. These criteria specify the primary tasks the software will allow the users to perform and the common errors that the software will handle. Comparing the requirements against the user acceptance criteria will establish if the requirements are correct. On a side note, they also provide starting points for testing scenarios for the quality assurance team.

I would like to point out that you don’t need to develop all the requirements for the entire project at once. Requirements development is an iterative process, so trying to develop detailed requirements all at once can lead to analysis paralysis. During elicitation, you will identify the high priority or first built features. Start with analysis and specification of these requirements and do validation with a quick informal review. Then move to the next set of elicited requirements for analysis and specification, all the while correcting the previous set of requirements of missing or misunderstood requirements that are discovered along the way. By infusing quick review cycles between analysis and specification, you will filter out errors and increase the completeness and quality of the requirements with each cycle. Having multiple cycles will refine the requirements to a level of detail that can be efficiently communicated to the stakeholders, testers, and developers. At the end of the day, a project will never have a set of perfect requirements, but it will have a good enough set of requirements to proceed to development and testing. Since we can never produce a perfect set, we want to adopt practices that result in fewer requirement defects, especially the ones that have high impact and severity. We can weed out these nasty defects before they are injected into the SDLC. This can decrease the amount of development rework, which results in reduced product cost and quicker time to market.

On a final note, to further increase efficiencies in your requirement development activities, you should input all of the requirements in a single repository. It lets you capture elicited requirements and you can you can easily access them for usage as the basis for initial development of detailed use cases, UI mockups, data models and business process diagrams during analysis. Also a requirements repository allows you to trace any requirement to any other requirement. Since it is a repository, you can trace across all these elements to see all the dependencies and evaluate the impact of changes.

Don’t forget to leave your comments below.

Zeena Kabir is a Sales Engineering Consultant for Blueprint Software, the leader in requirements definition and visualization software. Prior to Blueprint, Zeena has worked 20+ years in the IT field in the areas of requirements engineering, testing, and development. She holds a Bachelor of Science degree in Computer Science and a Master of Science degree in Software Engineering from the University of Maryland. She resides and works with many IT organizations in the Mid-Atlantic region.

The Quest for Good Requirements

Written by Martin Schedlbauer on January 25, 2011. Posted in Articles.

The main responsibility of the analyst is the discovery, analysis, documentation, and communication of requirements. A requirement is simply a feature that a product or service must have in order to be useful to its stakeholders. For example, two requirements for a customer relationship management system might be to allow users to update the payment terms for an account and to add new customers.

In this article, we will look at the different aspects of the requirements management process and the lifecycle of requirements.

Definition of a Requirement

A more precise definition is provided by the IEEE Glossary of Software Engineering Terminology and the Business Analysis Body of Knowledge® (BABOK®). Both define a requirement as a

condition or capability needed by a user to solve a problem or achieve an objective.
condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
documented representation of a condition or capability in (1) or (2).

Not all requirements are at the same level. Some might be high level requirements expressed by the business sponsor (e.g., reduce the cost of invoicing customers), others might be very specific requirements that describe a function needed by a particular user (e.g., allow me to click on a customer name and then display that customer’s account history).

The BABOK® defines the following requirements types: business, user (stakeholder), functional (solution), non-functional (quality of service), constraint, and implementation (transition).

Note that these terms are overloaded and often have different definitions within some organizations. For example, a user requirement is referred to as a business requirement in some organizations and a business requirement is sometimes called a business goal or project objective. Functional requirements are also often called technical requirements, detailed requirements, or system requirements. So, it is important to understand the semantics of the terms being used. If in doubt, ask, but don’t assume. In fact, publish a glossary of terms to clarify the meaning of terms that are used by the project team.

Examples of Different Types of Requirements

To clarify the different kinds of requirements types, let’s take a look at some examples for each type.

Table 1. Requirements Examples

Scope

The scope of a project refers to the agreed upon set of features that the final product will contain. Scope creep is a common occurrence and it describes the propensity of scope to expand as stakeholders add requirements during the project without regard to its impact on budget, schedule, and deliverables. The project manager must work with the stakeholders to get agreement on the scope.

Stakeholders

The stakeholders are the main source of requirements. They have specific needs that the analyst must identify. This is easier said than done: often stakeholders are not quite sure what they need and they often don’t know how to express what they need. It is the analyst’s job to help uncover the requirements of the stakeholders.

A stakeholder is anyone who has an interest in the successful outcome of the project, including project sponsors, users, business executives, managers, developers, clients, customers, vendors, and government or regulatory agencies.

Eliciting requirements is surprisingly hard work. Stakeholders often do not know exactly what they need and eliciting the requirements can be quite challenging. As Fred Brooks has stated so poignantly in his seminal essay “No Silver Bullet: Essence and Accidents of Software Engineering”

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirement, including all the interfaces to people, machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

He goes on to say that in a systems development project there are two kinds of complexities that must be managed: accidental and essential (or inherent).

Much of software engineering is focused on reducing accidental complexity, which is the complexity that we add to a project by way of the tools and programming languages that we use. For example, writing code in C is much harder than Java and writing code in Java is much harder than doing a “mashup” with web components.

While it is good to focus on reducing accidental complexity, much of the complexity of a project is rooted in essential (or inherent) complexity. Essential complexity is the difficulty of the problem itself: launching a rocket into orbit is hard no matter what programming language you use. The techniques studied in this book are about managing essential complexity.

Brooks also argues that systems are best developed incrementally. Start with something small that you understand and improve and expand it rather than building the penultimate version at the outset. This approach is the foundation for iterative and agile methods.

Requirements Management

Requirements management is the process of defining and maintaining the requirements that form the agreement between the project team and the stakeholders. A requirements management plan (RMP) is a document that defines the process, procedures, and standards for eliciting, documenting, storing, and updating the requirements. The typical requirement management activities include the following:

Figure 1. Requirements Management Activities

Requirements Management Activities

Requirements management is generally supported by the use of requirements tracking or requirements management tools. There are numerous commercial, free, and open source tools that can be used.

Requirements Process

The process of requirements specification can be broken down into discovery (elicitation), analysis, modeling and documentation, communication, and validation (see Figure 2.) As part of the process, the project team must also negotiate the relative importance of each requirement, so that an appropriate prioritization can be established. The requirements that are considered to be implementable within the allocated time and budget are called the project scope or simply scope.

The project team generally implements the requirements in order of priority, starting with the most important ones. The reason is simple: most projects have limited time and budget and commonly not all requirements can be addressed. By the time we run out of time and money the stakeholders would want the most important requirements taken care of. While this sounds simple, establishing and negotiating the priorities of requirements can often be very difficult and politically challenging. Stakeholders don’t want to prioritize for fear of not getting what they want; the project team does not want an unlimited scope as they know that they likely cannot accomplish everything with the allotted resources.

Figure 2. Requirements Management Process

Stakeholder Obligations

For an IT project to be successful, the stakeholders have certain responsibilities:

they must spend the time with the analyst and educate them about their business and help them understand their objectives
they need to allocate the time necessary to provide clear requirements and validate the requirements in a timely fashion
they must precisely describe their requirement; vaguely stated requirements are not implementable and documenting them is a waste of time
they must provide feedback when needed
they must provide additional information in a timely fashion
they must prioritize the requirements
they must respect the estimates for time and budget provided by the project team and resist the urge to “negotiate”
they must inform the project team of changes to requirements as soon as they occur

The analyst must continually remind (in subtle ways, of course) the stakeholders of their responsibilities. If the stakeholders don’t live up to them, then that introduces project risks which must be made known to the projects manager and included in the project’s risk catalog.

Requirements Elicitation and Discovery

To discover requirements, the analyst applies a variety of techniques. The steps in requirements elicitation are generally as follows:

Plan the requirements elicitation process and how the team will document and validate the requirements. This plan is referred to as the Requirements Management Plan (RMP) and is considered a key document for project planning.
Write a Project Charter or Project Mission Statement containing the business requirements and the overall scope of the project. Often a Context Diagram is provided to clarify the scope of the system development effort. All stakeholders must agree to the vision for the project. Some organizations refer to this document as the Business Requirements Document (BRD). Use brainstorming and interviewing to arrive at the key business requirements.
Identify the key users and their usage characteristics and select a proxy for each user that can present the requirements for that class of users. These “user representatives” will be consulted throughout the requirements elicitation effort.
Collaborate with the user representatives to identify use cases and then analyze those use cases to derive the detailed functional requirements for the product.
Analyze any events to which the system must respond, such as input from hardware devices or messages from other systems.
Identify any other stakeholders who might provide requirements or constraints.
Convene requirements workshops in which users work together for a few days to explore user needs and to agree on the requirements. Requirements workshops are a way to reduce the amount of time it takes to find all the requirements by getting everyone together at the same time. Joint Requirements Planning (JRP) and Joint Application Development (JAD) are examples of facilitated requirements workshops.
Shadow users as they perform job tasks and use the results of the observations to identify needs and to understand business processes. Document these insights in flow charts or UML Activity Diagrams.
Hold feedback sessions during which users can provide feedback on issues or problems with the current system. The results can be used to formulate requirements on how to enhance the system. Looking at problem reports from the help desk can be particularly insightful.
Build a prototype that demonstrates the requirements and provides realistic feedback to the users.
Identify, document, and address any risks that might have a negative impact on the project, i.e., that might cause a delay in delivery, an increase in budget, or a reduction in scope.
Validate the requirements through walkthroughs and other formal or informal meetings with stakeholder to assure that the right requirements have been discovered.

Requirements Analysis

As soon as requirements have been identified, they must be analyzed to ensure that they are correct, not in conflict with each other, and that they are precisely understood by all stakeholders. During analysis, the requirements must be decomposed into sufficient detail so that the project team can accurately estimate effort for implementation and assure that the requirements are indeed feasible.

Analysis Artifacts

During analysis, the analyst constructs a number of textual, digital and visual artifacts, including:

context diagrams
use case model
conceptual data models and data dictionary
user interface model
business process models
prioritized requirements catalog
business rule catalog
prototypes (horizontal discovery as well as vertical feasibility prototypes)

Requirements Documentation

To communicate the requirements to the stakeholders for validation and to provide the development team with a thorough understanding of what must be done, the analyst must write a requirements specification. This is simply called the requirements package as there are no industry standards for the format of that specification. Every organization has adopted a different document template. It is important, however, that an organization has a standard document template. The template must be flexible as no single structure will fit all projects.

The successful analyst knows how to select the right documentation techniques and does not limit himself to just one documentation approach, such as wireframes, use cases, or narrative requirements. He blends the different approaches to specify all requirements clearly, unambiguously, and concisely.

While writing documentation is generally not a value-added activity from the user’s perspective, it is a necessary mechanism to mitigate certain project risks. The amount of necessary documentation is dependent on the specific risks that are present, particularly when projects are implemented by outsourcing partners, distributed teams, or when access to stakeholders is limited or sporadic.

Requirements Validation

Requirements must be validated prior to implementation to assure that they are correctly understood and still valid lest the team wastes precious resources implementing functionality that is not needed. Validation is achieved through several means, including:

Formal and informal inspection: In this approach, the project team meets and walks through the requirements package, including any visual and executable models.
Stakeholder reviews: Present the requirements, models, and prototypes to the stakeholders for review and validation. At the conclusion of the review, the stakeholders “sign-off” on the requirements to indicate their approval.
Acceptance criteria definition: For each user requirement (generally expressed as a use case), define post conditions so that tests can be constructed that verify that the requirements have been met.

Writing Effective Requirements

Documenting requirements is an essential part of the requirements process. Over the years, many approaches to documenting requirements have been developed. Among the more prominent recommendations is IEEE Standard 830, which contains the recommended practices for writing software requirements specifications (SRS).

Requirements that are useful, exhibit several important characteristics:

complete: the requirement must contain all the information necessary to allow the project team to fulfill the requirement
accurate: the requirement must be correct; validation is generally done through reviews with stakeholders; an accurate requirement cannot be in conflict with another requirement
testable: the requirement can be verified through a test
feasible: the requirement can be implemented; there is no technical or other impediment that make the requirement undoable
necessary: the requirement must describe a feature that the stakeholders actually need; it must relate to a business objective
unambiguous: the requirement must be described in a simple and concise manner that guarantees that there are no differing interpretations of what the requirement means
prioritized: the requirement’s degree of necessity relative to other requirements has been established through stakeholder consultation

Documentation Formats

Requirements are commonly written as simple narrative statements. User requirements are best expressed as more elaborate documents. A common format for documenting user requirements are use cases. In addition, constructing visual models simplifies communication of complex requirements. A visual model, such as a UML diagram, can more precisely describe requirements than a written paragraph. It is also easier to discover mistakes in a diagram than a lengthy narrative. A requirements specification typically includes a combination of narratives, use cases, and visual models.

Requirements Identification

All requirements must be labeled so that it is easy to refer to them through a unique handle rather than its description. The following conventions are often used:

User Requirements are expressed as use cases and use the prefix UC, e.g., UC1.
Functional Requirements use the prefixes R or FR, e.g., R92, FR876
Business Requirements use the prefix O (for objective), e.g., O2
Business Rules use the prefix BR, e.g., BR12
Non-Functional (or Quality of Service) Requirements also use the prefix R, although some prefer to use NFR, e.g., R14 or NFR23

Requirements Traceability

Requirements must be traceable. That means for any requirement, one must be able to ascertain its source and its realization, i.e., a reason why the requirement exists and a guarantee that the requirement has actually been implemented. Generally, analysts construct a matrix that traces each requirement to implementation, test cases, and sources. The source of a requirement is generally some stakeholder but might also be a regulation or mandate.

Requirements Approval

Many organizations have a formal process of “sign-off” or approval where the customer or project sponsor formally agrees to the requirements that have been captured. While it is somewhat formal, sign-off must be viewed as a project milestone rather than a formal contract. Requirements very likely will still change after sign-off. After all, the business does not remain static; things change constantly in the business world. Project teams must adopt a requirements change procedure that stakeholders can fall back on when a requirement does indeed change. Naturally, the project manager must explain to the stakeholders that a change to the requirements (either by adding, modifying, or removing a requirement from the specification) likely will have an impact on the project’s schedule, budget, and delivery milestones.

While it is desirable for the project team that requirements are eventually “frozen” it is not realistic. The project team should be prepared to continually manage the requirements scope: scope is not static, it is dynamic and the development lifecycle must accommodate the dynamic nature of requirements. Because of that inherent dynamic, agile methods have become more appealing to many organizations. Agile methods acknowledge that requirements change and therefore they do not force a formal “sign-off” and “freezing” of the requirements. Scope is managed much more flexibly and informally in agile projects.

Conclusion

In this article, we summarized the important aspects of gathering, analyzing, documenting, communicating, and validating requirements. The techniques provided should serve as a foundation for your own best requirements management practices.

Don’t forget to leave your comments below.

Dr. Martin Schedlbauer, consultant and instructor for the Corporate Education Group, is an accomplished business analysis subject matter expert, and has been leading and authoring seminars and workshops in business analysis, software engineering, and project management for over twenty years. Beyond that, he coaches his clients in business analysis practices, process modeling, and lean project management. When he is not working with his clients or delivering workshops for CEG, he lectures at Northeastern University in Boston in his capacity as Clinical Professor.

[1] Brooks, F., “No Silver Bullet: Essence and Accidents of Software Engineering”. IEEE Computer, 20 (4), April 1987, pp. 10 – 19.

[2] A mashup is a re-combination of available web components to provide powerful new functionality using simple visual editors and little programming. As examples, see Yahoo pipes and Google mashups.

Why is Business Process Design the Future of Business Analysis?

Written by Angelo Baratta on November 2, 2010. Posted in Articles.

“Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”

– BABOK V2, page 3.

In order to achieve the objective of enabling the organization to achieve its goals, the business analyst engages in Requirements Elicitation. The following is extracted from the BABOK:

“The definition of elicitation is:

to draw forth or bring out (something latent or potential)
to call forth or draw out (as information or a response)

These definitions highlight the need to actively engage the stakeholders in defining requirements.”

– BABOK V2 (page 53)

The implication is that requirements come from subject matter experts (SMEs) and that the BA must extract them or draw them forth. But where did the SMEs get the requirements? Did they make them up? Do they represent their personal preferences? If the answer is yes to either, then requirements become virtually untouchable statements that can only be verified by the person who verbalized them. If the answer is yes, then a requirement can change at the whim of its originator.

Requirements are not and should not represent personal preferences that can’t be independently verified. Requirements must be owned by the organization. But what do they represent? Let’s again turn to the BABOK.

“A requirementis:

A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.”
A documented representation of a condition or capability as in (1) or (2).”

– BABOK V2 (pages 4-5)

The difficulty with these definitions is that they portray requirements as already existing prior to the start of the BA’s work. The BA’s challenge, then, is to somehow pry or draw out the requirement from its source-the stakeholder, the contract, the standard, or other imposed document. They imply that requirements are the output of some other process but somehow they were never properly recorded. So, in rides the BA to record them. If that were truly the case, then requirements would be captured correctly the first time, for the most part, because the stakeholders already know them. Requirements would be unlikely to change.

We know that this is not consistent with reality. Requirements are often wrong, irrelevant, or incomplete, and not because they were misunderstood. They were wrong from the start. In addition, requirements statements tend to change frequently and continuously. Why would that be? A reasonable conclusion is that the requirements that we are trying to elicit (draw out) don’t actually exist yet. It is the process of drawing them out that is making people think about them-possibly for the first time. That’s why they change so often. In other words, people are designing their process on the fly and in an unstructured and unreliable manner.

“No matter how hard individuals work, they cannot overcome a flawed process design, much less the burden of no design at all.”

Michael Hammer, The Agenda.

So what should requirements be? As per the definition, they represent a condition required to solve a problem or achieve a solution. Or they are constraints imposed from the outside. If a requirement is something needed to solve a problem, then we need to have developed the solution to the problem. In other words, we need to have gone through proper design.

This leads to an alternative way to view a requirement-as an output of process design. True Requirements can only be produced if and while a process is properly designed. That means that in order for a business analyst to achieve the intent of business analysis-recommend solutions that enable the organization to achieve its goals-the BA must engage the Requirements Team in designing the business process. Design is the activity. It must be carried out overtly and systematically and not as a side-effect of elicitation. Requirements are the output. They must be overtly documented in the form of a business blueprint.

Requirements should not be drawn forth. They should be hammered out as part of a structured process of design activity.

Process Design is the Future for Business Analysis

When the going gets tough, the middleman is the first to go. The BA, today, plays too much of a middleperson role. The future BA will be a process design master that leads SMEs and other stakeholders in process design. The endgame is a better process, not just requirements. And a better process requires a structured approach to process design.

The future business analyst will lead a structured design process that produces a process blueprint which contains structured requirements. The blueprint will represent organization needs that can be independently verified for correctness and completeness. The blueprint will separate out any personal preferences from process needs.

The separation of personal preferences is important because these account for many of the unnecessary conflicts that arise in requirements statements. Of course, in order to achieve this a few role changes are required.

The business analyst will no longer be a go-between. Instead she will lead a cross-functional team in the all important activity of designing the business. Today, the BA is master of few things. A BA knows project management but not as well as a project manager. The BA understands technology but not as well as the developer. The BA knows the target business domain but not as well as the subject matter experts. Today the BA is a jack of too many trades and a master of no particular one. This presents a clear and present danger for the BA. In the future, the BA will be the master in process design.

The process owner role needs to disappear. Firstly, few organizations have successfully implemented such a role. Think of ownership and what it implies. An owner can do what he likes to what he owns. That implies that a process owner can do whatever he likes to his process. But value delivering processes are cross-functional with functional owners. That leads to conflict. It leads to processes with two sets of owners, one for the cross-functional process, and one for each functional component. However, it is the organization that should own the business process. Process owners need to be replaced by process governors. A governor manages within a given framework. This makes more sense. The organization owns the process and defines the performance framework for it. The process governor manages that process within the given framework. He is not completely free to do whatever he wants. He must manage within boundaries.

Subject Matter Experts are not the customer. The customer does not change based on perspective. The external customer is the customer. A business process should be designed to deliver value to the external customer. The SMEs are participants of the business process. When the SME or other internal stakeholder becomes a customer, the risk is that their personal needs hijack the true needs. So SMEs,, developers, and other stakeholders become key process participants. Like the process governor, internal participants need to act in accordance with the process blueprint. That ensures that everyone is aligned to the process blueprint which represents the intent of the process.

Of what use is a business process blueprint?

“People who are aligned around a common goal but lack the discipline of a well-designed process will go nowhere … likewise the best-designed process has no chance of survival when people aren’t aligned around the process and its goals.”

Michael Hammer, The Agenda.

Conclusion

Design is the defining discipline of this decade. Structured Process Design is the new discipline whose mastery will set the business analyst apart. Process design will produce, as an output, the business process blueprint, which will contain structured requirements. These will be the foundation for developing strong and useful software applications. Process Mastery is the key future capability that will distinguish the business analyst from other roles.

Elicitation is a middleperson activity that will disappear and no one will mourn its passing. Incorrect, incomplete, irrelevant, and conflicting requirements will be dramatically reduced. Requirements will be independently verified and first pass quality will rise. More projects will be a business success and they will deliver more stakeholder value.

Roles will change to make accountability clear. Teamwork will need to rise. The BA will be the design team leader with SMEs, developers, and other stakeholders as team members. The process blueprint will become a persistent, reusable organization resource for managing process performance rather than a temporary throw-away project resource.

A focus away from elicitation to design will yield benefits for everyone. It will increase productivity and more importantly it will increase value delivered to the organization. Of course, the shift has to be driven by someone. If you like your current job as a requirements order taker, then you don’t need to take any action. But if you prefer the more proactive role of Process Design Master, then you should take the initiative in driving the future, if you haven’t already done so.

Don’t forget to leave your comments below

Angelo Baratta’s focus is advancing human mindware. Based on 30+ years cross-industry experience and over 10,000 hours of R&D comes ePPM by Design – a framework for structured process design (SPD) and requirements.

Learn more about SPD from his book “More Perfect by Design: A framework for designing more perfect business processes” available soon.

In progress is “Getting to Understanding: A framework for Structured Requirements.”

http://www.performanceinnovation.com/
[email protected]
905-270-7591

Read My Lips: Requirements Provide NO Value!

Written by Robert Galen on September 20, 2010. Posted in Articles.

I was telling a colleague the other day a coaching story that I found somewhat humorous. I was visiting a potential client not that long ago and my timing was just right. That day they were running their sprint reviews, so I asked if I could attend and they generously agreed.

I remember each of the teams showing PowerPoint presentations that represented the results of their 2-week long sprints. They had apparently spent hours on the slides, searching the web for interesting artwork and photos that somehow represented the features that they’d worked on. They worked incessantly to match their slide prose to the images and try to tell a very compelling and humorous story that captured their overall sprints efforts.

From my perspective, alarm bells went off after the first review that I attended. Something was amiss. It struck me that the team unfortunately didn’t understand the fundamental point of sprint reviews nor one of the core tenants of agility.

So what was missing you might ask?

They forgot the software in the sprint review. They literally had shown no working software-not one bit! You can show all sorts of things in a review, but the most important doesn’t revolve around PowerPoint or documents of any kind.

No! It’s in showing honest to goodness working software. Software that has been thoroughly tested, verified, and “accepted” by the customer. In other words, creating value by instantiating your requirements in software. That’s what its about and the Agile Manifesto thoughtfully reminds us of that in one of its four core tenets.

We Prefer Working Software over Comprehensive Documentation

It’s not to say that the team was entirely wasting its time. Sure, connecting with the audience was important-as as showing creativity and engagement with the project. However, the entire point of software development is producing software that has value in the eyes of the customer that is directed by the customer towards addressing their most pressing needs.

So as I was leaving the client, I shared this insight with their coaches. As time has passed, they’ve become much better at demonstrating working code and it’s made a huge difference in their customers’ perception of the value the team is delivering.

Nice Story, But What’s the Point?

Extending from the story, I think that we need to approach software project documentation (the wide variety of plans, status reports, regulatory checklists, and most importantly for this post – requirements) from the perspective that it serves no eventual purpose except delivering working software.

The documents have no value independent of the software…none!

So am implying that we don’t need any documentation? No, nothing could be further from my point. But we must stop producing documentation as if it’s a salient deliverable on its own. It’s not! Requirements are intended to drive the evolution of a product, nothing more and nothing less.

Can you sell them to a client? No! Are they tangible without the software? No! Do they usually stay current with the software’s evolution? I’d say quite rarely, so they can easily become dated and inconsistent.

So, What are Some of the Key Attributes of Working Software?

So if working software is our ultimate goal and value proposition, let me share a few key attributes that come to mind:

Working software drives feedback. Not by reviewing a document or diagram, but by observing the behavior within a running system. It exemplifies that old adage that a picture is worth a thousand words. Working software is worth immeasurable words.
Working software is the great equalizer. You’re not 90% done or “almost there”. You can either demonstrate the feature or you can’t. It works or it doesn’t. Usually in a more robust environment that is established and stable.
Working software doesn’t always have/need a UI. It does need some mechanism to share behavior and workflow in a fashion that can be exposed to and simply explained to your stakeholders, but don’t get caught up too heavily in UI exposure under all circumstances.
Working software is a confidence builder. First, with you stakeholders. It takes us from the normal hand-waving associated with documentation and requirements and brings us visually into focus for their perusal.
It also builds confidence inside the team. It should progress, in small chunks of understandable and simple functionality. It facilitates the team working together to deliver on a small and achievable goal. They inherently want to get to the next piece.
Working software focuses us on testing, making the feature work, checking design quality and exception handling. Checking acceptance criteria with our customer early in development; gaining their feedback and making adjustments.
Working software is done. Think of it as inventory. We should be able to put it on the shelf and declare this small section of the product complete fully ready for adding or integrating with other features. The customer is convinced that it meets their needs.
Working software includes all of the software. Unit tests and functional tests can be a part of the effort. If the software works-so do the tests.
Working software is continuously working; meaning it can’t regress. If we had it working once but now its broken, then making the software and the associated tests work becomes our highest priority.

Wrap-Up

The key discussion here isn’t about requirements. Nor is it about artifacts. It’s focused towards the BA’s role in guiding your products towards working software. I’d argue that the largest part of your value is here. Not in writing or reviewing or updating or interviewing or drawing, but in taking all of these activities and driving them into effective execution and articulation within your software. Making it work as viewed and assessed by your customer.

That’s where true value lies and I hope you start skewing your attention more and more in that direction.

Don’t forget to leave your comments below