Specify and Model Requirements - Business Analyst


To analyze expressed stakeholder desires and / or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models.


Specifications and models are created to analyze the functioning of an organization and provide insight into opportunities for improvement. They also support a number of other objectives, including development and implementation of solutions, facilitating communication among stakeholders, supporting training activities and knowledge management, and ensuring compliance with contracts and regulations.

The specifics of this task are highly dependent on the techniques used for specifying and modeling requirements.


Requirements [Stated]: Specification or modeling of requirements is performed to structure and improve our understanding of needs as expressed by stakeholders.

Requirements Structure: Defines how the requirement fits into the general requirements and which other sets of requirements may include related information.



A textual requirement must describe the capabilities of the solution, any conditions that must exist for the requirement to operate, and any constraints that may prevent the solution from fulfilling the requirement. Guidelines for writing textual requirements include:

  • Express one and only one requirement at a time.
  • Avoid complex conditional clauses.
  • Do not assume your reader has domain knowledge.
  • Use terminology that is consistent.
  • Express requirements as a verb or verb phrase.
  • Write in the active voice, clearly describing who or what is responsible for fulfilling the requirement.
  • Use terminology familiar to the stakeholders who must review or use the requirement.

2. Matrix Documentation

A table is the simplest form of a matrix. A table is used when the business analyst is looking to convey a 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.

Requirements attributes and data dictionaries are often expressed in tabular form. Matrices are often used for traceability of requirements to each other, from requirements to test cases, and for gap analysis. Matrices are also used for prioritizing requirements by mapping them against project objectives.

A more complex matrix will also express information in the rows of the table. Rather than presenting repeating information, this form of matrix is usually intended to indicate that two elements are related in some fashion (for instance, that a requirement affects a particular data element).

3. Models

Modeling Formats

A model is any simplified representation of a complex reality that is useful for understanding that reality and making decisions regarding it. Models may be either textual or graphical, or some combination of both. Graphical models are often referred to as diagrams.

The choice of which model(s) to use for a particular set of requirements is determined by the type of information to be communicated, as well as the audience who will consume the information. Models can:

  • Describe a situation or define a problem
  • Define boundaries for business domains and sub-domains, and describe the components within each defined boundary
  • Describe thought processes and action flows
  • Categorize and create hierarchies of items
  • Show components and their relationships
  • Show business logic

Whether or not a diagram is used in place of or in addition to a textual description is often determined by the audience for the information, as well as the level of detail in a particular model.

Models may be used not only to document requirements in their final form, but also as a tool while performing elicitation activities.


Describe any symbol or notation used. On diagrams, this often means including a ‘key’ that aids in the interpretation of the symbols and/or colors used, or referring to an external standard.

Formal versus Informal Models

A formal model follows semantics and iconography that are defined in a standard to indicate the meaning of each model element. A formal model can often convey a great deal of meaning, but some of the subtleties of the model may not be properly conveyed to an audience that is unfamiliar with the specific notation.

An informal model does not have a formal semantic definition and instead connects elements in ways that are meaningful for the analyst and the audience. While the model may be less expressive, it requires no special training to interpret.

4. Capture Requirements Attributes

As each requirement or set of requirements is specified and modeled, the relevant attributes, as selected when Plan Requirements Management Process is performed, must be captured.

5. Improvement Opportunities

Analysts should work to identify opportunities to improve the operation of the business. Some common examples of opportunities that a business analyst is likely to identify include:

Automate Or Simplify The Work People Perform: Relatively simple tasks, where decisions are made on the basis of strict or inflexible rules, are prime candidates for automation.

Improve Access To Information: Provide greater amounts of information to staff who interface directly or indirectly with customers, thus reducing the need for specialists. Decision makers may not require this level of detail, but should be made aware of where and from whom they may get it if required. Normally, decision makers need to be provided with the meaning and relevance of the data acquired and used by operational personnel.

Reduce Complexity Of Interfaces: Interfaces are needed whenever work is transferred between systems or between people. Reducing their complexity can improve understanding.

Increase Consistency Of Behavior: Different workers may handle similar cases in a very different fashion, causing customer dissatisfaction and frustration.

Eliminate Redundancy: Different stakeholder groups may have common needs that can be met with a single solution, reducing the cost of implementation.


1. General Techniques

Techniques that can be used to specify or model requirements include:

  • Acceptance and Evaluation Criteria Definition
  • Business Rules Analysis
  • Data Dictionary and Glossary
  • Data Flow Diagrams
  • Data Modeling
  • Functional Decomposition
  • Interface Analysis
  • Metrics and Key Performance Indicators
  • Non-functional Requirements Analysis
  • Organization Modeling
  • Process Modeling
  • Prototyping
  • Scenarios and Use Cases
  • Sequence Diagrams
  • State Diagrams
  • User Stories


Any Stakeholder: The business analyst may choose to perform this task alone and then separately package and communicate the requirements to stakeholders for their review and / or approval, or invite some or all stakeholders to participate in this task (depending on which requirements are being analyzed, the business analysis approach, the preferences of the business analyst, and other factors).


Requirements [Analyzed]: Modeled and specified requirements are produced by this task.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Business Analyst Topics