Chapter 7 – 7.1 – Specify and Model Requirements

7.1.1 Purpose

The purpose of Specify and Model Requirements is to analyze, synthesize, and refine elicitation results into requirements and designs.

7.1.2 Description

Specify and Model Requirements describes the practices for analyzing elicitation results and creating representations of those results. When the focus of the specifying and modelling activity is on understanding the need, the outputs are referred to as requirements. When the focus of the specifying and modelling activity is on a solution, the outputs are referred to as designs

Important

In many IT environments, the word “design” is used specifically for technical designs created by software developers, data architects, and other implementation subject matter experts. All business deliverables are referred to as “requirements”.

In addition to the models used to represent the requirements, this task also includes capturing information about attributes or metadata about the requirements. The specifying and modelling activities relate to all requirement types.

7.1.3 Inputs

Elicitation Results (any state): modelling can begin with any elicitation result and may lead to the need for more elicitation to clarify or expand upon requirements. Elicitation and modelling may occur sequentially, iteratively, or concurrently.

7.1.4 Elements

.1 Model Requirements

A model is a descriptive and visual way to convey information to a specific audience in order to support analysis, communication, and understanding.

Models may also be used to confirm knowledge, identify information gaps that the business analyst may have, and identify duplicate information.

Business analysts choose from one or more of the following modelling formats:

Matrices: a matrix is used when the business analyst is modelling a requirement or set of requirements that have a complex but uniform structure, which can be broken down into elements that apply to every
entry in the table. Matrices may be used for data dictionaries, requirements traceability, or for gap analysis. Matrices are also used for prioritizing requirements and recording other requirements attributes and metadata.
Diagrams: a diagram is a visual, often pictorial, representation of a requirement or set of requirements. A diagram is especially useful to depict complexity in a way that would be difficult to do with words. Diagrams can also be used to define boundaries for business domains, to categorize and create hierarchies of items, and to show components of objects such as data and their relationships.

Using one or more of the model formats, business analysts determine specific categories and specific models within categories to be used. Model categories can include:

People and Roles: models represent organizations, groups of people, roles, and their relationships within an enterprise and to a solution. Techniques used to represent people and their roles include Organizational Modelling, Roles and Permissions Matrix and Stakeholder List, Map, or Personas.
Rationale: models represent the “why” of a change. Techniques used to represent the rationale include Decision Modelling, Scope Modelling, Business Model Canvas, Root Cause Analysis, and Business Rules Analysis.
Activity Flow: models represent a sequence of actions, events, or a course that may be taken. Techniques used to represent activity flows include Process Modelling, Use Cases and Scenarios, and User Stories.
Capability: models focus on features or functions of an enterprise or a solution. Techniques used to represent capabilities include Business Capability Analysis, Functional Decomposition, and Prototyping.
Data and Information: models represent the characteristics and the exchange of information within an enterprise or a solution. Techniques used to represent data and information include Data Dictionary, Data Flow Diagrams, Data Modelling, Glossary, State Modelling, and Interface Analysis.

Business analysts should use any combination of models best suited to meet stakeholder needs in a given context. Each modelling technique has strengths and weaknesses and provides unique insights into the business domain.

.2 Analyze Requirements

Business analysis information is decomposed into components to further examine for:

anything that must change to meet the business need,
anything that should stay the same to meet the business need,
missing components,
unnecessary components, and
any constraints or assumptions that impact the components.

The level of decomposition required, and the level of detail to be specified, varies depending on the knowledge and understanding of the stakeholders, the potential for misunderstanding or miscommunication, organizational standards, and contractual or regulatory obligations, among other factors. Analysis provides a basis for discussion to reach a conclusion about solution options.

.3 Represent Requirements and Attributes

Business analysts identify information for requirements and their attributes as part of the elicitation results. Requirements should be explicitly represented and should include enough detail such that they exhibit the characteristics of requirements and designs quality (see Verify Requirements (p. 141)). Various attributes can be specified for each requirement or set of requirements. These attributes are selected when planning for information management (see Plan Business Analysis Information Management (p. 42)).

