Module Two provided an introduction to project
management planning, managing, control, and reporting.
Moving into Module Three, students will perform the tasks
for system design. The bulk of the systems analyst’s
project work begins in system design.
Requirements Gathering
Requirements gathering is as much of an art as it is a
science. Requirements gathering is one of the biggest
challenges a systems analyst will face throughout a
project. In requirements gathering, the systems analyst
works with system users to determine what the users
want. As a project begins, the analyst would be assigned a
project with a request such as, “Develop a report to show
department sales growth.” Requirement gathering may
seem easy enough on the surface; however, great detail
emerges throughout the remainder of the requirements
process.
As an experienced systems analyst, one must schedule a
meeting with the user that requested the project. In the
discussion, the user claims, “…it is not a big deal, I just
want this report to see sales growth.” The systems analyst
needs to begin fact finding. Below are some sample
questions that the systems analyst will need to have
answered by the user:
• Will this be a daily report? Will it show growth day by
day? Month to date? Last 30 days? Rolling six
months? Year over year?
• Are all sales weighted the same for growth? Are there
differences in currencies such that we need to convert
all to U.S. dollars?
• Are there control data requirements for growth
measurements? Example 4% required growth? Will
departments be measured on different control
metrics?
• Is data collected “as of”: the end of day (EOD)? The
end of week (EOW)? The end of month (EOM)? What
are the time and time zone requirements for the end
of day?
• Who will use the report? Is it to be a pivot table? Pivot
chart? Other chart requirements?
• Where do the source data come from? Will all data be
used or do we need to cleanse data first?
• Do data require a snapshot in time on a daily basis?
Weekly basis? Monthly basis? Annual basis? Is
reconciliation required to ensure data accuracy?
• Will historical data change? For example, in February
growth was 3.7% based on 1M rows of transactional
data. In October, February growth is shown as 3.2%
due to retro changes of historical data values for 250K
rows due to a system defect that stored a wrong value
for sales line items.
The questions above are just a sampling of questions for a
very basic report request. Methodologies, such as Joint
Application Development (JAD), Rapid Application
Development (RAD), Agile, and Unified Modeling
Languages (UML), are very important to use in order to
work through the requirements. These methodologies
ensure that requirements are collected in a manner that
produces a complete final product.
Consider a much larger user system design with over 100
user screens and 500 database tables. Requirements
gathering can take months to complete for a system of this
size. In larger structured design projects, the requirements
are typically written as business flows and for each
process step of a business flow diagram. The process is
further broken down into smaller units of process flow
diagrams. The process flow diagrams are further
decomposed into written business function documents that
detail the function, including the business rules, the event
triggers that call it, the events it triggers, the key data
elements it sources, and the key data elements it modifies.
In a larger system, there may be hundreds of business
function documents.
To accomplish and manage so many intricacies, this type
of requirements gathering is done as iterations. A sample
iterative process may be: Iteration 1 Business Flow,
Iteration 2 Business Process Flow, Iteration 3 Business
Function Definition documents, and Iteration 4 Enterprise
System Flow.
There are different ways to conduct user meetings to exact
information. In iteration 1 and iteration 2 from the example
above, a large meeting with a large whiteboard and
multiple meeting scribes is a good setting. Bringing a large
group of users that span the different levels and areas of
the system is a proper audience. The meeting is led by
either the project manager or systems analyst. The
meeting lead stands at the whiteboard and starts flowing
diagrams. Users generate thoughts and information spills
out. The scribes are the note takers and will capture the
information.
Iteration 3 meetings are typically quite focused with the
knowledge experts in the user areas for the specific focus
topic. Documents and diagrams are provided to the invited
users prior to the meeting with the purpose being that the
users read and prepare with digging further into details
and exceptions to process definitions. In the meeting, the
systems analyst is the lead and scribes assist with note
taking. The meetings can be very challenging. As the
discussion can be an hour focusing on an entity such as
how to calculate a field based on user input. Iteration 3
meetings are the most challenging and trying meetings of
all in the process. Most users are tired of meeting at this
point in a project. Recall that users are still performing
day-to-day jobs, over and above the system requirement
gathering meetings. Patience wears thin at all points here,
but this is a task that simply must be done.
A systems analyst gains credibility with users and builds
the IT team confidence in the system solution through the
information collection process. The information collection
process is a very important step that a systems analyst
should not overlook.
