Chapter 4 Gathering User Requirements PDF

Chapter 4. Gathering user requirements 4.1. Putting together requirements gathering team 4.2. Fundamental requirements gathering techniques 4.2.1. Essential Use Case Modeling 4.2.2. Essential User Interface Prototyping 4.2.3. Domain modeling with class responsibility collaborat...

Chapter 4. Gathering user requirements 4.1. Putting together requirements gathering team 4.2. Fundamental requirements gathering techniques 4.2.1. Essential Use Case Modeling 4.2.2. Essential User Interface Prototyping 4.2.3. Domain modeling with class responsibility collaborator (CRC) cards 4.2.4. Developing a supplementary Specification 4.2.5. Identifying Change Cases 4.3. Ensuring Your Requirements Are correct: Requirement validation Techniques 4.3.1. Testing Early and Often 4.3.2. Use Case Scenario Testing  4.1. Putting together requirements gathering team After placing organized the requirements gathering team, you want to ensure that the group is collected from individuals with a diverse skill set and expertise to capture the full scope of the project’s needs. This team will be responsible for collecting, documenting, and analyzing business, user, and technical requirements. Here’s a step-by-step approach to assembling an effective requirements gathering team: 1. Identify the Key Roles The team Composition for a Software Development Project for a requirements gathering team will typically include people with various skills and roles like:  Project Manager (PM) – Ensures the process stays on track. Business Analyst (BA) – Gathers and documents business needs. Technical Architect – Provides insight on technical feasibility and constraints. Subject Matter Experts (SMEs) – Represent business units (e.g., Marketing, Sales, Finance). End Users – Provide insights into usability and user experience. QA Lead – Helps define testable requirements. Compliance Officer (if necessary) – Ensures legal/regulatory requirements are met. 2. Define the Scope and Purpose of the Requirements Gathering: these includes Type of project: Stakeholders: Methodology: 3. Select Team Members Based on Expertise: skill and experience,stalkholder representation 4. Foster Collaboration Across Disciplines: Create a collaborative atmosphere where team members from different backgrounds and skill sets can exchange ideas. 5. Assign Clear Roles and Responsibilities: 6. Incorporate Feedback Mechanisms 7. Use Tools for Documentation and Tracking 8. Plan for Continuous Review and Refinement  4.2. Fundamental requirements gathering techniques 4.2.1. Essential Use Case Modeling An essential use case is a structured narrative, expressed in the language of the application domain and users: comprising a simplified, generalized, abstract, technology-free and implementation independent. description of one task or interaction that is complete, meaningful, and well-defined from the point of view of users in some role or roles in relation to a system and that embodies the purpose or intentions underlying the interaction. an essential use case describes the interaction between the user and the system at a high level of abstraction  The goal of an essential use case is to convey the most important aspects of the user- system interaction by focusing on the user’s intent. and on the observable result of the system without specifying the internal steps. Since an essential use case describes only the most important information it represents a single success scenario. Essential Use Case Modeling is an effective way to model user goals and system interactions at a high level, ensuring that the focus remains on what the system should do rather than how it will be implemented. It serves as a foundation for further elaboration of requirements and eventual system design, keeping stakeholders aligned while minimizing complexity in the early phases of the project.  The following shows an example of essential use case for a certain help desk scenario In the following statement/scenario basic thing that is the actor, the use case and the interactions, and its system responsibilities are listed. Key Benefits of Essential Use Case Modeling Clarity and Focus: It helps define the system’s essential functionality without unnecessary detail, ensuring focus on the user’s needs. Foundation for Communication: Helps stakeholders, users, and developers align on what the system is expected to do, ensuring a shared understanding. Flexibility for Design: By abstracting away implementation details, it allows flexibility in how the functionality is realized later on (e.g., choosing technologies, designing interfaces). 4.2.2. Essential User Interface Prototyping An Essential User Interface Prototyping is a low-fidelity user interface prototype, also known as an abstract prototype or paper prototype, is a simple model, or prototype, of the UI for your system. It represents the general ideas behind the UI, but not the exact details. Low-fidelity UI prototypes represent user interface requirements in a technology independent manner, just as essential use case models do for behavioral requirements. A low-fidelity user interface prototype is effectively the initial state-the beginning point-of the user interface prototype for your system Steps to Create Essential UI Prototypes 1. Define the Core User Flows It is to focus on the key interactions or user flows that are essential to the application’s purpose. Example: For an e-commerce app, the core user flows might include: Browsing and selecting products. Adding products to a shopping cart. Checking out and completing the purchase. 2. Sketch Initial Wireframes Wire framing is the process of creating basic layouts for the user interface: that show where key elements (such as buttons, text fields, and navigation elements) will be placed. 3. Define Interactions defining user interactions that are core to the system’s functionality. For example: What happens when a user clicks a button? How does the system respond when a user navigates between screens? What happens after a user submits a form? 4. Keep It Low-Fidelity focus on making it low-fidelity—don’t worry about making it look perfect or adding visual details. Some key elements of low-fidelity prototypes include: Basic layouts and navigation. Wireframe-style elements such as buttons, text fields, and navigation bars. Simple transitions to show how users move from one step to another. 5. Test with Users and Gather Feedback Conduct Usability Testing: Test the prototype with actual users (or potential users) to see if they can navigate the interface and accomplish the tasks you’ve defined. Focus on Task Success: Measure how easily users can complete the essential tasks. 6. Iterate and Refine Clarify navigation and reduce friction. Enhance core interactions. When a team is creating a low-fidelity user interface prototype, it iterates between the following tasks Explore system usage. Your team will explore system usage via several means. First, you will likely work together on a whiteboard to discuss ideas, work on initial drawing together Second, develop a business use case modeling is an effective technique for understanding the behavioral requirements for your system. Model major user interface elements. Major user interface elements, such as potential screens and reports, can be modeled using flip-chart paper Model minor user interface elements. Minor UI elements, such as input fields, lists, and containers are modeled using sticky notes. Explore the usability of your user interface. Highly usable systems are learnable, they enable user productivity, their use is easy to remember, and they are supportable Example to show Essential UI prototype for enrolling in seminars. The sketches provide a final level of detail than the paper prototypes do, it is much easier to get a feel for how the screen will be implemented from than it is from Figure below: Once you understand the UI needs of your stakeholders the next step is to actually build a prototype. Using a prototyping tool or high-level language you develop the screens, pages, and reports needed by your users. Figure: sample Essential user interface prototype for a student transcript Benefits of Essential UI Prototyping Faster User Feedback: It allows you to quickly test and refine key interactions without investing too much time in visuals. Cost-Effective: Low-fidelity prototypes are cheaper to build, which helps reduce overall project costs. Minimized Risk: By catching usability problems early, you avoid spending time and money on building a UI that may not work for your users. Improved Communication: Prototypes serve as a visual tool that helps bridge the gap between designers, developers, and stakeholders. Encourages Iteration: The low-fidelity nature makes it easy to revise and experiment with different design solutions based on real user input.  4.2.3. Domain modeling with class responsibility collaborator (CRC) cards A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that have been divided into three sections, as depicted in figure below. A class represents a collection of similar objects, a responsibility is something that a class knows or does, and a collaborator is another class that a class interacts with to fulfill its responsibilities A class Represents a collection of similar objects. An object is a person, place, thing, event, or concept that is relevant to the system at hand. For example, in a university system, classes would represent students, professors, and seminars. The name of the class appears across the top of a CRC card It can be a singular noun or singular noun phrase, such as Student, Professor, and Seminar. Class names should also be simple. For example, which name is better: Student or Person who takes seminars? A responsibility It is anything that a class knows or does. For example, students have names, addresses, and phone numbers. These are the things a student knows. Students also enroll in seminars, drop seminars, and request transcripts. These are the things a student does. The things a class knows and does constitute its responsibilities Sometimes a class has a responsibility to fulfill, but not have enough information to do it. For example, as you see in the figure below students enroll in seminars.  To do this, a student needs to know if a spot is available in the seminar and, if so, he then needs to be added to the seminar. However, students only have information about themselves (their names and so forth), and not about seminars. What the student needs to do is collaborate/interact with the card labeled Seminar to sign up for a seminar. Therefore, Seminar is included in the list of collaborators of Student. Figure. Student CRC card.  Collaboration takes one of two forms: A request for information or a request to do something. For example, the card Student requests an indication from the card Seminar whether a space is available, a request for information. Student then requests to be added to the Seminar, a request to do something. Another way to perform this logic, however, would have been to have Student simply request Seminar to enroll himself into itself. Then have Seminar do the work of determining if a seat is available and, if so, then enrolling the student and, if not, then informing the student that he was not enrolled.  So how do you create CRC models? Iteratively perform the following steps: Find classes. Finding classes is fundamentally an analysis task because it deals with identifying the building blocks for your application Find responsibilities. You should ask yourself what a class does as well as what information you wish to maintain about it. You will often identify a responsibility for a class to fulfill a collaboration with another class.  Define collaborators. A class often does not have sufficient information to fulfill its responsibilities. Therefore, it must collaborate (work) with other classes to get the job done. Collaboration will be in one of two forms: a request for information or a request to perform a task. To identify the collaborators of a class for each responsibility ask yourself “does the class have the ability to fulfill this responsibility?”. If not then look for a class that either has the ability to fulfill the missing functionality or the class which should fulfill it.  Move the cards around. To improve everyone’s understanding of the system, the cards should be placed on the table in an intelligent manner. Two cards that collaborate with one another should be placed close together on the table, whereas two cards that don’t collaborate should be placed far apart. Furthermore, the more two cards collaborate, the closer they should be on the desk. By having cards that collaborate with one another close together, it’s easier to understand the relationships between classes.  The coming slide shows A Class Responsibility Collaborator (CRC) model which is a collection of standard index cards that shows the different classes with its responsibility and collaborated class of the university student management system. It’s important to recognize that a CRC model isn’t fixed in stone. When you evolve it into a UML class diagram, or perhaps straight into code, you’ll change the schema over time. Responsibilities will be reorganized, new classes will be introduced, existing classes will disappear, and so on Figure. CRC Model for a university student management system. Benefits of Using CRC Cards Simplifies Design: CRC cards are a simple way to brainstorm and document the design of the system, focusing on the essential aspects of each class. Encourages Collaboration: allowing team members to collaborate and discuss the system design as they create the CRC cards. Focuses on Behavior: Instead of being overly concerned with implementation details, encourage thinking about what each class should do (its responsibilities) and how it will work with other classes to accomplish its tasks. Evolves with the System: flexible and can be easily modified as the system design evolves. Improves Understanding: encourages clear thinking and helps ensure that all team members share a common understanding of the design. 4.2.4. Developing a supplementary Specification A supplementary specification is a document that captures requirements for a system that are not easily captured in use cases. A well-developed Supplementary Specification complements the Functional Specification by addressing non-functional requirements and constraints that affect the design, implementation, and operation of the system. In general it deals with: What it captures: Requirements that are not specific to a use case, such as legal and regulatory requirements, quality attributes, operating systems, and compatibility requirements. What it does: Provides input for the design, verification, and maintenance of a system. What are functional requirements? Functional Requirements are product features or functions that developers must implement to enable users to accomplish their tasks. Generally, functional requirements describe system behavior under specific conditions. Functional requirements examples Functional requirements will vary for different types of software. For example, functional requirements for a website or mobile application should define user flows and various interaction scenarios. The system sends a confirmation email when a new user account is created. The system sends an approval request after the user enters personal information. A search feature allows users to search content/items by entering the query in the search bar. The user can review items in the cart, change their number, or remove them before checkout  The app should allow users to create accounts and log in using credentials like email and password or through social media integration. The app can send notifications to users for updates, reminders, or promotional content. Users should be able to provide feedback or rate services/products within the app. These are some common functional requirements. More specialized software systems will have more specific requirements. For example, a hotel property management system will include such requirements as “the user should be able to view and update room status” or “the system must aggregate bills from all points of service in a folio.” Functional requirements types Functional requirements differ by feature functions they describe. According to this classification approach, we can distinguish the following types of functional requirements. Authentication. This group is about verifying the identity of a user before allowing access to the system, including entering usernames and passwords, biometric verification, or multifactor authentication. Authorization levels. These requirements aim to define and control the access levels of different users within a system. For example, an admin may have complete system access, while a regular user has limited access to certain features. Data processing. These requirements can include data entry, validation, storage, and retrieval.  User interface and user experience These are the requirements related to the design and interaction elements of the system. Their goal is to ensure that it’s user-friendly and meets users’ needs. Reporting. These requirements define generating reports, e.g., data sources, formats, etc. System integration. These requirements describe how the system interacts and integrates with other systems or third-party services. Transaction handling. This group contains requirements for handling transactions. Error handling and logging. These requirements specify how the system should handle errors and log them. Backup and recovery. These are the requirements for data backup and system recovery processes,. What are nonfunctional requirements? Nonfunctional requirements are not related to the system's functionality but rather define how the system should perform. They are crucial for ensuring the system's usability, reliability, and efficiency, often influencing the overall user experience. Nonfunctional requirements examples Some examples of nonfunctional requirements are: The website pages should load in 3 seconds with the total number of simultaneous users