“A software package implemented using phantom business requirements, or those born of the IT developers’ imagination, will most likely generate discord, inefficiencies, and occasional outright resentment of the tool.”
-unknown author
All Process Management software products are not created equal. So determining which one is right for your company takes more than a wish and a prayer. Now we’re not experts in the Procurement process, but the typical vendor RFP (Requests for Proposal) and software implementation requirements we’ve seen are so vague they could easily wind up producing unintended results as depicted in Figure 1.
FIGURE 1 – The Result of Good Intentions vs. Good Requirements
If Figure 1 looks familiar, you are not alone. According to the Standish Group, a market research and advisory firm specializing in strategic software, incomplete business requirements are one of the top-three causes of unsuccessful IT project implementation. So how do we build better business requirements to ensure that what we get is really what we wanted?
GUIDELINES FOR BUILDING QUALITY BUSINESS REQUIREMENTS
Understand the Purpose. Technically speaking, a requirement is a condition or capability to which the system must conform. However, building requirements is not an exercise in tedium intended to make your project team break out in a cold sweat. They are a way of clarifying the project vision and scope. They make it tangible. As you develop requirements, you confront issues and make decisions about what the project outcome will be. You are, in fact, building the blueprint that will guide the design.
Business requirements are called “business” requirements for a reason. They should reflect the perspective of the business- what the business needs the solution to do or provide. They are not the intended to indicate how the solution will be implemented or the technology that should be used.
Apply Structure to Each Requirement. To build good requirements, there are some basic guidelines you can follow to ensure they will be interpreted as you intended. Every requirement should be:
Unambiguous – Be very specific in your wording of the requirement to ensure that anyone reading the requirement understands it in the same manner. Leave no room for interpretation.
- Avoid vague phrases like “user friendly” or “easily accessible” should be avoided.
- Don’t use workplace jargon or acronyms unless you capture their definition in a Glossary. Others who are less familiar with the term will need to have a reference so they can clearly understand your intention.
- Use of the word “or” typically indicates that the requirement is conditional. If so, make certain that the specific conditions guiding the requirement are clear.
- If you get questions about the meaning of a requirement, use that as an indicator that additional clarity is needed. So rephrase or add additional business rules to clarify the statement.
Singular – As a general rule, each requirement should be a one sentence statement of thought. Do not use the word “and” to combine two separate thoughts into one requirement. If it’s two separate thoughts, make it two requirements. This singularity of requirements set the stage for “requirements traceability” – the ability to trace elements of our design or implemented solution back to the business requirements that are supported and the customer needs that are fulfilled.
Testable – Each functional requirement should be able to be tested to see if it works or not. As you’re building your requirements, ask yourself or your team “could I test this requirement?”. Doing so will help you think more granularly.
Focused on “What” – Keep discussions focused on “what is needed” rather than “how to implement”. Avoid using system names or making undocumented assumptions about technology implications.
Ability or Capability – Often we see requirement statements phrased as tasks – do this, follow up on that. A good requirement is not a task; it is a statement of the ability or capability needed to achieve the business goal. In fact, many good requirements are actually worded as “the ability to…”
Ensure You’ve Covered All the Bases. For any software implementation, you should document requirements related to the functions it must perform and the performance required. But we also recommend capturing requirements related to people and the processes affected by the implementation.
Functional Requirements describe what the system must be able to do in order to achieve the business goals. Functional requirements typically include:
- Business requirements – Concise statements of the required functionality.
- Business rules – Conditions that describe when the requirement is applicable, computations or calculations that relate to the requirement or explicit constraints on its behavior. These are not processes or procedures. Rather, they are rules which are applied across the processes or procedures to consistently enforce business activity.
- Interface requirements
Non-Functional Requirements are qualities or attributes that the system must have in addition to the functions it performs. Common types of non-functional requirements include:
- Performance requirements
- Reliability requirements
- Interoperability requirements
- Scalability requirements
- Security requirements
People and Process Requirements describe what the people or process must be able to do and are often more implementation-oriented. Common types of people and process requirements include:
- Training, documentation, communication requirements
- Service and support requirements
- Legal, Compliance or Audit requirements
- Reporting requirements
Capture Supporting Information. No set of requirements is complete without an understanding of the constraints, assumptions and dependencies upon which they are based. Document these items to paint a complete and comprehensive picture of your software package requirements.
Constraints – Factors that limit the possible solution. These factors may include budget limitations, hardware constraints, project completion date commitments and other such restrictions. For example:
- We are constrained by a contractual agreement to implement no later than 9/2007.
- We are limited to a budget of $1M for the project.
Assumptions – Factors outside the project scope that you are basing a requirement or set of requirements upon. Examples would include:
- We assume that the necessary vendor relationships will be in place to support web implementation.
- We assume that screening for eligibility will occur prior to application acceptance.
Dependencies – A list of projects upon which this implementation is dependent for functionality or strategic direction. Alterations in the timeline or implementation of dependent projects usually have a direct effect on the implementation date of the project under discussion. This is not intended to be an all inclusive list of known projects, so focus on dependencies that are unique to this project.
CONCLUSION
Developing requirements is a critical and necessary part of selecting the right Process Management software package. Their purpose is to clarify the project vision and scope. They make it tangible by building the blueprint that will guide the design. So follow the suggested guidelines to document your functional, non-functional, people and process requirements. Then augment them with supporting assumptions, constraints and dependencies to ensure you effectively capture and communicate comprehensive, quality business requirements.
REFERENCES
Alexander, C., Silverstein, M., Angel, S., Ishikawa, S., Abrams, D. The Oregon Experiment. New York: Oxford University Press. 1975, p. 44.
“The CHAOS Report”, The Standish Group International, Inc. 1995.
Means, J. and Adams, T. Facilitating the Project Lifecycle: Skills and Tools to Accelerate Progress for Project Managers, Facilitators, and Six Sigma Project Teams. San Francisco: Jossey-Bass, 2005.
