Beyond requirements


Published on

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.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Beyond requirements

  1. 1. BEYOND REQUIREMENTS 1 Beyond Requirements Fran McKain Kaplan University
  2. 2. BEYOND REQUIREMENTS 2 AbstractOn some software projects, the analyst may spend more time researching the impact of requiredchanges than actually documenting the requirements. Analysts often encounter this when dealingwith changes to existing systems. A senior requirements analyst shares a real-world experiencetypical of modifying legacy systems. Given a single requirement, this analyst invested fourmonths researching the impact of the proposed change. Discover how analysts must cope withlack of documentation, getting time with resident experts, and translating jargon while seeking tounderstand current processes and systems. Keywords: software, requirements, analysis, legacy systems, business process.
  3. 3. BEYOND REQUIREMENTS 3 Beyond Requirements As a business systems analyst, have you ever been on a project where your work was notvalued, and you were treated as a mere note-taker? Have you ever been on a project where therequirements you documented were ignored? Or how about this one: Do you recall seeing somevariation 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 encountersuch situations due to problems beyond your control. But, just possibly, you may find that youcan contribute more effectively and change these scenarios. Business systems analysts will be farmore effective if they realize that on some projects their work is more about understanding thecurrent situation than about identifying and documenting requirements.
  4. 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 aboutfour months. Project A developed an all-new application, while Project B modified existinglegacy systems. I was fascinated at the huge difference in the number of requirements identifiedduring 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 toexplain 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. 5. BEYOND REQUIREMENTS 5 Analyzing the current situation requires a much greater percentage of the analyst’s timeon 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 newsoftware application to support a new business function: that of enabling the managers across themany company’s many divisions to share ideas with one another. Because the managers werenot 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, thedesign, the tests, and the code. I was able to perform the requirements analysis tasks on this project just the way I hadbeen taught that I should. I clarified the business problem that we were to solve and the businessneeds 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. Ireviewed the business process design and the logical data model to confirm alignment with therequirements. And I reviewed the test cases for compliance with the use cases and detailedrequirements. This was a classic textbook project which develops a new system with new businessprocesses, new data models, and new requirements. Because everything is new, the projectfocuses entirely on what is needed with no looking back at existing business processes, datamodels, or system behavior. In the lingo of analysts, the project is focused entirely on the “tobe.” The authors of the book, Requirements Engineering, refer to this as working in the “solutiondomain” (Hall, Jackson, & Dick, 2005, p. 109). In the “solution domain,” the project teaminvents the solution.
  6. 6. BEYOND REQUIREMENTS 6 Although I did not know it back then, all-new projects like this are rare. Most IT projectsinvolve 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). Suchprojects 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 boththe “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 manualversion of the process when identifying the requirements to automate it. For example, whenbuilding a system to automatically calculate price changes for a retail store, the analyst shouldknow 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 priceless than a state-dictated amount. Understanding the existing process helps the analyst to clarifywhat 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 adifferent operating model and require different business processes. It may also require differentdata, so the data model may be substantially different. This may mean that the analyst mustchange the use cases and detailed requirements as well. To understand how much the new systemwill change the current business environment, the analyst must thoroughly understand the
  7. 7. BEYOND REQUIREMENTS 7existing business processes and systems. In fact, the analyst may spend nearly as much timeanalyzing the current situation as identifying the requirements for the new system. Projects likethis are often massive efforts, and I have observed that analyzing the “as is” situation can takemonths. The project that modifies legacy systems. The surprising case is the project that modifies existing systems rather than replacingthem. As requirements expert, Karl Wiegers puts it, “unexpected complications can lurk belowthe surface of even minor change requests” (Wiegers, K. E., 2003, p. 344). Naturally, the impactto existing business processes, data models, and requirements depends entirely on what thechange is. But sometimes, the time required to assess this impact can be out of proportion to thesize of the change. Project B, which was illustrated in Figure 2, was this type of project. Understanding thebusiness need was simple: It was to modify the formula for calculating a particular businessmetric. Understanding the impact of making this change was not simple. Why? The answerinvolves two realities regarding legacy systems: 1) The requirements alone are not enough todetermine an acceptable solution to the business need, and 2) The complexities of these systemsand 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 architectforewarned me that I must do more than identify requirements. More important thandocumenting requirements, I must determine how this change would affect the existing systemsand processes.
  8. 8. BEYOND REQUIREMENTS 8 The systems affected by the change were very old, and no one was quite sure how theyworked from end to end. As a result of multiple mergers and acquisitions, these systems hadbeen integrated together over time. As one IT leader put it, this was “such a patchwork quilt ofsoftware and interfaces that the integration is like blending ‘software shanty towns’ and is rarelyas quick or as simple as projections suggest” (Shearer, 2004). The business team knew what the new formula for their business metric should be, andthey knew the data elements involved. But no single person could tell how those data elementsflowed through the series of systems or whether there were points at which manual processesaffected the data. No one knew exactly where in the process the new formula should becalculated, or which downstream processes would be affected by the change, or whether thoseaffects were desirable. In fact, no one knew whether we might discover that the impact of thechange 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 Ihad no idea what they were used for. I knew nothing about the business processes. To learnabout the systems, I asked the architects for system architecture documentation and I got anarchitect to give me an overview. To learn about the business process, I asked the businessprocess designer for any existing business process documentation and had him explain them tome. I also elicited the names of business users and IT support staff for the systems. With theseresources, I expected to be able, very quickly, to scope out the potentially impacted systems andprocesses and to identify the points of impact. Instead, I very quickly became confused. Challenges understanding the existing systems.
  9. 9. BEYOND REQUIREMENTS 9 The process and architecture documents did not align. While the business processdocumentation did mention systems, as is customary, it used generic names for them. In fact, thediagrams sometimes represented multiple systems as one. The business process designer couldnot tell me which actual systems they represented so I could not align them to the systems shownon 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 surroundingthem. So this documentation did little to enlighten me. I finally decided that I must create my own business process diagrams and label thesystems to match the architecture diagrams to clarify which systems were used for what. Whiledocumenting these processes, I realized an additional problem: The existing business processdocumentation did not have enough detail about how information moved through the process andthe systems for me to determine what would happen if we changed it. To fill the gaps, I soughthelp from the business users and from the IT support staff. In doing so, I discovered yet anotherissue: 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 hadbeen introduced during a past merger or acquisition. This jumble reminded me of anarcheological dig, unearthing one layer of history after another. Before I was finished, all thenames were documented in a glossary to provide a thorough cross-reference and eliminate someconfusion. Challenges documenting “as is” business processes. After I had identified all the systems that might be impacted by the proposed change Icould begin to assess that impact. Among all the different processes that these systems were used
  10. 10. BEYOND REQUIREMENTS 10for, I asked the business users and IT support staff to help me to identify those that they thoughtwere most likely to be affected. I documented these processes in detail. While doing so, Iencountered 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 expertshad left the company after a recent acquisition, which seems to be a common fallout of mergersand 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 ofthe process, but not always. One group told me they received their data from “Minnesota.” Theywere referring to another team which was located in that state, but they were unable to clarifyfurther. Even when I did find the right people, often they could only give me a practitioner’sview of their tasks. They could tell me which screens they used within the application and whatdata they entered, but they could not give me the bigger picture about where their own tasks fitinto the whole stream of work. The second challenge was getting enough detail. Because the business users wereexplaining things that were very familiar to them, often they would leave out things that I neededto know, without realizing that I was confused. Their own familiarity also caused them to usejargon 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 hadmore 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 hardtime 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 pictureof the existing system behavior and business processes. With that in place, the team could
  11. 11. BEYOND REQUIREMENTS 11quickly identify where the formula change should be implemented and what business processesmust change to support it. Both business and IT had confidence that it was the right change andthat it would have the intended impact. Benefits of “as is” Analysis Since completing work on Project B, I have worked on several more similar projectswhich required analysis of the “as is” situation. In each case, this analysis has provided the wholeteam, business and IT, with confidence that we have identified the right solution. I am convincedthat “as is” analysis is one of the things that justifies the term “analyst” in the business systemsanalyst title. I encourage analysts who are wondering whether they add enough value to theirprojects to consider whether such analysis may be a missing piece in their work. Perhaps justdelivering the requirements is not enough. Not all analysts are asked to do such analytical work. They may not even be allowed todo it. But it’s worth asking permission and explaining the benefits. If they can’t make time to doa thorough analysis, they may still be able to do a little and that little will be enlightening. Insome 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 ITteams can come to a shared agreement about what the solution must be. The old tire swingcartoon can be redrawn to look like this:
  12. 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 aswell. As a result of this research, the analyst gains an ever-increasing acumen about the businessdomain and the systems involved. With such knowledge, the analyst will have clear insight andmake recommendations with confidence. Gradually, the analyst will gain a reputation as the “goto” person for this combined, big picture understanding of the domain. And, happily, the teamwill cease to view the analyst as a note-taker or as an ineffective member of the team, andinstead recognizes him or her as indispensable.
  13. 13. BEYOND REQUIREMENTS 13 ReferencesAuthor unknown. (n.d.). Tree swing cartoon. Retrieved July 3, 2011 from, 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 Dealermakers 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.