Skip to main content

Tag: Software

STOP the Software Requirement Insanity

Rgalenoct251I attended the Agiles 2011 conference in Buenos Aires, Argentina in early October. Jeff Patton was a keynote speaker at the event. In his keynote, one of the remarkable (at least to me) points that Jeff made was that he really hated the term requirements.

He made the point that in the early parts of his career, he worked for small software companies that really didn’t refer to requirements as requirements. The used customer centric terms that connoted customer needs, business problems, and desired outcomes. There was no “requirements analysis” or “requirement sign-off” per se; there were only customer and business problems to solve.

When he changed jobs and first encountered true waterfall processes and the term requirements, he encountered the fixed, seemingly non-negotiable nature of requirements.

Software Requirements?

So the critical question that Jeff raised is that are software requirements truly REQUIREMENTS? Are they:

  • Absolutely required?
  • Non-negotiable?
  • Blindly followed?
  • Simply listed?
  • Taken verbatim?
  • Targeted as a whole?

In the interactions of the organization asking for them and in the minds of the teams tasked with implementing them.

In Jeff’s view and my own, they are. Organizations get wrapped around the “requirement axle” in demanding “a list” that they blindly follow to completion. Oh sure, requirements are discussed, clarified, negotiated, decomposed, written, and dissected. But they are, by and large, followed!

But what’s missing?

I think the key point is that demanding anything specifically limits our solutions, our creativity, our ability to innovate, and our thinking. Let me try to make this point with an example.


I love Maine. It’s one of my favorite states and since I moved from Connecticut to North Carolina many years ago, I don’t visit it often enough.  One of the wonderful aspects of Maine is the cabins and cottages along its many lakes. Let’s pretend I have a little piece of property in Maine and I want to build a year-round cottage on the lake. I want to give my architect some directions towards designing my cottage, so here goes…I can say that my requirements are:

  • A 3 bedroom, 2 bath cottage
  • Somewhere around 1900 to 2200 sq. ft.
  • I want it to be a log cabin
  • Timber frame construction
  • The family room should look out over the lake
  • I want a sun room, encased in glass
  • The master bath needs to include a whirlpool and sauna
  • Granite, state of the art appliances, and Italian tile need to be in the kitchen
  • Wrap-around porch – 10’ for a porch swing
  • 2 car garage, etc.

You get the idea, it’s a list of “requirements”, and I’m “the customer”. So, what will I get in my house design? I strongly suspect exactly what I asked for. Not bad, but what if I was mistaken? Nor am I an expert in house design—so what if I asked for the wrong things?

Perhaps something else…

Now let me try another approach. I want to simply describe the business situation, but not necessarily require anything. I’m not sure this will be the best example, but I hope you get the idea…So instead I describe for my architect some of my preferences, or things that I really enjoy. For example:

  • My wife and I are gourmet cooks and we’d really like a kitchen that would support the both of us cooking. It needs to be modern, with high-end appliances, but reflect the simple nature of a Maine kitchen.
  • We also entertain quite a lot, so we need space to support that. Most of the entertainment starts with dinner, again our cooking thing. And we’d like the ability to entertain inside & outside as the seasons and weather permit.
  • I personally love the water. I love seeing it in the morning when I get up and looking out over it at night with the moon reflecting off of it. Can we position the house to maximize the exposure to the water?
  • There’s just the two of us. Our children and friends visit infrequently, perhaps 4-5 times a year. So, we need some space for visitors…but, but not too much. Oh, and I’m a consultant, so I need a private office.
  • I plan on purchasing a boat, somewhere in the 22-27 ft. range, within the next 2-3 years. I’d love a place to store it in winter and something dock it on in the summer.
  • Oh and I hate, absolutely hate, doing yard work. Yet, I love a well groomed property and garden. It just needs to be ultra-easy to maintain.

I’d like to call this last list something other than requirements. I consider it insights, design goals, customer usage intentions, etc; almost anything other than requirements.  What does this re-frame do?

My hope is that it communicates my home goals while leaving the flexibility for my architect to do their job. Then I hope it fosters review and communication while we refine the plans.  Ultimately, I want my architect to “delight me” by interpreting my goals, collaborating with me, and leveraging their creativity to create something “just right”.

Wrapping Up

