IIBA ECBA – Requirements Architecture and Design Options (IIBA – ECBA) Part 2

4. Define Requirements Architecture: Techniques

Define requirements. Architecture Techniques After completing this topic, you should be able to recognize guidelines and techniques for defining the requirements. Architecture managed software includes modeling tools and requirements, management tools, legal and regulatory information, including contractual requirements, may impact the architecture. Methodologies and frameworks such as Agile uses lightweight documentation, but the relationship between user stories and the backlog must be maintained. Frameworks include a predetermined set of models such as use case models or unified modeling language.

Data modeling is used to show how data is structured. Interviews and workshops can be used to collaborate with stakeholders to define how the requirements will be structured and the modeling notations to be used. Functional decomposition breaks down the solution scope or an organizational unit into component parts and illustrates the relationship between them.

So many types of guidelines and tools are used, such as architecture management software, legal and regulatory information, and methodologies and frameworks. Each of the stakeholders show in the diagram are active in determining the requirement structure. For example, implementation subject matter expert provide input in the modeling notation. All the stakeholders will use the architecture to ensure that they are complete based on their viewpoint. The domain subject matter expert will ensure that all the functions, process models and prototypes reflect their needs.

The sponsor will ensure that the requirements reflect the business goals and objectives. The tester will ensure that the requirements are complete and testable the requirements. Architecture defines the requirements and their interrelationships. It also includes any contextual information such as market, environment or political climate. So there are three types of techniques modeling, group techniques and tools. Modeling includes data modeling, organizational modeling and SCA.

Modeling. Group techniques includes interviews and workshops. Tools include functional decomposition. Stakeholders help define architecture and use it to confirm requirements are complete. Stakeholders roles include implementation subject matter expert, doom, main subject matter expert, project manager, sponsor and tester. And don’t forget output requirements. Architecture defines requirements, interrelationships and contextual information.

5. Exercise: Defining the Requirements Architecture

Exercise Defining the Requirement Architecture after completing this topic, you should be able to recognize what’s involved in defining the requirement architecture. So in this exercise, you are required to demonstrate your understanding of what’s involved in defining the requirement architecture. And it involves several tasks identifying characteristics of the requirements architecture identifying benefits of creating a visual representation of the requirements architecture recognizing inputs to the defined requirements architecture task identifying considerations to make when defining the requirements architecture identifying how viewpoints and views are used, understanding how each stakeholder role, guideline, tool and technique help define the requirement architecture and finally, recognizing which stakeholders are involved in defining the requirement structure.

Once requirements are specified, verified and validated, you can define the requirements architecture. What are the characteristics of the requirements architecture? Remember, please try to solve the question yourself and then compare. Here you have the options. It’s a layout of requirements that collectively illustrate how a particular activity state changes. It’s a structure that helps ensure requirements and designs are communicated as a cohesive whole and relate to one another. It’s a structure that is used to demonstrate traceability. And here we have the answer. Option one. That’s incorrect. State changes are reflected in a state change diagram, which may be included as a subcomponent of a requirement architecture.

However, it isn’t the core component of the architecture. Option Two this is the correct option. The purpose of a requirement architecture is to outline how requirements are interrelated. It ensures that requirements all support business goals collectively. Option three. That’s incorrect. The requirements architecture is not intended to demonstrate traceability. Rather, it is used to show how requirements work together to support business and stakeholder needs. The requirements. Analysis and design definition process includes defining the requirements architecture. What are some of the characteristics of a requirement architecture? Here I have the options. It demonstrates the links between requirements for the purposes of traceability.

It results in an information management approach and the solution scope. It structures requirements in a way that makes it clear which functions relate to which processes. And finally, it indicates how requirements relate to one another and align with a particular business goal. Here, I have the answer for you to compare. Option one. That’s incorrect. The requirements architecture is not intended to demonstrate traceability. Instead, it shows how requirements collectively meet business and stakeholder needs. Option two. That’s incorrect. Information Management Approach and Solutions Group are two of the inputs required to define the requirements architecture. Option three. That’s correct. Business analysts define the requirements architecture to determine which function relates to what process requirements are organized accordingly.

