MODULE 2 Flashcards
(16 cards)
Collaborative Requirements Gathering:
Collaborative Requirements Gathering (CRG) is a technique used to gather requirements from stakeholders in a structured, team-oriented way. It involves active participation from both the software engineering team and stakeholders (such as customers, end-users, and other business representatives). The primary goal is to establish a shared understanding of what the system should accomplish and to create a clear, documented set of requirements.
Steps in Collaborative Requirements Gathering:
Identify Stakeholders: Identify the individuals who will provide input, such as users, business managers, developers, and system engineers.
Facilitated Meetings: A neutral facilitator helps guide discussions among stakeholders to ensure that all viewpoints are captured. Meetings follow a structured agenda but remain open to discussions to encourage creative input.
Brainstorming and Listing Requirements: Stakeholders list the requirements they believe are necessary for the system. Each requirement is discussed, elaborated on, and clarified.
Prioritization: Using voting schemes like “priority points,” stakeholders rank requirements to help determine which are most important.
Resolve Conflicts: As stakeholders may have different or conflicting requirements, the group works to resolve these through discussions and negotiations.
Example of Collaborative Requirements Gathering:
For a home security system (SafeHome), a collaborative requirements gathering meeting might include:
A marketing manager, who wants features that can be sold easily.
A product engineer, who focuses on cost-effective design.
An end-user representative, who demands easy-to-use features.
A facilitator manages the meeting to ensure productive discussions.
During the meeting, stakeholders would create lists of necessary features, such as alarms, sensors, and notifications. Through discussions, the group would prioritize features like “Internet-accessible security functions” while addressing issues like security concerns (preventing hacking). Conflicting requirements (e.g., cost vs. functionality) would be negotiated until a consensus is reached
Quality Function Deployment (QFD):
QFD is a customer-driven process used to transform customer needs into engineering characteristics for a product or system. It aims to maximize customer satisfaction by understanding what is valuable to them and ensuring these values are incorporated throughout the engineering process.
QFD works by systematically identifying customer expectations and translating them into measurable design targets, technical requirements, and quality standards.
Types of Requirements in QFD
Normal Requirements: The basic features that the customer expects (e.g., the system must have an alarm function).
Expected Requirements: These are often not stated explicitly but are assumed by customers (e.g., the system must be reliable and easy to use).
Exciting Requirements: Features that exceed customer expectations and provide delight (e.g., an unexpected mobile app that allows users to control the system remotely)
Example of QFD
For the same SafeHome system, customer needs like “easy-to-use alarm system” would be translated into technical specifications such as “user-friendly control panel design” and “interactive mobile app support.” If the system exceeds customer expectations by including facial recognition or voice control for added security, this would be an exciting requirement that could greatly enhance customer satisfaction(@vtucode.in-BCS501-modu…).
QFD focuses on continuous customer feedback to ensure that the design aligns with customer needs, resulting in higher customer satisfaction and a more successful product.
What is a Scenario-Based Model?
A scenario-based model focuses on describing how users (actors) interact with a system through specific scenarios or use cases. These scenarios capture user requirements by outlining the sequence of actions users take to achieve their goals, along with how the system responds.
Key Elements: sbm
Use Cases: These are narratives that describe the interaction between the user and the system.
Actors: Represent entities (users or other systems) interacting with the system.
Primary and Secondary Scenarios: Primary scenarios represent the main use cases, while secondary scenarios capture alternative or exceptional actions.
Activity Diagrams: These diagrams visually represent the flow of activities within a scenario, similar to a flowchart.
Steps to Create a Scenario-Based Model:
Identify Actors: Who will interact with the system?
List Actions: What tasks will the actors perform?
Capture Requirements: What are the functional requirements from the user’s perspective?
Develop Use Cases: Write the interactions that capture how actors achieve their goals.
Example: SafeHome Security System
Consider a home security system called SafeHome. One use case might be the scenario where the Homeowner accesses the system remotely to view camera feeds. The following steps describe the use case:
The Homeowner logs into the system via the Internet.
The system verifies credentials and displays the available cameras.
The Homeowner selects a specific camera to view.
The system streams live footage from the selected camera.
This is a straightforward, scenario-based model, illustrating how the user interacts with the system to achieve a particular goal: viewing camera footage remotely.
Advantages of Scenario-Based Models:
Helps to ensure that the system aligns with user expectations.
Facilitates communication between stakeholders and developers.
Useful for capturing requirements in terms that are easy for non-technical stakeholders to understand
Data Modelling Concepts
Data modeling is the process of defining and analyzing the data involved in a system’s development, ensuring that data structures and their relationships are clearly identified. Data models represent how data objects are stored, processed, and produced within an application, which helps in designing the database and handling complex data requirements.
Key Elements of Data Modelling:
Data Objects: A data object is a composite entity, representing a set of attributes. For example, a data object “Car” might have attributes such as make, model, ID number, body type, color, and owner(@vtucode.in-BCS501-modu…).
Attributes: Attributes describe properties of data objects. For instance, the attributes of a “Car” would include its model, body type, and color(@vtucode.in-BCS501-modu…).
Relationships: Relationships between data objects describe how they interact. For example, a “person” owns a “car,” and a “person” is insured to drive a “car”(@vtucode.in-BCS501-modu…).
Entity-Relationship Diagram (ERD): ERD is a visual representation of data objects and their relationships. In ERDs, entities (data objects) are represented as rectangles, and relationships between them are depicted using connecting lines
Characteristics of Analysis Model in Class-Based Modelling:
Class-based modeling focuses on identifying classes and their relationships. It represents the system’s objects, their operations, and the relationships between them.
Classes and Objects: A class is a blueprint for objects, defining attributes and operations that all objects of the class will have. For example, a “Sensor” class may represent a sensor object in a home security system, with attributes like sensor type and ID, and operations like enable and disable(@vtucode.in-BCS501-modu…).
Attributes: Attributes in a class define the properties of the class’s objects. For instance, a “Sensor” class could have attributes like type and sensitivity level(@vtucode.in-BCS501-modu…).
Operations (Methods): Operations are functions or services that can be applied to objects of a class. For example, a “Sensor” class might include operations like “enable sensor” or “disable sensor”(@vtucode.in-BCS501-modu…).
Relationships: Relationships between classes define how objects of one class interact with objects of another class. For example, a “Homeowner” class may interact with a “Sensor” class through operations that enable or disable the sensor(@vtucode.in-BCS501-modu…).
Collaborations: Collaborations represent how different classes work together to accomplish a task. For example, a “Homeowner” class and a “Sensor” class collaborate in the context of enabling and monitoring the home security system(@vtucode.in-BCS501-modu…).
These concepts form the backbone of both data and class-based modeling in software engineering, ensuring clarity and organization of data and its associated functionalities
- Activity Diagrams:
Activity diagrams graphically represent the flow of interactions within a specific scenario. They are similar to flowcharts and help capture the dynamic aspects of a system by showing the sequence of activities or tasks.
Elements:
Rounded Rectangles: Represent system functions or activities.
Arrows: Indicate the flow from one activity to the next.
Decision Diamonds: Represent choices or decision points, with arrows branching out to show different paths.
Example: In the SafeHome system, an activity diagram for accessing camera surveillance via the internet might include actions like logging in, selecting a camera, and viewing the video feed. The diagram shows the sequence of steps and any decision points (e.g., invalid login) that may occur
Swimlane Diagrams:
Swimlane diagrams are a variation of activity diagrams that indicate which actor or system component is responsible for specific activities. The diagram is divided into vertical or horizontal lanes, with each lane representing an actor or component.
Example: For the SafeHome surveillance system, a swimlane diagram might divide the actions between the Homeowner and the System, showing which tasks each performs.