So enough of my ramblings… Do you feel the term requirement has become too restrictive? Or are Jeff and I simply overreacting? Please weigh-in with your comments. And please share your experiences, thoughts and ideas for how we might frame requirements to drive more innovation & creativity, team-based engagement, and simpler overall solutions.

It’s not required that you weigh-in, but it’s very, very welcome!


Don’t forget to leave your comments below.

Technology: Choice or Chosen?

Once upon a time a consulting firm bid for a high profile, fixed price project using Platform A.

I realize that I have only started reading this fairytale story but how on earth has this bid included a technology choice when they are yet to do the analysis?

The clients were delighted, as were the consulting firm when they won the > 15M contract. “And now for the real work to begin!” declared the (first) Project Manager.

The Business Analysts swooped in and worked their magic on high-level design documentation and a long list of prioritized requirements. “Wonderful” declared both the (first) Project Manager and client.

This really is a fairytale story!

It was then time for the developers to descend. They began gnawing away on a prototype on day one. “Finito” they finally declared. So off they trotted to proudly show the client what they were in store for.

Uh-oh, I feel trouble brewing…

“We never liked Platform A, we just wanted to see if we would like it more once we had seen what you had done with it…but no, we still hate it” stated the client matter-of-factly.

“Why is this? We think it suits your requirements down to the ground” quietly demanded the (first) PM.

“We have used it before, I just don’t like it, isn’t that reason enough?” declared the client, with a stomp of his foot.

The opinion of only one Stakeholder was enough to represent all interests?

The PM huffed and puffed and… was told to go and work in Siberia.

Not quite as dramatic as blowing the house down, but I’m sure it had a similar effect.

The project team were back to square one and without Project Manager, so in his place stepped in the Program Manager.

* Program Manager enters project*

Discussions were being held while the BA’s finished off their low level design documentation. It was decided that Platform B would be used instead. Unfortunately I was not privy to these discussions, however, I do think it was no coincidence that this technology was an area that the consulting firm were keen to gain experience on as the lead Technical Architect was Platform B’s biggest fan.

Did they push the client into making this Technology Choice or was there a fair analysis?

The project team and developers were then trained in Platform B and unleashed straight onto the client with some difficult questions to answer having not been exposed to the product in a working environment before.

*Expensive Contractors enter fixed price project*

The developers cracked on, the testing team were formed, the UI specification was underway… it all seemed to be back on track.

 * (Second) Project Manager enters project*

Relationships were formed, confidence restored and bridges built.

The fairytale ending?

The developers then realised the massive pitfalls of Platform B (in relation to the project requirements, not as a product) and they now had to learn Platform B’s bespoke coding language as the customisation needed was so vast. The Project Manager was not impressed with the timelines given, neither was the client.

“Why are we using this product in the first place?” The client repeatedly asked.


The End.

Although this project has had its highs and lows I am pleased to say that it did come together in the end, neither on time nor to budget, but it did come together. Sadly it was without the fairytale ending of another piece of work.

There is no reason to point fingers or hold one person accountable when ultimately projects are a team effort. However, I do think that the team were misled in two respects:

  1. The bid team had proposed the use of a Technology before fully understanding the requirements of the project
  2. There was no analysis of other products which then provided the client with a solid reason as to why that product was chosen and which boxes it ticked

Based on my knowledge and experience I feel that it is inappropriate for bids to select a product before requirements are gathered. If I were a client I would be wary of a consultancy second guessing what the best product would be without considering other options and ‘seeing their homework’.

There are pros and cons to being partnered with a software house. In one respect you can add benefits to your clients by passing on reduced costs, more well-informed consultants resulting from reduced training costs and access to a wealth of knowledge. On the other hand they may have hidden agendas and feel compelled to sell you said software or have quotas to meet to remain a certain level of Partner.

In a perfect world I would undertake a requirements driven Technology Choice analysis and use the chosen technology to determine the software development house / vendor.

Clients take note: demand a full Technology Choice exercise, it can make or break a project. Analysts, colleagues, friends or competitors may suggest a solution that has worked for them but only a comparison specifically for your project requirements will represent the best choice and deliver real benefits.

Don’t forget to leave your comments below.

Emily McCreadie  is a London based business analyst working for BSG (Africa)’s London operation. She is interested in evolving methodologies, requirements elicitation and innovation in the workplace.

The Business Analyst Facilitator Role in an Agile Software Development Team

