Modeling requirements, on the surface, to many of our stakeholders often seem easy or simple, but they are actually quite complex and can take a long time to master. This “complexity” is driven by many things including; different types of modeling (process, data, use case, interface, and scope modeling) size of project, methodology, approach, stakeholder preferences, and time to model. As a result, I often see Business Analysts frequently needing to repair, reconstruct, or renovate their requirements models which is not always a good thing nor does it always make sense. One of these works for me and the other two do not.

Renovation – it works. When I think of renovation, I often think of process improvement efforts. Continuous improvements. To reinvigorate something, make new, revive. It is about keeping value, being future focused. This concept for any business makes sense to me. This type of remodeling works because it is often driven by ideation, some kind of Enterprise Analysis, Six Sigma, Lean, or other approach. It, perhaps, can even be seen as an attitude or force that drives how you work, but it is different than repairs or reconstructions, which do not work for me.

Repairs and reconstruction – do not work. Why do we have to repair or reconstruct our requirements models? When I think of repairing or completely reconstructing requirements models, I think of rework. I do not like to work much as it is, so the idea of doing it again is not exciting to me. A classic example is the process flow diagram. Let’s run through a scenario:

1. Business Analyst schedules meeting with stakeholders to discuss process.
2. BA interviews stakeholders during meeting.
3. BA takes notes and goes back to cube to work on process flow.
4. BA schedules new meeting for review.
5. BA reviews process flow with stakeholders at meeting.
6. Stakeholders rip the process flow to shreds.
7. Go to step 3.

And there you have it. A potential infinite loop of rework! And this loop is costing a lot of time and money. Time you probably did not have to begin with. So we need to ask some questions. Did you understand your stakeholder’s point of view? Did you have the correct stakeholders? What approach to your model did you take? The approach is very important. It drives how and when you model. Is there a different way of doing this? How about this as an alternative:

1. Business Analyst schedules interactive process modeling meeting with stakeholders to discuss process.
2. BA facilitates stakeholders during meeting to “interactively” develop the process model together as a team during the meeting using white board, post-its, or other preferred materials.
3. BA gains agreement/consensus on the process model at the meeting.
4. BA takes picture of agreed upon process flow with smart phone and goes back to cube to create a final version in the company’s diagramming tool of choice.

Less steps, less rework = less cost and less chance of needing repairs! If you do your stakeholder analysis up front you can get the right people. The stakeholders, together as a group, will provide their viewpoints during the meeting. The approach requires less time. Remember, for this approach to work, the BA must be a strong facilitator (a theme in the BABOK®).

So with regard to repair and reconstructing requirements, I am not a big fan. An anonymous salesman once said, “Genius is the ability to evade work by doing something right the first time.” What you are really doing is evading the rework. I cannot agree more. Renovation will be needed some year in the future, but if we can avoid the repair and reconstruction on our current projects our work lives will be more enjoyable. Modeling is complex, but if we can do something proactively to limit repairs and reconstruction, well, that is where the true value of your requirements “home” will be kept up and you will not have to wait for the market to rebound.

The Big Remodel was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Of course, there is no “right” a lot of the time.  In my classes, for example, I instruct and inform, but I also facilitate discussions about the options, and the students decide what’s going to work for them.

This brings me to the recent Facilitation Skills Workshop class I taught.  In this class, we learn about different facilitation techniques and then the students do the work; they actually facilitate each of the 12 sessions throughout the class.

Maybe you are like many of the students in this class who are terrified of speaking in front of groups. Their hands shake, they sweat, and some have a hard time breathing.  This fear is not unlike other fears and there is often a visceral response.

It is amazing to watch those folks who are terrified of facilitating get up in front of a group and, with some preparation, tools, and guidance, actually help the group accomplish a goal.  It is enormously validating- for them, the participants, and me.

The last session of the 12 sessions is one in which the facilitator brings the class to consensus on the top 5 characteristics of a good facilitator.  My last class came up with the following Top 5 Characteristics of a Good Facilitator:

1.     Neutrality
The facilitator cares that the group achieves their goal in the session, but they don’t care what the results look like specifically.   

2.   Preparedness
A facilitator needs to be prepared for their session. Facilitation might look easy, but it is hard work. Taking time to understand the group and issues, as well as practice the skills and techniques to be used make for a far more effective facilitator and one who will be much more likely to help the group achieve its goals.