Option Four and the last one that’s correct. The requirements architecture is structured in a way that indicates how requirements and models relate to each other to support business goals. The requirements architecture is used for communicating with stakeholders and may include visual representations. What are some of the benefits of creating a visual representation of the requirements architecture? Here we have the options. You can visually represent key decision making stages, you can visually represent how particular use case is executed, you can visually represent traceability during the defined requirement architecture task, and finally you can statistically measure the prioritization of requirements. And here you have the answer option one that’s correct.

The requirements architecture may consist of visual presentations such as a decision tree which illustrates where decisions are made. Option two that’s correct, the requirements architecture may consist of visual presentations such as an activity diagram which helps illustrate how use cases are executed. Option three that’s incorrect. The requirements architecture is not intended to demonstrate traceability and the visual representations are not used for traceability during the defined requirements architecture task.

Option four and the last one that’s obviously incorrect the requirements architecture is not intended again to demonstrate prioritization of requirements, statistically or otherwise. The defined requirements architecture task has both inputs and outputs. What are the inputs to the defined requirements architecture task? Here you have the options the requirements model, the solution scope, the business process model, requirements at any state, and the information management approach. And here you have the answer. Option one that’s incorrect the requirements model is not an input of the defined requirements architectural task. The inputs are requirements at any stage, an information management approach and the solution scope. Option two that’s correct the three inputs of the defined requirements architectural task are requirements at any stage, an information management approach and the solutions comp.

Option Three that’s incorrect, the business process model is not an input of the defined requirements architecture task. The inputs are requirements at any stage, an information management approach and the solutions cop. Option four that’s correct the three inputs of the defined requirements architectural task are requirements at any stage, an information management approach and the solution scope. Option five that’s correct the three inputs of the default requirements architectural task are requirements at any stage, an information management approach and the solution scope.

The requirement architecture task involves mapping out the relationships between requirements. Which considerations should you make when determining the requirements architecture? Here we have the options ensuring that all the requirements relationships are necessary determining whether the information management approach will meet the needs of the requirements ensuring that requirements relationships are defined correctly verifying that the solution scope is big. Enough to accommodate the requirements, ensuring that there are no conflicting requirements relationships and verifying the requirements relationships are consistent and here has the answer option one that’s correct. When defining the requirements architecture, business analysts should consider whether requirements relationships are necessary, whether they are needed for the requirements as a whole. Option two that’s incorrect the information management approach is one of the inputs of the defined requirements architectural task. Whether it meets requirements needs is not a consideration in defining the requirement architecture.

Option three that’s correct relationships between requirements must be defined and they must be correct. As a business analyst, you need to verify there is a relationship and establish what type of relationship it is. Option Four that incorrect the solution scope is one of the inputs of the defined requirements architecture task. Its size is not a consideration when defining the requirement architecture. Option Five that’s correct requirement relationships should be unambiguous. There shouldn’t be conflicting relationships between requirements in the requirement architecture. And lastly, option Six that’s also correct requirements relationships must be consistent in order to be included in the requirement architecture.

When mapping out the requirements relationships for the requirement architecture, business analysts need to consider views and viewpoints. How are viewpoints and views used? Viewpoints define which elements are included in the solution scope. Viewpoints describe how requirements will be documented and communicated according to stakeholder needs. A group of viewpoints collectively form a stakeholder’s view and a collection of views from a stakeholder’s viewpoint and help from an idea of a stakeholder’s requirements. And here you have the answer. Option One that’s incorrect the solution scope is one of the inputs of the defined requirements architectural task that is not defined according to stakeholder’s viewpoints.

Option Two that’s correct viewpoints are conventions that describe how requirements will be documented and communicated according to stakeholders needs. Option three. That’s incorrect. Actually, it is the opposite a group of views collectively form a stakeholders viewpoint, which is an idea of a stakeholder’s requirement. Option Four and the last one that’s correct collection of views from a stakeholder’s viewpoint a viewpoint helps to provide an understanding of what a stakeholder’s requirements and expectations are.

The defined requirements architecture task involves various guidelines and techniques match each stakeholder role, guideline, tool and technique with how it helps define the requirements architecture. Here we have the options functional Decomposition, Legal and Regulatory Information, Data Modeling and Implementation Subject Matter Expert and here we have the targets breaks down the solution scope into ports and represents the relationship among them. Defines how contractual requirements may impact the requirements architecture, shows how requirements are structured and finally provides input into the modeling notation. And here we have the answer functionally composition is a tool that breaks a solution scope or an organizational unit down into its parts to illustrate the relationship between them.

