I wrote this conference paper and created the associated presentation for a technical writing class. The paper explains my experienced observation that requirements analysts often must do more analysis of existing business processes and data models than actual requirements documentation.

1. BEYOND REQUIREMENTS 1
Beyond Requirements
Fran McKain
Kaplan University

2. BEYOND REQUIREMENTS 2
Abstract
On some software projects, the analyst may spend more time researching the impact of required
changes than actually documenting the requirements. Analysts often encounter this when dealing
with changes to existing systems. A senior requirements analyst shares a real-world experience
typical of modifying legacy systems. Given a single requirement, this analyst invested four
months researching the impact of the proposed change. Discover how analysts must cope with
lack of documentation, getting time with resident experts, and translating jargon while seeking to
understand current processes and systems.
Keywords: software, requirements, analysis, legacy systems, business process.

3. BEYOND REQUIREMENTS 3
Beyond Requirements
As a business systems analyst, have you ever been on a project where your work was not
valued, and you were treated as a mere note-taker? Have you ever been on a project where the
requirements you documented were ignored? Or how about this one: Do you recall seeing some
variation of the cartoon below and feeling a vague guilt about what you should do to help?
Figure 1 The famous “tire swing” cartoon
(Author unknown, n.d.).
If you answered yes to any of these questions, you are not alone. You may encounter
such situations due to problems beyond your control. But, just possibly, you may find that you
can contribute more effectively and change these scenarios. Business systems analysts will be far
more effective if they realize that on some projects their work is more about understanding the
current situation than about identifying and documenting requirements.

4. BEYOND REQUIREMENTS 4
Business Analysis on Various Types of Projects
In recent years, I worked on two different projects where the analysis phase took about
four months. Project A developed an all-new application, while Project B modified existing
legacy systems. I was fascinated at the huge difference in the number of requirements identified
during these two projects.
PROJECT A PROJECT B
4 months of analysis 4 months of analysis
329 requirements 4 requirements
A comparison of the tasks an analyst must perform on different types of projects help to
explain this large discrepancy. As the hypothetical ratios in the chart below illustrate, the “as is”
and “to be” work for each type of project vary dramatically.
Project A Project B
Figure 2 Comparison of analysis tasks by project type

5. BEYOND REQUIREMENTS 5
Analyzing the current situation requires a much greater percentage of the analyst’s time
on some types of projects than on others.
The All New Project
Project A provided my debut as a new analyst. This project involved developing a new
software application to support a new business function: that of enabling the managers across the
many company’s many divisions to share ideas with one another. Because the managers were
not formally sharing ideas at the time, the project had no existing business processes to consider.
Instead, everything this project created was new: the business processes, the requirements, the
design, the tests, and the code.
I was able to perform the requirements analysis tasks on this project just the way I had
been taught that I should. I clarified the business problem that we were to solve and the business
needs we must satisfy. I identified the features that the solution must have to satisfy those needs.
I created use cases to illustrate what the solution must do. I defined the detailed requirements. I
reviewed the business process design and the logical data model to confirm alignment with the
requirements. And I reviewed the test cases for compliance with the use cases and detailed
requirements.
This was a classic textbook project which develops a new system with new business
processes, new data models, and new requirements. Because everything is new, the project
focuses entirely on what is needed with no looking back at existing business processes, data
models, or system behavior. In the lingo of analysts, the project is focused entirely on the “to
be.” The authors of the book, Requirements Engineering, refer to this as working in the “solution
domain” (Hall, Jackson, & Dick, 2005, p. 109). In the “solution domain,” the project team
invents the solution.

6. BEYOND REQUIREMENTS 6
Although I did not know it back then, all-new projects like this are rare. Most IT projects
involve changing or replacing existing systems or processes, not building them from scratch.
This is caused not just by mergers and acquisitions, but by the need to keep technology current,
to optimize systems, and to repair issues, according to one IT manager (Bagnulo, 2009). Such
projects require spending more time considering the “problem domain” (Hall, Jackson, & Dick,
2005, p. 87). Because these projects involve changes to the current state, they must consider both
the “to be” and the “as is.”
Projects Involving Legacy Systems
The project that automates existing processes.
The first time a business process is automated, the analyst must consider the manual
version of the process when identifying the requirements to automate it. For example, when
building a system to automatically calculate price changes for a retail store, the analyst should
know that the manual process requires all price changes to be approved by the store manager.
The analyst should also recognize that state regulation prevents selling certain products at a price
less than a state-dictated amount. Understanding the existing process helps the analyst to clarify
what the new system must do.
The project that replaces legacy systems.
For a project that replaces an existing system, the analyst will encounter further demands.
Unless it is just a new version of the existing system, the new system is likely to be based upon a
different operating model and require different business processes. It may also require different
data, so the data model may be substantially different. This may mean that the analyst must
change the use cases and detailed requirements as well. To understand how much the new system
will change the current business environment, the analyst must thoroughly understand the