As part of specifying requirements, they can also be categorized according to the schema described in task Requirements Classification Schema (p. 16). Typically elicitation results contain information of different types, so it is natural to expect that different types of requirements might be specified at the same time.

Categorizing requirements can help ensure the requirements are fully understood, a set of any type is complete, and that there is appropriate traceability between the types.

.4 Implement the Appropriate Levels of Abstraction

The level of abstraction of a requirement varies based on the type of requirement and audience for the requirement. Not all stakeholders require or find value in the complete set of requirements and models. It may be appropriate to produce different viewpoints of requirements to represent the same need for different stakeholders. Business analysts take special care to maintain the meaning and intent of the requirements over all representations.

The business analysis approach may also influence the level of abstraction and choice of models used when defining requirements.

7.1.5 Guidelines and Tools

Modelling Notations/Standards: allow requirements and designs to be precisely specified, as is appropriate for the audience and the purpose of the models. Standard templates and syntax help to ensure that the right information is provided about the requirements.
Modelling Tools: software products that facilitate drawing and storing matrices and diagrams to represent requirements. This functionality may or may not be part of requirements life cycle management tools.
Requirements Architecture: the requirements and interrelationships among them can be used to ensure models are complete and consistent.
Requirements Life Cycle Management Tools: software products that facilitate recording, organizing, storing, and sharing requirements and designs.
Solution Scope: the boundaries of the solution provide the boundaries for the requirements and designs models.

7.1.6 Techniques

Acceptance and Evaluation Criteria: used to represent the acceptance and evaluation criteria attributes of requirements.
Business Capability Analysis: used to represent features or functions of an enterprise.
Business Model Canvas: used to describe the rationale for requirements.
Business Rules Analysis: used to analyze business rules so that they can be specified and modelled alongside requirements.
Concept Modelling: used to define terms and relationships relevant to the change and the enterprise.
Data Dictionary: used to record details about the data involved in the change. Details may include definitions, relationships with other data, origin, format, and usage.
Data Flow Diagrams: used to visualize data flow requirements.
Data Modelling: used to model requirements to show how data will be used to meet stakeholder information needs.
Decision Modelling: used to represent decisions in a model in order to show the elements of decision making required.
Functional Decomposition: used to model requirements in order to identify constituent parts of an overall complex business function.
Glossary: used to record the meaning of relevant business terms while analyzing requirements.
Interface Analysis: used to model requirements in order to identify and validate inputs and outputs of the solution they are modelling.
Non-Functional Requirements Analysis: used to define and analyze the quality of service attributes.
Organizational Modelling: used to allow business analysts to model the roles, responsibilities, and communications within an organization.
Process Modelling: used to show the steps or activities that are performed in the organization, or that must be performed to meet the desired change.
Prototyping: used to assist the stakeholders in visualizing the appearance and capabilities of a planned solution.
Roles and Permissions Matrix: used to specify and model requirements concerned with the separation of duties among users and external interfaces in utilizing a solution.
Root Cause Analysis: used to model the root causes of a problem as part of rationale.
Scope Modelling: used to visually show a scope boundary.
Sequence Diagrams: used to specify and model requirements to show how processes operate and interact with one another, and in what order.
Stakeholder List, Map, or Personas: used to identify the stakeholders and their characteristics.
State Modelling: used to specify the different states of a part of the solution throughout a life cycle, in terms of the events that occur.
Use Cases and Scenarios: used to model the desired behavior of a solution, by showing user interactions with the solution, to achieve a specific goal or accomplish a particular task.
User Stories: used to specify requirements as a brief statement about what people do or need to do when using the solution.

7.1.7 Stakeholders

Any stakeholder: business analysts may choose to perform this task themselves and then separately package and communicate the requirements to stakeholders for their review and approval, or they might choose to invite some or all stakeholders to participate in this task.

7.1.8 Outputs

Requirements (specified and modelled): any combination of requirements and/or designs in the form of text, matrices, and diagrams.