Legal and regulatory information defines how contractual requirements may impact the architecture. Data modeling is a technique that is used to show how the requirements data is structured. Implementation subject Matter Expert provides input into the modeling notation that should be used to establish how the data is structured. In addition to the project manager and implementation subject matter experts, which other stakeholders are involved in defining the requirements architecture? Here you have the options end users, sponsors, testers customers, and domain subject matter experts.

And here you have the answer. Option One That’s Incorrect the stakeholders involved in defining the requirements architecture are implementation subject matter Experts or SMEs domain subject matter experts, project managers, sponsors and testers. Option Two that’s correct the stakeholders involved in defining the requirements architecture are implementation subject matter experts, domain subject matter experts, project managers, sponsors and testers. And again, you should repeat this.

6. Define Design Options: Inputs and Elements

Define design options, inputs and elements. After completing this topic, you should be able to recognize relevant considerations when defining design options. The purpose of design options of these defined design options is to identify business improvement and determine which solution approach addresses the business needs that make that improvement. Requirements are allocated across the solution components. The design options ultimately achieve the desired future state. Each design option is tactical and evolved along with the requirements. The inputs for defining design options include requirements that are validated and prioritized the change strategy and requirements architecture.

The task is to define the design options and the output are the design options themselves. Requirements must be validated by stakeholders before design options can be considered. Prioritized requirements assist in determining design options. The change strategy is determined in the strategy analyzes knowledge area. It describes the approach to transition to the future state and may impact feasibility. The requirements architecture is a set of complete requirements and their relationships. The business analyst assesses if a solution should be purchased or built in house. The implementation team and subject matter experts will develop the solution as defined in the requirements. So defining design options includes inputs, a task and an output.

Inputs include requirements, validated and prioritized. Change strategy and requirements architecture the output includes design options. Various forms of inputs exist, including validated and prioritized requirements. As we said, change strategy and requirements architecture. Validated and prioritized requirements consider only validated requirements and higher priority requirements are given. Preference change strategy is a transition approach to the future state. Requirements architecture is a complete set of requirements and their relationships.

Creating and purchasing are two solution approaches, just an example to create in house. Experts develop a solution and by purchasing the organization outsourced its components owned and maintained by independent parties. Some organizations choose to use a combination of create and purchase software as a solution is one approach which provides software functionality and maintains the structure of the software off the shelf.

Software are installed internally and maintained during. There could be a combination of both approaches to address all of the business needs and requirements. Solution designs are assessed to ensure that they meet the business objectives and key performance metrics. Each design is analyzed to ensure that they increase the efficiency through automation, improving access information and allowing staff to provide services to customers without experts. For example, when a business rules engine is considered as an option, it can automate decisions relating to the business rules.

Also, there may be additional capacities that add value that can be used in the future which had not been considered during the elicitation process. Allocation is the process of assessing requirements and allocating them to solution components and or to releases. Requirements can also be allocated to business units and job functions. The purpose is to optimize allocation to maximize value by maximizing benefits and minimizing cost so improvement opportunities can increase efficiencies, improve access to information and identify additional capabilities. During requirements, allocation requirements are assigned to solution components and allocation can be optimized to maximize value. Allocation continues through design and implementation until all valid requirements are allocated.

The process continues throughout design and implementation until valid requirements are allocated. For example, reporting requirements could be allocated after the implementation of software functions needed to collect the data to be reported. Design options take the future state into consideration and are driven by performance measures. In the public health example, a design option that supports a 95% paperless environment is the preferred option and consists of design components described by Design Elements.

The design elements may describe business policies and rules about how long patient records are stored, purchases to be performed and managed, which could include a process to manage appointments, patient assessments and treatments, rules and responsibilities, and access. For example, the receptionist would not have access to private patient information.

Software applications are used in the solution and organizational structures, so design options are determined when defining the desired future state. They are assessed using performance measures and consist of design components described by Design Elements. Design elements may describe business policies and rules, processes to be performed and manage roles and responsibilities, software applications used in a solution and organizational structures.