One of the key Roles that a Requirements Analyst plays is defining and managing the scope of a project. Of all the tasks we perform, this is one that is
Questionnaires are a very useful tool for gathering requirements. We’ve written other blog posts about this before here. Questionnaires are usually associated with getting information from large groups of distributed users.
For the purpose of this discussion, let me define data defects in a software development process as defects caused when improper data setup manifests itself as “application errors.” I ran
As Requirements Analysts we use Models to paint a picture of the Application we are defining for the developers and eventually to derive the final requirements they will build to.
Change Requests or CR from Business Users after an application has been deployed are an integral part of the Development Process. No matter how much care and thought went into
I have been on teams that created requirements for replacing old “Green Screen” mainframe applications and have also observed the work of my colleagues on similar projects. The observations here
As someone who is part of the family of requirements professionals, it is always exciting to find a new source of writings on the subject that is near and dear
Prioritizing and identifying requirements that get developed in a release cycle can be a tricky proposition. It is one of the most important things we do as Product Managers. It
Performing traceability of delivered functionality to requirements without tying them back to Business Objectives is in my opinion an exercise in futility. To anyone engaged in this exercise, I ask
When gathering requirements there is a natural desire on part of both the requirements analyst and the subject matter expert to “just get on with it.” Both sides want to
Don’t miss out on this opportunity
and request a conversation today!
