By Cathy Dew
Let's jump right in with characteristics of good business requirements:
- Each requirement is atomic and specific to a single need
- Requirements use clear terminology.
- Requirements should avoid acronyms, buzz words
- Requirements should not include ambiguous words, don't use "user friendly" and "robust"
- Requirements focus on the who and the what of the requirement
- Requirements should avoid describing how the requirement will be met (implementation)
- Requirements are not duplicated or described in a different way later in the document
- Requirements are organized into logical groupings
Remember, the point is to make this document easy to read and understand by the project team including stakeholders with various levels of involvement with the target business process. Good business requirements meet objectives (i.e., provide value) when satisfied. There are always business deliverable whats that provide value when satisfied.If you've been following along, we have gone through almost all the major steps and templates for business process analysis projects.
Now where were we...
In case you missed it, here are the first seven (7) blogs in our series on business process analysis templates:
This week we look at requirements…
Now that we have completed surveys and interviews and we have an excellent understanding of the target user (persona) and their processes (flows and data), let’s put it together into one of the most important Business Process Analysis templates for projects that involve software — Requirements.
Requirements are the full expression of exactly what needs are required from the software. Wikipedia has this description of the software requirements specification. It is a communication tool between stakeholders and the technical team and its value is in its ability to accurately describe a scope of work. There are functional requirements and technical requirements and they both describe features based on user need.
There are many components to format your requirements; we’ve used all three, depending on the project:
- Narrative list of statements, usually starting with “ability to...”
- Use Cases
- User Stories — especially good for agile development
Both Use Cases and User Stories are especially good techniques if you are building the software solution, either with your internal team or an external development partner, like us here at 2Plus2.
Lynda.com has a class to learn how to write requirements with use cases. And Udemy has a comprehensive masterclass to learning how to prevent project scope management failure (A key to PM Success! Check out Project Scope Management: Writing Good Requirements.
User stories are often associated with the agile development process and have a simple format to follow:
- As a “fill in the blank” (who you are, role)
- I want “fill in the blank” (your goal, what you are trying to accomplish)
- So that “fill in the blank” (what you expect to achieve, benefit or value)
Why We Write Requirements
As with many of the business process analysis templates, good requirements provide a tool to reinforce and provide cohesion for a project team. The business process analyst job is to understand the user and articulate requirements and ensure the technical team understands why the user needs something.
A basic rule of thumb to remember is that approximately 25% of project time should be devoted to requirements definition and 5% of project time reserved for updates throughout the process.
There are many benefits of writing good requirements, including:
- Setting a basis for agreement between stakeholders and technical developers. Also, serves as a basis for estimating effort.
- Saving development time. By carefully reviewing requirements early on, you can spot omissions, misunderstandings, and inconsistencies when it's easier to correct.
- Serving as the baseline for validation and test plans. Use your requirements document as the basis for writing your test plan. This will also act as a check that your requirements are complete.
- Acting as a basis for future enhancement. Requirements will need updating but they provide a foundation for ongoing evaluation and improvement.
I Have a List, Now What?
Now that you have this awesome list of requirements, you need to start reviewing and adding information to each requirement. Each requirement is a row in the spreadsheet. Here are the columns:
Priority
You can rarely get everything you want; the reality is projects don't have infinite time and money. A typical way to prioritize is by thinking about each feature as “must-have” / “nice-to-have” / “future.” This framing really makes users think about what is the most important.
Included or Extra
If you are going out to bid through the RFP process, you might include something like:
- Out-of-the-box
- Configuration required (this is really a flavor of out of the box)
- Customization required (this costs extra)
Effort
This is really what it takes to deliver the feature. If you are building the solution, for any nice-to-haves or future items, you will want to capture expected effort to deliver generally (high, medium, low) or specifically (# of hours or days). Often this can help prioritize feature development. If you know something is very expensive (or not) that may influence its priority. Other ways to codify your requirements is to add a way to group them — by function or by user group (role or type of user) or you could capture both.
Here is an example of a Requirements document.
Make Requirements Work for You Throughout the Project Lifecycle
Another couple of parameters that can help, especially if you have expensive items — is to consider how many users (are impacted) and the frequency of use. If it’s a twice a year feature for two people, even if the manual effort is 2 days, that may be a reasonable trade off.
Tell us about your project.
Click for a free consultation
Up to this point, we’ve been focused on writing the initial requirements and while they represent the bulk of all requirements, there will be things that come up during the project development and/or implementation. Trust me they always do. You will need a way to manage these and more important the team’s expectations. If you are going with a vendor solution, then any additional requirements most likely will result in a change order and additional costs. You have a little more flexibility if you are developing the solution — there may be partial implementations that address most of the need.
Is this do-able?
As with most things, there is a balance to strive for in writing requirements. We have seen some go overboard with software documentation and it is possible to kill a good product by spending too much time specifying it. However, the bigger problem is in short cutting the requirements phase. By not taking the time up front to clearly specify function, you doom the project to an unsuccessful fate. The balance we seek is found in taking the time you need to document complicated requirements while not over-documenting well understood functions.
The bottom line is that well written requirements that are organized, qualified and prioritized can keep your project focused and on track to deliver what your users need.
Do you need help requirements? 2Plus2 can help you build the configuration you need. Call us on 510-652-7700 or arrange a consultation.