Module 4: System Integration and Architecture PDF

SYSTEM INTEGRATION AND ARCHITECTURE 1 MODULE 4: Learning Objectives: 1. Define requirement analysis 2. Identify and described the types of requirements 3. Understand the importance of requirements analysis 4. Define what is requirement elicitation 5. Enumerate and unde...

SYSTEM INTEGRATION AND ARCHITECTURE 1 MODULE 4: Learning Objectives: 1. Define requirement analysis 2. Identify and described the types of requirements 3. Understand the importance of requirements analysis 4. Define what is requirement elicitation 5. Enumerate and understand the concept of nine types of requirements documents. Requirements Requirement Analysis Requirements Analysis, also called Requirement Engineering, is the process of determining the expectations of the users for an application that is to be built or modified. It involves all the tasks that are conducted to identify the needs of different stakeholders. Therefore, requirements analysis means to analyze, document, validate and manage software or system requirements. These requirements, often also called as features, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications. Requirements analysis involves frequent communication with system users to determine specific feature expectations, resolution of conflict or ambiguity in requirements as demanded by the various users or groups of users, avoidance of feature creep and documentation of all aspects of the project development process from start to finish. Energy should be directed towards ensuring that the final system or product conforms to client needs rather than attempting to mold user expectations to fit the requirements. Requirements analysis is a team effort that demands a combination of hardware, software and human factors engineering expertise as well as skills in dealing with people. High-quality requirements are documented, actionable, measurable, testable, traceable, helps to identify business opportunities, and are defined to a facilitate system design. Requirement Analysis is always done in the early phase of any project to ensure that the final product conforms to all the requirements. Requirement Analysis Process A requirements analysis process involves the following steps: Step 1: Identify Key Stakeholders and End-Users The first step of the requirements analysis process is to identify key stakeholders who are the main sponsors of the project. They will have the final say on what should be included in the scope of the project. Next, identify the end-users of the product. Since the product is intended to satisfy their needs, their inputs are equally important. Step 2: Capture Requirements Ask each of the stakeholders and end-users their requirements for the new product.  Here are some requirements analysis techniques that you can use to capture requirements: 1. Hold One-on-One Interviews Interview each stakeholder and end-user individually. This technique will help you gather specific requirements. 2. Use Focus Groups Conduct group interviews or group workshops to understand the flow of information between different stakeholders and end-users. This technique will ensure that there will be no conflict of interest later on during the project. 3. Utilize Use Cases Use cases provide a walkthrough of the entire product through the eyes of the end- user. This technique will help visualize how the product will actually work. 4. Build Prototypes A prototype provides users a sample look and feel of the final product. This technique will help address feasibility issues and identify problems ahead of time. Step 4: Interpret and Record Requirements Once the requirements are categorized, determine which requirements are actually achievable and document each one of them. Here are some techniques to analyze and interpret requirements: Define Requirements Precisely - Ensure that the requirements are clearly worded, sufficiently detailed, and related to business needs. Prioritize Requirements - Prioritize requirements and list them out based on which ones are the “most critical” and which ones are just “nice-to-have”. Carry Out an Impact Analysis - Carry out an impact analysis to make sure that you fully understand the consequences of the requirements. Resolve Conflicts - Arrange a meeting with key stakeholders and resolve conflicting requirements. You can also perform a scenario analysis to explore how the requirements would work for different possible scenarios. Analyze Feasibility - Perform a detailed analysis of the product based on the requirements gathered to determine its reliability and to identify any major problems. Once all the requirements are analyzed, create a detailed written document and circulate it among the key stakeholders, end-users and development teams. Step 5: Sign off Once a final decision is made on the requirements, ensure that you get a signed agreement from the key stakeholders. This is done to ensure that there are no changes or uncontrolled growth in the scope of the project. Requirement Analysis Techniques There are different techniques used for business Requirements Analysis. Here are some requirement analysis techniques: 1- Business process modeling notation (BPMN) This technique is similar to creating process flowcharts, although BPMN has its own symbols and elements. Business process modeling and notation is used to create graphs for the business process. These graphs simplify understanding the business process. BPMN is widely popular as a process improvement methodology. Example: 2- UML (Unified Modeling Language) UML consists of an integrated set of diagrams that are created to specify, visualize, construct and document the artifacts of a software system. UML is a useful technique while creating object-oriented software and working with the software development process. In UML, graphical notations are used to represent the design of a software project. UML also help in validating the architectural design of the software. 3- Flowchart technique A flowchart depicts the sequential flow and control logic of a set of activities that are related. Flowcharts are in different formats such as linear, cross-functional, and top-down. The flowchart can represent system interactions, data flows, etc. Flow charts are easy to understand and can be used by both the technical and non-technical team members. Flowchart technique helps in showcasing the critical attributes of a process. Example 4- Data flow diagram This technique is used to visually represent systems and processes that are complex and difficult to describe in text. Data flow diagrams represent the flow of information through a process or a system. It also includes the data inputs and outputs, data stores, and the various sub-process through which the data moves. DFD describes various entities and their relationships with the help of standardized notations and symbols. By visualizing all the elements of the system, it is easier to identify any shortcomings. These shortcomings are then eliminated in a bid to create a robust solution. Example: 5- Role Activity Diagrams (RAD) Role-activity diagram (RAD) is a role-oriented process model that represents role-activity diagrams. Role activity diagrams are a high-level view that captures the dynamics and role structure of an organization. Roles are used to grouping together activities into units of responsibilities. Activities are the basic parts of a role. An activity may be either carried out in isolation or it may require coordination with other activities within the role. 6- Gantt Charts Gantt charts used in project planning as they provide a visual representation of tasks that are scheduled along with the timelines. The Gantt charts help to know what is scheduled to be completed by which date. The start and end dates of all the tasks in the project can be seen in a single view. 7- IDEF (Integrated Definition for Function Modeling) Integrated definition for function modeling (IDEFM) technique represents the functions of a process and their relationships to child and parent systems with the help of a box. It provides a blueprint to gain an understanding of an organization’s system. 8- Gap Analysis Gap analysis is a technique which helps to analyze the gaps in performance of a software application to determine whether the business requirements are met or not. It also involves the steps that are to be taken to ensure that all the business requirements are met successfully. Gap denotes the difference between the present state and the target state. Gap analysis is also known as need analysis, need assessment or need-gap analysis. Types of Requirements Clearly defined requirements are essential signs on the road that leads to a successful project. They establish a formal agreement between a client and a provider that they are both working to reach the same goal. High-quality, detailed requirements also help mitigate financial risks and keep the project on a schedule. According to the Business Analysis Body of Knowledge (BABOK) definition, requirements are a usable representation of a need. Creating requirements is a complex task as it includes a set of processes such as elicitation, analysis, specification, validation, and management. BABOK, which is a recognized set of business analysis industry standards, offers the following classification of requirements. 1. Business requirements These include high-level statements of goals, objectives, and needs. Business requirements do not include any details or specific features. They just state the problem and the business objective to be achieved such as: increased revenue/throughput/customer reach, reduced expenses/errors, improved customer service, etc. 2. User (stakeholder) requirements The needs of discrete stakeholder groups (top-level managers, non-management staff, customers, etc.) are specified to define what they expect from a particular solution. This group serves as a bridge between the generalized business requirements and specific solution requirements. They are outlined in a User Requirements Specification and can include, for example, ability to create various reports, view order history and status, manage customer databases, etc. 3. Solution requirements Solution requirements describe specific characteristics that a product must have to meet the needs of the stakeholders and the business itself. They fall into two large groups. Functional requirements define what a product must do, what its features and functions are. Also, functional requirements are product features or functions that developers must implement to enable users to accomplish their tasks. It is important to make them clear both for the development team and the stakeholders. Generally, functional requirements describe system behavior under specific conditions. For example: The system sends an approval request after the user enters personal information. A search feature allows a user to hunt among various invoices if they want to credit an issued invoice. The system sends a confirmation email when a new user account is created. Nonfunctional requirements describe the general properties of a system. They are also known as quality attributes. Nonfunctional requirements are not related to the system functionality, rather define how the system should perform. For example: The website pages should load in 3 seconds with the total number of simultaneous users