An Organization’s Formal Methodology

An organization may have adopted one or more formal methodologies that define deliverables. This usually takes the decision about which requirements deliverables to use out of the hands of the team members and forces consistency from project to project. Unfortunately, many methodologies do not provide much detail on requirements elicitation and analysis from a business perspective. The business requirements document may be a single deliverable within the methodology. A business requirements document is made up of a set of requirements components and should be viewed as multiple deliverables.

If you are assigned to a project using a formal methodology, your first task should be to review the methodology for its handling of requirements deliverable(s) and determine if it meets the needs of the stakeholders. Part of your planning effort will be to add items to the formal methodology as needed for the project.

Using a methodology has its advantages and limitations. On the positive side, the BA can read the methodology and know exactly what is expected. The project plan is easier to develop because milestones are stipulated and defined.

The limitations of this scenario are obvious. Even the best methodologies cannot anticipate the circumstances of every project or the nuances of an individual organization. The prescribed deliverables may not work well for a particular project and you may find yourself forcing round requirements into a square hole. Create the required deliverables as best you can, and then use some additional deliverables that make more sense for the project needs. Few methodologies forbid you from creating more deliverables than prescribed! Although these additional deliverables may require more time, if they are beneficial in representing project needs, the time will be well spent. If a prescribed deliverable doesn’t make sense for your project, petition the standards board to omit it.

Why Don’t Most Methodologies Detail the Business Analysis Approach?

Most application development methodologies have limited coverage of requirements because most methodologies were developed by software developers and are focused on how to develop software. It makes perfect sense for a software development methodology to focus on development, but the assumption is that business requirements are well understood and available. This assumption usually is false. Methodologists have spent years trying to speed up the development process and steer developers toward techniques that will produce high-quality code that is easy to maintain. They have not focused their efforts on making sure that the team truly understands the business need before designing the software. This is where the BA needs to step in and enhance the methodology. Business analysis must be done before software development (see Figure 5.2).

Figure 5.2: Business Requirements Come before Software Development

Most of the business analysis and requirements techniques that BAs use have been around for a long time. Why haven’t methodology authors incorporated them into their approaches? The simplest answer is that every project is different and deciding which techniques and approaches to use is not a simple task. Even the most experienced BA must spend time thinking about a new project assignment and finding the techniques that meet the needs of the team and the characteristics of the project. A smart methodology would need an expert system to ask hundreds of questions about a new assignment and based on those answers tell you exactly which techniques to use. This expert system currently exists only in the minds of experienced BAs.