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

1. Section Overview

The Requirements Architecture and Design Options course is the 7th one of the Business Analysis certification program, which includes a total of 14 courses. This course is part two of requirements analysis and Design. Definition knowledge Area It covers the last three tasks, which are all related to creating Requirements Architecture. You develop a set of designs and analyze those to determine where the best value is. The final step is to develop the solution recommendation that represents the best design. The first section of this course called Define Requirements Architecture includes the following topics requirements Architecture Overview, define Requirements, Architecture, Inputs and Elements, define Requirements, Architecture Techniques. And finally, an exercise on defining the Requirements Architecture.

The second section, the one called Define Design Options, has the following content define design options, inputs and elements. Define design options, guidelines and techniques. Define design options, stakeholders and outputs. And finally, an exercise on defining design options. The last section of this course, called Potential Value and Solutions, has the following structure analyze potential value inputs and Elements analyze potential value guidelines and techniques, recommend the solution elements and outputs and finally on Exercise on Creating Requirements Analysis and Design definitions. Final Output you can use this course to improve your business analyzes knowledge and abilities, and to obtain the certifications provided by the International Institute of Business Analyzes. Next, let’s an overview of the whole Business analyzes certification program.

2. Requirements Architecture Overview

Requirements Architecture Overview after completing this topic, you should be able to identify the characteristics of a Requirement Architecture. We covered the first three steps of Requirements Analysis and Design Definition in the previous course. This course will cover the last three topics task culminating in the final output of Requirements Analyzes and Design Definition. The Solution Recommendation defining Requirements Architecture ensures that the requirements and designs are communicated as a cohesive whole and relate to one another.

Defined Design Options describes the Solution Approach identifies opportunities to improve the business and allocates requirements and designs across solution components which will achieve the future state Analyst Potential Value and Recommend Solutions determines the value of solution options to ensure that they meet the business objectives. According to the Body of Knowledge Guide and I quote the purpose of Defining Requirements Architecture is to ensure that the requirements collectively support one another to fully achieve the objectives. To do this, the inputs required are requirements at any State Information Management Approach and the Solution Scope.

The task define requirements architecture produces the output requirements architecture the requirements. Analyzes and Design definition. Overview consists of six tasks. This is just to remind you. The first three topics in order are specify and mode the requirements, Verify Requirements and Validate Requirements. The second groupic of three topics is highlighted and consists of define requirements, architecture, define design options and analyze potential value and recommend solution. The defined requirements. Architecture process consists of inputs, a task and output. The input are requirements at any state. Information Management Approach and solutions. Cop the task is defined.

Requirements architecture. The output is requirements architectural. Business analysts use the Requirements Architecture to determine which models are appropriate and organize requirements into a structure to ensure that the requirements work together to achieve the overall objectives while working for a public health unit. Just to give an example to implement a paperless office. The Requirements Architecture was designed to address the functions needed by a software product to align to current manual processes, each function related to a process to make and manage appointments, provide and manage patient information record results from health assessment and treatment such as prescriptions or blood test requisitions.

Designs included process maps to support the desired state screen capture, illustrating electronic forms and decision trees illustrating where decisions are made. A Requirement Architecture is not intended to demonstrate traceability, but rather to show how requirements work together to support business requirements and stakeholder needs from the public health example the health records would work with a treatment functionality to maintain patient records accurately. The prescription requirements relates to the treatment requirements, as does the blood test requirements requisition.

Now a graph illustrates the requirements architecture. You will see this in the course. The business objectives consist of Requirements Models and Requirements Specifications architecture a graphic illustrates the way in which requirements work together again, you will see this in the course. In the graphic, there are eleven spherical graphics representing requirements given each connected to the next via directional arrows. Some are connected to more than one requirement they range from one to eleven. For example, requirements one is connected to requirements Three, four, five. And requirements two is connected solely with requirements Five.

It depends on the project. The purpose of Requirements Architecture is to show how requirements and models all fit together, ensures Requirements all support business goals, which means requirements will be combined and they achieve the task necessary to accurately manage patient record. If you still consider our project, the architecture is used for communicating with stakeholders and may consist of one Use Cases text that describes the non Functional Requirements activity diagrams that illustrate how the Use case is executed, and the state diagrams to illustrate how, for example, a patient record state changes from issued to pending. The structure of the Business Analyzes Information is designed as part of the task plan. Business Analyzes information Management requirements Architecture shows how requirements and models all fit together, ensures Requirements all support business goals, and is used for communicating with stakeholders.

