Chapter 1
Introduction to Requirements Analysis

In This Chapter:

• Defining Requirements Analysis and Specification

• Challenges in Requirements Analysis

• Requirements Analysis Activities

• What Are Models?

• Stages of Requirements Analysis

• Wrapping Up Elicitation Before Starting Analysis

Defining Requirements Analysis and Specification

Requirements are the necessary and sufficient properties of a product that will satisfy the consumer’s need. Software requirements are the necessary and sufficient properties of software that will ensure the solution achieves what it was designed to accomplish for its users and for the business.¹ Requirements for a new business solution, therefore, are the necessary and sufficient properties of a business system that will ensure the business goals and objectives are met.

Requirements analysis is the process of structuring requirements information into various categories, evaluating requirements for selected qualities, representing requirements in different forms, deriving detailed requirements from high-level requirements, and negotiating priorities. Requirements analysis also includes the activities needed to determine required function and performance characteristics, the context of implementation, stakeholder constraints and measures of effectiveness, and validation criteria. Throughout the analysis process, requirements are decomposed and captured in a variety of formats, in both text and graphics. Analysis represents the middle ground between requirements and design.²

Requirements analysis encompasses the activities involved in scrutinizing the information that has been elicited about the business need and the scope of a new or changed business solution. In analysis, requirements information is decomposed, examined, and restated until the requirements specifications are accurate, unambiguous, and complete. Specifications are representations of requirements in the form of diagrams and structured textual documents that are elaborated from and linked to the various requirement components, thereby providing a repository of requirements. Requirements analysis is an important part of the business solution life cycle (BSLC) process whereby business analysts, in collaboration with business and technical subject matter experts (SMEs), analyze and then specify, document, and validate the requirements of the business entity undergoing change (see Figure 1-1). Because the business analysis profession is just now emerging and a standard language has not been put into place, requirements analysis can also be referred to with any of the following phrases:

•   Requirements engineering

•   Systems analysis

•   Requirements specification

•   Business requirements analysis

In generally accepted engineering practice, requirements analysis and specification is typically completed before design and design is completed before construction. Of these phases, requirements analysis is considered by many the most vital part of the business solution development process. As mentioned in the first book of this series, studies reveal that project costs and technical risks can be reduced through rigorous and thorough requirements elicitation, analysis, specification, and validation. Indeed, it is not uncommon for projects that are following one of the agile methods for incremental development to spend up to nine months on requirements development and release planning prior to design and construction of the incremental releases. It must be noted, however, that requirements elicitation, analysis, and specification is an iterative process. Depending on the product development methodology used, it often continues at a progressively more detailed level throughout design and construction and even, to a limited degree, into the test activities.

