IIBA ECBA – Requirements Analysis and Design Definition (IIBA – ECBA) Part 2
- Specify and Model Requirements: Inputs and Elements
Specify and model requirements, inputs and elements. After completing this topic, you should be able to recognize considerations that are relevant when modeling and analyzing requirements. The purpose of specify and model requirements is to take elicitation results, amalgamate the them, analyze them, model, and organize the information into requirements and designs. This is a primary activity of business analysis. Elicitation results are obtained through various requirements discovery techniques. Once the information is gathered, it is confirmed and ready to be analyzed. The task specifies and model requirements utilizes modeling techniques such as process models, data and scope models, among others, to create an organized view of the requirements. The output is a specified and modeled requirements.
Modeling requirements is a visual way of communicating requirements. It is also a way of analyzing information using different views of the information. One view, which is a flow of activities, inputs, activities, actions, and outputs. The specify and model requirements process involves inputs, a task and an output. The inputs are elicitation results in any state. The task is specified and model requirements, and the output is requirements that are specified and modeled.
Data modeling can be in matrix format or diagram format. The data flow diagram views the business need as a process whereby information flows within the process. Data models are a static view of the information the organization needs to collect to produce business intelligence. Matrices are used to take complex information and create a uniform structure. They can be used for requirements, traceability gap analysis, periodizing requirements, and recording attributes and metadata. Diagrams are, on the other hand, are used to depict information visually.
They depict complexity in a visual form and can be used to define boundaries, categorize items, create item hierarchies, and display object components and their relationships. There are various modeling categories that are supported by techniques. People and drawers are modeled using organizational models such as organizational charts. Personas rationale models include those techniques used to describe why a change is occurring. They include scrub models, decision models, the business model, canvas, root cause analyzes, and business rules analyzes. Activity flow models depict what happens or flow of activities and events. This includes user stories, process flow scenarios, and use cases.
The metrics modeling format has a complex uniform structure and can be used for requirements, traceability gap analysis, prioritizing requirements and recording attributes and metadata. The diagram modeling format depicts complexity in a visual form and can be used to define boundaries, categorize items, create item hierarchies, and display object components and their relationships. So there are five model categories people and roles, rational, activity, flow capability and data and information capability. Models communicate functions, often enterprise or selections. Functional decomposition, capability analysis and prototyping are used to describe capabilities.
Data and information. Models use techniques such as data dictionaries, data flow diagrams, data models, glossaries, interface analysis and state models to describe the characteristics of the information used by the organization to make decisions and interact with other systems. Analyzing is an activity that decomposes business analyzes information into components. This is referred to as abstraction and will be covered shortly. The Business Analyst will analyze components to determine what must change to meet the need, what must remain unchanged, are there any missing components, are there any unnecessary components, and what constraints or assumptions may impact those components. Requirements Attributes describe metadata about the Requirement during the creation of the Business Analyzes Plan, the Business Analyst will specify which attributes will be used when planning information management. Analyzing Requirements involves breaking information down into components.
Remember this the Business Analyst analyzes the components to determine what must change to meet the need, what must remain unchanged to meet the need, if there are any missing components, if there are any unnecessary components, and what constraints or assumptions may impact the components. I’m repeating this on purpose. Requirements Attributes describe the quality characteristics of Requirements and design attributes such as Author of the Requirement, unique Identifier and Priority help to describe the requirements. Requirements are also categorized based on the Requirements Classification schema Business Requirements, Stakeholder Requirements functional and Non Functional Requirements are in the Requirements Schema.
The level of abstraction depends on where the Business Analyst is in his or her process and who will be consuming the information. For example, when the business is describing what they need to meet a business challenge, the information is conceptual and described at a high level or feature level, such as Manage Patient Information. This level is then decomposed into sub components of the feature or the logical level. So Manage Patient Information would be broken down into describe the patient information that’s needed the process to manage patient information, the rules associated to manage the information and would be accompanied by design, such as a prototype of a form used by the patient to enter his or her information.
Another way to look at obstruction is to use the Requirements categories. Business Requirements are decomposed into Stakeholder Requirements, which may be decomposed into Functional and Non Functional Requirements. So as attributes should be specified when planning for information management, and they should be categorized by type. The level of obstruction depends on the type of requirement and the type of audience. It should be specified in the Business Analyzed approach.
- Requirements Modeling: Guidelines and Tools
Requirements. Modeling Guidelines and Tools After completing this topic, you should be able to recognize activities related to specifying and modeling requirements. There are many guidelines and tools to use when specifying and modeling requirements. Modeling notations are like a language that uses symbols, and there are various dialects used. For example, structured Analysis uses entity relationship diagrams to describe data, and one notation is referred to as the brace notation.
This notation uses a crowfoot symbol to describe a many relationship between data elements. In other words, a data element called Customer can have many accounts. Business Process Modeling Notation is a popular approach for modeling processes. Modeling tools include Visio for modeling all kinds of diagrams and Erwin for modeling data Visual Paradigm is used to model use cases. Requirements These are just some examples. A requirement architecture is a collection of all the requirements communicated as a cohesive whole requirement. Lifecycle management tools help to address requirements changes, traceability and storage solutionscope is modeled using context diagrams or other models to describe the boundaries of a solution. I’ll address a few of the techniques used by the business analyst to analyze and describe requirements. There are several guidelines and tools to use when specifying and modeling requirements.
They include modeling notations and standards, modeling tools, requirement architecture requirements, lifecycle management tools and solutions cop techniques for specifying and modeling requirements a table list and you will see this in the course lectures. A table list examples of techniques used to analyze and describe requirements analyzes modeling, group techniques, tools, and document reviews. The Analyzes column includes business Capability Analyzes, business rules, Analyzes, interface analyzes, nonfunctional requirements to analyze, and root cause analyzes. The modeling column includes business model canvas, concept modeling, data modeling, decision modeling, organizational modeling, process modeling, and state modeling. The Group Techniques column includes focus groups, interviews, surveys, and questionnaires and workshops.
The Tools column includes data dictionaries, data flow diagrams, functionally composition, glossaries, prototyping roles and permissions matrices and sequence diagrams. The Document Reviews column includes acceptance and evaluation criteria take all the list maps or personas, use cases and scenarios, and user stories. Business Capability Analysis describes what an organization or department can do. Capabilities help the organization to achieve its goals. The methods to achieve those goals may change, but the capability remains constant.
For example, capabilities of a grocery store include the knowledge and skills needed to purchase and manage goods consumed by a customer. A product manager may use various research techniques to determine what the customer wants to purchase, but the product management capability would not change. Capabilities must have clear definitions and are unique based on the information used. Capabilities ensure the organization meets its goals by reducing cost, increasing customer value, improving service, and meeting compliance regulations. Decision Modeling uses decision trees and decision tables to illustrate how business decisions are made based on business rules. These models are linked to organizations, processes, and performance measures.
For example, a decision table lists the condition, the rules associated with the condition and the outcomes. A condition such as an insurance claim would map to eligibility rules with an outcome of eligible or ineligible. Surveys are used to gather data based on answers to a series of questions. The questions are used to elicit opinions from stakeholders regarding customer satisfaction, products and processes. Close ended questions are used along with list or likely to scale with a rating of one to five denoting a high to low score.
Open ended questions are used by the respondent to enter freeform text. The resulting data is analyzed to make determinations about the survey topic. This is a relatively inexpensive way to reach a large dispersed audience. Roles and permissions metrics defines the roles associated with functions which are associated to activities. The roles are assembled into groups. For example, one group may represent operations made up of an administrator and manager. The approval of a credit line would be assigned to the manager but not to the administrator. The tool is used to identify roles and ensure that the authorities are assigned to the right role and ensure that all roles and functions are listed. Acceptance criteria is used to define the conditions needed for the requirements to be acceptable. It describes the minimum requirements needed to be met in order to implement the solution. Acceptance criteria is measured in a testable format, so when a user acceptance test is incomplete, it either has a true pass or force failed outcome evaluation criteria are measured to determine which solution meets the defined requirements. Value attributes are characteristics that define the value of the solution to the stakeholder.
They could include the ability to support operations, specific features, usability, and performance. The evaluation criteria is often described in a scale. Stakeholders are involved in specifying the requirements needed to meet their needs. They will work with a business analyst during elicitation activities, for example, during a workshop. The business analyst models a process flow to help the stakeholders think through each aspect of the process and fill in the blanks, identify issues and make suggestions for improvement.
Once the requirements are analyzed, the models are used to communicate the requirements which the stakeholders will review and approve. The outcome is a set of cohesive requirements that are specified with accompanying diagrams and designs. Requirements are communicated using text matrices and diagrams so all stakeholders are involved. There are two approaches stakeholders can help specify the requirements or stakeholders can review the work done by the business analyst. The output is specified, specified and modeled. Requirements the requirements could be text based matrices or diagrams.
- Exercise: Defining Requirements
Exercise Defining Requirements after completing this topic, you should be able to recognize what’s involved in specifying and modeling requirements. So in this exercise, you will demonstrate your understanding of what is involved in specifying and modeling requirements. This involves the following following task identifying the input recognizing modeling categories establishing when to use matrices and diagrams identifying guidelines, tools, and techniques in defining requirements and understanding the role of the stakeholders during requirement analysis and design definition activities information is analyzed by using different representations and ways of organizing the data. What is the input to the Specify and Model requirements task?
Here you have the options Elicitation results, requirement Models, Requirements Matrices, and Requirements diagrams and here you have the answer. Option One this option is correct. Elicitation results are obtained through various requirements discover techniques. Once the requirement is confirmed, it is ready to be analyzed. Option Two this option is incorrect. The output of the task is specified and modeled requirements, which could be in the form of text matrices or diagrams. Option Three this option is incorrect. The creation of requirements matrices is used for prioritizing requirements and recording other requirements, attributes and metadata. Option Four this option is incorrect. A diagram is a visual of an pictorial representation of a requirement or set of requirements. Modeling requirements is a visual way of communicating requirements. Identify the modeling categories.
Here you have the options data and information, people and roles, diagrams, activity flow, and organizational charts. And here you have the answer. Option One this option is correct. Data and information models use techniques such as data dictionaries, data flow diagrams, data models, glossaries, and interface analysis. Option Two this option is correct. People and drawers are modeled using organizational models such as organizational charts, personas, stakeholders, stakeholder drawers, and permission matrices. Option Three this option is incorrect. This is a method used to model the requirements. Option Four this option is correct.
Activity flow models depict what happens or a flow of activities and events. Option Five this option is incorrect. This is a method used to model the roles of people in organization. Matrices and diagrams are commonly used to model requirements. Match each requirement to the method that you would use. In that case, each method may have more than one match. Here you have the options, Requirements Traceability, prioritizing Requirements, defining Boundaries, recording attributes, and categorizing items. And here you have the targets, metrics, and diagram.
And here have the answer to compare. This method is used to take complex information and create a uniform structure. For example, in Requirements traceability, privatization of requirements, and recording of attributes. This method is used to depict complexity in a visual form. For example, to define boundaries and categorize items. Certain elements need to be considered during the Specify and Model requirements task.
Which of the following factors should you consider when analyzing requirements during the task? Here have the options are there any unnecessary components? Are there constraints or assumptions that could impact certain components? How is the need communicated? Which stakeholders are involved in the process? And finally, what needs to change in order to meet the need? And here I have the answer. Option One this option is correct. Unnecessary components need to be identified and removed. Option Two this option is correct. Constraints need to be investigated and their impact considered. Option Three this option is incorrect. This is not one of the main considerations used during the analyzes of requirements.
Option four disruption is incorrect. This is not relevant to the analysis of the requirements. And finally option Five this option is correct. Changes and their impact need to be considered. There are several guidelines, techniques and tools used when performing the Specify and Model requirements task identify appropriate activities used when specifying and modeling requirements. Here we have the options performing a business capability analysis, creating decision trees, conducting surveys, item tracking, and identifying possible stakeholders. And here we have the answer for you to compare. Option One this option is correct. A business Capability Analyzer describes what an organizational department can do.
Capabilities help the organization to achieve its goals. Option Two this option is correct. Decision Modeling uses decision trees and decision tables to illustrate how decisions are made based on business rules. Option Three this option is correct. Group techniques like surveys are used to gather data from stakeholders regarding customer satisfaction, products and processes. Option Four this option is incorrect. This task is not related to specifying and modeling requirements. Option Five this option is incorrect. At this point, the stakeholders have already been identified. Analyzing requirements is an integral part of the requirements analyzes and design definition activities. What roles do stakeholders play in analyzing and designing requirements?
Here have the options reviewing requirements, specifying requirements, estimation of timing, ensuring operational support, and working with analysts during a list station. Here you have the answer. Option One this option is correct. Once the requirements are analyzed, the models are used to communicate the requirements. Which stakeholders will review and approve? Option Two this option is correct. Stakeholders are involved in specifying the requirements needed to meet their business needs. Option Three this option is incorrect. This is the responsibility of the business analyst during planning and monitoring. Option Four this option is incorrect. This is not a stakeholder activity during requirement specification and modeling activities. Option Five and the last One this option is correct. The stakeholders can assist in gathering information.
- Verify Requirements: Inputs and Elements
Verify requirements, inputs and Elements after completing this topic, you should be able to recognize considerations that are relevant when verifying requirements. The purpose of the task verify Requirements and designs is to ensure that they are of sufficient quality and understood by the implementation team in order to move forward to the next phase. The inputs are specified and modeled. Requirements the task is to verify requirements, often through a structured walkthrough, and the output is verified.
Requirements the following are the characteristics that make up quality requirements and designs atomic requirements are described and grouped in such a way as to standalone independent of other requirements. Complete requirements contain enough information to guide further work. The completeness of the requirement depends on where the Business Analyst is in the process and the level of details provided. Consistent requirements do not conflict with other requirements and describe the business need on size. Requirements are accurate and reflect the business need. Feasible requirements are possible within the constraints of the budget time and based on the associated risk.
These requirements can move to the stage where they are further described in prototypes and ambiguous are requirements that are described in such a way that all stakeholders understand them. Evaluating ambiguity includes ensuring the requirements meet the business need so the stages involved in verifying requirements are inputs, task and output. The inputs are specified and modeled requirements the task is verifying requirements and the output is verified. Requirements there are nine quality standards for requirements and designs. They should be atomic, complete, consistent, concise, feasible, and ambiguous. Testable, prioritized and understandable. Testable requirements and designs describe a specific outcome based on the level of abstraction. Prioritized requirements are ranked based on the importance of the requirement and the value that it holds. Understandable requirements are communicated in such a way that a specific audience comprehends them.
Limited use of jargon and the use of common business terms have requirements to meet these quality attributes verification ensures organization standards and templates are used properly. Models use notation that is understood by the recipient and reflect organizational standards. Comparing relevant models ensures that models are consistent where elements in one model are also included in other relevant models. The Business Analyst checks for missing elements and ensures that they are consistent with their referencing, and the Business Analyst checks for appropriate language and provides clarifying examples.
Checklists provide guidance to stakeholders, ensuring rigorous assessment of the requirements. They are excellent tools that ensure all elements are reviewed and corrective input is collected. Key characteristics that should be evaluated and ensure quality standards are met so verification activities ensure templates and forms are used properly.
Check that models are complete and understandable. Compare relevant models check for missing elements and consistent referencing and include appropriate clarification examples. Checklists are used to verify requirements. They contain the key characteristics that requirements should have, and they ensure that quality standards are met. A requirement attributes checklist contains four requirements attributes complete, clear and concise feasible, and specifies priority or urgency.