The purpose of this article is to define the need for the business analyst facilitator role in an agile software development team. Traditionally the business analyst role has been defined in the context of a project, utilizing the waterfall solution development life cycle (SDLC). This approach has the business analyst collecting all the requirements and business rules upfront prior to development. However, today’s demand for accelerated solutions has changed the dynamics of system development to a more agile approach, where requirements and business rules are defined in conjunction with solution development in iterative cycles. Hence, the question – “Is there a need for a business analyst role in an agile software development team?”

Some readers of this article may believe that the business analyst role is not needed with the agile approach. To those of this position, I encourage you to read on. I suggest regardless of the SDLC chosen (waterfall or agile), the role of the business analyst is still needed. As a developer, you may say, “but we are doing fine on my agile project without a BA role.” To you I ask, “Have you examined your expanded role of directly interfacing with stakeholders?” For the past 40 years in the IT business, I have experienced several approaches to solution development. One rule that does not seem to change is that regardless of the SDLC used, functions that roles provide remain. In the agile case, BA functions are absorbed by members of the software development team at some risk.

Please note, I am assuming that the reader is familiar with waterfall and agile SDLC approaches, so I will not attempt to define them in detail in this article. For the purposes of this article, a Scrum like process for the agile approach is used.

As an instructor of business analysis techniques and practices, I often field questions on the role of the business analyst (BA) in an agile software development team as opposed to the traditional waterfall solution development life cycle (SDLC) approach. After much thought and input from many sources, I am convinced that the role of the business analyst facilitator is needed in an Agile Software Development Team.

The Role of the BA Facilitator

The role of the BA facilitator is to guide activities on developing both the vision and software solution. The key word here is guide. The BA facilitator role provides process to group settings and avoids participating in content. Typically, the BA facilitator role serves as the liaison between stakeholders, and the stakeholders and software development team respectively. As the liaison, the BA facilitator role uses various techniques and emotional intelligence skills to assist project sponsors and/or team leaders in accomplishing group meeting goals:

  • Facilitation Techniques for Identifying Solution Features
    • Creating a Solution Vision and Scope
      • Brainstorming – discussing of ideas
      • Brainwriting – submitting written ideas for discussion
    • Eliciting Features and Associated Business Rules
      • Focus Group Meetings – soliciting opinions
      • Joint Application Design – resolving conflicts
    • Analyzing Features – Assumptions, Constraints, Risks, and Issues
      • Root Cause – five whys, Ishikawa Diagrams
      • Force-Field – listing negative and positive influences
      • As-Is and To-Be Gap
    • Making Decisions on Features and Priorities
      • Multi-voting – subjective paring down a long feature list
      • Criteria-Based Grid – weighting feature value criteria
      • Impact/Effort Grid – comparing feature benefits versus effort
  • Emotional Intelligence Skills for interfacing with stakeholders
    • Active Listening and Paraphrasing
    • Generating Participation
    • Neutrality – focus on meeting process instead of solution content
    • Questioning – seeking answers rather than posing solutions
    • Maintaining Focus – use a parking lot and issue log for off agenda topics
    • Obtaining stakeholder feedback
    • Summarizing and synthesizing Ideas
    • Conflict intervention

Under the agile SDLC, the BA facilitator role contributes in two main activities: Continuous Vision and Scope Sessions, Iterative Software Development Meetings and Workshops.

Every project starts with a vision and scope of the solution to meet a business need. This vision may be definitive or fuzzy. However defined, the vision will reflect a prioritized set of high-level solution features that is essentially the scope of work to be done by the software development team. In the agile approach, defining the vision and scope is a continuous set of sessions. Each session represents a snap-shot of the vision and scope at that time determined by the stakeholders. These sessions manage the scope of solution features either as additions, changes and/or refinements until the stakeholders complete their vision.

These vision and scope sessions are chaired by the project sponsor. The challenge for the project sponsor is to ensure that the project vision and scope is a collaborative effort among all the stakeholders, hence the need for the BA facilitator role. The role of the BA facilitator is to assist the project sponsor by providing and executing session plans. Each vision and scope plan consists of:

  • ensuring the correct participants attend
  • accounting for meeting risks
  • arranging for an adequate facility conducive to collaboration
  • setting an appropriate agenda

