Waterfall SDLC and JAD Sessions Flashcards
(33 cards)
What artifacts (documents) have you produced within your previous projects?
Ø Business Requirements Document
Ø System Requirements Document
Ø Functional and Non Functional requirement Documents
Ø Use Cases, and
Ø User Stories
What is a Business Requirements Document?
I write Business Requirement Documents to define the requirements of a business process or a system that needs to support a business process. Business requirements specify “what” the system must do in order to fulfill the requirements of the business.
What is a purpose of the Business Requirements Document?
Ø To gain agreement with stakeholders
Ø To provide a foundation to communicate to a technology service provider whatthe solution needs to do to satisfy the customer’s and business’ needs
Ø To provide input into the next phase for this project
Ø To describe WHAT, not HOW, the business needs will be met by the solution
What do you include within the content of the Business Requirements Document?
Ø Project overview including project charter information, scope, and objectives
Ø Dependencies
Ø Assumptions
Ø Business rules and constraints
Ø As is Business Process
Ø To be Business Process
Ø User Requirements
Ø Risk / Opportunities
Ø Appendix
What is a System Requirements Document?
The SRD or SRD defines “how” the system will accomplish the requirements by outlining the functionality and features that will be supported by the system. It also captures the technical and the database requirements.
What do you include within the content of the System Requirement?
Ø Objectives
Ø In Scope
Ø Out of Scope
Ø Assumptions
Ø Functional Requirements
Ø Non Functional Requirements
Ø Data Requirements
Ø Gap Analysis
Ø Appendix
What are differences between Business and System Requirements?
How are they related?
BRD describes WHAT the application should do. SRD describes HOW the applicationshould do it, and provides step by step details on the functionality provided by the system (Details of the HOW).
Each low level requirement must be traceable back to the high level business requirements, and vice versa.
What are the attributes of a good requirement Document?
Ø Requirements must be SPECIFIC. It cannot be vague.
Ø It must be MEASURABLE/TESTABLE.
Ø It must be AGREED UPON.
Ø It must be REALISTIC.
Ø It must be TIME BOUND.
What is a difference between Functional and Non Functional Requirements?
The functional requirement describes the behavior of the system as it relates to the system’s functionality.
The non-functional requirement elaborates on performance characteristic of the system.
Describe a time when you had to deal with a stakeholder that
just didn’t want to participate in one of your requirements
workshops and tried to sabotage it. What did you do?
Ø If I sense others may be intimidated by the stakeholder’s opinion, I suggest the group do a round-robin and start at the opposite end of the table to the sponsor (so that his/her opinion comes near the end).
Ø It’s easy for requirements-gathering sessions to turn into wish list-gathering sessions, where stakeholders tell me everything they want. My approach isn’t to ignore that information but rather to clearly prioritize what I’ve heard and define what is in scope for the initial launch and what is not.
What makes You effective in gathering the requirements?
Ø I Establish the project definition and scope Early in the project.
Ø I am transparent. Sure, I understand the requirements. And my client understands the requirements. But does my client understand MY understanding of the requirements? After every meeting, I go
through the notes and clean them up – then share them with the project team, including the client.
Ø I Talk To The Right People. Some of my projects had “hidden” stakeholders. Once I ask probing questions in the kickoff and initial meetings with our clients – often find the people that use a system every day but are not the main decision-makers. These people’s buy-in in the project is essential to a successful outcome.
Ø I Get Detailed, and never assume that I understand everything, even if it seems obvious. Success truly is in the details, and I achieve it by asking a lot of questions and not relying on assumptions.
Ø I Focus On Requirements, Not Tools. I am always careful that I am
really focusing on and listening to what my client needs, not what your tool of choice happens to do best. Even when I knew that we were going to be using a certain product, I focus on adapting the product to the user, not the other way around.
Ø Prioritize. It’s easy for requirements-gathering sessions to turn into wishlist-gathering sessions, where stakeholders tell me everything they want. My approach isn’t to ignore that information but rather to clearly prioritize what I’ve heard and define what is in scope for the initial launch and what is not.
How do you keep your JAD Session notes and run the meeting at the same time?
When possible, I use additional staff support to keep the meeting minutes, but if not available, it’s not a problem. During the JAD session, I use the flipcharts extensively, and after the meeting, I keep them for my records. I also ask for permission to voice record the meeting and later go back to the recordings and document the meeting discussions. These notes are later sent to all attendees to confirm or add their comments if needed.
What are the JAD Session meeting deliverables?
Ø First, I aim to define and refine the project’s scope and objectives. This helps ensure that everyone involved has a clear understanding of what we’re trying to achieve.
Ø Secondly, I work on creating detailed functional requirements. This involves breaking down the project into specific features and functionalities, which is crucial for the development team to understand what they need to build.
Ø Additionally, I often produce process models or flowcharts that outline how the system or process should work. This can be in the form of diagrams or written documentation.
Ø Finally, I also aim to establish a consensus among stakeholders. This is important for ensuring that everyone is on the same page and agrees on the project’s direction.
Overall, the primary goal of my JAD
sessions is to facilitate effective communication among stakeholders, resulting in a clear understanding of the project’s requirements and objectives.
What do you do if requirements are complete and there is no enough time but stakeholders want to add more requirements
The new requirements must go through the Change Control Board and get approved to be added to original requirements. The stakeholders must understand that the additional requirements will most probably result in change of scope, thus will impact the time deadline of the project.
What do you do if the stakeholder is talking to you about the design
solution during the requirements gathering phase?
I don’t interrupt his/her statements, but try steer the meeting towards the business needs and away from the technical solution. If the stakeholders keep pushing towards the technical design aspect, I encourage them that we will get into more technical specification details in the later point once we have clear and precise business
requirements. I explain them that our business requirement will drive the technical solution, and I suggest that I’ll involve them in during the system design phase as well
What do you think about challenges faced by Business Analyst?
A common challenge that I deal with is changing requirements. In my experience, I’ve encountered situations where the project scope or business needs shifted mid-way. To handle this, I’ve focused on maintaining open lines of communication with stakeholders,
being adaptable, and documenting changes diligently. This helps ensure that everyone is on the same page and that the project stays on track. Additionally, collaborating with cross-functional teams and learning from their expertise has been valuable in addressing various challenges. It’s all about being flexible, proactive, and a good communicator.
What is Requirements Risk?
Requirements risk is a risk that is associated directly to specific requirements. For example:
Ø Stakeholders deliver poorly articulated statements of requirements and upon receiving requirements from the BA for validation, may reject them as incomplete or incorrect.
Ø Requirements may be overly complex leading to a risk of poor understanding by the development team.
Ø Insufficient time may be allocated to requirements gathering and definition resulting in gaps or errors in requirements.
What do you think about the requirements GAP and how do you
handle it?
I think Requirements GAPs are common challenges, and they can happen when there’s a difference between what the stakeholders expect from a project and what the project team understands. It is very important to bridge these gaps. I’ve encountered a requirements gaps several times in the past. One of the examples is the project when I was working developing a mobile app for XYZ client. The
stakeholders had certain expectations about the app’s features, user experience, and security measures. However, during the initial analysis, it became evident that the development team had a different understanding of these requirements. To address this gap, I
Ø I organized meetings and workshops to bring together the stakeholders and the development team. This facilitated open communication and allowed us to clarify any ambiguities in the requirements.
Ø I ensured that all requirements were documented in a clear and concise manner. This included creating detailed use cases, user stories, and flow diagrams to provide a visual representation of the requirements.
Ø I helped implementing a validation and verification process where both the stakeholders and the development team could review and approve the documented requirements. This step helped identify any remaining gaps or discrepancies.
Ø We also created a prototype of the mobile app to provide a tangible representation of the requirements. This allowed the stakeholders to interact with the app and provide feedback, which further refined the requirements.
Ø Also, throughout the project, I maintained continuous communication with the stakeholders to ensure their expectations were met. Any changes or new requirements were promptly addressed through a change management process.
What do include in your non-functional requirements?
Ø Security
Ø Recovery
Ø Operation (system availability, system support, etc.)
Ø Performance
What is Functional Decomposition Approach?
I break down each Business Requirements into detailed functional requirements that shall decompose based on the functionality’s depth. I use it for projects that require object oriented functional approach, and I usually include the screenshot and markups when possible.
What is use case?
Use Case is a particular example of how a system is used that describes a sequence of interactions between the user and a system. It includes
Ø Title
Ø Description.
Ø Pre-conditions.
Ø Flow of Events which includes Main Flow, Alternative Flow, and Exception flow.
Ø Post Conditions
Ø Field Specific Error Messages
What types of the functional requirements have you created?
Ø Functional Decomposition
Ø Use Cases, and
Ø User Stories
What are the differences between the Alternate Flow and
Exception Flow?
Ø An Alternate Flow is a step or a sequence of steps that achieves the use case’s goal following different steps than described in the main success scenario. But the goal is achieved finally.
Ø An Exception is anything that leads to NOT achieving the use case’s goal.
What is use case diagram and why is it significant? How is it
different form the context diagram?
Both the Context and Use Case diagrams are essential in understanding and designing systems, but I use them to serve slightly different purposes. In a nutshell, Context diagrams gives my audience the broader view of WHO or WHAT the system is connecting with, while Use Case diagrams delve into the details of how these interactions occur within your system.
I see the difference is that while a use case diagram focuses on the interactions between users or external systems and the system you’re building, the context diagram is more about the external entities that interact with your system. It’s kind of like the big picture view. In a context diagram, I typically put my system in the center, and all the external entities (like other systems or users) surrounding it, showing how they connect and interact with your system.