3.   Energetic
A facilitator needs to be neutral, but that doesn’t mean they should be comatose.  Bringing some energy to the session helps keep people focused and engaged. 

4.   Clear idea of Purpose/Agenda
A good facilitator needs to start with a clear understanding of the goal of the session and the tools they might use to achieve that goal.  In short, be flexible, but have a plan. 

5.   Positive
An effective facilitator makes the participants want to achieve the session objective.  Even if it’s addressing a problem, a positive tone will encourage participants to own their part of the outcome.

It wasn’t necessarily the list I would have come up with, although those are certainly things we talk about in the class.  As I sat in the back of the room watching them come to this conclusion together as a group, facilitated by one of the students, it was an interesting and, in some way, teachable moment.  For me.

Facilitation Top 5 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

The close of one year tends to make one reflect on what has occurred in the past year and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.

1. Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:

• Business analysis is maturing as a profession. As the IIBA has gained traction, more organizations have become aware of the BA role and its importance. From 2010 to 2011 the number of IIBA members increased about 50%.
• Organizations have found that even with successful project management, many projects fail because of dissatisfaction with the end product. Having business analysts helps ensure that the product is a solution that works and is one the organization needs.
• PMI has recognized the importance of the business analyst role. In 2010 they undertook a study to determine areas of overlap, handoffs, and how the two roles could collaborate.

2. Combined Agile methods. We predict that Agile methods will continue to change and merge as organizations take advantage of the benefits of Agile. In our 2009 Trends blog we stated that “Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue.”

 In the two years since we wrote that article, Agile methods have continued to evolve. Although organizations have widely adopted Scrum as the predominant Agile method, they still struggle with its implementation. We think that organizations will continue to adopt Agile methods, but that these methods will continue to evolve. Combined techniques, such as Scrum-ban (which combines Scrum with the Lean technique Kanban) or Scrumerfall (a combination of Scrum and Waterfall) will be adopted for different kinds of projects.

 3. PM and BA on Agile projects. We predict that the role of the BA and PM on Agile projects will solidify. When Agile started to be adopted, some organizations thought that the roles of PM and BA were obsolete. However, more and more organizations have recognized that the need for both roles, even if the titles are new. The Scrum Master role is best filled by someone with the expertise to coordinate the initiating, planning, executing, monitoring, & controlling, and closing each iteration and release. In other words, the work typically done by a PM. The designations of Certified Scrum Master (CSM) from the Scrum Alliance and Agile Certified Professional (ACP) from PMI have solidified this role.

 The role of the BA on an Agile project has not solidified. BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Going against most of the current thinking, we predict that organizations will realize in the next few years that business analysis is essential to Agile projects. Agile projects still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the needed functionality. Organizations will realize that this in-depth analysis cannot be completed during an iteration, that it has to happen just prior to development. This is called grooming the product backlog and is the perfect role for the business analyst.

 4. The BA as management consultant. We predict that in 2012 BAs will actually function as described in the BABOK® Guide, version 2.0. That is, more BAs will “recommend solutions that help the organization achieve its goals.” They will do that in a variety of ways:

• Business cases. More organizations will recognize that the BA is in the best position to develop business cases. Although often performed by PMs, this function happens prior to the initiation of a project and is input to project initiation (PMBOK® Guide – Fourth Edition). The PMBOK recognizes that the performing organization (business owner) is accountable for the business case, but it is the BA who is in the best position of developing it.
• Ability to Influence without Authority. We are seeing more organizations tell us that they want their BAs to move away from taking customer orders and start using their expertise to recommend solutions. This need correlates to the enthusiasm we have seen around the need to influence without authority.
• In her keynote at the BBC conference in Ft. Lauderdale last year, Kathleen Barrett, CEO of IIBA mentioned that one of the key competencies of the enterprise BA is management consulting.

5. BAs as change agents.We think that BAs will be more involved in change management. At the BBC conference in Ft. Lauderdale last year Kathleen Barret announced a new tag line for IIBA—that business analysis was about changing how organizations change. In other words, BAs will be more involved in change management. Changes might include changes in business processes, job descriptions, reporting structures, software, and more. Here are some of the ways we see this happening:

• Enterprise analysis. Before projects are initiated, BAs determine the business need across the enterprise and recommend solutions, which need to include the ways in which organizations will need to change when these solutions are implemented.
• Project work. While the identified at the enterprise level are by necessity high-level, the changes resulting from each project will be specific in nature. We predict that BAs will develop better tools for assessing whether or not the organization is ready for the change. We think that they will act as management consultants once the project has been defined to ease the pain associated with implementing the changes associated as with implementing the solution.
• Post-project follow-up.We believe that BAs will be called on to monitor the post-implementation changes and continue to consult with the organization on the best way to make the solution work, even when there is some organizational resistance to it.

 6. The virtual environment.Now that it is here, the virtual environment will continue to flourish, even if the economy improves. There are a variety of reasons why organizations will continue to rely on the virtual environment for completing projects, for training, and for webinars to replace live conferences.

• Travel budgets.Spurred by a sluggish world economy, many organizations have reduced travel budgets for team meetings, training, and international conferences, relying instead on the virtual environment. Although colocation of teams is ideal and preferred, it is not always possible. More teams communicate and collaborate virtually, more virtual training will occur, and more webinars will take the place of live conferences.
• Globalization has made travel impractical. Although face-to-face time, particularly during project initiation, is helpful in building trust, respect, and relationships, it is not possible to be together for all project meetings and/or requirements elicitation interviews and workshops when the team is located across the county or world.
• Collaboration toolshave made the virtual environment not only possible, but practical. Net meetings, as well as more robust training and webinar tools have supported virtual teams, so that real work can be accomplished. In addition, teams have learned how to build relationships and trust in the virtual environment. Building relationships and trust in a virtual environment is easier and quicker once people accept and feel comfortable with the virtual tools available.

 7.  “The economy, stupid,” a past political slogan said. During a slumping economy, organizations look of ways to maximize efficiencies. Focus turns to business processes and how to improve and manage them. During more prosperous times, interest in business process management tends to wane. We predict that business process management, with an emphasis on eliminating waste in organizations, will continue throughout 2012, even as the economy (hopefully) shows signs of improvement. We also predict that there will be no dominant tools for managing processes and recommend that project professionals doing business process work focus on core concepts and skills and be flexible when it comes to using BPM tools.

7 Trends in Business Analysis and Project Management to Watch for in 2012 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

In any interview process, the key to being successful is to be prepared. However, we often get caught up with the one thousand and one things we have going on and we do not prepare as well as we should or (cringe!) we even wing it. Besides preparing a list of questions, one of the things that I do when I go into an interview is to have my checklist that helps drive my process. I used to struggle with being prepared until I related my experience with that of the hostage negotiator. Guess what? They have to be very prepared and they have a checklist too. Let’s see what their checklist looks like and then translate into BA speak to see if we can be more successful!

The hostage negotiator arrives on the scene and goes through their checklist (Credit to “howstuffworks.com” and “Ed Grabianowski” for the hostage negotiation checklist steps):

All questions “Q” are from the Hostage Negotiator. All answers “A” are from the Business Analyst and how you might respond.

Q What has occurred?
A As a BA you need to know all about what has occurred and what has not. Make sure you dive deep and understand the reasons for the project, the issue and/or the reason for why you are interviewing. There is a reason that your interviewee is holding requirements hostage and being difficult. Get a good layout of the situation so that you can approach it from a stable point of view. A perceived unbalanced approach could enflame the situation more. You must understand the context of the problem you are trying to solve.

Q Who initiated the call?
A Stakeholder analysis – it is NOT just for PMs! Determine who is driving the project you are on and why. The sponsor is your friend and should be your biggest supporter. Know what they want and why. Do they have a relationship with your difficult stakeholder? They might be able to help.

Q Time of occurrence?
A Does time really matter? Absolutely. Why was this project pursued at this time? What are the impacts of doing this project now vs. later? When does it really need to be completed? How does the timeframe impact your difficult stakeholder? It will certainly impact the questions you might ask during your interview.

Q What is the nature of the surrounding scene?
A Do you understand the political landscape of your environment and how it impacts the project you are working on? What about how it impacts your difficult stakeholder?

Q Police injuries? Suspect injuries? Hostage injuries? Other injuries?
A What relationships have been damaged in this “hostage” crisis? Have people, processes, data or systems been impacted, cutoff or disallowed as a result of this requirements hostage crisis? Will there be future injuries?

