3.4.1 Purpose
The purpose of Plan Business Analysis Information Management is to develop an approach for how business analysis information will be stored and accessed.
3.4.2 Description
Business analysis information is comprised of all the information business analysts elicit, create, compile, and disseminate in the course of performing business analysis. Models, scope statements, stakeholder concerns, elicitation results, requirements, designs, and solution options are just a few examples. This includes requirements and designs, from lightweight user stories to formal requirement documents to functioning prototypes.
Information management entails identifying:
- how information should be organized,
- the level of detail at which information should be captured,
- any relationships between the information,
- how information may be used across multiple initiatives and throughout the enterprise,
- how information should be accessed and stored, and
- characteristics about the information that must be maintained. Information management helps ensure that business analysis information is organized in a functional and useful manner, is easily accessible to appropriate personnel, and is stored for the necessary length of time.
3.4.3 Inputs
- Business Analysis Approach: incorporating the overall business analysis approach into the information management approach is necessary to ensure consistency across the approaches.
- Governance Approach: defines how business analysts manage changes to requirements and designs, how decisions and approvals for business analysis deliverables will be made, and how priorities will be set.
- Stakeholder Engagement Approach: identifying stakeholders and understanding their communication and collaboration needs is useful in determining their specific information management needs.
3.4.4 Elements
.1 Organization of Business Analysis Information
Business analysts are responsible for organizing business analysis information in a manner that allows for efficient access and use. Information must be well structured to ensure it is not difficult to locate, conflicts with other information, or is needlessly duplicated.
The business analyst determines how best to structure and organize the business analysis information at the start of an initiative. This involves taking into consideration the type and amount of information to be collected, the stakeholder’s access and usage needs, and the size and complexity of the change.
Relationships among the types of information must be defined to assist in managing the effect of new or changed information in the future.
.2 Level of Abstraction
Level of abstraction describes the breadth and depth of the information being provided. Representations of information may range from highly conceptual or summarized to very detailed. In determining how much detail each stakeholder may require as the initiative evolves, consideration is given to the needs of the stakeholders, the complexity of what is being explained, and the importance of the change. Rather than present the same information to all stakeholders, business analysts should present information with appropriate breadth and level of detail based on each stakeholder’s role. Business analysis information regarding a topic of significant importance or high level of risk is frequently represented in greater detail.
.3 Plan Traceability Approach
The traceability approach is based on:
- the complexity of the domain,
- the number of views of requirements that will be produced,
- any requirement-related risks, organizational standards, applicable regulatory requirements, and
- an understanding of the costs and benefits involved with tracing. Business analysts plan to ensure the approach is at a level of detail to add value without excessive overhead.
.4 Plan for Requirements Reuse
Reusing requirements can save an organization time, effort, and cost – provided the requirements are accessible and structured in a manner that supports their reuse.
Requirements that are potential candidates for long-term use are those an organization must meet on an ongoing basis such as:
- regulatory requirements,
- contractual obligations,
- quality standards,
- service level agreements,
- business rules,
- business processes, or
- requirements describing products the enterprise produces.
Requirements may also be reused when describing common features or services that are used across multiple systems, processes, or programs.
To make requirements useful beyond the current change, business analysts plan ahead for requirements reuse by identifying how best to structure, store, and access requirements so they are usable and accessible for future business analysis efforts.
In order for requirements to be reused they must be clearly named, defined, and stored in a repository that is available to other business analysts.
.5 Storage and Access
Business analysis information can be stored in many ways. Storage decisions depend on many factors such as who must access the information, how often they need to access it, and what conditions must be present for access.
Organizational standards and tool availability also influence storage and access decisions. The business analysis approach defines how various tools will be used on the initiative and how the information will be captured and stored within those tools. Tools may shape the selection of business analysis techniques, notations to be used, and the way that information is organized.
The repository may need to store information other than requirements and designs. It should be able to indicate the status of any stored information, and allow for modification of that information over time.
.6 Requirements Attributes
Requirements attributes provide information about requirements, and aid in the ongoing management of the requirements throughout the change. They are planned for and determined with the requirements themselves.
Requirements attributes allow business analysts to associate information with individual or related groups of requirements. The information documented by the attributes helps the team efficiently and effectively make trade-offs between requirements, identify stakeholders affected by potential changes, and understand the effect of a proposed change.
Some commonly used requirements attributes include:
- Absolute reference: provides a unique identifier. The reference is not altered or reused if the requirement is moved, changed, or deleted.
- Author: provides the name of the person who needs to be consulted should the requirement later be found to be ambiguous, unclear, or in conflict.
- Complexity: indicates how difficult the requirement will be to implement.
- Ownership: indicates the individual or group that needs the requirement or will be the business owner after the solution is implemented.
- Priority: indicates relative importance of requirements. Priority can refer to the relative value of a requirement or to the sequence in which it will be implemented.
- Risks: identifies uncertain events that may impact requirements.
- Source: identifies the origin of the requirement. The source is often consulted if the requirement changes or if more information regarding the requirement or the need that drove the requirement has to be obtained.
- Stability: indicates the maturity of the requirement.
- Status: indicates the state of the requirement, whether it is proposed, accepted, verified, postponed, cancelled, or implemented.
- Urgency: indicates how soon the requirement is needed. It is usually only necessary to specify this separately from the priority when a deadline exists for implementation.
3.4.5 Guidelines and Tools
- Business Analysis Performance Assessment: provides results of previous assessments that should be reviewed and incorporated into all planning approaches.
- Business Policies: define the limits within which decisions must be made. They may be described by regulations, contracts, agreements, warranties, certifications, or other legal obligations.
- Information Management Tools: each organization uses some tools to store, retrieve, and share business analysis information. These may be as simple as a whiteboard, or as complex as a global wiki or robust requirements management tool.
- Legal/Regulatory Information: describes legislative rules or regulations that must be followed, and helps determine how business analysis information will be managed.
3.4.6 Techniques
- Brainstorming: used to help stakeholders uncover their business analysis information management needs.
- Interviews: used to help specific stakeholders uncover their business analysis information management needs.
- Item Tracking: used to track issues with current information management processes.
- Lessons Learned: used to create a source of information for analyzing approaches for efficiently managing business analysis information.
- Mind Mapping: used to identify and categorize the kinds of information that need to be managed.
- Process Modelling: used to document the process or method for managing business analysis information.
- Survey or Questionnaire: used to ask stakeholders to provide input into defining business analysis information management.
- Workshops: used to uncover business analysis information management needs in a group setting.
3.4.7 Stakeholders
- Domain Subject Matter Expert: may need to access and work with business analysis information, and will be interested in a more specific view of business analysis information which relates to their area of expertise.
- Regulator: may define rules and processes related to information management.
- Sponsor: reviews, comments on, and approves business analysis information.
3.4.8 Outputs
• Information Management Approach: includes the defined approach for how business analysis information will be stored, accessed, and utilized during the change and after the change is complete.
