Análisis Microbiológico

Business Rules Analysis (9.4)

▶

Data Dictionary and Glossary (9.5)

▶

Data Flow Diagrams (9.6)

▶

Data Modeling (9.7)

▶

Functional Decomposition (9.12)

▶

Interface Analysis (9.13)

▶

Metrics and Key Performance Indicators (9.16)

▶

Non-functional Requirements Analysis (9.17)

▶

Organization Modeling (9.19)

▶

Process Modeling (9.21)

▶

Prototyping (9.22)

▶

Scenarios and Use Cases (9.26)

▶

Sequence Diagrams (9.28)

▶

State Diagrams (9.29)

▶

User Stories (9.33)

▶

Stakeholders 6.3.6

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).

Output 6.3.7

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

Define Assumptions and Constraints 6.4

Purpose 6.4.1

Identify factors other than requirements that may affect which solutions are viable.

Description 6.4.2

Assumptions are factors that are believed to be true, but have not been confirmed.

Assumptions may affect all aspects of the project and pose a certain degree of risk if they do not prove to be true. The business analyst identifies and documents assumptions, attempts to confirm the accuracy of the assumptions, and identifies and manages risks related to the ability of a solution to meet the business need.

Constraints are defined as restrictions or limitations on possible solutions. The business analyst is responsible for documenting any restrictions or limitations to the solution design, construction, testing, validation and deployment. Solution constraints describe aspects of the current state, or planned future state that may not be changed. They are not requirements, since they are not implemented in any form by the project team.

Constraints are provided to the project team to inform them that options they would normally be allowed to consider are not available.

Assumptions and constraints are generally documented with associated attributes (e.g., date identified, owner, impact, associated risk, and other explanatory information). They are defined and clarified as requirements are understood. In many cases, lower-level requirements may be dependent on, and therefore traced back to, the presence of an assumption or constraint and so may be affected if the assumption proves false or the constraint is changed.

Input 6.4.3

Stakeholder Concerns: Assumptions and constraints are identified through elicitation from stakeholders.

Elements 6.4.4

Assumptions .1

An assumption is anything that is believed to be true but that has not actually been verified. Assumptions can relate to something in the present or in the future. Assumptions need to be documented, and if an assumption is found to be false it will usually impact the project in some manner. Assumptions are therefore a source of potential project risk.

Assumptions may also reflect an understanding of how desired outcomes are likely to be achieved. For instance, stakeholders may believe that customers will respond in a certain way to a change in how a product is delivered, but there may be only anecdotal evidence to support that belief.

Business Constraints .2

Business constraints describe limitations on available solutions, or an aspect of the current state that cannot be changed by the deployment of the new solution. They may reflect budgetary restrictions, time restrictions, limits on the number of resources available, restrictions based on the skills of the project team and the stakeholders, a requirement that certain stakeholders not be affected by the implementation of the solution, or any other organizational restriction. Constraints need to be carefully examined to ensure that they are accurate and justified.

Technical Constraints .3

Technical constraints include any architecture decisions that are made that may impact

Requirements Analysis Define Assumptions and Constraints

the design of the solution. These may include development languages, hardware and software platforms, and application software that must be used. Technical constraints may also describe restrictions such as resource utilization, message size and timing, software size, maximum number of and size of files, records and data elements. Technical constraints include any enterprise architecture standards that must be followed.

Technical constraints may create a situation where a requirement cannot be met using the current solution approach or by a solution component and the business analyst must work with the project team to identify other ways to meet the associated business need.

Figure 6–5: Define Assumptions and Constraints Input/Output Diagram Inputs

6.4

Define Assumptions and Constraints

6.4 Assumptions and Constraints

3.3 Stakeholder

Concerns

Tasks Using This Output

7.1 Assess Proposed

Solution 5.4 Define Solution

Scope

Requirements Mgt.

and Communication

+

5.5

Define Business Case

Techniques 6.4.5

Problem Tracking (9.20): Both assumptions and constraints are often identified, reviewed and managed using the ongoing planning, monitoring, and issue/risk management activities of the project team.

Risk Analysis (9.24): Assess the risk (both positive and negative) if an assumption proves invalid, or a constraint is removed.

Stakeholders 6.4.6

Implementation SME: Must take the assumptions and constraints into account when designing a solution.

Project Manager: Must assess assumptions and constraints to identify potential risks that may impact project delivery, and manage against schedule, cost and resource constraints.

All Stakeholders: The stakeholder who is responsible for defining a particular assumption or constraint should be involved in any discussion that involves changing it.

Since assumptions and constraints can originate from and/or affect any stakeholder all stakeholders may be involved in the identification of assumptions or constraints.

Output 6.4.7

Assumptions and Constraints: Assumptions and constraints will limit potential solution options and will be monitored for potential changes. While they are not technically requirements, they can be managed and communicated by performing the tasks in Chapter 4: Requirements Management and Communication.

Verify Requirements