This agenda contains facilitation techniques that will lead the stakeholders to a consensus on a prioritized set of high-level solution features to be pursued by the software development team. During the session, the BA facilitator role uses emotional intelligence skills to ensure that all stakeholders participate and that their ideas are respected. The BA facilitator role ensures through “questioning” that the features are justified and can be traced back to the business need. Note that all features are subject to the approval of the project sponsor – chair of the session.

Iterative Software Development Meetings and Workshops

After the initial vision and scope features are determined, the Software Development Meetings begin with a consensus on which of the prioritized set of high-level features will be developed on the first iteration. Once a finite set of features is selected and time-boxed by the software development team, then a series of follow-on status meetings are held addressing progress and the removal of impediments. Between these status meetings, the software development team holds workshops with stakeholders to develop the solution. These iterative workshops conclude with a validation meeting of the developed solution and a decision on implementation by the project sponsor. In summary,

  1. Select vision and scope features from prioritized list
  2. Develop a solution for this iteration within a time-box
    1. Conduct workshops producing prototypes
    2. Hold status meetings on progress
  3. Validate final prototype and implement with project sponsor approval
  4. Return to step one for further features and add rework as needed until feature list is exhausted

Note that with implementation, the iterative software development meetings are renewed by another selection of prioritized high-level features to address. These features may have been changed by the stakeholders in the meantime by further vision and scope sessions held in parallel with the software development meetings.

The feature selection and status meetings are chaired by a team leader similar to a project manager. In these meetings, the team leader faces the same challenge as the project sponsor – ensuring that solution development is a collaborative effort through consensus. Once again there is a need for a BA facilitator role. As in the vision and scope sessions, the role of the BA facilitator is to assist the team leader by providing a plan for each meeting and executing that plan.

The software development team is self-directed and/or self-organized. The team runs the workshops according to their skills and experience, rather than using a set plan by the team leader. The workshops are direct conversations between the software development team and the stakeholders. These workshops involve vital business and technical details in developing the solution:

  • User and system functional requirements
  • Associated business rules
  • Information needed to be managed
  • User Interface
  • Technical implementation methods

Both what needs to be developed and how it is to be implemented are discussed at the same time during the workshop. As a result of these discussions, the development team provides a solution through a series of prototypes each tested with direct stakeholder feedback. The final prototype (for this iteration) is then validated and approved by the project sponsor for implementation. A new cycle then starts with the selection of further features from the vision and scope including possible rework items….etc, etc, etc.

In the workshops, the role of the BA facilitator is different from the previous planning meetings. During the planning meetings, the BA facilitator role provided and executed an agenda. The role of the BA facilitator in the workshop is to assist the stakeholders and the software development team to determine system requirements from stated user requirements for the purpose of building prototypes. The software development team uses these prototypes to build an incremental solution.

The BA facilitator role accomplishes the above by using an expanding BA tool which includes:

  • Business Modeling Tools for identifying and analyzing user requirements, system requirements, and business rules
    • Activity Workflows with Swim Lanes – manual processes
    • Use Case – user / system dialogue – system functional requirements
    • Storyboard – user / system interface – screen flows
    • Entity-Relationship – organizing information used by the system
    • State Change – information changes as it proceeds through processes and systems
    • Class / Object – use for Object-Oriented implementations

The thoroughness with which Business Modeling is used by the BA facilitator role is tempered by the needs of the software development team. Rather than comprehensive documented requirements as in the waterfall SDLC, the BA facilitator role generates “just enough” documentation as needed by the software development team to code the prototypes.

Conclusion – Formal BA Facilitator Role “Just Ensures”

Whenever solution features are being defined, prioritized, analyzed and/or developed, the BA facilitator role is used naturally to ensure stakeholder buy-in and acceptance of the final solution. Whether it is the vision and scope sessions, the iterative software development meetings or the workshops, the BA facilitator role may be taken on by a member of the software development team. However, consider the risk involved in building a consensus with someone less trained and experienced in BA facilitation. The level of productivity and consensus is directly dependent on effective use of the BA facilitator tool set. In addition, there is a risk that the stakeholder and the developer will focus on the technical aspects of the prototype rather than requirements. It is prudent to avoid this risk. To “just ensure” the success of the team, a formal BA facilitator assisting the agile software development team needs to be that best practice.

Don’t forget to leave your comments below