7. BEYOND REQUIREMENTS 7
existing business processes and systems. In fact, the analyst may spend nearly as much time
analyzing the current situation as identifying the requirements for the new system. Projects like
this are often massive efforts, and I have observed that analyzing the “as is” situation can take
months.
The project that modifies legacy systems.
The surprising case is the project that modifies existing systems rather than replacing
them. As requirements expert, Karl Wiegers puts it, “unexpected complications can lurk below
the surface of even minor change requests” (Wiegers, K. E., 2003, p. 344). Naturally, the impact
to existing business processes, data models, and requirements depends entirely on what the
change is. But sometimes, the time required to assess this impact can be out of proportion to the
size of the change.
Project B, which was illustrated in Figure 2, was this type of project. Understanding the
business need was simple: It was to modify the formula for calculating a particular business
metric. Understanding the impact of making this change was not simple. Why? The answer
involves two realities regarding legacy systems: 1) The requirements alone are not enough to
determine an acceptable solution to the business need, and 2) The complexities of these systems
and the processes surrounding them may not be well-understood or easy to figure out.
Requir ements ar e not enough.
Having never worked on a project like this before, I was fortunate that the senior architect
forewarned me that I must do more than identify requirements. More important than
documenting requirements, I must determine how this change would affect the existing systems
and processes.

8. BEYOND REQUIREMENTS 8
The systems affected by the change were very old, and no one was quite sure how they
worked from end to end. As a result of multiple mergers and acquisitions, these systems had
been integrated together over time. As one IT leader put it, this was “such a patchwork quilt of
software and interfaces that the integration is like blending ‘software shanty towns’ and is rarely
as quick or as simple as projections suggest” (Shearer, 2004).
The business team knew what the new formula for their business metric should be, and
they knew the data elements involved. But no single person could tell how those data elements
flowed through the series of systems or whether there were points at which manual processes
affected the data. No one knew exactly where in the process the new formula should be
calculated, or which downstream processes would be affected by the change, or whether those
affects were desirable. In fact, no one knew whether we might discover that the impact of the
change was unacceptable and might require a different strategy.
“As is” analysis is challenging.
So, I set out to perform this analysis. I did not know which systems were involved and I
had no idea what they were used for. I knew nothing about the business processes. To learn
about the systems, I asked the architects for system architecture documentation and I got an
architect to give me an overview. To learn about the business process, I asked the business
process designer for any existing business process documentation and had him explain them to
me. I also elicited the names of business users and IT support staff for the systems. With these
resources, I expected to be able, very quickly, to scope out the potentially impacted systems and
processes and to identify the points of impact. Instead, I very quickly became confused.
Challenges understanding the existing systems.

9. BEYOND REQUIREMENTS 9
The process and architecture documents did not align. While the business process
documentation did mention systems, as is customary, it used generic names for them. In fact, the
diagrams sometimes represented multiple systems as one. The business process designer could
not tell me which actual systems they represented so I could not align them to the systems shown
on the architecture diagrams. The architecture diagrams depicted more detail about the systems,
but called them different names and included no reference to the business processes surrounding
them. So this documentation did little to enlighten me.
I finally decided that I must create my own business process diagrams and label the
systems to match the architecture diagrams to clarify which systems were used for what. While
documenting these processes, I realized an additional problem: The existing business process
documentation did not have enough detail about how information moved through the process and
the systems for me to determine what would happen if we changed it. To fill the gaps, I sought
help from the business users and from the IT support staff. In doing so, I discovered yet another
issue: Both of these communities referred to these systems by still different names.
Sometimes the names were old titles that they had used for more than twenty years.
Sometimes the labels they used reflected the way they had come to refer to a system that had
been introduced during a past merger or acquisition. This jumble reminded me of an
archeological dig, unearthing one layer of history after another. Before I was finished, all the
names were documented in a glossary to provide a thorough cross-reference and eliminate some
confusion.
Challenges documenting “as is” business processes.
After I had identified all the systems that might be impacted by the proposed change I
could begin to assess that impact. Among all the different processes that these systems were used