Q What kind of contact has been made with the suspect? When?
A What contact have you made with your interviewee? Did you just email them and set up a meeting? How well do you know this person? Did you reach out to them as soon as you knew they were involved? After the kickoff? Not at all yet? How you answer this question may give you insight as to why they are being difficult.

Q Is the situation locked in?
A Rarely have I come across a situation that is truly locked in. You may feel that it is locked in but as you explore what it means to be a good Business Negotiator (or Hostage Analyst) you will find that you can affect the outcome in a positive fashion. Remember, your difficult stakeholder wants something and there is always hope of influencing them.

Q Where are the suspects located?
A Know the dynamics of team and business. Geographically dispersed? Teleconferences not working? You may need to travel to more effectively to deal with the situation.

Q Where are the hostages located?
A More than likely the requirements being held hostage are locked up in the stakeholder’s mind and are not documented anywhere. However, do not assume that this is totally true as you may have access to materials that you assumed did not exist. Ask – you just never know. Maybe they are being difficult because they expect you to do all the work of pouring through volume after volume of mind numbing facts.

Q Where are the non-hostages?
A What is the state of other requirements elicitation and documentation? Is there a bigger problem here or is it just the one person? Make sure you know what you have and what you do not. Maybe there is another crisis just around the corner.

Q Where are the suspect’s observation points?
A What powerbase does your stakeholder have? Will they only operate from their home-base (their cube/office, their floor, favorite conference room, working from home)? What are they doing when no one is talking to them? Do they only have rules for you?

Q What firearms, explosives, and chemicals could be used/located on the site?
A What could your stakeholder do to sabotage your efforts if their needs are not met? What tactics will they employ? Do they have access and power to do so?

Q What is the description/profile of the hostage taker?
A Key stakeholder analysis. Do you truly understand your stakeholder? WIIFM – what’s in it for me? Do you know what’s in it for them? Is their effort to hold these requirements hostage unintentional or a directed effort to prevent things from moving forward? Are they in favor (accepting) of what you are doing?

Q What is the offender affiliation/public support like?
A Do you know who they influence and who influences them? Do they have support or are they left on their own? If a decision is not made in their favor will it affect you?

Goodness, there is a lot to think about in interviewing difficult stakeholders and this was all from the eyes of a hostage negotiator! And this was just the prep piece – there is also the techniques of the hostage negotiator and more that we can be inspired by and innovate. I realized early on that preparing was difficult and it took a lot of work. I also learned that when I looked at things a little differently I could introduce something new into my process which is an act of innovation. The result? My innovation = better preparedness = more “hostages” (requirements) released = requirements trash turned into stakeholder treasure!

Turning Requirements Trash into Stakeholder Treasure – Part 2 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

So what would make a requirement illicit? Let’s explore this short list of illicit requirements.

1. Requirements that are not in scope. It is very important when conducting our elicitation that we guard against scope creep (BABOK® section 3.2.4). Tracing requirements back to the business goals and objectives will help us validate whether the requirement(s) should be included or not. If we are eliciting and documenting requirements that are not in scope they are by their very nature illicit. I have run into this very issue three times in the last month where BAs have been eliciting and documenting requirements that are out of scope. Requirements that were not generating new ideas for business or addressing current business needs. A considerable amount of resources, project hours and budget were inappropriately used.

2. Misunderstood requirements. It is very important that we have set criteria to ensure the quality of our requirements. Our requirements should be cohesive, consistent, complete, correct, feasible, modifiable, unambiguous and testable (BABOK® section 6.5.4). If the requirement has any ambiguity it fails. Ambiguity can lead to misunderstanding. Additionally, the requirement must be communicated (BABOK® section 4.5.1) to bring our stakeholders to a common understanding. If we communicate that ambiguity the implementation of the solution could be adversely affected because our requirements are misunderstood by our stakeholders (BABOK® section 4.4.2). This can lead to rework, increased costs, increase or decrease in resources and more. Misunderstood requirements are illicit requirements.

3. Requirements that jump to the solution. After we have elicited requirements we document the results which will include stated requirements and stakeholder concerns (BABOK® section 3.3). Stated requirements describe the stakeholder’s need from the stakeholder’s perspective. We must be wary of technical design in sheep’s (requirements) clothing. If we immediately jump to the solution we may ignore the stakeholder need or simply take away from their perspective which can lead to a design that will not cover the true need. Technical design(s) disguised as requirements are illicit.