The information architecture is a component of the requirements. Architecture? It defines relationship between elicitation, results, requirements and designs. This ensures that a complete set of requirements, by verifying the relationships are complete. Information received through an interview with a doctor, for example, will relate to the model that relates to the requirements, which would include audit and regulatory rules, a data dictionary and the functionality to enter treatment. Information Architecture templates are predefined frameworks based on industry norms and proven practices which provide guidance and help the business analyst to consider each section of the template, thus ensuring a complete picture of the needs. The business analyst may create a template or modified for a particular initiative to meet organizational domain specific needs.

For example, an enhancement would likely not be communicated using a template, which would likely be used to communicate a complex, large enterprise initiative. The enhancement may be communicated using a simple email in the graphic. There are eleven spherical graphics representing requirements given, each connected to the next via directional arrows. You will see this in the course. Some are connected to more than one requirement. They range from Require One to Requirements Eleven or as many as you need in your project. Each requirements fear is accompanied by a text box label. Model Architecture Templates so our predefined framework based on industry are created by a business analyst and our organization domain specific.

3. Define Requirements Architecture: Inputs and Elements

Define Requirements Architecture inputs and Elements after completing this topic, you should be able to recognize considerations that are relevant when defining the requirements architecture. We’ll now look at the elements of the task. Define Requirements Architecture the first thing you need to do when creating a requirements architecture is map out the relationships between requirements. Relationships must be defined, in other words, answering the questions is there a relationship? And what are the types of these relationships? For example, functional requirements that relate to rules would have a business role relationship and when it relates to nonfunctional relationships could be described as a usability relationship or a non functional relationship.

Relationships must be correct and is a check to ensure that there is a relationship. They must be consistent, meaning that relationships are described in the same way they are unambiguous. In other words, relationships that do not conflict and necessary. That means relationships that ensure the relationships are needed to describe the requirements as a whole. So relationships must be defined, correct, consistent, unambiguous and necessary. Viewpoints are conventions that describe how requirements will be documented and communicated. Viewpoints align to the needs of the stakeholders.

They define how requirements will be represented, organized and related. They include guidelines for model types, attributes, notations and analytical approaches. Standards can include model types such as object oriented models, process model notations and data models or regulatory requirements, but also policies shown in the decision trees and in business rules matters. This allows the business analyst to see various views of a need, a process view, a regulatory view and a data view, among others.

The collection of each view creates a complete picture of the requirements that address each stakeholder view. Business process models illustrate the input activities that produce something of value and an output. Data models provide a view of the elements and information needed by the organization and relate to processes.

For example, what are the data elements that are needed to be captured when a patient calls in for an appointment? Requirement viewpoints define how requirements are represented, organized and related. They include guidelines for model types, attributes, notations and analytical approaches. User interactions can be modeled using prototypes and provide information about what the user needs to do and could include interface requirements.

For instance, when a user must access data from another source, use cases describe user interaction and the responses needed by the system to reach a goal. All the requirements describe what must be captured in the case of a transaction and what needs be reviewed to meet regulatory requirements. For example, an audit requirement for prescriptions would record the date, time and personal name who issued the prescription. Business models provide information on how the process is structured, which again can be linked to processes. Multiple views make up a viewpoint. They are the actual requirements and designs for a solution.

Collections of views make up the requirements. Architecture viewpoints provide guidance and information to provide for each stakeholder. Stakeholder groups have different viewpoints, so some examples of requirements viewpoints are business process models, data models and information user interactions use cases or user experiences, audits and security and business models. Just imagine this pyramid graphic shows the relationship between views, viewpoints and stakeholder groups. The base is Views, the second tire is Viewpoints and the third tire is Stakeholder groups. The receptionist viewpoint is about collecting correct appointment information.

Just to give an example, the nurse’s viewpoint is about collecting patient information regarding height, weight and blood pressure and the doctor’s view is about symptoms and treatments. By linking requirements to design and other information, this ensures that requirements are complete. Any dependencies that may keep business objectives from being met are also kept in mind. The architecture helps the stakeholder to see the requirements as a whole to the various stakeholder viewpoints.

Requirements can only be complete once any gaps are identified which result in missing requirements. The viewpoints help with this inconsistency such as requirement describing the information necessary to collect patient information are compared to a mockup of an online form where the field names are different. In the model collecting conflicting requirements must be resolved in this case in the case of the patient information, for example, a business rule may dictate that a patient’s blood pressure must be taken every time and the patient visits the doctor, but a data dictionary shows it as an optional field. To conclude, architecture is used to ensure requirements are complete, dependencies are considered and stakeholders understand the full picture. Requirements must be free of gaps, missing requirements, inconsistencies and conflicts.