I was leading a training session on SharePoint a few years ago, and while I was covering list templates, one of the participants in the class blurted out, “Oh! An Issues list? We should use that. We have issues!!!” Don’t we all? Still makes me smile when I think about it.
His comment reminds me of something that I see happen in a lot of SharePoint solution deployments, and that’s the technical aspects of the platform leading the business requirements discussions. One example of this is when a stakeholder sees a feature during a demo and makes it an absolute must-have requirement that every conversation starts to pivot on, and the solution will be a complete failure if you don’t include it. Obviously that happens a lot because the first thing people want to see when evaluating a platform/application/product is a live demo with all the bells and whistles, and there’s no question that new technology inspires us and gets the creative juices flowing, but it’s important to separate yourself from the technology to focus on the business requirements before you start to create the solution. Think about when you go to a grocery store, you are much more likely to have a successful shopping experience when you write shopping list before you walk in the front door. Same concept here, the requirements you gather are the “recipe” for the solution that you will design and deploy.
So what is a business requirement? And how does it differ from the other requirements that should be gathered as well? The following is an abbreviated excerpt from the Microsoft Office SharePoint Server 2007 Best Practices book by Ben Curry, Bill English and the Microsoft SharePoint Teams. This is the best explanation of each of the requirement categories that I’ve found, and I still refer to it all these years later:
Excerpt Below Taken from https://msdn.microsoft.com/en-us/library/dd184062.aspx
Business Requirements
A business requirement is a simple description of how the organization is to be improved or enhanced by the new technology solution. Sample business requirements include:
- Lower order-entry costs
- Speed up product time-to-market
- Improve communications with regional offices
- Improve order-to-ship times
- Expand into overseas markets
Functional Requirements
Functional requirements are measurable descriptions of the new features or functions that must be developed in order to meet the needs of the business requirements. For instance, the business requirement to lower order-entry costs could yield the following requirements:
- Reduce the number or order-entry screens from five to two
- Pre-populate key information, such as customer identification and address, automatically
- Change a form from fill-in-the-blank to pick-list data entry
- Provide better training to order-entry personnel to reduce the learning curve
Constraints or Nonfunctional Requirements
Projects are also bound by constraints or non-functional requirements. These are requirements that do not add functional value to the software being developed, but must be included in order to meet regulatory, cost, or quality requirements imposed on the organization as a whole. Examples of these constraints can include:
- Adherence to corporate document management policies
- Corporate security policies
- Requirements to integrate with other technologies
- Conformity with corporate, enterprise architecture standards
Testing Requirements
By definition, requirements must be objectively testable. Therefore, the testing requirements are written before the solution is designed or developed! This occurs to ensure that the requirements being handed to the technology stakeholders are valid before the development team begins working on a solution. Therefore, a test requirement must be written for each of the business, functional, and non-functional requirements that the technical team is being asked to develop.
Technical Specifications or Requirements
After the project stakeholders have all agreed on the validity of the requirements outlined previously, the technical team must determine how it will provide a solution that meets the test requirements."
One thing that you’ll notice is that the technical requirements come last, not first. This benefits the technical team because they are able to swap out different options and features depending on if they meet the requirements outlined by the solution stakeholders. It benefits the solution as a whole because the focus is placed on what the solution is doing to address the business need before anything else.
Some of the things I see happen often is that functional requirements are labeled as business requirements, and people start requesting capabilities without really diving into why they need that capability, or at least communicating it to the rest of the team so that they understand it as well. Or I see project teams pick the tool they’re going to use first (technical), test them (testing), check with the security and compliance team (non-functional), show the users how everything works (functional), and then present the final product to the project sponsors (business).
Will this produce a usable product? Maybe, every situation is different.
Having been part of these types of projects I would say it has a much greater chance of being an incredibly frustrating process that produces a product that doesn’t necessarily address the business needs.
When I get involved in a project, the customer has already decided that SharePoint is probably the direction that they're going to go. So being truly technology agnostic is a little bit of an exercise at that point, but it's a worthy one. Forget that you're using SharePoint. Think about what the solution would look like regardless of the technology that you're using, and then introduce the SharePoint feature-set into consideration.
Designing and developing a new solution for a recently defined business process is one of the most challenging tasks that I’ve come across in my time as a consultant. I completely understand that people can get overwhelmed by this prospect, they feel a combination of indefinite optimism and decision paralysis, which is a feeling that I am very familiar with. This is why I prefer structuring requirements this way because they I know exactly what needs to be addressed and I’m not overwhelming everyone, or myself, with a bunch of disjointed features. It allows me to produce a solution that is as complex as it needs to be to address the business requirements, and nothing more.
Or as a French writer once said:
“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery
Until next time!
Written and composed by our Practice Director, Collaboration and Content, Troy Brittain