4. Gathering requirements. Okay, while technically not an illicit requirement in itself, I find this to be one of the contributing factors to why requirements end up being illicit in the long run. The idea that we “gather” requirements is contrary to “elicit”. Elicit means to draw forth or bring out (something latent or potential) or to call forth or draw out (as information or a response). Gathering requirements as a term is more synonymous with simply taking in and documenting what is heard which I would call the job of a scribe. BAs are more than just scribes. Scribing what you hear without true elicitation and active engagement of your stakeholders in defining requirements (BABOK® section 3) which could be a root cause of illicit requirements!

Well I hope that you have the opportunity to discuss these things during some business analysis elicitation training in a safe environment but if not, be aware that illicit requirements do happen. Do you have other examples of illicit requirements? Do you think there is ever a time when illicit requirements actually work? I am all for breaking the rules, taking risks to innovate and in general push boundaries as long as we truly meet the needs of the business. What do you think? Yea or nay?

Illicit Requirements was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

I was surprised at this reaction, which was expressed so emphatically. Perhaps she had no experience modeling requirements and felt insecure about her ability to do so. Perhaps she assumed that the norm for her organization was the norm for the industry. Perhaps she thought that models were truly technical in nature. Perhaps the line in the sand between business analysis and design was clear in her mind and modeling of requirements went into the technical bucket. Perhaps she thought that “solution” requirements (functional and non-functional) had no place in business analysis.

Is the real answer the consultant’s mantra “it depends?” In this instance I’m not convinced that it is. It seems to me that business analysis has to be concerned with what affects the business. If we’re creating a new web page or modifying one, we want to be sure that the navigation makes business sense (process modeling), that the information on the page is flexible and correct (data modeling), that how our customers interact with the website works for them (use case modeling). And I know that when we show people pictures, we uncover requirements that they would never have thought of.

Do these models have to be completed by a BA? No, they don’t. They can be performed by anyone in the organization who has knowledge of and experience in creating these documents. Having just said that anyone can model requirements, however, I’m now going to go out on a limb and make the case that BAs are best suited to model them. Here’s why:

1. Modeling is a great way to uncover expectations—those unarticulated requirements that are rarely revealed at the beginning of business analysis, if at all. One of the advantages of modeling is that it provides a structure that encourages questions.  Business analysts are in the best position to understand this structure and ask questions of the business SMEs. They also are in the best position to interpret the answers and understand the impacts of responses they receive.  Also, BAs generally recognize the importance of asking a variety of questions from multiple perspectives. Creating different models , such as business process, data, use case, low-tech prototypes, provides different viewpoints (more about which in a future blog).
2.  Being consultants and liaisons, BAs are in a unique position to understand the business and to translate the requirements into something the designers can design and the builders can build. They can also translate the technical design back into something the business clients can understand and approve.
3. BAs who can model requirements will almost certainly see gaps that jump out at them, screaming to be addressed. BAs, it seems to me, are uniquely qualified to address these gaps in a way that serves the business and makes sense technically.
4. BAs are probably more likely than technical staff to go to the business to get questions answered. At the risk of gross generalizations, technical people may have a tendency to answer the questions themselves, without getting input from those who will be most affected—the business users.

My advice is to recognize that business modeling is best done during the business analysis phase(s) of a project and is best done by those who understand their importance in eliciting requirements.

For Additional Learning:

Check out two of our modeling courses: 
Data Modeling Course
Use Case Modeling Course

View our article: Oh No, You Gave Me What I Asked For (pdf) (You must be a Watermark Learning Member to access this article.  Membership is free and allows you to access valuable skill-development tools, such as articles, webinars, eNewsletters and special discounts.)

Should Business Analysts Model Requirements? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

1)      Test your technology. If you have never used the software or hardware for your virtual meetings, make sure you practice with a small group first. If you are doing a formal presentation, I suggest you reboot your PC right before you make it. We recently did a product demo where the presenter’s PC froze up right at the start. It took some fancy “tap dancing” to recover and keep the meeting going. Better to reboot first than to recover later.

2)      Presenters: clear your desktop. There is nothing worse than seeing an incoming email notice popping up on the moderator’s screen, or seeing his or her calendar reminder saying “Pick up Amie from soccer practice.” If you are a participant and there’s a chance your screen will be displayed during the session, this applies to you, too.

