Comments on: Is an AS-IS Workflow Diagram a “Requirement?”

By: Dave M.

Dave M. — Thu, 12 Oct 2006 20:09:26 +0000

Requirements for a new system include all the functionality and data definitions of the (newly) required system. However, we often live in the system modification world where we are only adding or changing a subset of the system elements.
There are two areas of project activity that need the elicitation of the unchanged requirements. These are: Testing, where regression testing is performed to discover unwanted changes in the unchanged portion of the system, and Analysis, where we discover and resolve requirement conflicts. Life cycle management also needs to work from a base set of essential requirements as well. The key to managing requirements in a project, (a Business Analyst/Project Manager role) is to understand hwat is changing and what must remain unchanged. How would you do this if you did not know what are the already satisfied features?

By: Eddie B.

Eddie B. — Thu, 29 Jun 2006 22:58:24 +0000

The as-is model is simply a tool for clearly defining the current system capabilities. I believe in using the as-is model to elicit discussion and ensure that there is a clear understanding of the current system functionality with the client. The as-is model is not technically a client requirement. Without getting into the semantics game it does not detail any "new" requirements. It is assumed – unless explicitly stated otherwise – that the user doesn't want to lose the functionality they have today. It is simply a way of defining the current system model in order to effectively rewrite the system.

By: Bruce Anderson

Bruce Anderson — Fri, 26 May 2006 02:00:20 +0000

In my experience in facilitating the capture of required Business Processes I have found that the documenting or dicussing of AS-IS draws the Business representatives back to their comfort zone and does not encourage creative thinking or allow the introduction of new best practice benchmarks. Therefore would not use it to determine new processes.

Having stated the above I have found that defining the AS-IS process at a high level is invaluable to measure the gap to the To-BE processes. The gap I refer to is the change the organisation (Organisation Change Management) needs to undergo to support their new, hopefully more optimal, business processes. The gap analysis may highlight a need for a new knowledge or skill set for the organisation requiring either retraining or restructuring. So from an organisation change impact perspective it is useful but not necessarily to determine a new To-Be model. I would like to think many BAs would agree that the impact of any new processes on individuals supporting the new processes is often overlooked and adversly impacts the successful roll out of any new processes.

By: Tommy

Tommy — Thu, 25 May 2006 18:41:22 +0000

If the product manager (who is the primary business-side stakeholder) wants a screen (or screens) to look and function as a workflow in a specific way, then the screens/webpages are mocked-up/prototyped then documented as a requirement, which must be coded ‘as is’ by the engineer (i.e., technical-side stakeholder). In this scenario, the screen/webpage is WHAT the business is requiring, thus it is a requirement and belongs in the Requirements Specification artifact. HOW the screen/webpage is coded does not belong in a Requirements Specification artifact.

By: Paul Tayler

Paul Tayler — Wed, 24 May 2006 05:22:24 +0000

Of course the AS IS model shows requirements – it’s just that they are not NEW requirements. A Gap Analysis (comparison of the AS IS and the TO BE) identifies those requirements that are new, or in fact DIFFERENT. The key here is that there isn’t just an “as is” and a “new” – we have to consider the requirements that were previously met, but have now changed. Thinking about the AS IS as requirements helps identify that.

But for others that also claimed these are requirements, you aren’t expecting someone to build the AS IS – right? So these requirements only exist in the problem domain not the solution domain.

By: RBK

RBK — Tue, 16 May 2006 13:29:02 +0000

Some rather long-winded responses here. I will keep mine brief. When I started as a BA, I painstakingly documented the As-is. But in discussions with the developers who read and work off of my requirements, I found that they rarely read the As-is portion. Often they said, they did not want to know the as-is b/c it would taint their programming approach.

Now I usually do a rough As-is for my own understanding and to make sure the To-be captures all necessary functionality. But I keep it simple and don’t waste time with a lot of fancy formatting.

By: Bee

Bee — Tue, 16 May 2006 12:14:44 +0000

Well put Jason P. I also do not believe that as-is maps are requirements but believe strongly that they are one of the many tools we use to elicit requirements that may not come out clearly in one-on-one interviews or JAD sessions. There are nuggests of gold in the as-is model that lead to further investigation. Just because it’s done that way today does not mean it should be or that it is being done in a consistant manner by all or that it is being done as intended.

By: Jason P

Jason P — Mon, 15 May 2006 17:48:53 +0000

An AS-IS model is not a requirement. I know I may be preaching to the choir here but, let's go off the assumption that an AS-IS model is a representation of the current process. 1.) What are we trying to accomplish? (High level business requirements, scope and objective, tell me what YOU THINK I shouldn't look at. Put up a small fence, keep it small because I'm going to be looking over.) 2.) What are we currently doing? (Discover the current process, environment, or whatever makes sense given the situation.) 3.) What do you want to do? (TO-BE. Not requirements but this is what everyone expects the system to do. This is how the stakeholders will measure whether or not you met their requirements.) 4.) How are we going to get there? (The delta between the AS-IS and the TO-BE. Add this to any existing user requirements… leading into and RFP for a buy or functional/non-functional requirements for a build.) 1, 2 and 3 obviously lie within the minds of all stakeholders as well as within the problem domain, the business environment. As BSA's we need to discover this information either by happenstance (the Forrest Gump method – not recommended) or through structured techniques. I see #1 as very high level information for a project charter (Enterprise Analysis). #2 is where the AS-IS lives. This is requirements modeling. A model is not a requirement. The AS-IS model's purpose is to assist in the discovery of user requirements; it is not a set of requirements in and of itself. A model is used to create a visual representation of a concept. It is something tangible that a user can look at and, ideally, it will give them a different perspective of something familiar, like their day-to-day tasks. But it is not a requirement. If I was asked by someone to remodel their existing home and I created a model of that home I could envision the client and me looking over this model and the client saying, "Yes, here is the wall I was talking about, it needs to be removed so I can open this space up." Now, where is the "potential" requirement here, in the static model that I spent hours creating or in the information that was provided to me by my client after looking at the model? The latter, of course. Now I can follow up on the nugget he/she provided and get to the requirements. So I say that the AS-IS or current process is a requirements modeling technique. A requirements model is a tool used for the discovery of requirements.

By: Laura

Laura — Mon, 15 May 2006 14:44:28 +0000

Boy, has this been a hot topic at work! I agree that it is crucial to understand how the current system operates, however, I also believe it is very important to differentiate between what the system is and what the users require of the system going forward. To document an existing system and define it as a "requirement" similar to your "to be" requirements, muddies the waters. What if the way the system was designed was never a user request, but a design flaw? What if you accidentally documented the "as is" system incorrectly? Which is correct–your "requirement" or the actual system? It is my opinion that you somehow have to understand and document the existing system, but label them as something other than a "requirement."

By: Yogi

Yogi — Fri, 12 May 2006 22:45:42 +0000

I agree with Requirements are often considered to be temporary, to last until they get fulfilled, very much like projects which are also temporary endeavors until they are completed. And here AS-IS / COTS paly a very important Role.

Yogi.