This question recently came up in an IIBA Business Analysis Body of Knowledge core team meeting. Everyone's first reaction was no, or of course not. It is an AS IS. I think that most people would say no because an "AS IS" is a currently implemented process or procedure. This brings up an interesting question: are requirements only things that have not been implemented? The definition of a requirement from the BA BOK is ". . . a condition or capability needed by a stakeholder to solve a problem or achieve an objective."
Just because a process or procedure has been successfully implemented (AS IS WORKFLOW), is it no longer a requirement? If the process was broken or was interrupted somehow would it then become a requirement again? And when we talk about requirements management, aren't we including the ongoing management of requirements after they have been implemented?
To me, all of these issues support the inclusion of AS IS WORKFLOW Diagrams and descriptions in our list of requirements.
11 Comments
I agree with you. I think the reason people say models are not requirements is that they consider requirements to be statements about what the solution system will accomplish. These text-based requirements are worded something like, "The system shall blah-blah." 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. A documented workflow or other model can live on after the project has been completed and has benefits beyond the project and its specific requirements. When we agree that requirements are limited to "to be" statements, we are saying that documenting/understanding the functionality of the business environment is not part of requirements. Before we can solve a problem or business need in a complex environment, we need to look at how the environment is currently operating. We need to remove the implementation specific criteria and describe or model the true requirements – the essential processes, the essential data, and the essential business rules for that business. The models we build are a key part of eliciting the true requirements and are normally delivered in the requirements document. A mixture of text and models gives the full picture of requirements and only then can we figure out how to design an appropriate solution to meet the true requirements.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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?