Mark A. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSMTM) and Certified Scrum Product Owner (CSPOTM) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF). Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

This article first ran in the IIBA newsletter February 2009.

Embracing Agility – Your Best Bet for Business Analysis Skill Development!

If you’ve been reading my blog entries at all this year, you’ve realized that I’m fairly enthusiastic about the agile methods. I think one of the most misunderstood aspects of agility and the methods themselves relates to their nature. You know, they’re really not methodologies. Certainly not in the same sense as heavily documented Waterfall and its variants or RUP or Spiral or any other traditional methodology.

Instead, I liken them more to Lean and other improvement oriented thinking tools and approaches than a specific methodology. They also gather concepts and patterns from historical software development practices that seem to work well , e.g,  unit testing, continuous integration, refactoring, and pair-programming.  That’s why I almost always hear the following from my students in my classes: “So that’s agile. I’ve been doing much of that for most of my career. It seems that the packaging is the key…and the mindset.”

I find myself universally agreeing with the students’ perception. It’s about a mindset that transcends “agility” and leads towards outstanding performance and growth as a technologist. Let’s explore some aspects of that…

Self-Directed, Empowered, and Accountable Teams

If you get the chance to join an agile team as a BA, jump on it. It will give you a chance to operate as a true, collaborative team member. Leadership opportunities will surface and you’ll get plenty of opportunities to show off your chops in a very visible venue.  High performance is what matters in these teams, and low performers can’t “hide” from the team. It draws out excellence.

In these teams words, written or otherwise, mean very little. What counts is delivering on commitments with working, demonstrable software. It’s about real delivery! Not in hours worked, but in raw productivity and creative solutions to the teams’ problems.

Focus on Quality and Improvement

As part of their career evolution, BAs need to become much more “quality literate”. Dive deeply into understanding the techniques for building in quality, for example reviews and inspections. What are the business cases behind them? The pay me now vs. later trade-offs in software and begin to challenge poor decision-making.

Partner with the testers. They are often underestimated and underutilized within most teams.  Yet, effective testing is as challenging a technical exercise as architecting or modeling any software system. Dive-in and test the software with a wide-variety of manual techniques, and learn how to test effectively. Even jump-in and do some simple automation. It will give you yet another perspective in your journey!

And when you attend retrospectives, have the fortitude to engage your team on continuous improvement. Call them out on the practices that need improvement and, during each iteration, demand focus on those improvements. Then celebrate each and every improvement!

Transparency and Feedback

There is tremendous power in making all of our project dynamics totally transparent to everyone.  First, it takes courage to “tell it like it is”. It also opens the door for feedback from all perspectives. That old notion of not raising issues without solutions doesn’t hold any longer. We’d rather get early visibility into the issues so the entire team can engage in solutions.

And don’t get defensive. If you get confronted on a mistake, take the time to explain the context and thinking processes behind your decisions. Be open to corrective action discussions without appearing defensive. In fact, become more comfortable with failure. Failure is good in agile teams; we simply want to fail early, small, and catch it quickly. This leads towards the necessary adjustments to get things “back on track”.

Generalist Mindset

I’ve seen so many software development roles (programmers, architects, testers, BAs, project managers, etc) take a very narrow view towards their roles and their work. Very often they create a narrow silo of responsibility that they ‘own’ and everything outside of that is “someone else’s’ job”. That often extends to their knowledge as well. They might only understand one narrow slice of their applications and not have a broader brush view.

In agile teams this view is highly discouraged. Not so much by management, but by the very definition of a self-directed team trying to meet their goals and objectives. The broader your view, the more  flexibly you can operate within your team and deliver the goods.  Oh and by the way, the more valuable you become!


Don’t let anybody tell you that agile teams are easy. They are not! To me they’re sort of a Boot Camp for personal growth and improvement. They provide opportunities for becoming more open-minded and trying new approaches. They also provide opportunities for thinking outside your traditional box and roles. If you’ve got the courage and persistence to truly want to improve, agility will provide you with incredibly diverse opportunities to learn, be recognized, and advance!

That is…if you embrace It!

Don’t forget to leave your comments below

Requirements; They Can Make or Break a Project

Every project an organization undertakes has requirements. It doesn’t matter if it’s building hardware solutions, developing software solutions, installing networks, protecting data, or training users – for the project to be a success, knowing what the requirements are is an absolute must.

