Who needs requirements!
George Haeger
IT leader | Commerce specialist with experience with B to x | Technical Sales Engineer | Public Speaker
After building Sitecore solutions for over a decade and asp/.net development for even longer, I have seen projects and clients look at requirements in many ways.? I have had the privilege to work with business analysts that get every element documented, listed how each element will work, what is a required field and what can be an optional field. On the other hand, I have seen other projects only give a high-level word document. The level of detail does more than you can imagine in saving your company money throughout the application's lifecycle. You will thank yourself after every sprint when you roll out a new feature in your application and it breezes through development, QA testing and is accepted as is.??
Are you still not sold on having to build out requirements?
Below is why it is important to document as much as you can before you go and build your shiny new feature or website.? Each of the people below will use the requirements to move your project along and ensure that you stay on time and better yet stay on budget. At the end of the day, we all want to produce good quality work that fits the requirements and keeps within the client’s budget.? Documenting everything you want in your application will ensure that you are not playing the telephone game with your company’s future.
Still don’t believe me, are you a person that feels that we only need to get the idea on paper, and we can explain to the teams the finer details? I think you are wrong, here is why.
These are high level benefits for each of the groups that will work on your application development projects.
Business analysts are the key to getting all the details documented and worked through. The more details we can document the more questions we can head off as the project goes on. The requirements document is not a one-time thing, we utilize the BA role to be the gatekeeper of what was discussed and if these requirements change, they will update them before development will start.? Documentation doesn’t have to be limited to a waterfall or an agile approach, just make sure that all work is started from these requirements and they are the single source of truth.
The business owner role is going to work closely with the BA team as we gather requirements. These sessions can be a few days or can span over a few months depending on how complicated the application needs are. The business owner must understand the business’ needs, in order to easily create the documentation that will be the road map. The project will go more smoothly if the business is collaborative and fully engaged from the start.? There is an understanding that we need full disclosure from our business partners to put all the details out for us to learn all the details of what we are building.
Now that we have the requirements defined, we can get down to the part of having our UX team layout how it will come together.? Some projects or companies will have your UX team handle the BA role, while this may work for smaller projects, having a true BA will get every detail defined and agreed upon is a better approach.? A good UX / UI team will make sure that your website is intuitive and easy to navigate. Design will also utilize the same information as the UX/UI teams.
Clearly defined requirements will help the PM team when we start to build out sprints. This will ensure there is no scope creep, and make sure that the project doesn’t derail.? Having a complete picture of what we are building with clear cut direction will make sure that we understand and complete the task as promised. With clear cut requirements we can layout a plan to build our application and make sure we hit our milestones.?
Starting out with a plan on what we are going to build will allow for clean concise code to be checked in from the start. The ability to divide the work into tangible buckets will make the code more readable and reusable.? Our teams can build the sections of the code as we need it but still have the plan for how to implement it, so the coding is seamless.? It is far more cost efficient to plan out the entire solution and build pieces then try to coble code together without a clear direction.? Since we have all the requirements and we have a clear understanding of what we are building, we can easily adopt Test Driven Development. TDD is a great way to build out your application, we have the test cases why not build cleaner, simple and bug free code.
领英推荐
QA engineers can quickly dive into writing test cases as soon as they have final requirements. This jump starts their effort, so they do not have to wait for delivered code. This allows us to have the QA team involved and trained in the early stages of the project so when the task is completed and delivered to the QA teams, they already understand it and have a plan to test it.???
This is not a mistake putting them in the list twice because at the end of the day they will need to sign off on what was built. Did we correctly capture the requirements, yes, we did because they signed off on it in step #2? So now it's up to our UX, developers and QA engineering teams to follow through and build out the functionality that was requested in the requirements.? At this point in the project, step # 7 should have us presenting polished code to the business owners for their final sign off.??
Future proofing your development needs.
Everything listed above is for your current working situation, but things change. What will you do if you lose your in-house developer or you split ways with your development partner? Are you going to be the one that goes and teaches them what is missing from the above requirements? Would it not be better if you had it fully documented and could just point the new person or partner to your OneNote or Confluence page where everything is laid out. I worked recently with a development partner that we were taking over for and they actually told me that there was no formal documentation that the “Code was the documentation”.? This is wrong in so many ways, now the developer is the only one that can go into the code base and see what is going on. That is assuming that the code is written in a readable way, not a spaghetti mess that it was.? The business owner can only go off what they remember when it was built and has no way to validate it unless someone goes in and looks at the code.?
This also brings up a shift in how you should look at requirements. Requirements are living breathing documents.? If you decide to add a new requirement to the additional code, you should be diligent in making the updates to the requirements document first. Requirements should not be changed to match the code, but code should reflect what the requirement is. Requirements are as important as the code itself. This can be added to your agile process to make sure you track these requirements changes in your sprint. Make sure to have one single source of truth.?
To all the business analysts, developers are very grateful for your partnership on these projects. The BA role is pivotal in making sure everyone agrees to what will be built, what gets built, and what is released to the world.
The above approach is ideal, yet it's unrealistic to assume that all projects will be run this way.? If you want to save yourself from a lot of headaches and re-work, it would be a good idea to adopt as much of this as you can.? Even though I strive to follow this methodology, more and more projects go down the path of having limited time and budget. Often the things that get cut are the things that would have made the project more successful.
?
About the author
George is the owner of a digital agency dedicated to helping clients maximize their digital investments. With experience as a client, customer, and former Sitecore specialist, George has a comprehensive understanding of software applications and their intended use. His background includes working closely with software development teams and witnessing many less-than-ideal implementations, which motivated him to establish this digital agency.
Our mission is to guide clients in implementing best practices and leveraging our extensive experience to optimize their digital investments. We have a proven track record of successfully setting up Sitecore personalization and achieving impactful results for our clients. We value building lasting relationships and look forward to the opportunity to discuss how we can support your goals.
Additional resources