The traditional way of doing requirements analysis is to capture all information about the business need in a single (often very large), rather unstructured document and leave the task of requirements analysis to the developers. However, organizations are beginning to realize that requirements analysis is a specialized field, with the analysis best carried out by experts. These experts are business analysts, who bridge the gap between the business world and the technology world. The business analyst’s role is increasingly accepted in industry, as evidenced by the formation and rapid growth of the International Institute of Business Analysis (IIBA). (See the first book in the series for more information about the IIBA, or refer to its website, http://www.theiiba.org.) In addition, techniques used to analyze requirements are maturing into efficient and effective methods. Techniques introduced in the mid-1980s and 1990s, like a robust stakeholder analysis, the use of prototypes, Unified Modeling Language (UML), use cases, and agile development, are currently in vogue and promise to provide more effective analysis results than those of the past.

Challenges in Requirements Analysis

It is not a trivial endeavor to identify the relevant stakeholders, give them all an appropriate level of involvement in defining and validating requirements, and document their perspectives in a clear, concise format. In addition, the project team is expected to determine whether it is feasible to design and construct a new solution that meets the high-priority requirements within time, cost, legal, and ethical constraints. The challenges involved in requirements analysis are many, but they fall into three main categories:

•   People. The right people—those with adequate experience, technical expertise, and communication skills—might not be available to lead and contribute to the requirements development activities.

•   Bias. The initial ideas about what the solution should look like are often incomplete, optimistic, and firmly entrenched in the minds of the people leading the effort. Therefore, the requirements are constructed to meet the preconceived ideas.

•   Complexity. The difficulty of using the complex tools and diverse methods associated with requirements analysis might get in the way.

Requirements Analysis Activities

The business analyst does not perform the requirements analysis activities alone, but instead performs them in a collaborative and iterative process involving key business and technical SMEs. Analysis activities include:

•   Modeling requirements to restate and clarify them; modeling is accomplished at the appropriate usage, process, or detailed structural level.

•   Studying requirements feasibility to determine whether the requirement is viable technically, operationally, and economically.

•   Trading off requirements to determine the most feasible requirement alternatives.

•   Assessing requirements risks and constraints and modifying requirements to mitigate identified risks.

•   Deriving additional requirements as more is learned about the business need.

•   Structuring requirements into small, stand-alone, manageable components (usually feature-based building blocks) that can be implemented incrementally.

•   Prioritizing requirements to reflect the fact that not all requirements are of equal value to the business. Prioritizing is essential to determine the level of effort, budget, and time required to provide the highest-priority functionality first.

In addition, each unique requirement is assigned a set of attributes. Attributes are useful pieces of information about individual requirements that are used for a variety of purposes, including explanation, selection, allowing filtering and sorting, and validating.

As requirements analysis proceeds, requirement specifications are developed. Through this process of iterative, progressive elaboration, the requirements analysis team often detects areas that are not defined in sufficient detail, which unless addressed can lead to uncontrolled changes to requirements. Requirements documents and models are the output of the requirements analysis and specification process.

What Are Models?

Models are representations of components of a business process, system, or subject area, generally developed for understanding, analysis, improvement, and/or replacement of the process. Often, models are used to represent information, activities, relationships, and constraints that are relevant to the business area undergoing change. A model can take the form of a complex diagram, a structured document, a simple list, or a structured table. According to Ellen Gottesdiener, models are invaluable to business analysis because they:³

•   Make the requirements development process more interesting and engaging to all stakeholders. Using both text and visual models provides variety and permits stakeholders to understand requirements from more than one perspective.

•   Uncover missing, erroneous, vague, and conflicting requirements. Requirements models link together, allowing the team to discover related requirements and inconsistencies between models. Discovering and correcting these errors early results in higher quality requirements and reduces change and rework during design and construction of the solution.

•   Tap into different modes of human thinking. Some people think more precisely with words, while others are better able to understand concepts with diagrams. Text representation of requirements is appropriate when a precise definition is needed, whereas visual representation is useful when depicting dependencies or sequence of events.

•   Facilitate communication between the technical and business teams. Models let team members look at different aspects of the requirements from different perspectives.

It is importance to separate the modeling activities during requirements analysis from those performed during solution design. Analysis is concerned only with modeling the nature of the enterprise, and how it uses information to conduct its operations, whereas design is modeling the solution composed of technology (hardware and software) that supports any manual processes, policies, and procedures. Requirements analysis is concerned with what is to be performed, not how it is performed. To complicate the issue even further, although modeling has been around for a long time, it is not widely practiced. This is not surprising, due to the complexity that abounds in the universe of models. Specific models are interpreted differently by different people and methodologies. Select any specific model, and you will find several alternative names, uses, and descriptions for it. The wise business analyst becomes expert at a few selected models that can be indispensable in documenting the business and validating business requirements.

Stages of Requirements Analysis

The three primary stages in the requirements analysis and specification processes, discussed in detail in Chapters 5, 6, and 7, are:

1. Analyze scope

2. Analyze requirements

3. Specify requirements for the new business solution

Wrapping Up Elicitation Before Starting Analysis

The elicitation phase must be at least partially complete before analysis can begin. In practice, the business analyst moves back and forth between elicitation and analysis. Partially complete means:

•   Interviews have been conducted with key stakeholders to discover their interests, success criteria, concerns, perspectives, etc. Interview notes should be drafted immediately following the interview.

•   Requirements elicitation workshops have been conducted, and the first iteration of several requirements models might have been developed, e.g., use cases, business rules, data models.

•   Several other elicitation activities have likely been completed, including focus groups, observation, user task analysis, and study of existing documentation. A summary of the activities that took place and the resulting learning has been prepared.

Chapter 3 of this book covers transitioning from elicitation. See Unearthing Business Requirements: Elicitation Tools and Techniques, a volume in the Business Analysis Essentials Library, for more information on requirements elicitation.

In addition, the following activities should be complete before analysis starts:

•  Stakeholder identification and assessment. At the start of the elicitation phase, an analysis of stakeholders was conducted. It should be reviewed and updated with information discovered during the elicitation. The stakeholders, or sources of requirements, are identified and assessed. New business solutions change the business environment and relationships between people, so it is important to identify all the stakeholders, take into account all of their needs, and ensure that they understand the implications of the changes brought about by the new business solution. To do this, a formal assessment of each stakeholder’s level of importance to and influence on the project should be conducted. It is important to understand the degree to which the project cannot be considered successful if stakeholder needs, expectations, and issues are not addressed. Influence indicates the stakeholder’s relative power over and within the project. A simple grid with importance on one axis and influence on the other is helpful. The scale could be low, medium, and high for each axis. The stakeholders in the high influence and high importance area should be considered key stakeholders. (See Appendix A, Stakeholder Analysis Template.)

• Requirements planning. The business analyst plans the requirements elicitation, analysis, specification, and validation activities in collaboration with the core project team members (the project manager, technical lead, and business lead) and documents the activities in the requirements management plan (RMP). The RMP was probably initiated at the start of elicitation, and it must be completed before analysis starts. At the same time, the core project team has begun to draft the project plan, schedule, and budget for the overall project. (See Appendix B, Requirements Management Plan Template.)

Endnotes

1. Ellen Gottesdiener. The Software Requirements Memory Jogger, 2006. Salem, NH: GOAL/QPC.

2. Scott Ambler. Agile Analysis. Online at http://www.agilemodeling.com/essays/agileAnalysis.htm (accessed April 2005).

3. Ellen Gottesdiener. The Software Requirements Memory Jogger, 2006. Salem, NH: GOAL/QPC.