Requirements exist for virtually any components of a project or task. For example, a project may require specific methods, expertise levels of personnel, or the format of deliverables. This article will discuss the various kinds of information technology requirements, their importance, the different requirement types, the concept of requirements engineering and the process for gathering requirements.

It’s an area that every business analyst is very familiar with but, to paraphrase an old saying, “familiarity sometimes breeds contempt” so it’s well worth taking the time to look back on what requirements are all about and how we’ve been handling them since we first learned about them. Let’s get back to some basics.

What Are Requirements?

The IEEE Standard 1233-1998, IEEE Guide for Developing System Requirements Specifications, defines a well-formed requirement as a statement that:

  • States system functionality (a Capability)
  • Can be validated
  • Must be met or possessed by a system
  • Solves a customer problem
  • Achieves a customer objective
  • Is qualified by measurable Conditions and bounded by Constraints

Specifically, a well-formed requirement should contain:

  • Capability
  • Condition(s)
  • Constraint(s)

According to the Oxford American Dictionary:

Capability as a noun is defined as the capability of doing something; or a power or ability, e.g, “the capability of bringing the best out in people” or “the capability to increase productivity.” However, when used with an adjective, a capability describes a facility on a computer for performing specific tasks, e.g., “the computer has a graphics capability.”

Condition as a noun is defined as the state of something, especially with regard to its appearance, quality, or working order, e.g., “the wiring is in good condition,” or “the bridge is in an extremely dangerous condition.” A condition can also be a state of affairs that must exist or be brought about before something else is possible or permitted, e.g., “for a member to borrow money, three conditions have to be met,” or “all personnel should comply with this policy as a condition of employment,” or “I’ll accept your offer on one condition.”

Constraint as a noun is defined as a limitation or restriction, e.g., “the availability of water is the main constraint on food production” or “time constraints make it impossible to do everything.”

Wherever There are People, There are Problems.

Different institutions are created to solve these unique, large-scale problems: government, healthcare, transportation, telecommunications, etc. These institutions, utilizing a “systems approach” for planning, organizing, and controlling resources, initiate projects to focus on “specific objectives” or components of their problems.

Importance of Requirements

Requirements are the documented needs of a project that are gathered to identify the specific constraints (scope) of each project component and act as the foundation for everything else that occurs in a project.

Project Failure

Requirements are considered by many experts to be the major reason projects do not achieve the triple constraint of “on-time, on-budget, and high quality.” Very few projects do an effective job of identifying and carrying through the project and all the requirements correctly.

Various studies have shown that failure to meet requirements is the biggest problem in projects. Most defects occur during the requirements phase. Project teams need to do a much better job on requirements if they wish to develop quality projects on-time and on-budget.

The Problem

Since the invention of computers, there have been three primary issues to meeting project requirements.

First, the technology learning curve is advancing much faster than the business learning curve. In other words, while technology concepts are changing rapidly, business management concepts have not changed at the same pace.

Second, there is a huge disconnect in the language between business people and technology people. Each group has its own taxonomy (glossary) for how to operate.

Third, because businesses are so reliant on technology, it is more important than ever that the two environments align to insure that the systems being built match the requirements of the business needs.


An institution’s ability to efficiently align resources and business activities with strategic objectives can mean the difference between succeeding and just surviving.

The world is cut-throat. To achieve strategic alignment, institutions are “projectizing” their business to monitor performance more closely and make better business decisions about their overall work portfolio.


Because of errors and omissions on the part of institutions in the public trust, (e.g., government agencies and publicly held corporations) the U.S. Congress has passed legislation to require transparency throughout organizations to eliminate opportunities for fraud.

Transparency is the ability of an institution’s governing body to see through the organization. The way to see through an organization is by documenting – creating a paper-trail – all of the transactions that occur. Today, institutions utilize their information systems and IT departments to insure that the electronic paper-trail exists and is working correctly.

The costs of non-compliance are very large and can include incarceration for the institution’s executives. However, the benefits to be derived from transparency should be the dream of every executive; transparency will bring about the ultimate goal of executives having access to “any data, on any part of the business, from anywhere, and at any time.”


Due to the “time value of money,” all institutions must put their financial resources to work. If there are errors in requirements, they increase the need for re-work and decrease an institution’s operational efficiency. This works against every institution’s goal of managing for value.