10. BEYOND REQUIREMENTS 10
for, I asked the business users and IT support staff to help me to identify those that they thought
were most likely to be affected. I documented these processes in detail. While doing so, I
encountered some of the typical challenges that business process designers experience.
First, no one understood more than a small portion of any process. Many of the experts
had left the company after a recent acquisition, which seems to be a common fallout of mergers
and acquisitions according to one study (Katerattanakul, Kam, Lee, and Soongoo, 2009).
Usually, the remaining team members could tell me who to talk with to learn the next portion of
the process, but not always. One group told me they received their data from “Minnesota.” They
were referring to another team which was located in that state, but they were unable to clarify
further. Even when I did find the right people, often they could only give me a practitioner’s
view of their tasks. They could tell me which screens they used within the application and what
data they entered, but they could not give me the bigger picture about where their own tasks fit
into the whole stream of work.
The second challenge was getting enough detail. Because the business users were
explaining things that were very familiar to them, often they would leave out things that I needed
to know, without realizing that I was confused. Their own familiarity also caused them to use
jargon that I did not know and I struggled sometimes to get definitions that I understood.
Additional problems involved availability and resistance. Most of the business users had
more than a full-time commitment doing other work and had to fit me in around their other tasks.
And there were a few who had been doing things the same way for so long that they had a hard
time imagining why a change was needed. Some of them provided resistance about the project
With all these challenges, it was four months before I finally worked out a clear picture
of the existing system behavior and business processes. With that in place, the team could

11. BEYOND REQUIREMENTS 11
quickly identify where the formula change should be implemented and what business processes
must change to support it. Both business and IT had confidence that it was the right change and
that it would have the intended impact.
Benefits of “as is” Analysis
Since completing work on Project B, I have worked on several more similar projects
which required analysis of the “as is” situation. In each case, this analysis has provided the whole
team, business and IT, with confidence that we have identified the right solution. I am convinced
that “as is” analysis is one of the things that justifies the term “analyst” in the business systems
analyst title. I encourage analysts who are wondering whether they add enough value to their
projects to consider whether such analysis may be a missing piece in their work. Perhaps just
delivering the requirements is not enough.
Not all analysts are asked to do such analytical work. They may not even be allowed to
do it. But it’s worth asking permission and explaining the benefits. If they can’t make time to do
a thorough analysis, they may still be able to do a little and that little will be enlightening. In
some organizations, such analysis is performed by someone other than the analyst. In that case,
the analyst would do well to talk to that person and learn from their research.
The most obvious benefit of analyzing the “as is” situation is that the business and IT
teams can come to a shared agreement about what the solution must be. The old tire swing
cartoon can be redrawn to look like this:

12. BEYOND REQUIREMENTS 12
Figure 3 The "tire swing" project with a strong analyst involved.
Besides this very tangible benefit, the analyst will discover some valuable intangibles as
well. As a result of this research, the analyst gains an ever-increasing acumen about the business
domain and the systems involved. With such knowledge, the analyst will have clear insight and
make recommendations with confidence. Gradually, the analyst will gain a reputation as the “go
to” person for this combined, big picture understanding of the domain. And, happily, the team
will cease to view the analyst as a note-taker or as an ineffective member of the team, and
instead recognizes him or her as indispensable.

13. BEYOND REQUIREMENTS 13
References
Author unknown. (n.d.). Tree swing cartoon. Retrieved July 3, 2011 from
http://www.businessballs.com/treeswing.htm
Bagnulo, R. (2009). How technology will make or break banks integrating mission-critical
processes as a result of a merger. Journal of Securities Operations & Custody, 2(2), 106-
119. Retrieved from EBSCOhost.
Hull, E., Jackson, K., Dick, J. (2005). Requirements engineering. London: Springer Science &
Business Media.
Katerattanakul, P., Kam, H., Lee, J. J., & Soongoo, H. (2009). Migrating Legacy Systems in the
Global Merger & Acquisition Environment. Journal of Information Systems Education,
20(3), 281-288. Retrieved from EBSCOhost.
Shearer, B. (2004). Avoiding the IT Integration Blues. (cover story). Mergers & Acquisitions:
The Dealermaker's Journal, 39(11), 10-15. Retrieved from EBSCOhost.
Wiegers, K. E. (2003). Software requirements: Practical techniques for gathering and managing
requirements throughout the product development cycle. Redmond, WA: Microsoft
Corporation.