Waterfall SDLC and JAD Sessions

Question 1

What artifacts (documents) have you produced within your previous projects?

Answer 1

Ø Business Requirements Document
Ø System Requirements Document
Ø Functional and Non Functional requirement Documents
Ø Use Cases, and
Ø User Stories

Question 2

What is a Business Requirements Document?

Answer 2

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.

Question 3

What is a purpose of the Business Requirements Document?

Answer 3

Ø 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

Question 4

What do you include within the content of the Business Requirements Document?

Answer 4

Ø 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

Question 5

What is a System Requirements Document?

Answer 5

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.

Question 6

What do you include within the content of the System Requirement?

Answer 6

Ø Objectives
Ø In Scope
Ø Out of Scope
Ø Assumptions
Ø Functional Requirements
Ø Non Functional Requirements
Ø Data Requirements
Ø Gap Analysis
Ø Appendix

Question 7

What are differences between Business and System Requirements?
How are they related?

Answer 7

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.

Question 8

What are the attributes of a good requirement Document?

Answer 8

Ø 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.

Question 9

What is a difference between Functional and Non Functional Requirements?

Answer 9

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.

Question 10

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?

Answer 10

Ø 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.

Question 11

What makes You effective in gathering the requirements?

Answer 11

Ø 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.

Question 12

How do you keep your JAD Session notes and run the meeting at the same time?

Answer 12

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.

Question 13

What are the JAD Session meeting deliverables?

Answer 13

Ø 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.

Question 14

What do you do if requirements are complete and there is no enough time but stakeholders want to add more requirements

Answer 14

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.

Question 15

What do you do if the stakeholder is talking to you about the design
solution during the requirements gathering phase?

Answer 15

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

Question 16

What do you think about challenges faced by Business Analyst?

Answer 16

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.

Question 17

What is Requirements Risk?

Answer 17

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.

Question 18

What do you think about the requirements GAP and how do you
handle it?

Answer 18

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.

Question 19

What do include in your non-functional requirements?

Answer 19

Ø Security
Ø Recovery
Ø Operation (system availability, system support, etc.)
Ø Performance

Question 20

What is Functional Decomposition Approach?

Answer 20

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.

Question 21

What is use case?

Answer 21

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

Question 22

What types of the functional requirements have you created?

Answer 22

Ø Functional Decomposition
Ø Use Cases, and
Ø User Stories

Question 23

What are the differences between the Alternate Flow and
Exception Flow?

Answer 23

Ø 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.

Question 24

What is use case diagram and why is it significant? How is it
different form the context diagram?

Answer 24

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.

Question 25

What is UML modeling?

Answer 25

UML stands for Unified Modeling Language. It is the standard in the industry for visualizing, documenting and constructing various components of a system.

Question 26

What is the purpose of requirements traceability?

Answer 26

RTM enables users to find the origin of each requirement and track every change that was made to this requirement. Traceability starts within the BRD, and traces down to System Requirements, Functional Requirements, and the Test Cases.

Question 27

What UML diagrams do you know?

Answer 27

Context Diagram, Use Case Diagram, Activity Diagram, State Chart, Sequence Diagram

Question 28

If the QA tester feels like the requirements are incomplete and
give it back to you what would you do?

Answer 28

First, I would discuss this with the QA to understand his/her take on the GAP in the requirements. I’ll look at this from the tester perspective- and see if I have an answer to tester’s concern. If I can address the issue, I’ll update the requirements and get approval
from the Business. In case I don’t have an answer, I’ll meet with business and technical staff to find solution and document it.

Question 29

How do you know which techniques to use to gather the
requirements?

Answer 29

I would employ a combination of several effective techniques to gather requirements.
Ø First and foremost, client interviews would be a key strategy. I like interviews as I think they are invaluable in gaining insights directly from our stakeholders, and helps to allowing us to understand their needs, preferences, and expectations.
Ø Additionally, I would suggest utilizing workshops as another essential tool. Workshops bring together various stakeholders, fostering collaboration and ensuring that we collect diverse perspectives and insights. This interactive
approach can lead to rich and well-defined requirements.
Ø Moreover, I’d consider creating prototypes as a means to further refine our requirements. Prototypes are a visual representation of what the end product might look like, and they can serve as a valuable communication tool to ensure that everyone is on the same page regarding the project’s direction. By combining these techniques - client interviews, workshops, and prototypes - we can
ensure that our requirements gathering process is thorough and comprehensive, ultimately leading to the successful execution of our projects.

Question 30

Have you done testing previously?

Answer 30

Yes, I have been involved in Functional and UAT testing. I’ve used several bug tracking tools, including Jira, SharePoint and Bugzilla.

Question 31

What is UAT testing?

Answer 31

User Acceptance Testing (UAT) - is a phase of software development in which the software is tested by the end user. I am always heavily involved in UAT testing, making sure that the software meets client’s expectations.

Question 32

How to write test cases (Example of test case)?

Answer 32

There is no particular formula for writing the test case. Basic elements used in the test case are:
Ø Test case number: 1 OR 1.1
Ø Test Case Name: Login Verification
Ø Test case Description: Enter Login credentials, Click on “login” button.
Ø Test Case Expected Result: Verify that user is successfully login to “Home” page.
Ø Test Case Actual Result: Use is able to login
Ø Test Case Status: Pass or Fail.
Ø Comments: If test case is fail then you can write why it is failed. Also you can write bug number here which you are going to be reporting.

Question 33

What was your involvement with UAT testing?

Answer 33

I always tend to work very closely with QA team to ensure that they understand the requirements, and provide adequate testing.
1. I review the test plan, and discuss it with QA lead and Project manager to make sure that the test acceptance criteria, scope and test methodologies are in accordance with the requirements document.
2. Once the QA team is completed writing the test cases, I work with the testers to trace each requirement to the appropriate test cases. This gets documented in the Requirements Traceability Matrix.
3. When the QA team starts executing the tests, I receive and review daily test reports and discuss it with QA team if I have any suggestions/concerns.
4. Close to completion of the QA testing phase, I tend to create the UAT Test Plan that documents the strategy that will be used to verify and ensure an application meets its requirements to the business. This plan is provided to User to give them a guidance of how the UAT test will be conducted.
5. I also create the UAT test cases, and provide them to the Business Users right before the UAT testing gets started. It helps the Business team to test the application thoroughly. This also helps ensure that the UAT testing provides sufficient coverage of all the UAT scenarios.