Therefore, the earlier requirements problems are found, the less expensive they are to fix. The best time to fix them is when you are involved in gathering, understanding, and documenting them with your stakeholders (who should be the source of your project requirements).

The Challenge

The requirements phase is considered by many experts to be the most difficult part of any project. The hardest requirements problems to fix are those that are omitted.

This really becomes the requirements analyst’s dilemma. The analyst often does not know what questions to ask, and the stakeholder does not know what information the analyst needs. Since the analyst doesn’t ask, the stakeholder doesn’t state requirements.

Types of Requirements

Business Objectives

The overall business goals and guidelines for the project are the business objectives. Business objectives help provide the foundation for a project and are obtained normally from management or from existing company documents. For example: Company XYZ will increase sales domestically by 50 percent within two years.

Business Requirements

Requirements from stakeholders are business requirements. These requirements can include business processes the system needs to support; various constraints such as cost, resources, schedule; and more.

Business requirements often come from managers, although workflow processes (how people do their jobs or should do their job, if you are trying to optimize business processes) will probably come from those actually doing the work or end-users of the system.

Stakeholder Requirements

A stakeholder is anyone with a vested or substantive interest in the project. Stakeholder requirements include the needs of stakeholders both internal and external to the organization. The challenge of any project is to accurately identify all of the stakeholders, and to elicit and understand their needs.

End-User Requirements

Needs from those who will directly or indirectly interact with the system are called end-user requirements. These include requirements for the documentation and user interface, which can be very complex and are often a source of error.

System Requirements

System requirements come from analyzing the business objectives and stakeholder requirements. While business objectives and stakeholder requirements are written in business terms and are from a real-world perspective, system requirements are more rigorous, more formal, and are written in systems (technical) terminology. For example, a stakeholder requirement might refer to “Company XYZ Monthly Sales Report,” while a system requirement might refer to that same thing as “XYZMoSalesRept.doc.”

System requirements are high-level requirements for an entire system. Systems may include subsystems (for example, hardware subsystem, operating subsystem, software subsystem [or subsystems], or network subsystem).

Software Requirements

Software requirements, such as the functionality necessary for operating within a harsh physical environment or the graphical user interface needed between the user and the machine, are detailed, specific requirements written for a software system (or subsystem).

Requirements Engineering

According to the IEEE Software Engineering Body of Knowledge® (SWEBOK®), requirements engineering includes four processes: elicitation, analysis, specification, and validation.


Requirements elicitation is concerned with where project requirements come from and how the analyst can collect them. It is the first stage in building an understanding of the problem the project is required to solve. It is fundamentally a human activity, and is where the stakeholders are identified and relationships established between the project team and the customer. It is variously termed “requirements capture,” “requirements discovery,” and “requirements acquisition.”

One of the fundamental tenets of good project management is good communication between users and the engineers. Before development begins, requirements specialists may form the conduit for this communication. They must mediate between the business domain of the users (and other stakeholders) and the technical world of the engineers.


Analysis is the process of:

  • Detecting and resolving conflicts between requirements
  • Discovering the bounds of the project and how it must interact with its environment
  • Elaborating system requirements to derive software requirements

The traditional view of requirements analysis has been that it be reduced to conceptual modeling, using one of a number of analysis methods such as the Structured Analysis or Design Technique (SADT).

While conceptual modeling is important, analysis includes the classification of requirements to help inform trade-offs between requirements (requirements classification) and the process of establishing these trade-offs (requirements negotiation).

It is important to describe requirements precisely enough to allow the requirements to be validated, their implementation to be verified, and their costs to be estimated.


For most engineering professions, the term specification refers to the assignment of numerical values or limits to a product’s design goals. Typical physical systems have a relatively small number of such values. Typical software has a large number of requirements, and the emphasis is shared between performing the numerical quantification and managing the complexity of interaction among the large number of requirements.

So, in software engineering jargon, “software requirements specification” typically refers to the production of a document, or its electronic equivalent, which can be systematically reviewed, evaluated, and approved.

For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced: concept of operations, system requirements, and software requirements.


The requirements documents may be subject to validation and verification procedures. The requirements may be validated to ensure that the software engineer has understood the requirements. It is also important to verify that a requirements document conforms to company standards, and that it is understandable, consistent, and complete.

