Over the years that I've spent practicing, studying, and quietly observing all things analysis across a handful of projects I've come to learn that following a few simple rules can help lead to a successful project. Let's take a look at the top five things that you should always do to make your job easier in the long run, keep your customer happy, and ultimately deliver a winning product:
1.) Maintain consistency in document design, and file storage structures. It's a very simple, but often overlooked practice that can mean the difference between avoiding last minute confusion and encountering some embarrassing heartache (Read: Exactly where is it in this document?!?).
Not only is document structure an important part of successful delivery, but file structure is important as well. Forget "where in this document is that feature" when you cant find the file easily. Clear folder structure brings you one step closer to leaving maintainable artifacts as you transition to your next role once the project wraps up.
So what good is consistency if your team isn't following your good example? Make sure everybody is on the same page with the template and file structure and you'll be headache free when it gets to crunch time.
2.) Capture who submitted the requirement. Ever find yourself in a scenario wondering "Who exactly asked for this in the first place?". Or how about being on the receiving end of the dreaded, "Who asked for this? I didn't!". Not only is not capturing who requested the feature important for the immediate development effort, but think downstream. Think big picture. We're not always going to be the analyst on this gig, so we need to make sure the next person down the line has all the information they need to be successful in maintaining this documentation. Don't leave them begging for some clarification with nobody to go to.
Need more incentive? Accountability. By adding an individual's name to the requirement, when approval time comes around that person is on the hook to defend their requested feature.
3.) Provide specific and testable requirements. How do you test the following requirement:
1. 'The system must be fast'
Testable requirements are paramount to the success of a project. In the example above, what defines fast? What's fast to me is not what's fast to the customer, which is not what's fast to you. Think specifics. Think, "The system must have an average response time of 100ms when submitting the new customer form and displaying the success message". Not only can specifics aide in testing, but these can also be used if the delivered products contents ever come in to question. How can you defend "fast" without knowing what fast is?
4.) Obtain proper sign off. Put a home or car project in mind and consider if you'd be willing to let the contractor or mechanic work on your property without your explicit sign off on the solution. Probably not going to happen in a million years, right? That's exactly how your customer feels about his or her project! Make sure that you're locking in the exact business need, the specific requirements to meet that need, and involve all contributing parties in the sign off process prior to delivering to the project stakeholders for review.
5.) Ensure that the customer knows how to maintain the project artifacts. So what do you do with all of this documentation once you've completed the project? First, and foremost you need to make sure your client knows where everything is. A requirement traceability matrix listing all related documentation will assist the client in knowing exactly which documents need to be updated when they begin researching what requirements need to change in order to implement that "next big thing". Stress to your customer the importance of ownership around these documents; keeping them up to date will help with providing better support of the product and will make for a much better relationship in the end!