3)      Participants: minimize your distractions. Don’t text or read emails when you should be participating. Pretend it’s a live meeting. How would you behave? (I know, some of you out there would be on your Blackberries during a meeting. Ha ha.) One method to deal with this issue is to call on participants to ask for their input or thoughts. Some virtual meeting tools provide an “attention” meter. Ours does. It’s very useful to see who has other non-meeting screens in the foreground. It’s also good feedback for the facilitator on how engaging the meeting is going. That can be a bit deflating, I’ll admit, but an impetus to try harder!

4)      Larger meetings: use your name. I was recently in a virtual meeting with people I just met and every one of them sounded the same! I could not distinguish them and I kept asking “Jennifer is that you?” or “Was that Tom who said that?” In retrospect, I should have asked at the beginning for people to announce their name as they commented. Better yet, I think it should be a standard ground rule for virtual meetings.

5)      Take notes as you normally would. Unlike an in-person meeting, though, announce you are pausing to write down your notes. If people can’t see you, the audio pause is disconcerting and vocal people will fill it and try and move the discussion along. If you want to successfully capture an action item or decision, tell people you are writing and ask them to wait a moment. Make sure you write fast, though…virtual participants are more impatient it seems to me than in-person participants.

What other “musts” can you think of? I’d like to compile a top ten list and post it to our site.

Top Fundamentals for Successful Virtual Meetings was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Many times a problem we’re trying to solve or something we are analyzing is like that.

• How often do you forget the name of something when you try to recall it, only to remember it later while walking outside, or when you are in the shower?
• Or, the solution to a nagging problem suddenly pops into your head when you are working on something else?

These mental phenomena are very similar to the parallax effect. I’m sure there is a scientific name for it, but my psychology classes are only distant memories. I’ve noticed this same experience in business analysis countless times and informally call this the “parallax effect on requirements.”

The main way I’ve observed the parallax effect on projects is by focusing on too few methods to elicit and analyze requirements. For countless reasons, overworked business analysts may rely on one main method for eliciting requirements – such as interviews or requirements workshops. Then, to keep on schedule, BAs will use one primary method to analyze and document the discovered requirements. Swim lane diagrams and use case models come to mind here.

That is when the parallax effect strikes. Bam! You get stuck on a thorny issue like resolving an alternate path of a use case. You may resort to more interviews to solve it, but both struggling with the use case and re-interviewing are like staring at that star. The solution starts fading and disappearing.

So, what is the equivalent to diverting your gaze from the star so you can see it? How can you keep the problem in focus without over-focusing on it? The most practical way I’ve learned is to use a coordinated set of models to view the problem from multiple angles. You don’t need to use 27 models to do this – four categories will do. All software applications have the following four types of functional requirements in varying degrees:

1. Business Process – current and future states of the business processes affected by the solution being built. Business Process models set the context for and are the foundation for every other type of requirement.
2. Interaction – show how users will interact with a new system, and include scenarios, use cases and user stories as primary methods.
3. User Interface – an extension of the interaction requirements, these requirements uncover additional data that is input to or output from a system. Prototypes are excellent ways of drawing out user interface requirements.
4. Data – the data needed to support a business process and/or is input or output during the interaction with a system, and/ or appears on user interfaces. Data models, such as Entity-Relationship Diagrams and Class models are typical types of models that help here.

Concurrent Requirements Modeling is what we call the use of complementary modeling techniques to quickly and completely analyze functional requirements. Using these four categories of models provides a complete, well-rounded set of functional requirements. That’s a huge benefit in and of itself, and it also saves time and frustration by combating the parallax effect.

Let me give you a quick example. During a workshop a student team was working on a use case and got stuck on what happened during an error situation. Their first reaction was to ask the “customer” (me, during a role-play) what they wanted. When that didn’t work, they sketched out an activity diagram of the process and a rough prototype. The team got out of their use case rut, and were able to ask pointed questions about the business process and interface. They got most of what they needed to complete their use case alternate path. The data model would have supplied a few more missing pieces. But, by moving their analysis to other models, the team looked away from the “star” and were able to “see” the problem and solution more clearly.

So, the next time you stare too long at a problem and lose sight of it, maybe the parallax effect is at work. Try looking away by utilizing complementary techniques, and the problem may well come into focus.

The Parallax Effect on Requirements Analysis was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog