Establishing the Vision
One
of the most important aspects of designing a system is requirements
gathering. A company can have the most seasoned user experience
professionals, top-notch developers and exceptional testers that catch
every defect. But, will the customer be happy with a beautifully built,
flawless product that isn't what was needed? Probably not!
For over 8 years I've worked as a business systems analyst; typically hired as a consultant after a project has failed. And, in most cases, the projects that failed did so because incorrect assumptions were made. And, requirements were then written from a mixture of inaccurate assumptions and customer statements.
The only way to accurately identify customer requirements is to ask questions. Ask questions and let the customer state his/her vision for the implementation. Be sure to ask about business problems and needs that may have initiated the need for the project. You can manage this information by creating a list of business problems and/or needs. Ultimately, all requirements and problems/needs should be managed using a requirements management system such as RequisitePro.
For over 8 years I've worked as a business systems analyst; typically hired as a consultant after a project has failed. And, in most cases, the projects that failed did so because incorrect assumptions were made. And, requirements were then written from a mixture of inaccurate assumptions and customer statements.
The only way to accurately identify customer requirements is to ask questions. Ask questions and let the customer state his/her vision for the implementation. Be sure to ask about business problems and needs that may have initiated the need for the project. You can manage this information by creating a list of business problems and/or needs. Ultimately, all requirements and problems/needs should be managed using a requirements management system such as RequisitePro.
1.1 NEED: Need a dashboard that reflects current sales by region
1.2
PROBLEM: Currently, end users are not able to associate a customer
order with a region (data can only be associated with a city and state).
Should we have the system assign the region based on the city/state?
How can we fix this problem?
1.3 NEED: Need to be able to generate reports for segment marketing. We need to implement a business intelligence solution.
1.4 PROBLEM: All employees can add order records, when only Customer Support should be able to add order records. What’s the best way to address this problem?
1.3 NEED: Need to be able to generate reports for segment marketing. We need to implement a business intelligence solution.
1.4 PROBLEM: All employees can add order records, when only Customer Support should be able to add order records. What’s the best way to address this problem?
Notice,
with each problem the customer realizes that it’s a problem; but the
need that will be used to fix the problem has not been identified.
Ultimately, all problems should be translatable to a definite need that
everyone agrees on. Following is the updated Problems/Needs list with
the problems translated to a need. (Note that with requirements it is
good to keep all of the information in place and add notes as changes
are made. Then as questions arise as to where the requirement came from,
you have the historical data to refer to.)
Problem/Needs List UPDATED
1.1 NEED: Need a dashboard that reflects current sales by region
1.2 NEED: Add region data added to the database. Need to get the CD from the Post Office that includes city, states and zip codes. Verify that the region data is also included. If not our DBAs will need to add the region data. (Description for the need is: This need resolves 1.2 Problem: Currently, end users are not able to associate a customer order with a region (data can only be associated with a city and state). Should we have the system assign the region based on the city/state? How can we fix this problem?)
1.3 NEED: Need to be able to generate reports for segment marketing. We need to implement a business intelligence solution.
1.4 NEED: Need a Customer Support Role. This role should be the only role with the right to add a customer order. No other roles should be granted this right. . (Description for the need is: This need resolves 1.4 Problem: All employees can add order records, when only Customer Support should be able to add order records. What’s the best way to address this problem?)
1.2 NEED: Add region data added to the database. Need to get the CD from the Post Office that includes city, states and zip codes. Verify that the region data is also included. If not our DBAs will need to add the region data. (Description for the need is: This need resolves 1.2 Problem: Currently, end users are not able to associate a customer order with a region (data can only be associated with a city and state). Should we have the system assign the region based on the city/state? How can we fix this problem?)
1.3 NEED: Need to be able to generate reports for segment marketing. We need to implement a business intelligence solution.
1.4 NEED: Need a Customer Support Role. This role should be the only role with the right to add a customer order. No other roles should be granted this right. . (Description for the need is: This need resolves 1.4 Problem: All employees can add order records, when only Customer Support should be able to add order records. What’s the best way to address this problem?)
Once
the problems/needs list has been completed you will need to ask about
the Features the system is to support. Features are the highest level of
requirements. The features will ultimately be used to organize the use
cases.
Following is a list of features to provide an example of what a feature might look like:
1. Manage Customer Records
2. Interface with the XYZ Accounting System
3. Generate Business Intelligence Reports
4. Manage Sales Records
5. Manage Employee Records
6. Manage Customer Orders
Both
the Problems/Needs list and the Product Features are added to the
Vision document, which includes other information such as information
about the stakeholders (individuals who are directly impacted by the
success or failure of the projects). The Analyst should ask stakeholders
whether or not they have any type of success criteria. A success
criterion is a requirement that the system or project must meet for the
project to be viewed as a success. For example, a success criterion may
be that the system must be in place by a specific date. If this is the
case adding a priority to your features, use cases and functional
requirements become critical. When you have short timelines, you will
need to work with the stakeholders to prioritize the requirements.
Requirements marked with a “High” priority are implemented first. Then
the “Medium” priority requirements are implemented once all “High”
requirements have been successfully implemented. Lastly, your “Low”
priority requirements are implemented once the Medium priority
requirements have been implemented. The following table
shows an example of the High, Medium and Low priorities mapped to
features, use cases and functional requirements.
Features
|
Feature Ranking = High
|
Feature Ranking = Medium
|
Feature Ranking = Low
|
Use Cases
|
All Use Cases = High priority
|
Approximately %50 of use cases = High priority – ONLY IMPLEMENT THE USE CASES MARKED AS HIGH.
|
Less than %50 of use Cases = High priority– ONLY IMPLEMENT THE USE CASES MARKED AS HIGH
|
Functional Requirements
|
All functional requirements = High priority
|
Approximately %50 of functional requirements = High priority– ONLY IMPLEMENT THE FUNCTIONAL REQUIREMENTS MARKED AS HIGH
|
Less than %50 of functional requirements = High priority– ONLY IMPLEMENT THE FUNCTIONAL REQUIREMENTS MARKED AS HIGH
|
In
addition to adding information about the stakeholders, information
about the end users of the system is also included in the Vision
document. Other information included in the Vision document includes the
technical documentation and end-user training requirements as well as a
high-level list of other requirements such a performance. Once the
features have been identified, the use cases are defined and added to
the use case specification. Then the functional requirements are defined and added to the software requirements specification.
To accurately design a business solution from requirements; the analyst must take on the role of a detective. He or she must search for unknowns; and, turn mysteries into concrete statements for feedback. At times the analyst will have to draw conclusions from provided information; and, clearly state those conclusions for feedback. Thorough investigative work is what it takes to accurately define a business solution. But it also takes an understanding of the technology associated with the project.
It's also good practice to gain an understanding of any initial groundwork already laid for the project. For example, ask for a copy of the Statement of Work (SOW). Also, ask for existing system documents, system diagrams, and access to the current system, if applicable. And, in some cases, personal time may need to be used to read through the materials--if the deadlines are tight. But, it is worth it to put forth the effort to gain this insight prior to meeting with the customer. This allows requirements gathering sessions to be used to gather requirements.
Summary
Below is a list of tips you may find useful while meeting with customers to understand system requirements:
1. Ask for existing system or project documentation.
2. Be willing to use your personal time to learn concepts if deadlines are tight.
3. When meeting with the customer ask questions. And, make sure the stated business problems/needs are addressed.
4. Enter all requirements into a requirements management system.
5. Perform a gap analysis between the current system, the business problems/needs and the use cases and functional requirements. If a business need has not been translated into an actionable requirements be sure to translate it to either a use case or functional requirements—based on the need and how it is to be implemented.
6. Write questions that will help close the identified gaps. Then be sure to obtain complete answers to those questions.
7. Update the requirements as you receive answers to your questions.
8. Generate a trace matrix or report for customers to review.
