Organize Requirements - Business Analyst

Purpose

The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives.

Description

There are two key objectives when organizing requirements.

  • Understand which models are appropriate for the business domain and solution scope.
  • Identify model interrelationships and dependencies. Requirements alone are not complex; it is the relationships and interdependencies among requirements that adds the element of complexity. Therefore, the organized requirements must also clearly depict the inherent relationships between requirements.

Input

Organizational Process Assets: Describe the structures and types of requirements information that stakeholders expect.

Requirements [Stated]: Requirements are stated in various forms as an output from elicitation activities. Stated requirements are the expressed desires of stakeholders, which must be analyzed to ensure that they reflect a genuine need.

Solution Scope: The selected requirements models must be sufficient to fully describe the solution scope from all needed perspectives.

Elements

The following guidelines will assist in promoting consistency, repeatability and a high level of quality:

Follow organizational standards that describe the types of requirements that will be used consistently on projects. If no standard exists, the business analyst must select an appropriate set of techniques.

Use simple, consistent definitions for each of the types of requirements described in natural language, and using the business terminology that is prevalent in the enterprise.

Document dependencies and interrelationships among requirements.

Produce a consistent set of models and templates to document the requirements, as described in Specify and Model Requirements.

The various levels of abstraction and models used are not mutually exclusive. It will usually be beneficial to create multiple models of and perspectives on the requirements in order to ensure understanding, although any given requirement should only appear in one model in order to avoid confusion or contradictions.

1. Levels of Abstraction

Requirements can be articulated on a number of different levels of abstraction. Requirements are frequently described as needing to say what needs to be done, not how to do it. This formulation can be problematic, as whether something is a “what” or a “how” depends on the perspective of the audience. For instance, a decision to implement a business process management engine can be what we are doing (from the perspective of the project team) and how we are improving our process agility (from the perspective of the enterprise architecture group). When practicing business analysis, we can distinguish between what and how by understanding that our perspective on the difference between those terms needs to be aligned with the perspective of our business stakeholders.

There are a number of formal structures for levels of abstraction, including those outlined in enterprise architecture frameworks. Alternatively, the business analyst may informally designate a set of requirements as “high” or “low” level based on the level of detail included. While requirements often become less abstract as the business analyst defines business requirements, stakeholder requirements, and solution requirements, this is not mandatory - any category of requirement can be expressed at whatever level of abstraction is appropriate for the audience. Methodologies may also determine the level of abstraction used when defining requirements.

2. Model Selection

The business analyst must determine which types of models will be required to describe the solution scope and meet the informational needs of stakeholders. These needs may vary over time.

Models abstract and simplify reality. No model can be a complete description of reality; the objective of developing a model is to simplify reality in a way that is useful. Each model represents a different view into the reality of the business domain. It is usually necessary to develop multiple models using different modeling techniques to completely analyze and document requirements.

Models do not have any inherent hierarchy - effective analysis can potentially start with any aspect of the model and reach out to encompass the others. For example, use case analysis can start with goals or events and capture process and relevant rules. Business Process Management starts by identifying processes and then derive roles, events and rules from the processes.

There are a number of general modeling concepts that are relevant to business analysis:

User Classes, Profiles, or Roles. These models categorize and describe the people who directly interact with a solution. Each role groups together people with similar needs, expectations, and goals. Each role is likely to correspond to a stakeholder and should be investigated as a source of requirements.These are usually identified by performing Conduct Stakeholder Analysis and are used in a number of analysis models, particularly in organization models, process models, and use cases

Concepts and Relationships.Concepts usually correspond to something in the real world; a place, a person, a thing, an organization. They define the objects, entities or facts that are relevant to the business domain and what relationships they have with other concepts. Data models expand on this to also describe the attributes associated with a concept.

Events. A request to a business system or organization to do something, such as a customer placing an order, or a manager requesting a report, can be described as an event. The organization must respond to an event, and in most cases an event will trigger or affect a business process. Events can come from outside the business area, from within it, or occur at scheduled times. Events can serve as the basis for a scope model and may be described in other models, including process models, state diagrams, and use cases.

Processes. Processes are a sequence of repeatable activities executed within an organization. Processes can be simple (involving one person and a system) or complex (involving many people, departments, organizations and systems). Processes describe who and what has to be involved in fully responding to an event, or how people in the enterprise collaborate to achieve a goal. Processes are normally described in process models, although useful information may also be captured in organization models, state diagrams, or use cases .

Rules. Rules are used by the enterprise to enforce goals and guide decision - making. They determine when information associated with an entity may change, what values of information are valid, how decisions are made in a process, and what the organization’s priorities are. Business rules are normally described as such, although they may also be embedded in process models, state diagrams, and use cases.

Choose a set of modeling techniques that meet the informational needs of stakeholders and allow description of all five concepts to ensure full coverage of a business domain (assuming that full coverage is required).

Techniques

Business Rules Analysis : Business rules may be separated from other requirements for implementation and management in a business rules engine or similar.

Data Flow Diagrams: Shows how information flows through a system. Each function that modifies the data should be decomposed into lower levels until the system is sufficiently described.

Data Modeling: Describes the concepts and relationships relevant to the solution or business domain.

Functional Decomposition: Breaks down an organizational unit, product scope, or similar into its component parts. Each part can have its own set of requirements.

Organization Modeling: Describes the various organizational units, stakeholders, and their relationships. Requirements can be structured around the needs of each stakeholder or group.

Process Modeling: Requirements may be organized around relevant processes.

Processes themselves can embed subprocesses, and describe a hierarchy from the top level, end-to-end processes to the lowest - level individual activities.

Scenarios and Use Cases: Describe the requirements that support the individual goals of each actor, or the response to the triggering event.

Scope Modeling: Requirements may be organized based on the solution components they are related to.

User Stories: Describe the stakeholder objectives that the solution will support.

Stakeholders

Domain SME, End User, Implementation SME, and Sponsor: Affected by analysis techniques used to organize requirements since they need to verify and validate the requirements. The business analyst tailors the approach to meet the needs of key stakeholder groups, and must determine which models will be useful to each.

Project Manager: Uses the organized set of requirements to verify the scope of the solution and assess the work that needs to be done in the project.

Output

Requirements Structure: The output of this task is an organized structure for the requirements and a documented set of relationships between them. This structure is distinct from tracing, which links related requirements; rather, this structure is used so that the analyst and stakeholders know where a specific requirement should be found. Each model or set of requirements within the structure should have a clear implicit scope; that is, it should be clear to stakeholders what a particular model will and will not describe.

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

Business Analyst Topics