Post-Implementation User Assessment
Post-implementation user assessment is an evaluation of the effectiveness of the software after it has been thoroughly used in the business area. This is an important part of the testing life cycle but is often missed. The objective of post-implementation user assessment is to find out how well the solution meets user requirements. BAs, project managers, and/ or quality assurance analysts perform the assessment by observing users at their jobs or asking well-designed questions and conducting a follow-up session.
The real proof of whether a system fulfills the needs of the business area will only come as it is being used. This is the final validation. After training and a settling in period, BAs should discuss with users the usefulness of the system. BAs may also take measurements to determine if the system is performing as expected and to determine if the original objectives of the project were met.
Working with it Communicating with Developers
Some developers are not accustomed to receiving excellent requirements and as such don’t expect them. They may have been handed poorly written requirements in the past and don’t think that it is worth their time to read them. They may be accustomed to working without clear requirements and have experience iteratively developing and redeveloping them based on feedback. In some environments, this agile method of development works very well.
Work with the developers to encourage them to review requirements by walking through your requirements with them, helping them to see that they are getting useful information. If the developers aren’t accustomed to using or working from requirements, you may want to give them a small piece of a requirement, schedule a walkthrough over the phone or in person, and lead them through the document. You may want to present a use case or a subset of the data model. As you walk through the document, section by section, ask if they have questions or comments. As they begin to develop the software and come back to you with questions, point them back to the document if a question is one that you have already addressed. You want to get them in the habit of looking at the requirements package when they have questions. As they begin to see that you have already thought about things like exceptions and alternate paths, they will become more confident in your documents and more willing to read them.
Most developers are creative and enjoy offering suggestions. Whenever possible, ask developers for ideas within the limitations of the requirements. This is another reason why written requirements are so useful. If you give a developer clear guidelines within which he or she can be creative, you will often get a great design. When not given clear boundaries, a developer may create something that looks great but can’t be used because it doesn’t meet user needs. This can be discouraging for the developer. Be specific about the functionality that is needed and the business rules that must be adhered to.
Some developers will be interested in understanding why the business needs a particular function, while other developers will be satisfied just to build it. For developers who ask why, share business information. This will help them better understand the reason for their work and often make them more committed team members. For developers who aren’t interested in understanding the business reasons for a function, don’t give them too much information. Many developers are very “black and white”: “Do you want the source data field converted to a data field called lead source ? Yes or no?” Answer questions directly and concisely. (A three-paragraph dissertation on what a source is and how the business people use sources to generate more business is too much information for many developers.)
Communicating requirements is complicated by the use of outside and/or offshore developers. Utilize the best communication technology available and increase the formality and detail of your requirements for offsite team members.