Formal notations offer the important advantage of permitting the last two properties to be proven (in a restricted sense, at least). Different stakeholders, including representatives of the customer and developer, should review the document(s).

Requirements documents are subject to the same software configuration management practices as the other deliverables of the software life cycle processes. It is normal to explicitly schedule one or more points in the requirements process where the requirements are validated. The aim is to pick up any problems before resources are committed to addressing the requirements.

Requirements validation is concerned with the process of examining the requirements document to ensure that it defines the right software (that is, the software that the users expect).

Requirements Process

Identify what information is needed. What are the goal(s) and the purpose? Identify who or what is likely to have this information. A coverage matrix, a spreadsheet showing stakeholders and the information needed, can be a useful tool for this step.

Determine effective techniques to get this information from this person or these people. Write out the questions. Even if you are only job-shadowing, you are still observing in order to answer questions.

  • Obtain the information.
  • Process the information.
  • Refine and confirm the information through storyboarding and prototyping.
  • Write the stakeholder’s requirements document.

Progressive Elaboration

The concept of Progressive Elaboration states that the more we know about something, the better we are able to manage it.

Here is what we know:

Projects begin with “1% of what we know about what WE KNOW,” and “1% of what we know about what WE DON’T KNOW.” HOWEVER, the remaining 98% is “what WE DON’T KNOW about what WE DON’T KNOW” until we begin.


Iteration can be considered as “loops around the track” (i.e., how many times should you repeat a process before you are done?) This course will go through the requirements elicitation (and analysis, specification, and validation portions of requirements engineering) sequentially. However, in reality (for large projects, especially), the process is much more iterative. You may need to iterate among the various stakeholders. For example, you may interview the department director, and then, after interviewing her staff, realize you have more questions for her.

You may need to iterate among the processes. For example, you may be writing the requirements specification and realize you omitted an important end-user.


Requirements management is a supporting or infrastructure process that goes on throughout the entire life cycle. Requirements management, or managing requirements, usually involves three major components: Managing change, tracing from stakeholder needs all the way through delivered software, and identifying needed attributes on each requirement – things such as status, author, and priority.


Requirements are the foundation for testing.

Acceptance Testing

Acceptance testing should be based on stakeholder requirements. System testing is based on system and software requirements. Integration testing (plugging together the parts of the system) is based on architectural or high-level design; and unit or module testing is based on the design specifications (not the code itself).

What are some of the implications?

First, it’s impossible to do effective testing if the front-end documents do not exist or are not well-written. Second, all requirements must be testable.

How do you ensure they are testable?

The best way is to have the tester create the test cases while the requirements documents are in draft mode, nearing completion. If the tester cannot create a valid test case, the requirement is not testable and, therefore, should be rewritten now rather than weeks or months after this requirement was used for analysis, design, and coding, and then fails during testing.


The earlier you find defects, the cheaper they are to fix. This is one reason to find defects early.

How do you write a testable requirement?

First, requirements should be written in the form “A user shall…” (for stakeholder requirements, substituting any role for “user”), or “The system shall…” (for system and software requirements). Second, measurable terms must be included, such as “The system shall return a prompt within three seconds…,” not, “The system shall return a prompt as quickly as possible.”

Don’t forget to leave your comments below

Richard Frederick, PMP, MCP, MSF is a graduate of Southern Methodist University (SMU) Cox School of Business, a Project Management International (PMI®) certified Project Management Professional (PMP®), a Microsoft® Certified Professional (MCP) and Microsoft Solution Framework (MSF) Practitioner. Richard “Ric” Frederick gained his broad range of experience by treating problems as opportunities and creating innovative solutions. With work in government at the Superconducting Super Collider laboratory, in education with Apple Computer, Inc. and in business with Assured Solutions (his own consulting company), Ric has earned and applied the necessary techniques to achieve both tactical and strategic goals. His efforts to simplify complex issues and turn losing projects into winners have met with outstanding success. Ric, a distinguished speaker and teacher, periodically shares his expert knowledge of industry standard techniques in Program and Project Management Seminars. His insights reveal how to bring order and success to the often-times chaotic program management process.

Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge. Check out the following Global Knowledge courses:

Business Analysis Essentials and Requirements Development and Management

For more information or to register, visit or call 1-800-COURSES to speak with a sales representative.