Waterfall SDLC and JAD Sessions Flashcards
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 Document 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 what the 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 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 application should 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 defining 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 within 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 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 defining 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 project deadline.
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.
