Assessments

Chapter 1 - Identifying Requirements

1. A functional requirement describes what the software product does – that is, use case features visible to users.

A non-functional requirement describes how the software product works – that is, quality attributes/properties that are invisible but can be observed.

2. Some of the non-functional requirements are as follows:
   • Usability
   • Reliability
   • Security
   • Performance
   • Availability
   • Scalability
   • Interfaceable

Chapter 2 - Elicitation and Document Requirements

1. For a medium-complexity functionality, you do it about three times:
   • The first round to understand current processes (automatic or manual) and high-level business needs
   • The second round to dig deep using tools and techniques to probe further to closely understand the real needs
   • The third round to refine your understanding and document them at a high level, review, adjust, and get consensus.
2. The most important tasks are to be able to extract and understand:
   • Known knowns: These are easy to identify. Get as much detail as possible.
   • Known unknowns: The users do not know these clearly; you can help get to them by using various elicitation techniques.
   • Unknown unknowns: The users do not know what they want. They may not even know if they really want it. You can use techniques such as wireframes/prototypes to understand these unknowns.
3. If you diligently follow these tasks, you will be well prepared for effective and productive elicitation sessions:
   • Prepare for the elicitation session
   • Conduct elicitation
   • Confirm/validate business requirements
   • Communicate a summary of requirements and any assumptions
   • Collaborate and make the session engaging and transparent

Chapter 3 - Prioritizing Requirements

1. Conflicting requirements are conflicting if implementing one breaks the other. So, before we can implement any, we need to resolve the conflict. For example, one requirement states, “All service analysts shall be able to view and edit all customer cases,” and another requirement states, “All service analysts in the planning department shall be able to only view customer cases.”
2. The major advantage is that if it is done by a knowledgeable team, you can quickly group requirements into Must, Should, Could, and Would. After you get these into the initial buckets, you can prioritize each bucket using different techniques.

The main disadvantage is that you need knowledgeable SMEs and this technique is subjective. Some team members can wield their power and get their requirements to a higher priority.

3. Requirement prioritization helps the business get the most value for what they truly need so that they can get the benefit at the earliest stage.

Chapter 4 - Process Flows – “As-Is” versus “To-Be”

1. Some of the benefits of the current state process flow are as follows:
   • You can get an awareness of the existing processes
   • You can identify gaps and opportunities
   • You can understand who does what and in which order
   • You can identify missing, repetitive, inconsistent, and redundant steps/tasks
2. Yes. Process flows are snapshots and they keep changing as you add/remove steps in later phases of the project. What you call the “to-be” process flow will be the current state “as-is” process flow for the next phase of the project.

Chapter 5 - Business Requirements Document

1. There are four main types of requirements:
   • Business requirements
   • User requirements (also called stakeholder requirements)
   • Solution requirements (functional and non-functional requirements)
   • Transition requirements
2. Transition requirements are important as they ensure business continuity and are very critical for a project’s success. Examples include data conversions and end user training requirements.

Think of a scenario where you are migrating from a legacy system to a new cloud-based system; you need to plan to migrate legacy data to the cloud. This migrated data should be usable, and users should be able to create and complete transactions effectively.

3. Past project documents such as BRDs, Functional Specification Documents (FSDs), and test scripts/scenarios. The majority of the non-functional requirements can be identified from these artifacts. If your implementation is brand new, refer to best practices or blogs in user communities.

Chapter 6 - Solution Design and Functional Document

1. The following are a few benefits of a good functional document:
   • Helps you understand the features to be developed/tested
   • Provides a clear scope
   • Streamlines the development process
   • Aids in planning and documenting test scripts
2. The following are the three artifacts you may find useful during the solution design phase:
   • Conceptual flow
   • Architectural flow
   • Process flows
3. The following three key participants are required during the solution design phase in addition to you, as a business analyst:
   • Solution/technical architect
   • Technical lead/manager
   • Project manager

Chapter 7 - Demonstrate Functionality Using Prototypes

1. A prototype is used to demonstrate or test chunks of functionality incrementally whereas piloting is operational functionality delivered to a small set of users. If approved, this pilot functionality can be implemented for larger groups.
2. Horizontal prototyping is useful during high-level requirement gathering – for example, the business requirements phase, where all system functions are defined or designed at a high level.

Vertical prototyping is useful during detailed requirements gathering – for example, in a functional design document where we need to capture an entire set of tasks for a function that includes functional and non-functional requirement details.

3. Some of the prototyping techniques include the following:
   • Throwaway
   • Evolutionary
   • Operational
   • Incremental
   • Horizontal
   • Vertical
   • Rapid or dynamic system development

Chapter 8 - Exploring Conference Room Pilots

1. CRPs provide many benefits. Some of them are as follows:
   • Confirm and validate the understanding of business needs
   • Early feedback
   • Opportunities for improvement of the overall solution
   • Innovative ideas and solutions
2. Change control, also referred to as the Change Control Board (CCB), helps manage the scope by approving or rejecting changes to the project/system.
3. When there are resource constraints, you can optimize CRP by ensuring high-impact requirements are given the highest priority.

Chapter 9 - Technical and Quality Testing

1. Here are some automated testing tools:
   • Selenium
   • HPE Micro Focus UFT
   • HPL Software
   • Provar
   • Ranorex
   • TestingWhiz
   • Sahi
   • Waitir
2. These two are completely different. Re-testing deals with test cases that failed earlier during testing and after fixing. Regression testing is done on passed test cases and is for entire functionality to be checked for unexpected side effects, aiming for no additional problems to be introduced.
3. User acceptance testing, regression testing, and system testing are some examples of blackbox testing. This method of testing lets the user test functionality of the software without the ability to see the internal details such as how it was coded.

Chapter 10 - Requirements Traceability Matrix

1. Forward traceability helps us to ensure that we are building the solution/functionality correctly.
2. Backward traceability ensures that we are building the right solution/functionality. It traces back from test case -> test script -> design spec -> functional spec -> process flows -> business requirement.
3. True
4. True

Chapter 11 - User Acceptance Testing

1. Some of the types of UAT are as follows:
   • Alpha testing
   • Beta testing
   • Black-box testing
   • Operational testing
2. The following are key activities:
   • Planning
   • Configuring
   • Operating
   • Observing
   • Evaluating

Chapter 12 - Communication and Knowledge Management

1. Examples of formal communications are as follows:
   • Presentations
   • Agendas
   • Meeting minutes
   • Status reports
2. Examples of informal communication are as follows:
   • Chats
   • Social media
   • Emails
   • Side conversations

Chapter 13 - End User Training

1. Some advantages of synchronous training are as follows:
   • Real-time interactions
   • Questions are clarified immediately
   • Helps modulate session delivery
   • Individual attention for those needing extra help
2. Some advantages of asynchronous training are as follows:
   • Anytime, anywhere
   • Ability to revisit content
   • Easy to deliver

Chapter 14 - Post Go-Live Support / User Forums

1. The primary role of production support is to make sure the systems are running efficiently, and that users can use the system effectively.
2. Some of the production support tools are ServiceNow, Jira, Remedy, and Wrike. You can use a simple spreadsheet too!
3. There are three levels:
   • Level 1: Password resets and simple data updates
   • Level 2: Troubleshooting errors and fixing minor bugs
   • Level 3: Advanced-level troubleshooting and root cause analysis (RCA)